[U-Boot] [PATCH 0/4] sunxi: SPL size reduction patches

[Siarhei Siamashka]

On Wed,  4 Feb 2015 13:05:47 +0100
Hans de Goede <hdegoede at redhat.com> wrote:

> Hi All,
> 
> Inspired by Simon's work to make the FEL SPL and regular SPL builds more
> similar I've been looking into reducing the size of the SPL, resulting in
> the following patch series. This all seems quite safe, but we are past rc1,
> so may be best to keep this on a branch for now, or not ...
> 
> Simon, I think the malloc_simple changes should go through your tree, once
> those are merged I'll add the sunxi patch enabling malloc_simple usage in
> the SPL.
> 
> With this series we're already quite close to getting a full-blown SPL to
> fit in 16K, I've looked at removing CONFIG_SPL_LIBCOMMON_SUPPORT but that
> won't fly well I think. We could however add a CONFIG_SPL_NO_PRINTF, which
> automatically gets set when CONFIG_SPL_LIBCOMMON_SUPPORT is not set, and
> use that on sunxi, assuming that you (Simon) are ok with not being able to
> use printf in the device-model code which gets used in the SPL.
> 
> Things already almost built when not setting CONFIG_SPL_LIBCOMMON_SUPPORT
> since there are already a lot of places checking for that before calling
> printf. We could change all the CONFIG_SPL_LIBCOMMON_SUPPORT to
> CONFIG_SPL_NO_PRINTF checks and define CONFIG_SPL_NO_PRINTF on sunxi to win
> another "large" chunk of RAM.

Thanks for these patches. The SPL size optimization is very useful,
regardless of whether we want to wilfully confine ourself to just
16 KiB or not. Even with full 32 KiB, we still have NAND support
pending, the potential device-model code size overhead, not to
mention my little project which needs DRAM init code for multiple
SoCs in a single SPL. And extra headroom is always good to safeguard
against poor code generation by certain versions of compilers, etc.

I was intending to do something like this myself eventually, but did
not like the idea of being the only guy who actually cares about the
SPL size. Sometimes it has to get worse before it gets better ;-)

> Something else to look at is at the memory map of the first 32k of SRAM when
> in FEL mode. The only documentation we've is:
> https://github.com/hno/Allwinner-Info/blob/master/FEL-usb/USB-protocol.txt
> 
> Which is reverse engineered and not 100% clear on the memory map. We could
> add a memset to 0xaa for 0x6000 - 0x8000 to the fel spl as a test, as I've
> the feeling that what hno has found there are just scratch buffers and that
> using that in the SPL will be save, if that is the case we could use
> 0x2000 - 0x0000 (growing downwards) as stack, and always use a text-base of
> 0x2000 for the SPL, with the SPL code / data segments living at
> 0x2000 - 0x8000 and then everything should fit as is, and we can have one
> unified SPL binary for both FEL and sdcard booting.

The BROM sets up two stacks for itself. One at 0x2000 (and growing
down) for the IRQ handler. And another one at 0x7000 (and also growing
down) for the regular code. This unfortunately splits the usable SRAM
address space into disconnected chunks. Clashing with the upper parts
of these stacks is not a great idea. For example:

$ fel clear 0x0000 0x1F00
$ fel ver
AWUSBFEX soc=00165100(A20) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000

Great, we are still alive! But:

$ fel clear 0x1F00 0x100
$ fel ver

Here it dies and shows that messing with the addresses just below 0x2000
(the IRQ stack) is bad. The same applies to another stack.

Now I'm trying to get the best use of the available free SRAM areas with
a patched 'fel' tool:
    http://lists.denx.de/pipermail/u-boot/2015-February/204024.html

The layout of the usable SRAM locations can be SoC variant specific.
This needs further investigation.

> I don't have the time to look into this further atm, so I hope that one of
> you (Simon or Siarhei) has time to look into this further.
> 
> I see that we also never merged this related fix:
> http://lists.denx.de/pipermail/u-boot/2014-July/183986.html
> 
> We should probably merge a version of that when Simon's patches for fixing
> FEL have landed. I think it may be best to just always set the L2EN bit on
> sun4i/sun5i, without detecting whether we're in fel mode or not, setting it
> when it is already said should be a nop, and thus harmless.

This could be surely picked up, but IMHO it is not that urgent.

-- 
Best regards,
Siarhei Siamashka