[U-Boot] sun50i blocking SPL changes

[U-Boot] sun50i blocking SPL changes

[Dr. Philipp Tomsich]

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

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.
Any other suggestions are also welcome.

Regards,
Philipp.

[U-Boot] sun50i blocking SPL changes

[Jagan Teki]

On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
<philipp.tomsich@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?

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

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

[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] sun50i blocking SPL changes

[Jagan Teki]

On Sat, Nov 25, 2017 at 2:06 AM, Jagan Teki <jagan@amarulasolutions.com> wrote:
> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
> <philipp.tomsich@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?
>
>> 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.
>
>>
>> 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.
>
> [1] https://patchwork.ozlabs.org/patch/835973/

+ Andre

[U-Boot] sun50i blocking SPL changes

[Dr. Philipp Tomsich]

> On 24 Nov 2017, at 21:36, Jagan Teki <jagan@amarulasolutions.com> wrote:
> 
> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
> <philipp.tomsich@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] sun50i blocking SPL changes

[Dr. Philipp Tomsich]

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.

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

Thanks,
Philipp.

> On 24 Nov 2017, at 21:42, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote:
> 
>> 
>> On 24 Nov 2017, at 21:36, Jagan Teki <jagan@amarulasolutions.com> wrote:
>> 
>> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>> <philipp.tomsich@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

[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@theobroma-systems.com> wrote:
>>
>>>
>>> On 24 Nov 2017, at 21:36, Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>
>>> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>>> <philipp.tomsich@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
> 

[U-Boot] sun50i blocking SPL changes

[Dr. Philipp Tomsich]

> On 26 Nov 2017, at 01:06, André Przywara <andre.przywara@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@theobroma-systems.com> wrote:
>>> 
>>>> 
>>>> On 24 Nov 2017, at 21:36, Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>> 
>>>> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>>>> <philipp.tomsich@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
>> 
> 

[U-Boot] sun50i blocking SPL changes

[André Przywara]

On 26/11/17 00:15, Dr. Philipp Tomsich wrote:
> 
>> On 26 Nov 2017, at 01:06, André Przywara <andre.przywara@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@theobroma-systems.com> wrote:
>>>>
>>>>>
>>>>> On 24 Nov 2017, at 21:36, Jagan Teki <jagan@amarulasolutions.com> wrote:
>>>>>
>>>>> On Sat, Nov 25, 2017 at 1:17 AM, Dr. Philipp Tomsich
>>>>> <philipp.tomsich@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
>>>
>>
>