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:
>
> 1. 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.
>
> 2. Standard environment variables telling me where that DTB is located.
> Today this is often fdt_addr_r or fdt_addr.
>
> 3. Standard environment variables telling me what a replacement DTB
> would be named. Today ${soc}-${board} is almost reliable.
>
> 4. 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.
--
Tom
_______________________________________________
cross-distro mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/cross-distro
