[U-Boot] ARMv8 linking: how to properly accommodate the exception vector table?

[Andre Przywara]

On Wed, 20 Feb 2019 14:52:32 +0100
Alexander Graf <agraf at 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.

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

Cheers,
Andre.