[U-Boot] [PATCH] RFC: dm: Add proposed timeline and guide for porting serial drivers

[Siarhei Siamashka]

On Sat, 5 Sep 2015 15:52:03 +0200
Hans de Goede <hdegoede at redhat.com> wrote:

> Hi,
> 
> On 05-09-15 15:45, Simon Glass wrote:
> > Add a README with a brief guide to porting serial drivers over to use
> > driver model.
> >
> > Add a timeline also.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> 
> I assume that the purpose of the timeline is to retire the non dm
> serial drivers ?
> 
> What about SPL use ?
> 
> I do not see the SPL for sunxi move to dm / devicetree anytime soon,
> there simply does not seem to be enough space.

Based on my experience, introducing code bloat is always easier than
removing it. As long as the dm /devicetree remains optional for the
SPL, it is safer to stay away from it for sunxi. And prioritize the
use of precious SRAM space for user visible features.

> With the new nand SPL support we have already been hitting the 24k
> limit without bringing in dm + a dtb + a dtb parser ...

What is the exact limit for the SPL size when it is loaded by the
BROM? The comment in
   http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c;h=3361251c8e7fffcb4ccbc3e29eb5e2e956608b0c;hb=HEAD#l66
says that the limit is 0x7600, which means 30208 bytes. I guess,
somebody needs to do some experiments on different Allwinner SoC
variants and try to confirm this information.

Regarding gaining more space, there is still a decades old trick
we can take advantage of:
    https://en.wikipedia.org/wiki/Executable_compression

When using GCC 4.8.4, I'm getting 22756 bytes size for the
Cubieboard u-boot-spl.bin file. Running "lzop -9 u-boot-spl.bin"
results in 17876 bytes for the compressed file. Running
"uclpack --10 u-boot-spl.bin u-boot-spl.bin.ucl" results in
16652 bytes for the compressed file. Both LZO and UCL have
very simple small decompressors.

Basically, using compression can provide us with something
like 4 or 5 extra kilobytes. And we are not limited with just
32K for the uncompressed SPL size. For example, even Allwinner
A13 has the total size of SRAM equal to 48K. A small part of it
needs to be reserved for the USB (FEL) boot mode, but I think
that maybe up to something like ~38K of contiguous SRAM space
can be used for the uncompressed SPL (code+data+stack). The
other SoC variants are a bit tricky, for example A31 does not
have 38K of contiguous space starting at the address 0x0 in SRAM.
So these 38K would have to be uncompressed to some other location
and CONFIG_SPL_TEXT_BASE would need to be adjusted. And if we
want the same SPL binary to be in principle bootable on all SoC
variants (including A80), then relocations support can be added
too (fixup them immediately after the decompression). Though
additionally storing relocations can waste some space.

It's all about trade-offs. Compression tricks can provide extra
space at the cost of increasing complexity. The dm /devicetree
wastes space for the sake of architectural aesthetics and codebase
unification.

> Which reminds me I still need to look at your version of the
> patch for only using malloc_simple.c in the SPL and not build
> in dl_malloc.c, that saves about 1k which we could use really
> well. I still have this on my todo list.

The current printf related machinery is a little bit heavyweight
too.

-- 
Best regards,
Siarhei Siamashka