On Thu, 11 Jul 2013 10:35:07 +0200, Albert ARIBAUD <[email protected]> wrote:
> [...] nor is there currently a way to build several U-Boots in one go. Although, with recent proposals like the TPL one: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432 ... I am toying with the idea of a more generic build mechanism which would allow a target to specify as many binaries as it needs, each with its own configuration. The simplest targets would have a single build (U-boot itself). SPL-type targets would have two (SPL and U-Boot). TPL-like ones would have three (SPL, TPL and U-boot). Etc. A developer could then choose to build the default binaries or a specific set, e.g. only rebuild U-boot for targets whose SPL needs not change. For maximum reuse, U-boot would have to be a set of components (and that's what it is right now, and would be all the more with Kconfig) and each 'binary' would be a selection of which components. Examples of components would be: - startup (mandatory component which contains the entry point); - setup (optional component which would set up the system incl. DDR); - relocation (optional component which moves the code up in DDR); - console (optional component which allows interactive commands); - chainload (optional component which allows chainloading another binary); Etc. Of course there would be components for architecture support (PPC, ARM, MIPS, x86)..., for CPU [class] support, for driver support, for function support). The interest of this idea would be that SPL and U-Boot would not be distinguished by #ifs across the code, but only by their respective configurations. We'd have a clear view and control in a single place (the configuration header file) of what goes in SPL and what goes in U-Boot (and what goes in TPL). To be clearer on configurations and header files: my idea would be to put SPL configuration under a single '#if CONFIG_BUILDING_SPL'-like conditional, and U-Boot configuration under #if CONFIG_BUILDING_UBOOT, and that SPL related configuration options either be replaced by their general equivalents (for instance, no need for CONFIG_SPL_I2C_SUPPORT if the SPL configuration includes some CONFIG_I2C_somedriver) or turned into a component option (e.g. CONFIG_SPL_MAX_FOOTPRINT becoming option CONFIG_SIZECHECK_MAX_FOOTPRINT). I don't think this would require overhauling the whole of U-Boot; nor should all be done in one go. We could independently: - make sure SPL, U-Boot and TPL are independent sub-targets which can be built separately from the command line if needed, with a sane default for existing targets; - progressively replace CONFIG_SPL_xxx options with equivalent CONFIG_SYS_xxx ones or move them into new "components" such as "sizecheck" or "chainload". I realize I'm drawing a very rough picture here... Comments/Criticisms welcome. Amicalement, -- Albert. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
