[U-Boot] [PATCH 0/29] dm: Introduce device tree support in SPL (for Rockchip)

Simon Glass sjg at chromium.org
Fri Apr 10 19:37:47 CEST 2015


Hi,

On 27 February 2015 at 22:06, Simon Glass <sjg at chromium.org> wrote:
> With driver model SPL support in place the remaining driver difference
> between U-Boot proper and SPL is that SPL does not support device tree.
> This series adds this support, using a Rockchip board as an example.
>
> One problem with device tree is that U-Boot has no way of dropping features
> it does not need or use. For SPL this problem needs to be solved and this
> series uses the preprocessor for this. The 45KB Firefly device tree reduces
> to 693 bytes when unused material is removed. A better solution might
> involve the 'fdtgrep' tool but this has not made it into the device tree
> compiler as yet.
>
> This series includes some changes aimed at reduce code size in SPL,
> including:
> - dropping alias sequence support (the aliases node) since many boards just
>     use a single UART in SPL
> - adding a smaller panic() function that does not support printf()-format
>     strings
> - removing device unbind code which will never be used in SPL
>
> Overall the resulting SPL binary is 8829 bytes with my Linaro 4.8.2 compiler,
> including the device tree, using Thumb-2. Of this:
>
> 1768 bytes is driver model core code
> 1556 bytes is device tree code
> 693 bytes is the device tree itself
> 4756 is other code, including serial drivers, rodata and data
>
> The last figure includes rodata incorrectly added by the tool chain [1].
> With a bug-fixed gcc 4.9.2 the total size is 6893 bytes including device
> tree.
>
> Approximately 750 bytes is used for strings and driver data (root device
> and serial) associated with driver model and device tree. This adds up an
> overhead of around 4750 bytes for driver model and device tree, including
> the code, rodata and device tree itself.
>
> It should therefore be possible to use driver model and device tree in
> SPL for board that have enough SRAM. Clearly 4KB is impossible without
> further work (perhaps removing some error strings). I suspect 8KB would
> be tricky, allowing only 3KB for stack and other code. But 16KB should
> work OK.
>
> SRAM sizes for recent SoCs I am aware of are:
>
> Rockchip RK3288:     96KB
> Tegra 124:           128KB
> Samsung Exynos 5420: 384KB
>
> The Rockchip Firefly was chosen for this work since it is a fairly recent
> board and is readily available. Rockchip engineers have been actively
> upstreaming code to Linux in the past year and there is a very
> full-featured U-Boot available. But it is invisible to most U-Boot
> people - mainline Rockchip support seems well overdue. This series does
> not make a serious start on that, since it only prints a message in SPL
> and then hangs, but additional work should get it booting to a prompt.
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303

I've held off pushing this into u-boot-dm/next since it is RFC and the
device tree part needs work. But I'm thinking of respinning it to
apply it within the upcoming merge window, or at least the core
patches.

Does anyone have comments at this stage?

Regards,
Simon


More information about the U-Boot mailing list