Re: Using a custom device tree file
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}
else
setenv fdtpath dtb-${fk_kvers}
fi
Correct?
> 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$
{kernelpostfix}
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
--
Rainer Dorsch
http://bokomoko.de/
Reply to: