Hi,
On 4 July 2016 at 11:57, Simon Glass sjg@chromium.org wrote:
Note: This v3 series adds a test and fixes a few bugs found in generation of of-platdata.
This series provides a way to compile in the contents of a device tree as C code into U-Boot, implementing an idea that Tom Rini came up with. It is intended to deal with extremely tight environments where there is not enough space for the ~3KB device tree code overhead. Examples include SPL where there is only 16KB of available RAM yet a full MMC stack is required.
To provide a reasonable test environment, SPL support is added to sandbox, through a new 'sandbox_spl' target. A new tool 'dtoc' converts device tree data to C code (and structure definitions).
To check its effectiveness for a real application, the v2 series includes support for enabling of-platdata for a rockchip board (firefly-rk3288). The results are as follows:
Code Data u-boot-spl.bin sizeof-platdata disabled 23159 1624 28864 of-platdata enabled 19093 2616 21761
Overall the saving is 7103 bytes, about 7KB. Approximately 4KB of this comes from removing the device tree data from SPL although this is offset by the size of the of-platdata itself (around 1KB). On top of this effective 3KB reduction, another ~3KB reduction comes from dropping libfdt and a further 1KB from dropping unused setup and driver-model code.
Clearly this approach does have value. Looked at with a favourable light it provides the best of both worlds: configuration using standard device tree bindings without the run-time overhead.
Looking under the hood shows a less rosy picture. Effectively we end up with a new set of C structures which must be handled by the driver. This series suggests a suitable approach for dealing with this (see of-plat.txt) which is workable. However there are a number of serious caveats. See that file for details.
Thsi feature should be used sparingly. Rockchip is to some extent an unusual case: lots of features (leading to a large SPL device tree size of 4KB), no MMC stack available to SPL from the internal ROM* and a very limited maximum SPL code size. Most SoCs will not benefit from this.
However, for an SoC with very small SRAM where only a few drivers are needed in SPL (such as serial and MMC) then of-platdata could provide a useful benefit, without a significant increase in complexity.
With the v3 series this feature is ready for use. It is available at u-boot-dm/dt-working.
The dtoc tool might be better renamed fdttoc (which is clumsy) or fdt2c. Ideas welcome.
I'm planning to apply this series soon. Please let me know if there are any further comments.
Regards, Simon