Hi Jason, On Tue, Oct 11, 2011 at 6:00 PM, Jason <u-b...@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 <swar...@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. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
