On 08/15/2013 12:02 PM, Brendan Conoboy wrote:
On 08/14/2013 05:37 PM, Nicolas Pitre wrote:
Using /boot implies a distro filesystem and we'd rather wish for DT to be independent from a distro or even Linux. The DTB should therefore be stored and accessed in a way which is hardware/bootloader specific. The distro being installed on top shouldn't have to care.
Yes. As a distro provider I would like to see the following from uBoot-using hardware:
- Every device ships with a DTB embedded in non-volatile storage.
Basically, if it ships with uBoot it includes a device tree sufficiently accurate to boot a kernel configured to support the SoC.
- Standard environment variables telling me where that DTB is located.
Today this is often fdt_addr_r or fdt_addr.
- Standard environment variables telling me what a replacement DTB
would be named. Today ${soc}-${board} is almost reliable.
- A method by which to update the DTB stored in nonvolatile memory
without updating uBoot itself. This could be done via management controller or within u-boot (Again, using the variables from 2 and 3 above).
The core idea is that the device provide all the information necessary to boot the device. In the event that information becomes inaccurate relative to the needs of later kernels there needs to be a way to update that information, either per-boot or permanently.
What I don't see above is something about loading the full DTB from non-volatile storage and into memory.
The only problem I see is you're not dealing with platforms that don't include non-volatile storage on the board itself (Beaglebone White, Pandaboard, RPi, Allwinner boards without eMMC/NAND, etc). Or are you including somehow stored on SD card in the list?
It otherwise sounds reasonable to me, thanks.