Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
1) Anything missing of the pros and cons of different locations?
2) Are you interested in moving to a standardized location if cross-distro list proposes one?
Feel free to either comment here and/or update the wiki.
Riku
On 21.05.14 13:39, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
Anything missing of the pros and cons of different locations?
Are you interested in moving to a standardized location if
cross-distro list proposes one?
I like the kernel make install one the best. In fact, that was what we wanted to do in the first place, but then ditched it because openSUSE doesn't properly support multi-kernel boot with u-boot yet.
Eventually the idea was to have /boot/dtb be a symlink to /boot/dtb/<default kernel version>, similar to how /boot/uImage and /boot/initrd are symlinks to the currently selected default version.
I would like to maintain the dtb location at /boot, since we can't guarantee availability of /lib during the u-boot phase. For all I care, the rootfs could be btrfs, xfs or whatever you happen to like to use as file system. For /boot we force users to ext3.
Alex
On Wed, 21 May 2014 14:39:28 +0300 Riku Voipio riku.voipio@linaro.org wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
Anything missing of the pros and cons of different locations?
Are you interested in moving to a standardized location if
cross-distro list proposes one?
Feel free to either comment here and/or update the wiki.
Riku
you have the location for Fedora wrong it is /boot/dtb-(kernel version)/
I started a discussion last year to unify it http://lists.linaro.org/pipermail/cross-distro/2013-August/000463.html
Dennis
On 21 May 2014 16:02, Dennis Gilmore dennis@gilmore.net.au wrote:
On Wed, 21 May 2014 14:39:28 +0300 Riku Voipio riku.voipio@linaro.org wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
Anything missing of the pros and cons of different locations?
Are you interested in moving to a standardized location if
cross-distro list proposes one?
Feel free to either comment here and/or update the wiki.
Riku
you have the location for Fedora wrong it is /boot/dtb-(kernel version)/
Fixed.
I started a discussion last year to unify it http://lists.linaro.org/pipermail/cross-distro/2013-August/000463.html
Right I even answered to that thread... This was seeming a bit too familiar.
Riku
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
WRT the use of `uname -r` and DTB as stable ABI, might it be sensible to declare a search path type arrangement? i.e. try /path/with-uname-r/dtb then /path/dtb ? For example people might consider packaging https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.... which doesn't have a uname in it.
- Are you interested in moving to a standardized location if
cross-distro list proposes one?
Installing the dtb for the current platform into some known location easily accessed from bootloaders seems reasonable enough.
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
Ian.
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
From that point of view, there isn't really a "correct DTB for the
platform" because the platform it got installed on may not be the only one it's capable and wanting to boot.
-Andy
Ian.
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't it? In which case a single boot.scr could equally well handle it.
Or is there a separate effort to standardise uboot bootcmd settings as well?
From that point of view, there isn't really a "correct DTB for the platform" because the platform it got installed on may not be the only one it's capable and wanting to boot.
-Andy
Ian.
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 05/22/2014 08:49 AM, Ian Campbell wrote:
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't it? In which case a single boot.scr could equally well handle it.
Or is there a separate effort to standardise uboot bootcmd settings as well?
Yes, there is.
With the "standard U-Boot configuration" (include/config/distro_defaults.h?) header file that Dennis has been working on, identical boot.scr or extlinux.conf content should be able to work on any platform with a U-Boot that enables those options. This isn't upstream yet, but e.g. both Tegra and the Raspberry Pi already implement the options/variables/boot-scripts that will be embodied in distro_defaults.h.
On Thu, 22 May 2014 15:49:17 +0100 Ian Campbell ijc@hellion.org.uk wrote:
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't it? In which case a single boot.scr could equally well handle it.
fedora only provides a unified kernel, a fedora image will boot on any supported soc, though you may need to switch out u-boot for different platforms.
Or is there a separate effort to standardise uboot bootcmd settings as well?
There is an effort to standardise boot environments also.
Dennis
From that point of view, there isn't really a "correct DTB for the platform" because the platform it got installed on may not be the only one it's capable and wanting to boot.
-Andy
Ian.
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 22 May 2014 22:49, Ian Campbell ijc@hellion.org.uk wrote:
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't it?
No... if you consider "multi_v7_defconfig" in mainline that one kernel binary is supporting
CONFIG_ARCH_MVEBU=y CONFIG_ARCH_BCM=y CONFIG_ARCH_BCM_5301X=y CONFIG_ARCH_BCM_MOBILE=y CONFIG_ARCH_BERLIN=y CONFIG_ARCH_HIGHBANK=y CONFIG_ARCH_HI3xxx=y CONFIG_ARCH_KEYSTONE=y CONFIG_ARCH_MXC=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP4=y CONFIG_ARCH_QCOM=y CONFIG_ARCH_MSM8X60=y CONFIG_ARCH_MSM8960=y CONFIG_ARCH_MSM8974=y CONFIG_ARCH_ROCKCHIP=y CONFIG_ARCH_SOCFPGA=y CONFIG_ARCH_SPEAR13XX=y CONFIG_ARCH_STI=y CONFIG_ARCH_SUNXI=y CONFIG_ARCH_SIRF=y CONFIG_ARCH_TEGRA=y CONFIG_ARCH_TEGRA_2x_SOC=y CONFIG_ARCH_TEGRA_3x_SOC=y CONFIG_ARCH_TEGRA_114_SOC=y CONFIG_ARCH_TEGRA_124_SOC=y CONFIG_ARCH_U8500=y CONFIG_ARCH_VEXPRESS=y CONFIG_ARCH_VEXPRESS_CA9X4=y CONFIG_ARCH_VIRT=y CONFIG_ARCH_WM8850=y CONFIG_ARCH_ZYNQ=y
Installing only "correct DTB for the [install] platform" approach will break all that. For that defconfig, you should be installing all the DTB variations for all those supported machines to match the kernel capability. If you're getting the DTBs from outside the kernel, installing them all will solve it, otherwise the kernel should generate the DTB set you need according to the enabled machines and knowing itself which DTBs are related to those and building them.
The major discontiguity stopping it globbing up all the machines is "LPAE or not" forces needing a different kernel binary.
In which case a single boot.scr could equally well handle it.
...
Or is there a separate effort to standardise uboot bootcmd settings as well?
As Stephen says, a few weeks ago I installed Fedora 20 on a Cubiebrick for my own web services, I noticed there is a monster U-Boot script coming with Fedora now that is trying to normalize U-Boot across all the boards (a pretty amazing endeavour actually).
-Andy
From that point of view, there isn't really a "correct DTB for the platform" because the platform it got installed on may not be the only one it's capable and wanting to boot.
-Andy
Ian.
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On Fri, 2014-05-23 at 06:44 +0800, Andy Green wrote:
On 22 May 2014 22:49, Ian Campbell ijc@hellion.org.uk wrote:
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't it?
No... if you consider "multi_v7_defconfig" in mainline that one kernel binary is supporting
I know this.
What I meant was that the boot script on the sd card would be assuming that the bootloader was the Fujitsu one which "knows the right dtb filename for that SoC", and hence would only work on those systems. Unless this knowledge of the right dtb name is to become a standard also...
In which case a single boot.scr could equally well handle it.
...
Or is there a separate effort to standardise uboot bootcmd settings as well?
As Stephen says, a few weeks ago I installed Fedora 20 on a Cubiebrick for my own web services, I noticed there is a monster U-Boot script coming with Fedora now that is trying to normalize U-Boot across all the boards (a pretty amazing endeavour actually).
... which it sounds like it might be.
How do other OSes call their DTB files? I expect they aren't consistent with Linux...
Ian.
On 23 May 2014 14:41, "Ian Campbell" ijc@hellion.org.uk wrote:
On Fri, 2014-05-23 at 06:44 +0800, Andy Green wrote:
On 22 May 2014 22:49, Ian Campbell ijc@hellion.org.uk wrote:
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files
these
days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this
is
the place you can expect to find your device tree files
regardless of
what distribution you choose". Some questions I have here before
we
proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform
to be
installed as /boot/dtb-$(uname -r) as well as the /usr/lib
location.
...
I'm more or less ambivalent about installing all of the possible
DTB
files in a similar location though. I'm not sure what the use case
for
that is. Wouldn't you also need to standardise on the dtb filename
for
each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is
capable
to boot on any of them, since they're all supported by the same
single
kernel binary from the same SD Card, and the bootloader picked out
the
right one for what it happens to be running on. It's very
convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't
it?
No... if you consider "multi_v7_defconfig" in mainline that one kernel binary is supporting
I know this.
What I meant was that the boot script on the sd card would be assuming that the bootloader was the Fujitsu one which "knows the right dtb filename for that SoC", and hence would only work on those systems. Unless this knowledge of the right dtb name is to become a standard
No, as I wrote those systems have a board-specific bootloader on the board, not the OS media, that knows the correct dtb name for the board. There is no 'boot script on the SD card' needed for these kind of SoC.
That setup just requires a standard dir to find the already known dtb filename in and it can boot any OS that put the things in the right places.
Something will need to suggest which kernel to use in multi-kernel case, a symlink would do.
Otherwise it can work on any sd card image for, eg one aimed at uboot and the v7 defconfig, it'll just ignore the uboot bits, grab the right dtb and the kernel from the standard place on the sd card and boot.
-Andy
also...
In which case a single boot.scr could equally well handle it.
...
Or is there a separate effort to standardise uboot bootcmd settings as well?
As Stephen says, a few weeks ago I installed Fedora 20 on a Cubiebrick for my own web services, I noticed there is a monster U-Boot script coming with Fedora now that is trying to normalize U-Boot across all the boards (a pretty amazing endeavour actually).
... which it sounds like it might be.
How do other OSes call their DTB files? I expect they aren't consistent with Linux...
Ian.
On Fri, 2014-05-23 at 15:44 +0800, Andy Green wrote:
What I meant was that the boot script on the sd card would be
assuming
that the bootloader was the Fujitsu one which "knows the right dtb filename for that SoC", and hence would only work on those systems. Unless this knowledge of the right dtb name is to become a standard
No, as I wrote those systems have a board-specific bootloader on the board, not the OS media, that knows the correct dtb name for the board. There is no 'boot script on the SD card' needed for these kind of SoC.
My main point was that the fact that this works with some particular configuration which Fujitsu happens to use doesn't mean that it will work everywhere unless there is some sort of standardisation going on in this area, tailoring something to work with the Fujitsu setup is not all that useful.
Ian.
On 23 May 2014 16:34, Ian Campbell ijc@hellion.org.uk wrote:
On Fri, 2014-05-23 at 15:44 +0800, Andy Green wrote:
What I meant was that the boot script on the sd card would be
assuming
that the bootloader was the Fujitsu one which "knows the right dtb filename for that SoC", and hence would only work on those systems. Unless this knowledge of the right dtb name is to become a standard
No, as I wrote those systems have a board-specific bootloader on the board, not the OS media, that knows the correct dtb name for the board. There is no 'boot script on the SD card' needed for these kind of SoC.
My main point was that the fact that this works with some particular configuration which Fujitsu happens to use doesn't mean that it will work everywhere unless there is some sort of standardisation going on in this area, tailoring something to work with the Fujitsu setup is not all that useful.
Yes I agree. But no tailoring is being asked for,
it's an example of a setup where you can move one SD card around between different SoC systems using same kernel and multiple dtb.
I gave that example because you asked for use-cases where it was useful dumping all the DTBs on the card instead of the DTB matching the system it was installed on.
-Andy
Ian.
On Fri, 2014-05-23 at 16:40 +0800, Andy Green wrote:
On 23 May 2014 16:34, Ian Campbell ijc@hellion.org.uk wrote:
On Fri, 2014-05-23 at 15:44 +0800, Andy Green wrote:
What I meant was that the boot script on the sd card would be
assuming
that the bootloader was the Fujitsu one which "knows the right dtb filename for that SoC", and hence would only work on those systems. Unless this knowledge of the right dtb name is to become a standard
No, as I wrote those systems have a board-specific bootloader on the board, not the OS media, that knows the correct dtb name for the board. There is no 'boot script on the SD card' needed for these kind of SoC.
My main point was that the fact that this works with some particular configuration which Fujitsu happens to use doesn't mean that it will work everywhere unless there is some sort of standardisation going on in this area, tailoring something to work with the Fujitsu setup is not all that useful.
Yes I agree. But no tailoring is being asked for,
it's an example of a setup where you can move one SD card around between different SoC systems using same kernel and multiple dtb.
I gave that example because you asked for use-cases where it was useful dumping all the DTBs on the card instead of the DTB matching the system it was installed on.
I did yes, sorry, got confused with other subthreads!
Ian.
On 05/23/2014 02:41 AM, Ian Campbell wrote:
How do other OSes call their DTB files? I expect they aren't consistent with Linux...
The VxWorks example I was given a while ago (so I can try and not break booting them in U-Boot) for am335x follows the Linux names, and I think FreeBSD does as well.
That said, as I was saying at ELC during the BoF, at this time at least the contents (for FreeBSD, haven't deconstructed the VxWorks ones) are different.
On Fri, 23 May 2014 07:41:30 +0100 Ian Campbell ijc@hellion.org.uk wrote:
On Fri, 2014-05-23 at 06:44 +0800, Andy Green wrote:
On 22 May 2014 22:49, Ian Campbell ijc@hellion.org.uk wrote:
On Thu, 2014-05-22 at 20:52 +0800, Andy Green wrote:
On 22 May 2014 17:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different
locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
...
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
For installs on eg, an SD Card, there's nothing stopping the one SD Card being usable on multiple different SoC platforms if the bootloader will allow it.
For example Fujitsu have various SoC with bootloader in HSSPI NOR, which knows the right dtb filename for that SoC.
So if all the dtbs are in /boot/whatever, that same SD Card is capable to boot on any of them, since they're all supported by the same single kernel binary from the same SD Card, and the bootloader picked out the right one for what it happens to be running on. It's very convenient.
But such an sd card would only work on these Fujitsu SoCs, wouldn't it?
No... if you consider "multi_v7_defconfig" in mainline that one kernel binary is supporting
I know this.
What I meant was that the boot script on the sd card would be assuming that the bootloader was the Fujitsu one which "knows the right dtb filename for that SoC", and hence would only work on those systems. Unless this knowledge of the right dtb name is to become a standard also...
no it should be ingrained in u-boot and ideally people use extlinux.conf but if they use boot.scr they make sure and call into u-boots variables for memory locations and dtb file names
In which case a single boot.scr could equally well handle it.
...
Or is there a separate effort to standardise uboot bootcmd settings as well?
As Stephen says, a few weeks ago I installed Fedora 20 on a Cubiebrick for my own web services, I noticed there is a monster U-Boot script coming with Fedora now that is trying to normalize U-Boot across all the boards (a pretty amazing endeavour actually).
... which it sounds like it might be.
How do other OSes call their DTB files? I expect they aren't consistent with Linux...
Ian.
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On Thu, 22 May 2014 10:50:48 +0100 Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location.
WRT the use of `uname -r` and DTB as stable ABI, might it be sensible to declare a search path type arrangement? i.e. try /path/with-uname-r/dtb then /path/dtb ? For example people might consider packaging https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.... which doesn't have a uname in it.
- Are you interested in moving to a standardized location if
cross-distro list proposes one?
Installing the dtb for the current platform into some known location easily accessed from bootloaders seems reasonable enough.
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
u-boot 2014.04 added an option to the syslinux config support for a fdtdir entry which is a directory where u-boot can find the dtbs it relies on the platforms u-boot having a variable fdtfile to know which file to load for the platform
the syslinux config file is looked for in /boot/extlinux/extlinux.conf and /extlinux/extlinux.conf
contents is
timeout 20 totaltimeout 9000
default=Fedora (3.15.0-0.rc5.git2.9.fc21.armv7hl) 21 (Rawhide) label Fedora (3.15.0-0.rc5.git3.1.fc21.armv7hl) 21 (Rawhide) kernel /vmlinuz-3.15.0-0.rc5.git3.1.fc21.armv7hl fdtdir /dtb-3.15.0-0.rc5.git3.1.fc21.armv7hl/ append console=ttymxc0,115200 root=UUID=7ee85ed8-de4a-4779-8658-2daed0d35e97 ro rhgb quiet LANG=en_US.UTF-8 initrd /initramfs-3.15.0-0.rc5.git3.1.fc21.armv7hl.img
label Fedora (3.15.0-0.rc5.git2.9.fc21.armv7hl) 21 (Rawhide) kernel /vmlinuz-3.15.0-0.rc5.git2.9.fc21.armv7hl fdtdir /dtb-3.15.0-0.rc5.git2.9.fc21.armv7hl/ append console=ttymxc0,115200 root=UUID=7ee85ed8-de4a-4779-8658-2daed0d35e97 ro rhgb quiet LANG=en_US.UTF-8 initrd /initramfs-3.15.0-0.rc5.git2.9.fc21.armv7hl.img
So in theory you can pull a sdcard or hdd from one machine and boot it in another, in practice as so many vendors do not ship u-boot on some kind of local storage you need to put the right u-boot into the disk first.
Dennis
On Thu, 2014-05-22 at 08:24 -0500, Dennis Gilmore wrote:
u-boot 2014.04 added an option to the syslinux config support for a fdtdir entry which is a directory where u-boot can find the dtbs it relies on the platforms u-boot having a variable fdtfile to know which file to load for the platform
Thanks, this is looking like something which might actually motivate this sort of change.
Although the extlinux.conf entry is itself distro specific and could easily refer to a distro specific path.
the syslinux config file is looked for in /boot/extlinux/extlinux.conf and /extlinux/extlinux.conf
contents is
timeout 20 totaltimeout 9000
default=Fedora (3.15.0-0.rc5.git2.9.fc21.armv7hl) 21 (Rawhide) label Fedora (3.15.0-0.rc5.git3.1.fc21.armv7hl) 21 (Rawhide) kernel /vmlinuz-3.15.0-0.rc5.git3.1.fc21.armv7hl fdtdir /dtb-3.15.0-0.rc5.git3.1.fc21.armv7hl/ append console=ttymxc0,115200 root=UUID=7ee85ed8-de4a-4779-8658-2daed0d35e97 ro rhgb quiet LANG=en_US.UTF-8 initrd /initramfs-3.15.0-0.rc5.git3.1.fc21.armv7hl.img
label Fedora (3.15.0-0.rc5.git2.9.fc21.armv7hl) 21 (Rawhide) kernel /vmlinuz-3.15.0-0.rc5.git2.9.fc21.armv7hl fdtdir /dtb-3.15.0-0.rc5.git2.9.fc21.armv7hl/ append console=ttymxc0,115200 root=UUID=7ee85ed8-de4a-4779-8658-2daed0d35e97 ro rhgb quiet LANG=en_US.UTF-8 initrd /initramfs-3.15.0-0.rc5.git2.9.fc21.armv7hl.img
So in theory you can pull a sdcard or hdd from one machine and boot it in another, in practice as so many vendors do not ship u-boot on some kind of local storage you need to put the right u-boot into the disk first.
Yes, that is a bit of a pain isn't it. Often in these cases I suspect the u-boot end (presumably containing $fdtfile) is on the sdcard too.
Ian.
On 22 May 2014 12:50, Ian Campbell ijc@hellion.org.uk wrote:
On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote:
Hi,
I've collected a list of where people install their dtb files these days;
https://wiki.linaro.org/Platform/DeviceTreeConsolidation
Every distribution has a slightly different variation of install location, which is not good - we can't tell end users that "this is the place you can expect to find your device tree files regardless of what distribution you choose". Some questions I have here before we proceed discussing what would be the standardized location:
- Anything missing of the pros and cons of different locations?
FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location. WRT the use of `uname -r` and DTB as stable ABI, might it be sensible to declare a search path type arrangement? i.e. try /path/with-uname-r/dtb then /path/dtb ? For example people might consider packaging
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.... doesn't have a uname in it.
In the wikipage I suggested we might want to use a version string instead of uname -r, if we move forward to separate repository. A search path is bit over-engineering. We might suggest making dtb/ -> dtb-latest symlink the same way we often have vmlinuz -> vmlinux-3.x link.
I'd like the to keep the scope on the discussion clear:
The standard place where the distribution package drops compiled device tree files.
Else we end up like the last round where we just discussed what the ideal world would be...
- Are you interested in moving to a standardized location if
cross-distro list proposes one?
Installing the dtb for the current platform into some known location easily accessed from bootloaders seems reasonable enough.
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
Afaik if you use a u-boot with fdtdir option that is kind of the case already.
Ian.
On Thu, 2014-05-22 at 16:27 +0300, Riku Voipio wrote:
On 22 May 2014 12:50, Ian Campbell ijc@hellion.org.uk wrote: On Wed, 2014-05-21 at 14:39 +0300, Riku Voipio wrote: > > Hi, > > I've collected a list of where people install their dtb files these > days; > > https://wiki.linaro.org/Platform/DeviceTreeConsolidation > > > Every distribution has a slightly different variation of install > location, which is not good - we can't tell end users that "this is > the place you can expect to find your device tree files regardless of > what distribution you choose". Some questions I have here before we > proceed discussing what would be the standardized location: > > > 1) Anything missing of the pros and cons of different locations? FWIW Debian will now arrange for the correct DTB for the platform to be installed as /boot/dtb-$(uname -r) as well as the /usr/lib location. WRT the use of `uname -r` and DTB as stable ABI, might it be sensible to declare a search path type arrangement? i.e. try /path/with-uname-r/dtb then /path/dtb ? For example people might consider packaging https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.... which doesn't have a uname in it.
In the wikipage I suggested we might want to use a version string instead of uname -r, if we move forward to separate repository. A search path is bit over-engineering. We might suggest making dtb/ -> dtb-latest symlink the same way we often have vmlinuz -> vmlinux-3.x link.
That would work I suppose.
I'd like the to keep the scope on the discussion clear:
The standard place where the distribution package drops compiled device tree files.
Else we end up like the last round where we just discussed what the ideal world would be...
> 2) Are you interested in moving to a standardized location if > cross-distro list proposes one? Installing the dtb for the current platform into some known location easily accessed from bootloaders seems reasonable enough. I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
Afaik if you use a u-boot with fdtdir option that is kind of the case already.
fdtdir seems to be a cmd_pxe.c thing only.
Isn't most of this stuff hidden in the boot.scr and/or extlinux.conf or whatever anyway? What is the mechanism by which a standardised location for the DTB files becomes necessary?
Ian.
On 22 May 2014 17:47, Ian Campbell ijc@hellion.org.uk wrote:
Isn't most of this stuff hidden in the boot.scr and/or extlinux.conf or whatever anyway? What is the mechanism by which a standardised location for the DTB files becomes necessary?
There is really nothing that makes it "necessary" - it simply a convenience for users and tool writers that regardless of distribution, they can find the device tree files from same place.
Back to track, it Seems everyone agrees in putting dtbs under /boot. The kernel make install location /boot/dtbs/$(uname -r)/ has been preferred (Alex, Paolo), with the other candidate being the fedora location /boot/dtb-$uname -r)/.
Riku
Hi,
On Fri, 2014-05-23 at 12:33 +0300, Riku Voipio wrote:
Back to track, it Seems everyone agrees in putting dtbs under /boot. The kernel make install location /boot/dtbs/$(uname -r)/ has been preferred (Alex, Paolo), with the other candidate being the fedora location /boot/dtb-$uname -r)/.
Just to mention it, petitboot's native config file takes a dtb file path as an argument in the boot option, so any name or location would be OK, so as long as the installer writes the option properly to the config file. It would be nice, but not at all necessary, if the kernel image, initrd and dtb file were all on the same mountable device/partition.
Grub seems to have a devicetree command [1], which I think would take a file path. Petitboot's grub config parser doesn't support this devicetree command currently, but we can add it in easily.
[1] https://wiki.linaro.org/LEG/Engineering/Kernel/GRUB
-Geoff
On Fri, May 23, 2014 at 12:33:28PM +0300, Riku Voipio wrote:
On 22 May 2014 17:47, Ian Campbell ijc@hellion.org.uk wrote:
Isn't most of this stuff hidden in the boot.scr and/or extlinux.conf or whatever anyway? What is the mechanism by which a standardised location for the DTB files becomes necessary?
There is really nothing that makes it "necessary" - it simply a convenience for users and tool writers that regardless of distribution, they can find the device tree files from same place. Back to track, it Seems everyone agrees in putting dtbs under /boot. The kernel make install location /boot/dtbs/$(uname -r)/ has been preferred (Alex, Paolo), with the other candidate being the fedora location /boot/dtb-$uname -r)/.
can we reach a conclusion on this?
is it ok for everyone if we settle on /boot/dtb being a symlink to a distribution dependent location (e.g. /boot/dtbs/$(uname -r) or /boot/dtb-$(uname -r))?
On 13 June 2014 12:54, Paolo Pisati paolo.pisati@canonical.com wrote:
On Fri, May 23, 2014 at 12:33:28PM +0300, Riku Voipio wrote:
On 22 May 2014 17:47, Ian Campbell ijc@hellion.org.uk wrote:
Isn't most of this stuff hidden in the boot.scr and/or extlinux.conf or whatever anyway? What is the mechanism by which a standardised location for the DTB files becomes necessary?
There is really nothing that makes it "necessary" - it simply a convenience for users and tool writers that regardless of distribution, they can find the device tree files from same place. Back to track, it Seems everyone agrees in putting dtbs under /boot. The kernel make install location /boot/dtbs/$(uname -r)/ has been preferred (Alex, Paolo), with the other candidate being the fedora location /boot/dtb-$uname -r)/.
can we reach a conclusion on this?
is it ok for everyone if we settle on /boot/dtb being a symlink to a distribution dependent location (e.g. /boot/dtbs/$(uname -r) or /boot/dtb-$(uname -r))?
I think we can conclude that the kernel make install location: /boot/dtbs/$(uname -r) is the most favored location. I don't think adding a symlink would provide here extra value. If some of the distro's doesn't want to move to the upstream location, it is unlikely they would add the symlink either.
Riku
On Thu, May 22, 2014 at 10:50:48AM +0100, Ian Campbell wrote:
I'm more or less ambivalent about installing all of the possible DTB files in a similar location though. I'm not sure what the use case for that is. Wouldn't you also need to standardise on the dtb filename for each platform and effectively make that ABI?
i thought that was exactly what findfdt() was about: it abstracts all the details about all the different board revisions and upon execution you get the correct dtb file name in the dtbfile variable
FWIW, Ubuntu will soon move the dtbs from /lib/firmware/$(uname -r)/device-tree to /boot/dtbs/$(uname -r), and we already planned to create a shortcut symlink:
/boot/dtb -> /boot/dtbs/$(uname -r)
this or whatever this mailing list picks up.