Using a custom device tree file

[Rainer Dorsch]

Hello,

I try to use a custom device tree file, but uEnv.txt does not have any effect:

***@mohot:~$ cat /boot/uEnv.txt
fdtfile=imx6dl-hummingboard-spi.dtb
***@mohot:~$ fdtdump /boot/dtbs/4.14.0-3-armmp/imx6dl-hummingboard-spi.dtb|grep
model

**** fdtdump is a low-level debugging tool, not meant for general use.
**** If you want to decompile a dtb, you probably want
**** dtc -I dtb -O dts <filename>

model = "SolidRun HummingBoard Solo/DualLite SPI enabled";
model = "On-board Codec";
model = "On-board SPDIF";
***@mohot:~$ cat /proc/device-tree/model
SolidRun HummingBoard Dual/***@mohot:~$

Do I need to run flash-kernel or something else that uEnv.txt has any effect?

Thanks
Rainer

[Vagrant Cascadian]

Post by Rainer Dorsch
fdtfile=imx6dl-hummingboard-spi.dtb

...

Post by Rainer Dorsch
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

[Rainer Dorsch]

Post by Vagrant Cascadian

Post by Rainer Dorsch
fdtfile=imx6dl-hummingboard-spi.dtb

...

Post by Rainer Dorsch
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.
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]

Hello,

Post by Rainer Dorsch

Post by Vagrant Cascadian

Post by Rainer Dorsch
fdtfile=imx6dl-hummingboard-spi.dtb

...

Post by Rainer Dorsch
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.
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

[Vagrant Cascadian]

Post by Rainer Dorsch

Post by Rainer Dorsch

Post by Vagrant Cascadian
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?

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

Post by Rainer Dorsch
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.

Post by Rainer Dorsch
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*

Post by Rainer Dorsch
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

[Gene Heskett]

Post by Vagrant Cascadian

Post by Rainer Dorsch

Am Sonntag, 11. Februar 2018, 13:20:07 CET schrieb Vagrant

Post by Vagrant Cascadian
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
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
/etc/flash-kernel/bootscript/
So you could edit the script to do whatever you want.

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

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

Post by Rainer Dorsch
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*

Post by Rainer Dorsch
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.

Post by Vagrant Cascadian
live well,
vagrant

Take care, Gene

[Vagrant Cascadian]

...

Post by Gene Heskett
Thank you very very much, this is probably the post, a howto, that I've
been looking for, for months.

Glad it was helpful.

Post by Gene Heskett
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.

Post by Gene Heskett
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.

Post by Gene Heskett
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.

Post by Gene Heskett
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

[Gene Heskett]

Post by Vagrant Cascadian
...

Post by Gene Heskett
Thank you very very much, this is probably the post, a howto, that
I've been looking for, for months.

Glad it was helpful.

Post by Gene Heskett
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.

Post by Vagrant Cascadian
You can sometimes grab the relevent stanzas from newer versions and
use them on the old version of flash-kernel by adding them to

I'd imagine so.

Post by Vagrant Cascadian
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.

Post by Vagrant Cascadian

Post by Gene Heskett
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.

Post by Vagrant Cascadian
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.

Post by Gene Heskett
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?

Post by Vagrant Cascadian

Post by Gene Heskett
Where can I report that?

In Debian, it's often good to report a bug through the Debian Bug
https://www.debian.org/Bugs/Reporting

I'll see about this after I fix dinner for us. Thank you.

Post by Vagrant Cascadian
live well,
vagrant

[ibu ☉ radempa]

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

[Rainer Dorsch]

Hi Vagrant,

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

Post by Vagrant Cascadian
In Debian, using Debian-supplied u-boot and a boot script generated by
flash-kernel, hummingboard/mx6cuboxi variants run a
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 ;-)

Post by Vagrant Cascadian
All the above variants use the uboot-generic boot script, which can be
/etc/flash-kernel/bootscript/
So you could edit the script to do whatever you want.

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

# 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/*
$
if test -n "${fdtfile}"; then
setenv fdtpath dtbs/${fk_kvers}/${fdtfile}
else
setenv fdtpath dtb-${fk_kvers}
fi

Correct?

Post by Vagrant Cascadian
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

Post by Vagrant Cascadian

Post by Rainer Dorsch
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.

Post by Vagrant Cascadian
There's the README for flash-kernel in
/usr/share/doc/flash-kernel/README*

Post by Rainer Dorsch
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....

Post by Vagrant Cascadian
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

[Vagrant Cascadian]

Post by Rainer Dorsch

Post by Vagrant Cascadian

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

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

Post by Rainer Dorsch
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]

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:

***@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.000000000 +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>;
};
+
+&ecspi2 {
+ fsl,spi-num-chipselects = <2>;
+ cs-gpios = <&gpio2 26 1>, <&gpio2 27 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hummingboard_spi>;
+ status = "okay";
+ ***@0x00 {
+ compatible = "spidev";
+ spi-max-frequency = <5000000>;
+ reg = <0>;
+ };
+ ***@0x01 {
+ compatible = "spidev";
+ spi-max-frequency = <5000000>;
+ reg = <1>;
+ };
+};
+
+
+&iomuxc {
+ 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_IO26 0x80000000
+ MX6QDL_PAD_EIM_LBA__GPIO2_IO27 0x80000000
+ >;
+ };
+ };
+};
***@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

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian

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

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

Post by Rainer Dorsch
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