[U-Boot] sun50i blocking SPL changes

Sun Nov 26 00:42:37 UTC 2017

On 26/11/17 00:15, Dr. Philipp Tomsich wrote:
> 
>> 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.

Ah, OK, thanks for the explanation.

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

Indeed, I just found this myself. I guess it's quite risky to play with
the linker script to find some more clever location with less padding
for the table, as the script covers *all* platforms with ARMv8 SPL support.
One thing I found is that our exception code is 136 bytes per entry,
which is just 8 bytes more than we could directly put into the table. So
we waste 124 bytes per entry by just placing a branch in there.
And apart from the register savings there is mostly our dynamic EL
determination that uses code, which I am not sure is useful in an
exception context at all. We should actually very much know which EL we
are in, for a given particular table entry.

I'll try tomorrow to bring this down to 32 instructions.

But apart from that I am wondering about the usefulness of the exception
table for the SPL in general. I guess we don't loose much if we just
drop it (somehow)?

Cheers,
Andre

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