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>

Reply via email to