[U-Boot] [PATCH v3 0/6] Run-time configuration of U-Boot via a flat device tree (fdt)

[Simon Glass]

Hi Stephen,

On Tue, Oct 11, 2011 at 4:37 PM, Stephen Warren <swarren at nvidia.com> wrote:
> Simon Glass wrote at Tuesday, October 11, 2011 4:26 PM:
> ...
>> and add some defines to your board (only ARM is currently supported):
>>
>>  #define CONFIG_OF_CONTROL       (to enable run-time config control via fdt)
>>  #define CONFIG_OF_EMBED or CONFIG_OF_SEPARATE
>>  (either build the fdt blob into U-Boot, or create a separate u-boot.dtb
>>   and u-boot-dtb.bin)
>>  #define CONFIG_DEFAULT_DEVICE_TREE   "<your name>"
>>  (to specify the name of the device tree file is
>>   board/<vendor>/dts/<your name>.dts)
>>
>> Typically a CPU device tree include file is provided which defines all the
>> devices available on that CPU/SOC, with each set to 'status = "disabled"'.
>> Board device tree files should adjust only the devices they use, setting
>> 'status = 'ok"' in each case, and leaving the existing devices alone and
>> disabled.
>
> s/existing/other/ in the second-to-last line? Well, I guess given this is
> patch 0, that's not important.

Will fix.

>
> In the Linux kernel, things used to work exactly as described above, but
> the kernel has switched to having no "status" properties in the SoC base
> file (and hence everything defaults to enabled), with the per-board .dts
> files set 'status = "disabled"' where desired. I imagine U-Boot should
> follow the same practice.
>
> I forget the exact reason for this in the kernel; it may simply have been
> due to precedent on PowerPC. Grant Likely would know the details.

Well it's going to create a bit of work for boards that use only a
subset of these 30-peripheral SOCs, but perhaps the expectation is
that you would be buying a simpler SOC if you didn't need all the
features.

>
> ...
>> For example, for Tegra2 we might have in arch/arm/cpu/armv7/tegra2/config.mk
>> these lines:
>>
>> CONFIG_ARCH_DEVICE_TREE := tegra250
>>
>> This means that ARCH_CPU_DTS will point to arch/arm/dts/tegra250.dtsi.
>
> In the kernel, we renamed this to tegra20; "Tegra 250" is a marketing name,
> whereas "Tegra 20" is an engineering name. Engineering names should be more
> stable, and probably fewer in number, and so are more suitable for device-
> tree.
>
> (I guess that's not particularly important for this patchset, since it
> doesn't include tegra250.dtsi, but it'll be relevant soon I'm sure:-)

Yes I did see that on the list. I will change the message in this
patch set, and try to remember when we get to 'soon' :-)

Regards,
Simon

>
> --
> nvpublic
>
>