On 2018-02-17, Rainer Dorsch wrote: > Am Sonntag, 11. Februar 2018, 22:24:51 CET schrieb Rainer Dorsch: >> Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant Cascadian: >> > On 2018-02-11, Rainer Dorsch wrote: >> > Try adding the following to /etc/flash-kernel/ubootenv.d/fdtfile: >> > setenv fdtfile imx6dl-hummingboard-spi.dtb >> > >> > And running flash-kernel to regenerate the boot script. >> >> Thanks for your quick answer Vagrant. >> >> In case I try to boot a broken dtb (kernel does not boot), is there a way >> back to the previous dtb? > > AFAIK there are two ways to tell the kernel where to find the device tree: > -> append to the kernel binary > -> the bootloader handles this during boot and makes it available for the > kernel > > Can anybody tell, which method u-boot in Debian implements (in particular for > the hummingboard)? In Debian, using Debian-supplied u-boot and a boot script generated by flash-kernel, hummingboard/mx6cuboxi variants run a bootscript... flash-kernel defines in /usr/share/flash-kernel/db/all.db: Machine: SolidRun HummingBoard DL/Solo Machine: SolidRun HummingBoard Solo/DualLite Kernel-Flavors: armmp DTB-Id: imx6dl-hummingboard.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools Machine: SolidRun HummingBoard Dual/Quad Kernel-Flavors: armmp DTB-Id: imx6q-hummingboard.dtb Boot-Script-Path: /boot/boot.scr U-Boot-Script-Name: bootscr.uboot-generic Required-Packages: u-boot-tools So, flash-kernel copies the .dtb file listed there to /boot/dtbs/VERSION/ and symlinks /boot/dtb* to the .dtb in the versioned directory, based on the machine name defined in /proc/device-tree/model. All the above variants use the uboot-generic boot script, which can be found and edited on an installed system in: /etc/flash-kernel/bootscript/ So you could edit the script to do whatever you want. > Can anybody tell, if it is possible to configure from u-boot shell to loada > custom device treefile? To manually change it for a one-off boot: # disable the built-in setting of fdtfile setenv findfdt # manually set fdtfile setenv fdtfile /path/to/your/custom.dtb You could, of course, also manually load the kernel, initrd, fdt and use bootz rather than trying to work around the defaults in the boot script. > Is that somewhere documented? The latest documentation on flash-kernelI found > is from 2011... I'm not sure what sort of documentation you're looking for. You can learn about u-boot by looking in the source code for the README, the doc/* files, and of course the source code itself. Many modern boards are using distro_bootcmd, which is documented in doc/README.distro, which has improved the consistancy of behavior of boards. There's the README for flash-kernel in /usr/share/doc/flash-kernel/README* > https://wiki.debian.org/FlashKernelRework Some of the features documented there have been implemented, or don't really apply to modern boards that make use of distro_bootcmd. Now that I'm on a roll and this email is getting really long... I do think we should consider replacing flash-kernel with something else at this point. The tool has grown and evolved all sorts of features; I've never used it to "flash a kernel". I've exclusively used it for purposes other than it's original design (mostly just copying a .dtb and generating a boot script that is essentially re-useable on most boards I use it with). Scalability is a bit questionable; it actually cats the entire contents of all.db and reads it into a variable, and then does "echo $VARIABLE | grep FOO" type things in order to get data out of it. With new sunxi boards coming out what *feels* like twice each week, grepping through an echo'ed variable starts to seem like a bad idea to me. Of course, it also kind of works well enough for what it is... but adding new features is, in my experience, an unpleasant task. And occasionally those new features are really needed with modern changes. I've used u-boot-menu on a handful of boards, although it also currently has some limitations. For example, it doesn't support /boot on a separate partition without manual configuration ... anyone remember the lovely hack "ln -s . /boot/boot" ... well, yeah... using *that* again. It also doesn't handle copying the .dtb into /boot, so I still need flash-kernel for that. And then there's the support for u-boot emulating EFI so you could use grub-efi-*, which has made great progress in recent u-boot versions. But then we could use grub on more platforms ... that would be a nice goal for buster, at least. live well, vagrant
Attachment:
signature.asc
Description: PGP signature