Re: Using a custom device tree file

[Rainer Dorsch]

Hi Vagrant,

I want to use a modified dts file for a Hummingboard, I do enable spidev for 
the spi interfaces:

What I did so far is I created a new file:

rd@master:/mnt/disk/scratch/rd$ diff -u ./debian/kernel/linux-source-4.14/
arch/arm/boot/dts/imx6q-hummingboard.dts ./debian/kernel/linux-source-4.14/
arch/arm/boot/dts/imx6q-hummingboard-spi.dts
--- ./debian/kernel/linux-source-4.14/arch/arm/boot/dts/imx6q-hummingboard.dts  
2018-01-10 09:31:23.0 +0100
+++ ./debian/kernel/linux-source-4.14/arch/arm/boot/dts/imx6q-hummingboard-
spi.dts  2018-02-18 21:29:20.870755691 +0100
@@ -45,7 +45,7 @@
 #include "imx6qdl-hummingboard.dtsi"
 
 / {
-   model = "SolidRun HummingBoard Dual/Quad";
+   model = "SolidRun HummingBoard Dual/Quad spidev enabled";
compatible = "solidrun,hummingboard/q", "fsl,imx6q";
 };
 
@@ -56,3 +56,36 @@
fsl,transmit-atten-16ths = <9>;
fsl,receive-eq-mdB = <3000>;
 };
+
+ {
+   fsl,spi-num-chipselects = <2>;
+   cs-gpios = < 26 1>, < 27 1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_hummingboard_spi>;
+   status = "okay";
+   spidev@0x00 {
+   compatible = "spidev";
+   spi-max-frequency = <500>;
+   reg = <0>;
+   };
+   spidev@0x01 {
+   compatible = "spidev";
+   spi-max-frequency = <500>;
+   reg = <1>;
+   };
+};
+
+
+ {
+   hummingboard {
+   pinctrl_hummingboard_spi: hummingboard_spi {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_OE__ECSPI2_MISO   0x100b1
+   MX6QDL_PAD_EIM_CS1__ECSPI2_MOSI  0x100b1
+   MX6QDL_PAD_EIM_CS0__ECSPI2_SCLK  0x100b1
+   MX6QDL_PAD_EIM_RW__GPIO2_IO260x8000
+   MX6QDL_PAD_EIM_LBA__GPIO2_IO27   0x8000
+   >;
+   };
+   };
+};
rd@master:/mnt/disk/scratch/rd$

and build a new dtb and copied it to 

# cp arch/arm/boot/dts/imx6dl-hummingboard-spi.dtb /boot/dtbs/4.14.0-3-armmp/

and copied it to imx6q-hummingboard.dtb (i.e. overwrote the old supplied dtb 
after making a copy of it).

Introducing a new model name was probably not a good idea, since it breaks the 
upgrade, so I try to go back to the unmodified model name. Then after each 
kernel upgrade I need to go through the manual procedure of rebuilding a new 
modified dtb file do you see a better way to keep spidev enabled?

Thanks
Rainer

On Donnerstag, 8. März 2018 02:04:02 CEST Vagrant Cascadian wrote:
> On 2018-02-19, Rainer Dorsch wrote:
> > Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian:
> >> > 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?
> 
> In the built-in u-boot environment on some boards. Typically with u-boot
> variants that can support multiple similar boards; a single mx6cuboxi
> u-boot binary supports several cubox-i and hummingboard variants.
> 
> It's typically run from bootcmd, so "printenv bootcmd" from the u-boot
> prompt might show something like "run findfdt ; run distro_bootcmd".
> 
> >>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?
> 
> Ah, yes, full path wouldn't work in this case- you'd have to have it in
> one of the above locations the boot scripts look for.
> 
> 
> live well,
>   vagrant


-- 
Rainer Dorsch
http://bokomoko.de/

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-19, Rainer Dorsch wrote:
> Am Samstag, 17. Februar 2018, 16:22:06 CET schrieb Vagrant Cascadian:
>> > 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?

In the built-in u-boot environment on some boards. Typically with u-boot
variants that can support multiple similar boards; a single mx6cuboxi
u-boot binary supports several cubox-i and hummingboard variants.

It's typically run from bootcmd, so "printenv bootcmd" from the u-boot
prompt might show something like "run findfdt ; run distro_bootcmd".


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

Ah, yes, full path wouldn't work in this case- you'd have to have it in
one of the above locations the boot scripts look for.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Rainer Dorsch]

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 

Re: Using a custom device tree file

[ibu ☉ radempa]

Am 2018-02-18 um 01:22 schrieb Vagrant Cascadian:
> 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.

Yes, I'd appreciate grub.

When debugging the boot process with an encrypted rootfs on my Odroid
XU4s I found it very comfortable to be able to easily switch between
boot configurations with grub (which I had thanks to sesse's install
script for XU4). And maybe it's not just me, because one of the usage
scenarios for SBCs will be self-hosted services (think of freedombox),
for which disk encryption can be an issue.

ibu

Re: Using a custom device tree file

[Gene Heskett]

On Sunday 18 February 2018 17:43:11 Vagrant Cascadian wrote:

> On 2018-02-18, Gene Heskett wrote:
> > 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:
>
> ...
>
> > Thank you very very much, this is probably the post, a howto, that
> > I've been looking for, for months.
>
> Glad it was helpful.
>
> > 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,
>
> Please report bugs against flash-kernel, but please first check
> against current versions of flash-kernel. There's support for
> raspberry pi 2b and and 3b in the current version of flash-kernel.
>
2b is listed, but not the 3b in an uptodate yesterday stretch install.

> You can sometimes grab the relevent stanzas from newer versions and
> use them on the old version of flash-kernel by adding them to
> /etc/flash-kernel/db:

I'd imagine so.
>
>   Machine: Raspberry Pi 3 Model B
>   Kernel-Flavors: arm64 armmp armmp-lpae
>   DTB-Id: bcm2837-rpi-3-b.dtb
>   U-Boot-Script-Name: bootscr.uboot-generic
>   Required-Packages: u-boot-tools
>   Boot-Script-Path: /boot/boot.scr
>
>
> I am using the pi 2b with the version of linux and flash-kernel from
> Debian stretch. Raspbian's kernel likely has the legacy device-tree
> names and you might have to adjust flash-kernel configuration for
> that. Raspbian also doesn't typically use u-boot for a bootloader, and
> flash-kernel doesn't do anything to configure booting from the default
> boot firmware.

The machine in question is a pair of 4Gb rock64's.

> > nor the pine offering called the rock64.
>
> There isn't support for the rock64 in mainline u-boot, and I'm not
> sure how good the linux kernel support is.

The existing kernel in an ayufan release is solid, but I need to replace 
it with a local build, on the rockchip, v4.14.15-rt13 kernel.

> So I'm not sure it makes 
> sense to add a flash-kernel entry for it until it's better supported
> in mainline linux and u-boot; Debian doesn't usually add support that
> isn't present in mainline, as long-term maintenance impractical.
>
> I've got one, so I'll keep an eye on it and try to enable support in
> Debian as it becomes available.
>
> > And quite likely, u-boot-tools is also dated.
>
> I'm not sure what you're referring to here, but there's u-boot 2018.01
> in experimental, and 2017.11 in sid/buster. There's a 2018.03-rc1 that
> I haven't yet uploaded.  Stretch has the most recent u-boot version at
> the time of stretch freeze, which was in late 2016, so it only has
> 2016.11. But that's how stable releases work; major new versions of
> software does not typically get added to a stable release.

What do I use for a deb entry in sources.list.d to access this later 
stuffs?
>
> > Where can I report that?
>
> In Debian, it's often good to report a bug through the Debian Bug
> Tracking System:
>
>   https://www.debian.org/Bugs/Reporting
>
I'll see about this after I fix dinner for us.  Thank you.
>
> live well,
>   vagrant



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

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-18, Gene Heskett wrote:
> 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:
...
> Thank you very very much, this is probably the post, a howto, that I've 
> been looking for, for months.

Glad it was helpful.


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

Please report bugs against flash-kernel, but please first check against
current versions of flash-kernel. There's support for raspberry pi 2b
and and 3b in the current version of flash-kernel.

You can sometimes grab the relevent stanzas from newer versions and use
them on the old version of flash-kernel by adding them to
/etc/flash-kernel/db:

  Machine: Raspberry Pi 3 Model B
  Kernel-Flavors: arm64 armmp armmp-lpae
  DTB-Id: bcm2837-rpi-3-b.dtb
  U-Boot-Script-Name: bootscr.uboot-generic
  Required-Packages: u-boot-tools
  Boot-Script-Path: /boot/boot.scr


I am using the pi 2b with the version of linux and flash-kernel from
Debian stretch. Raspbian's kernel likely has the legacy device-tree
names and you might have to adjust flash-kernel configuration for
that. Raspbian also doesn't typically use u-boot for a bootloader, and
flash-kernel doesn't do anything to configure booting from the default
boot firmware.


> nor the pine offering called the rock64.

There isn't support for the rock64 in mainline u-boot, and I'm not sure
how good the linux kernel support is. So I'm not sure it makes sense to
add a flash-kernel entry for it until it's better supported in mainline
linux and u-boot; Debian doesn't usually add support that isn't present
in mainline, as long-term maintenance impractical.

I've got one, so I'll keep an eye on it and try to enable support in
Debian as it becomes available.


> And quite likely, u-boot-tools is also dated.

I'm not sure what you're referring to here, but there's u-boot 2018.01
in experimental, and 2017.11 in sid/buster. There's a 2018.03-rc1 that I
haven't yet uploaded.  Stretch has the most recent u-boot version at the
time of stretch freeze, which was in late 2016, so it only has
2016.11. But that's how stable releases work; major new versions of
software does not typically get added to a stable release.


> Where can I report that?

In Debian, it's often good to report a bug through the Debian Bug
Tracking System:

  https://www.debian.org/Bugs/Reporting


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Gene Heskett]

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 

Re: Using a custom device tree file

[Vagrant Cascadian]

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.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Using a custom device tree file

[Rainer Dorsch]

Hello,

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:
> > > I try to use a custom device tree file, but uEnv.txt does not have any
> > > effect:
> > > 
> > > rd@mohot:~$ cat /boot/uEnv.txt
> > > fdtfile=imx6dl-hummingboard-spi.dtb
> > 
> > ...
> > 
> > > Do I need to run flash-kernel or something else that uEnv.txt has any
> > > effect?
> > 
> > I don't believe the u-boot in Debian or mainline supports uEnv.txt for
> > the hummingboard variants. Or any of the variants supported in Debian's
> > u-boot package, though I haven't looked closely.
> > 
> > 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)? 

Can anybody tell, if it is possible to configure from u-boot shell to loada 
custom device treefile?

Is that somewhere documented? The latest documentation on flash-kernelI found 
is from 2011... https://wiki.debian.org/FlashKernelRework

Thanks
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: Using a custom device tree file

[Rainer Dorsch]

Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant Cascadian:
> On 2018-02-11, Rainer Dorsch wrote:
> > I try to use a custom device tree file, but uEnv.txt does not have any
> > effect:
> > 
> > rd@mohot:~$ cat /boot/uEnv.txt
> > fdtfile=imx6dl-hummingboard-spi.dtb
> 
> ...
> 
> > Do I need to run flash-kernel or something else that uEnv.txt has any
> > effect?
> I don't believe the u-boot in Debian or mainline supports uEnv.txt for
> the hummingboard variants. Or any of the variants supported in Debian's
> u-boot package, though I haven't looked closely.
> 
> 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?

Thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: Using a custom device tree file

[Vagrant Cascadian]

On 2018-02-11, Rainer Dorsch wrote:
> I try to use a custom device tree file, but uEnv.txt does not have any effect:
>
> rd@mohot:~$ cat /boot/uEnv.txt 
> fdtfile=imx6dl-hummingboard-spi.dtb
...
> Do I need to run flash-kernel or something else that uEnv.txt has any effect?

I don't believe the u-boot in Debian or mainline supports uEnv.txt for
the hummingboard variants. Or any of the variants supported in Debian's
u-boot package, though I haven't looked closely.

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.


live well,
  vagrant


signature.asc
Description: PGP signature