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