[U-Boot] sun50i blocking SPL changes

Sun Nov 26 00:15:02 UTC 2017

> On 26 Nov 2017, at 01:06, André Przywara <andre.przywara at arm.com> wrote:
> 
> 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).

It is related to, but not caused by, the Falcon boot support.  I need to
record the loadables into the FDT, so ATF is aware of some bits and
pieces (i.e. PMU firmware) that gets loaded.

As this needs to tie in with the Falcon changes, some refactoring was
needed before adding our new functionality—and this pushed sun50i
over the edge, even if only the refactoring was included.

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

Cleaning up the various code paths (and yes: this is related to Falcon
support in spl_fit.c) introduced a call to
	fit_image_get_os()
which adds a bit of bulk.

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

The exception vector alignment wastes approx. 1600 byte in sun50i
images, as of writing.

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