On Saturday 17 February 2018 19:22:06 Vagrant Cascadian wrote: > 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. > Thank you very very much, this is probably the post, a howto, that I've been looking for, for months.
Now my problem is that the db for flash-kernel is 2 or 3 years out of date and contains no mention of either the pi-3b, nor the pine offering called the rock64. And quite likely, u-boot-tools is also dated. Where can I report that? Another similar boot composer needs docker, but that doesn't run on stretch for arm64's. Many thanks for more info. > live well, > vagrant Take care, Gene -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>