Hi Vagrant,

many thanks for the comprehensive answer and summary on how flash-kernel works.

Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian:

> 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.

I replaced the dtb file in /boot/dtbs/VERSION/ that worked well. Thank you. 
Also mounting the sdcard and reverting back to the old one worked ;-)

> 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

Where is findfdt defined?

$ grep findfdt /etc/flash-kernel/bootscript/*

>From looking into the bootscr fdtfile needs only the filename:

if test -n "${fdtfile}"; then
   setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
   setenv fdtpath dtb-${fk_kvers}


> 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.

Hmm... not sure how that works, but would be worthwhile to document,. I assume 
I need to do something like

    load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix}
vmlinuz \
    && load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${pathprefix}dtb \
    && load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} ${pathprefix}
initrd.img \
    && echo "Booting Debian from ${devtype} ${devnum}:${partition}..." \
    && bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

I did not find an easy way to boot the .old kernel, just wondering if it would 
make sense to do add a kernelpostfix

load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix}vmlinuz$

and similar for the other lines. Then it would be sufficient to set in the u-
boot shell: kernelpostfix to .old

> > 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.

I have never seen that, thanks for mentioning this.

> 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 did not want to imply replacing flash-kernel....

> 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.

Many thanks for the detailed description, I bookmarked your post in the 
mailing list archive :-)

Does it make sense to paste the big picture in a Debian wiki page (or multiple 
of them) and link the /usr/share/doc/... files?

Thanks a lot again

Rainer Dorsch

Reply via email to