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

[Stephen Warren]

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.

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.

...
> 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:-)

-- 
nvpublic