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

[Simon Glass]

Hi,

On Saturday, 5 September 2015, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
>
> 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.


I think it will be optional for the forseeable future. But I think it
would be worth exploring for sunxi to see what the cost is.

I think device tree is a great unifier for SoCs that have the space
and don't impose some arbitrary limit on the amount of code the boot
ROM will load.

An interesting avenue that I have not explored is static binding of
devices. If device tree is not used a lot of the code size comes from
device_bind() and device_probe(). The first one could perhaps be
dropped by using some sort of static table. The second one is less
clear, but if we only have serial then perhaps some efforts can be
made to reduce space.

>
>
> > 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.


I'm not a huge fan of the additional complexity from compression. As
it happened this was implemented in the Chrome OS U-Boot to improve
boot time, but the effect was pretty small.  But perhaps as an option
to enable to get more features, it could be useful.
>
>
> > 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.


Yes a minimal printf() would be nice - perhaps just strings, hex and
maybe decimal.

Regards,
Simon