[U-Boot] sun50i blocking SPL changes

[André Przywara]

On 25/11/17 23:35, Dr. Philipp Tomsich wrote:
> Jagan,
> 
> I resolved this by introducing a new Kconfig that affects what functionality
> is included in spl_fit.c; however, this leaves an uneasy feeling, as we now
> start to have different logic in our SPL stage.

Thanks for taking care. Is that about Falcon boot? Don't we need
explicit platform support for this anyway? Then disabling this looks
much cleaner, if sunxi just doesn't support this for now (until we find
a good solution).

> Is there a plan in place to move sun50i to a TPL->SPL->U-Boot model?

I am not aware that anyone has ever started looking into this. So far we
were thinking about other options:
1) Use runtime decompression. ssvb mentioned this several times. The
boot ROM limits the load to 32KB, but the ARMv8 SoCs have in fact bigger
SRAM than that.
Siarhei, is this the time you come to the rescue with a flying cape?

2) Try to shave off some bits here and there. For instance I once
proposed a "tiny ctype" implementation, which saved around 200 bytes.
However this didn't save space universally for every platform or board,
so I dropped this back then.

3) Compile the SPL as ARM (using Thumb2). This gives quite some savings
and we should be good for quite a while with this. I keep a working
branch around[1].

4) Try to compile with -mabi=ilp32 to see if that saves some space, due
to pointers and longs being only 32-bit (which is all we need on sunxi
anyway, but especially for the SPL). Last time I tried this triggered
ICE's in GCC, but I might give this a shot again.

Point 3) gives us the biggest and sustainable saving, but has serious
implications to the build system, as we now need two (cross-)compilers
to generate an image. In the moment I solve this manually by using a
different defconfig, compiling with arm-gcc and saving the generated spl
binary. Then I re-configure for AArch64 and compile U-Boot proper,
manually glueing the two together.

Can you elaborate what makes your code blow up the SPL image? From what
I understand you mentioned the exception vector alignment, I guess it's
the ".align  11" in exceptions.S? So what does this push over the 2K
edge here?
I was wondering if we could build (or copy) the exception table on the
fly instead of relying it to be verbatim and properly aligned in the
image file?

Cheers,
Andre.

[1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip

> 
> Thanks,
> Philipp.
> 
>> On 24 Nov 2017, at 21:42, Dr. Philipp Tomsich <philipp.tomsich at theobroma-systems.com> wrote:
>>
>>>
>>> On 24 Nov 2017, at 21:36, Jagan Teki <jagan at amarulasolutions.com> wrote:
>>>
>>> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>>> <philipp.tomsich at theobroma-systems.com> wrote:
>>>> Jagan, Maxime & Tom,
>>>>
>>>> I have a couple of changes to spl_fit.c queued that we need to get merged to fix some issues for ATF support on Rockchip platforms.
>>>
>>> Does all rk64 has enough SPL size's to fit?
>>
>> The 64bit Rockchip platforms either have more than enough SRAM (i.e. the RK3399) or are already using a TPL w/ SPL executing in DRAM.
>> So the only failures I get are sun50i and sun50i_h3 platforms.
>>
>>>
>>>> However, due to internal alignment before the ARMv8 vectors, this breaks the sun50i builds (all exceeding their SPL size by up to approx. 1KB), even though I am adding only about a 100 bytes to the size of spl_fit.c.
>>>
>>> Yes, as per as my trails[1] it's not possible to increase SPL size.
>>
>> That is why I was suggesting to remove exceptions for sun50i for the time being, as the alignment for the vectors is more than 1kB in binary size.
>>
>>>> The change that triggers this is:
>>>>       https://patchwork.ozlabs.org/patch/813598/
>>>>
>>>> However, the root cause lies in the “.align 11” in exceptions.c, which generates a ‘*fill*’ similar to this one (and we have been lucky enough that this came out as a rather small number up until me increasing the size of spl_fit.o):
>>>>        *fill*         0x0000000000011214      0x5ec
>>>>        .text.vectors  0x0000000000011800      0x838 arch/arm/cpu/armv8/built-in.o
>>>>
>>>> The quickest way to resolve would be to drop support for exception vectors on sun50i.
>>>
>>> Don't we miss the exceptions during SPL?
>>>
>>>> Any other suggestions are also welcome.
>>>
>>> I would rather think to implement TPL provided if there is no option
>>> to increase the SPL size instead of missing exception vectors.
>>
>> Someone will have to do this eventually, as the sun50i platforms are becoming an issue for other platforms now.
>>
>>>
>>> [1] https://patchwork.ozlabs.org/patch/835973/
>>>
>>> thanks!
>>> -- 
>>> Jagan Teki
>>> Senior Linux Kernel Engineer | Amarula Solutions
>>> U-Boot, Linux | Upstream Maintainer
>>> Hyderabad, India.
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>