On 02/20/2019 03:29 PM, Andre Przywara wrote:
On Wed, 20 Feb 2019 14:52:32 +0100
Alexander Graf <ag...@suse.de> wrote:

Hi Alex,

thanks for having a look!

On 02/20/2019 01:36 PM, Alexander Graf wrote:
On 02/20/2019 12:19 PM, Andre Przywara wrote:
Hi,

I was looking for a solution to some linker problem and was hoping that
some linker cracks here on the list have some idea:

The generic ARMv8 ("arm64") code provides an exception vector table,
which architecturally requires a 2KB alignment. At the moment we don't
take any special measures about it, so we end up with a random padding
between 0 and 2044 bytes before the table:

0 bytes                   n * 2KB
|                            |
   <code before table><padding>|<vector table> <code after table>

The vector table takes up a bit more than 1KB, so we happily use the
space after that and can't afford to just waste the rest of the 2KB slot
(by putting it at the end of the code, for instance).

Depending on the link order some code ends up before the table, other
behind it, with seemingly random effects on the resulting code size, due
to the padding.

This is quite annoying with the Allwinner SPLs, which are quite tight.
On the H6 it seems like most code additions lead to a build break at the
moment due to this, which needs fixing. Actually it should affect all
ARMv8 boards, but it might just not be critical for most of them.


I was wondering if we can tell the linker in the (SPL) linker script to
drop code into *two* possible regions, so that we can use a fixed
location for the vector table somewhere in the middle, and tell the
linker to fill up the space before *and* after that at will, without
requiring us to specify the exact link order of code.
I can *manually* arrange the code to make best use of the space, but
this is very fragile and breaks every so often, and is thus not
sustainable.

Another idea would be to put the exception table at the end of the image
(at least for sunxi), then fill the remaining <1KB with some data. But I
didn't find a low hanging fruit data block which fills the gap nicely.

If anyone has any ideas on how to overcome this, I would be very
grateful
to hear about it.
Can't you just put the exception table at 0x0 and make the first
instruction be the "b reset" from start.S? Then (if we need that
vector, I don't know) overwrite it with the real exception vector down
the road.
The first vector is "data abort from same EL", which is probably the only one 
we will ever need ;-)
That's why I dismissed this idea earlier. But indeed overwriting this one 
instruction might be an easy enough solution. But we have quite some fragile 
constructs as the first code, with some platforms (including sunxi) using those 
BOOT0 hooks, so it won't be trivial. Especially Allwinner does the switch to 
64-bit there. So it's a bit nasty to make everyone happy there, but I might 
give it a try.

A few more ideas:

* Set CONFIG_ARMV8_SPL_EXCEPTION_VECTORS=n for H6
Well yes, that's why I originally introduced it back then ;-) Back to be 
honest, I think it should be the kind of last resort solution.

* Move "init" code to the lower 2kb, then dynamically generate vectors
at a post-init step and set vbar to _start
I was thinking about this already, but felt like this was a quite involved 
solution for a rather small linker problem. At the end we need the exception 
vector code (position independent) plus some code for copying and/or patching 
and relocation. If the linker could just be convinced to layout the code more 
cleverly, we could save all that.

I double checked with out toolchain people and the GNU linker doesn't have those smarts.


Realistically, CONFIG_ARMV8_SPL_EXCEPTION_VECTORS is currently broken in
the tree though (ifdefs on ...ARMV8__SPL...), so we may as well default
it to n :). That should save quite some space across the board.
Doh! That's cute, thanks for spotting this! I am pretty sure I tested this, 
though, with some deliberate NULL pointer dereference, IIRC.

Well, it does work outside of SPL :)


Alex

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to