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

Simon Glass sjg at chromium.org
Wed Oct 12 03:07:42 CEST 2011


Hi Jason,

On Tue, Oct 11, 2011 at 6:00 PM, Jason <u-boot at lakedaemon.net> wrote:
> Simon, Stephen,
>
> On Tue, Oct 11, 2011 at 04:54:27PM -0700, Simon Glass wrote:
>> 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.
> ...
>> >
>> > 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.
>
> I imagine u-boot's methodology of loading drivers only as needed will
> prevent the unnecessary initialization of 30 drivers which are default
> 'status = "enabled";'.  Or, am I missing something?

The glorious U-Boot driver refactor of 2015? :-) For now I don't know
how this will turn out, and I will change the commit message in the
next patch set.

Regards,
Simon

>
> thx,
>
> Jason.
>


More information about the U-Boot mailing list