[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using a custom device tree file

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:


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

There's the README for flash-kernel in

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

Attachment: signature.asc
Description: PGP signature

Reply to: