-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
Regards
Dennis
On Mon, Aug 05, 2013 at 04:41:10PM -0500, Dennis Gilmore wrote:
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
For what hardware are you proposing this? New ones? Or are you saying that we should change hardware that we've already enabled, so now we have two possible locations to consider on those (existing installations and your new standard)?
On 08/05/2013 02:50 PM, Robie Basak wrote:
For what hardware are you proposing this? New ones? Or are you saying that we should change hardware that we've already enabled, so now we have two possible locations to consider on those (existing installations and your new standard)?
I take Dennis's suggestion as a packaging decision: Kernel builds can produce dtbs. Ideally they're stored in a place that uboot can easily load them. Storing them on the same filesystem housing the kernel is a sensible approach in that they are both needed, and both come from the same source. For those who have used some other part of the directory tree (EG, /lib), I'd be curious how it's being used and if that's working well. Perhaps a legacy symlink could be used if the directory is moved.
In Fedora today we're using /boot/dtb-`uname -r` which is a mixed bag.
On 08/05/2013 04:02 PM, Brendan Conoboy wrote: ...
In Fedora today we're using /boot/dtb-`uname -r` which is a mixed bag.
Is that a directory or a single file? I'd hope it's a directory containing files named ${soc}-${board}.dtb, so that I can move my installed disk image between multiple machines.
On 08/05/2013 03:17 PM, Stephen Warren wrote:
On 08/05/2013 04:02 PM, Brendan Conoboy wrote: ...
In Fedora today we're using /boot/dtb-`uname -r` which is a mixed bag.
Is that a directory or a single file? I'd hope it's a directory containing files named ${soc}-${board}.dtb, so that I can move my installed disk image between multiple machines.
Yes, it's a directory with filenames provided by the kernel sources. Generally it's $soc-$board.dtb, but not always.
On 08/05/2013 03:50 PM, Robie Basak wrote:
On Mon, Aug 05, 2013 at 04:41:10PM -0500, Dennis Gilmore wrote:
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
For what hardware are you proposing this? New ones? Or are you saying that we should change hardware that we've already enabled, so now we have two possible locations to consider on those (existing installations and your new standard)?
In almost all cases right now, don't distro packages provide the DTB files, so if a common location is decided upon, you just need to update that package to move the files to the appropriate location.
In other words, when you install a distro, how do the files get onto disk in the first place? The distro is in control of that, in most cases, right?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 05 Aug 2013 16:15:53 -0600 Stephen Warren swarren@wwwdotorg.org wrote:
On 08/05/2013 03:50 PM, Robie Basak wrote:
On Mon, Aug 05, 2013 at 04:41:10PM -0500, Dennis Gilmore wrote:
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
For what hardware are you proposing this? New ones? Or are you saying that we should change hardware that we've already enabled, so now we have two possible locations to consider on those (existing installations and your new standard)?
In almost all cases right now, don't distro packages provide the DTB files, so if a common location is decided upon, you just need to update that package to move the files to the appropriate location.
In other words, when you install a distro, how do the files get onto disk in the first place? The distro is in control of that, in most cases, right?
Other than calxeda the dtbs are shipped by the distro. for pxe booting the dtb files would get placed in /dtb/ in the tftproot along with install kernels and initramfs's but the hardware vendor would be free to ship a dtb and use it.
Dennis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 5 Aug 2013 22:50:24 +0100 Robie Basak robie.basak@ubuntu.com wrote:
On Mon, Aug 05, 2013 at 04:41:10PM -0500, Dennis Gilmore wrote:
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
For what hardware are you proposing this? New ones? Or are you saying that we should change hardware that we've already enabled, so now we have two possible locations to consider on those (existing installations and your new standard)?
I am proposing that ultimately it be the sole location for dtbs. In conjunction with the unified u-boot environment proposal i've put forward u-boot would automatically load and provide the dtb at a known location for us. To simplify things greatly for us. i anticipate as part of the discussion that's covered https://lwn.net/Articles/560523/ the dtbs will be stable and detached from the kernel. we would then only need to install the dtbs in /boot/dtb/ u-boot will handle the rest for us
the known location would be ${fdt_addr} which cmd_pxe will pass on to the boot line as part of pxe booting or local booting using sysboot. and if a distro chooses to use uEnv.txt or boot.scr then they can just pass the variable to bootm or bootz and assume that a dtb is already loaded. The hardware vendor will be able to ship the dtb in local storage or load the copy we ship.
Dennis
On 08/05/2013 02:41 PM, Dennis Gilmore wrote:
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
What follows in the path, just the filename without any version string? DTBs change with time. It's not clear to me that it's always safe to mix and match.
On 08/05/2013 03:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
A symlink-to-the-latest-version doesn't seem that useful. If DTBs are tied to a particular kernel version (and in many cases they are today), then bootloaders/... will *have* to access /boot/dtb-${kernel_version} in order to pick up the correct DTB. As such, /boot/dtb itself won't ever be used.
Related, all of this pre-supposes that the DTBs are stored in the filesystem and installed via distro packages. On some systems (Calxeda?), I believe they're provided by firmware (i.e. are stored in flash), so are already in memory by the time e.g. U-Boot runs, and hence have no disk location.
On 08/05/2013 03:14 PM, Stephen Warren wrote:
Related, all of this pre-supposes that the DTBs are stored in the filesystem and installed via distro packages. On some systems (Calxeda?), I believe they're provided by firmware (i.e. are stored in flash), so are already in memory by the time e.g. U-Boot runs, and hence have no disk location.
They can still have a disk location- you just might not want to load the thing. Really, if all vendors would simply embed the dtb into their firmware that would be ideal. It's not happening, though.
On 08/05/2013 06:17 PM, Brendan Conoboy wrote:
On 08/05/2013 03:14 PM, Stephen Warren wrote:
Related, all of this pre-supposes that the DTBs are stored in the filesystem and installed via distro packages. On some systems (Calxeda?), I believe they're provided by firmware (i.e. are stored in flash), so are already in memory by the time e.g. U-Boot runs, and hence have no disk location.
They can still have a disk location- you just might not want to load the thing. Really, if all vendors would simply embed the dtb into their firmware that would be ideal. It's not happening, though.
Well, is there a recommended standard for doing this? And a follow-up on allowing for overrides or fix-ups to be done easily? I've done some poking about how to have more data be done as part of factory programming and it's both possible and something that they want to understand what's coming in, and have it be something that's know roughly at the start of the process, rather than the end (so we have some way to go, in terms of conversion in the kernel).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
Are you aware of dtb support in syslinux menu files? This could be added to u-boot as well.
http://www.zytor.com/pipermail/syslinux-commits/2012-June/001835.html
Rob
On Aug 5, 2013, at 23:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that.
+1
A generic solution should favor the platform providing the DTB, not the kernel. Note that I do not expect this to ever be fully possible until there is a 1,000 page DT spec written by an organization formed for the purpose, with trademark and test suite enforcement of compliance. But we have all seen the upstream discussions on bindings and everyone is trying their best, so we can keep this thread technical - and from a technical PoV DTB is platform data, not OS data.
Jon.
On 6 August 2013 06:46, Jon Masters jonathan@jonmasters.org wrote:
On Aug 5, 2013, at 23:05, Rob Herring robherring2@gmail.com wrote:
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions.
UEFI kind of depends on having a FAT partition to load things from. We need to keep that in mind so our solutions don't need symlinks etc.
I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that.
+1, with a caveat: users should still be able to load the previous known working dtb file in case upgrade brings in a DTB file that is FUBAR. For example the distribution could copy existing known-to-work dtb to .dtb.bak.
I would say we recommend board vendors to configure firmware to load their dtb from:
/boot/dtb/$soc-$board.dtb
And distributions should install all dtb files to /boot/dtb with filenames expected by firmwares.
If there is a general consensus about that, we can probably start drafting a "best practises for ARM boot" document from here.
We still have the issue of a board vendor reusing dtb filename of another board yet modifying the dtb file for their own needs. We can create a registry of filenames and say "YOU MUST REUSE FILENAME", But that didn't really help with machine ID's as either, there is quite a variety of machines called "cardhu".
A generic solution should favor the platform providing the DTB, not the kernel. Note that I do not expect this to ever be fully possible until there is a 1,000 page DT spec written by an organization formed for the purpose, with trademark and test suite enforcement of compliance. But we have all seen the upstream discussions on bindings and everyone is trying their best, so we can keep this thread technical - and from a technical PoV DTB is platform data, not OS data.
True, but we also know firmware has bugs and needs updates to fix them. Even in X86 with all the lovely ACPI standards, there is over 200K google results for "fixing DSDT".
Riku
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
U-Boot is bound up with compile-time decisions about targeting a single board at the moment, but if we're talking about long term decisions like /boot/dtb/ just like ARM isn't the only consideration U-Boot is not the only bootloader.
Once kernels capable of running a single binary on many platforms are common (they're already workable) pressure for the bootloader to do likewise will increase. So it'd be a shame to block that by choosing a dtb convention that assumes there's only one on the image.
-Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Aug 2013 11:53:02 +0800 Andy Green andy.green@linaro.org wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
/boot/dtb/ is the directory that contains all the dtbs. omap and other platforms, have a findfdt function that will tell you the expeted dtb filename for the board. we just need to put them in a know location.
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
depending on the system you would need to update the u-boot installed into the card, a scriptable task, or ensure that the installed u-boot has the unified features needed. but I fully expect that it something people can and will want to do.
U-Boot is bound up with compile-time decisions about targeting a single board at the moment, but if we're talking about long term decisions like /boot/dtb/ just like ARM isn't the only consideration U-Boot is not the only bootloader.
I hope the long term outcome here is that u-boot or any other bootloader would be able to know where to find the dtb file regardless of distro because we all honour and do the same thing.
Once kernels capable of running a single binary on many platforms are common (they're already workable) pressure for the bootloader to do likewise will increase. So it'd be a shame to block that by choosing a dtb convention that assumes there's only one on the image.
They exist today in fedora, as of Fedora 19 we are shipping a multiplatform kernel. The same images can run on multiple boards. I don't want to limit what systems are supported in any way. but come up with a flexible portable setup.
Dennis
On 6 August 2013 12:16, Dennis Gilmore dennis@ausil.us wrote:
On Tue, 6 Aug 2013 11:53:02 +0800 Andy Green andy.green@linaro.org wrote:
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
/boot/dtb/ is the directory that contains all the dtbs. omap and other platforms, have a findfdt function that will tell you the expeted dtb filename for the board. we just need to put them in a know location.
I think what you've been describing is a very good idea... but that's not what Rob wrote (" If /boot/dtb is THE dtb to use").
-Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Aug 2013 12:33:22 +0800 Andy Green andy.green@linaro.org wrote:
On 6 August 2013 12:16, Dennis Gilmore dennis@ausil.us wrote:
On Tue, 6 Aug 2013 11:53:02 +0800 Andy Green andy.green@linaro.org wrote:
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
/boot/dtb/ is the directory that contains all the dtbs. omap and other platforms, have a findfdt function that will tell you the expeted dtb filename for the board. we just need to put them in a know location.
I think what you've been describing is a very good idea... but that's not what Rob wrote (" If /boot/dtb is THE dtb to use").
Seems I was not clear initially. my proposal is not to make /boot/dtb the dtb to use but to make /boot/dtb/ the directory to place for all distros to place all dtb files in.
The hardware vendor would be free to use the dtb we as distros provide or one they provide by default. This choice can be overriden in the boot config file.
Dennis
On 08/05/2013 10:53 PM, Andy Green wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
Ah, right. I misread this.
So do we assume the dtb file names are known by the bootloader for a board or standardized in some way?
Rob
U-Boot is bound up with compile-time decisions about targeting a single board at the moment, but if we're talking about long term decisions like /boot/dtb/ just like ARM isn't the only consideration U-Boot is not the only bootloader.
Once kernels capable of running a single binary on many platforms are common (they're already workable) pressure for the bootloader to do likewise will increase. So it'd be a shame to block that by choosing a dtb convention that assumes there's only one on the image.
-Andy
On 6 August 2013 20:53, Rob Herring robherring2@gmail.com wrote:
On 08/05/2013 10:53 PM, Andy Green wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
Ah, right. I misread this.
So do we assume the dtb file names are known by the bootloader for a board or standardized in some way?
Yes it has to be like that, something has to pick a dtb one way or another and give it to the kernel.
It can be because that's the only dtb on the image and that's all it can deal with, but hopefully in the future the bootloader will absorb some of the ARCH_MULTIPLATFORM thinking from the kernel and not be limited by single compile-time platform choice any more, and support many possible platforms and select the correct dtb.
It doesn't hurt if it's a directory with one thing in for the first case, and doing that enables the second case, so it seems the right way.
-Andy
Rob
U-Boot is bound up with compile-time decisions about targeting a single board at the moment, but if we're talking about long term decisions like /boot/dtb/ just like ARM isn't the only consideration U-Boot is not the only bootloader.
Once kernels capable of running a single binary on many platforms are common (they're already workable) pressure for the bootloader to do likewise will increase. So it'd be a shame to block that by choosing a dtb convention that assumes there's only one on the image.
-Andy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 06 Aug 2013 07:53:14 -0500 Rob Herring robherring2@gmail.com wrote:
On 08/05/2013 10:53 PM, Andy Green wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
Ah, right. I misread this.
So do we assume the dtb file names are known by the bootloader for a board or standardized in some way?
Yes, u-boot today on omap had a find_fdt function that provides the name for the expected dtb for the board that its running on. as part of the unified u-boot platform ive proposed, u-boot would transparently load the dtb for us and pass it to the kernel. just like highbank does today.
Dennis
Rob
U-Boot is bound up with compile-time decisions about targeting a single board at the moment, but if we're talking about long term decisions like /boot/dtb/ just like ARM isn't the only consideration U-Boot is not the only bootloader.
Once kernels capable of running a single binary on many platforms are common (they're already workable) pressure for the bootloader to do likewise will increase. So it'd be a shame to block that by choosing a dtb convention that assumes there's only one on the image.
-Andy
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On Tue, Aug 6, 2013 at 8:51 AM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 06 Aug 2013 07:53:14 -0500 Rob Herring robherring2@gmail.com wrote:
On 08/05/2013 10:53 PM, Andy Green wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
Ah, right. I misread this.
So do we assume the dtb file names are known by the bootloader for a board or standardized in some way?
Yes, u-boot today on omap had a find_fdt function that provides the name for the expected dtb for the board that its running on. as part of the unified u-boot platform ive proposed, u-boot would transparently load the dtb for us and pass it to the kernel. just like highbank does today.
How would you provide a dtb to override the firmware version of the dtb? Of course the firmware version is perfect and will never have to updated, but suppose it does need to be overridden? We really want to load the dtb if present somewhere on disk, otherwise use the firmware version.
Rob
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 6 Aug 2013 17:31:04 -0500 Rob Herring robherring2@gmail.com wrote:
On Tue, Aug 6, 2013 at 8:51 AM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 06 Aug 2013 07:53:14 -0500 Rob Herring robherring2@gmail.com wrote:
On 08/05/2013 10:53 PM, Andy Green wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
Ah, right. I misread this.
So do we assume the dtb file names are known by the bootloader for a board or standardized in some way?
Yes, u-boot today on omap had a find_fdt function that provides the name for the expected dtb for the board that its running on. as part of the unified u-boot platform ive proposed, u-boot would transparently load the dtb for us and pass it to the kernel. just like highbank does today.
How would you provide a dtb to override the firmware version of the dtb? Of course the firmware version is perfect and will never have to updated, but suppose it does need to be overridden? We really want to load the dtb if present somewhere on disk, otherwise use the firmware version.
if using sysboot or pxe you would add a fdt line to your config then the dtb would be loaded from filesystem or network and used. if you use boot.scr or uEnv.txt ou would need to load the new dtb to ${fdt_addr}
Dennis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/06/2013 08:53 AM, Rob Herring wrote:
On 08/05/2013 10:53 PM, Andy Green wrote:
On 6 August 2013 11:05, Rob Herring robherring2@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/05/2013 04:41 PM, Dennis Gilmore wrote:
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
A DTB should not be tied to a kernel version. I realize that is a reality for some boards, but lets not encourage that. There are also plans to remove dts files from the kernel.
Is anyone working on these plans yet? There's infrastructure required for things like saying "board foo shall use foo.dtb as the base dtb".
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
If /boot/dtb is THE dtb to use, does more than that need to be specified (at least from a bootloader perspective).
If I understood you correctly, that'd be needlessly limiting one image to one board.
Consider an SD Card + CONFIG_ARCH_MULTIPLATFORM kernel you can pull out and plug in to use on a variety of different boards, the bootloader would need to identify the correct dtb and pass it to the kernel.
Ah, right. I misread this.
So do we assume the dtb file names are known by the bootloader for a board or standardized in some way?
Yes, it should be up to the firmware/bootloader to know what it's running on, and in turn map that to the dtb basename at least.
- -- Tom
On 08/05/2013 11:53 PM, Andy Green wrote:
U-Boot is bound up with compile-time decisions about targeting a single board at the moment, but if we're talking about long term decisions like /boot/dtb/ just like ARM isn't the only consideration U-Boot is not the only bootloader.
Once kernels capable of running a single binary on many platforms are common (they're already workable) pressure for the bootloader to do likewise will increase. So it'd be a shame to block that by choosing a dtb convention that assumes there's only one on the image.
I don't want to drag things vastly off-topic, but in some cases U-Boot does support multiple platforms on a single binary, it's just limited to the same SoC family and there being run-time differentiation possible (or being one of the platforms that uses DTs today). Once DTs are more fully fleshed out for ARM platforms and stable some further re-jiggering may be possible (and would rely, probably, on some standard way to merge device trees).
And of course, +1 to making sure the convention is widely re-usable. I sighed to myself late last year when I saw Ubuntu shoving dtbs under /lib and Fedora under /boot and wondering where the communications breakdown happened.
Define "transparently load".
Why wouldn't you just mandate that there are certain features enabled and that all platforms need a boot script - therefore abstracting the board name, dtb name, location, kernel version/naming scheme from the bootloader as a whole?
The location of that boot script would need to be agreed, and a standard search script if there is some variation (what if /boot isn't separate?)
On Mon, Aug 5, 2013 at 4:41 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
Regards
Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlIAG/wACgkQkSxm47BaWfcq2ACdFrw5/68I9+A2ls2htra3fMcN rN4An1dlK4H8vm4jlJEEYcdp26tRDgJ9 =SXTs -----END PGP SIGNATURE----- _______________________________________________ cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, 7 Aug 2013 13:09:08 -0500 Matt Sealey neko@bakuhatsu.net wrote:
Define "transparently load".
omap systems have a findfdt command that gives you the dtb file name expected for the board. I expect that u-boot will know the name of the file for its dtb. Hardware vendors would have the choice of how they implement loading the dtb. They could load a dtb shipped in onboard storage or load one from our common dtb directory. The user or distro can specifiy that the distro dtb be used
Why wouldn't you just mandate that there are certain features enabled and that all platforms need a boot script - therefore abstracting the board name, dtb name, location, kernel version/naming scheme from the bootloader as a whole?
because we don't need a boot script. we as distros shouldn't need to worry about things like memory locations. we should only need to load a kernel, initramfs, and pass boot args. http://lists.denx.de/pipermail/u-boot/2013-August/160080.html is my proposal to u-boot upstream on defining a standard platform. you are free to use a boot script still, however I strongly feel that using a extlinux config with the sysboot command offers a much better user experience.
The location of that boot script would need to be agreed, and a standard search script if there is some variation (what if /boot isn't separate?)
Everything needs to work with both cases where /boot is seperate and where /boot is part of /
Dennis
On Mon, Aug 5, 2013 at 4:41 PM, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all,
As part of the unified features in u-boot thread I said that I would work to get distros to agree to a common location that u-boot will be able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems with / and /boot on separate partitions. I believe Ubuntu and hence Debian put them in /lib somewhere today. Fedora puts them in /boot/dtb-<kernel version>. im not sure where the other distros put them.
I think that until they are decoupled from the kernel Fedora would have /boot/dtb be a symlink to the latest installed kernel. once its decoupled it would be the location where the dtbs are installed.
Can We all agree to implement ensuing that dtb files will be available in /boot/dtb/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/07/2013 07:16 PM, Dennis Gilmore wrote:
On Wed, 7 Aug 2013 13:09:08 -0500 Matt Sealey neko@bakuhatsu.net wrote:
Define "transparently load".
omap systems have a findfdt command that gives you the dtb file name expected for the board. I expect that u-boot will know the name of the file for its dtb. Hardware vendors would have the choice of how they implement loading the dtb. They could load a dtb shipped in onboard storage or load one from our common dtb directory. The user or distro can specifiy that the distro dtb be used
Why wouldn't you just mandate that there are certain features enabled and that all platforms need a boot script - therefore abstracting the board name, dtb name, location, kernel version/naming scheme from the bootloader as a whole?
because we don't need a boot script. we as distros shouldn't need to worry about things like memory locations. we should only need to load a kernel, initramfs, and pass boot args. http://lists.denx.de/pipermail/u-boot/2013-August/160080.html is my proposal to u-boot upstream on defining a standard platform. you are free to use a boot script still, however I strongly feel that using a extlinux config with the sysboot command offers a much better user experience.
One thing I wanted to bring back to this list as well is that I think part of the logic provided needs to come from outside the flashed-in-and-forever-locked (as some folks would like to see it) side of U-Boot. This is part of the discussion I'd like to see happen with the rest of the U-Boot list as well, but the distro must not have to worry about memory locations but must worry about providing the rest of their experience. The distro wants to provide the user with a consistent look and feel and experience from architecture to architecture and that involves getting your 'whatever' in front of them asap.
- -- Tom
-
Andy Green -
Brendan Conoboy -
Dennis Gilmore -
Dennis Gilmore -
Jon Masters -
Matt Sealey -
Riku Voipio -
Rob Herring -
Robie Basak -
Stephen Warren -
Tom Rini