Rework register usage in early boot code

[danh-arm]

The very early boot code in BL1 and BL3-1 needs to be reviewed regarding register usage. Currently we are relying on all functions collaborating to not step on each other's toes - this needs to be validated.

This task is motivated by the "TODO" comment in plat/fvp/aarch64/bl1_plat_helpers.S:

// TODO: Not a good idea to save lr in a temp reg

LR is saved in x9, which is a caller-saved register according to the AAPCS and thus x9 should be saved by the caller of platform_get_entrypoint(). This is not done currently but BL1 reset code doesn't use x9 so it's OK. Ideally LR should be pushed on the stack but we don't have stack at this point of time.

One solution is to define a convention of register usage in the early boot code (even if it's not AAPCS compliant) and stick to it.

[tixy]

How about specifying that a small number of registers (3 say) to be used as a stack, e.g.

function:
    /* Push LR */
    mov x27, x28
    mov x28, x29
    mov x29, x30

    /* Function body which can call other functions */

    /* Pop LR */
    mov x30, x29
    mov x29, x28
    mov x28, x27
    adr x27, debug_build_call_nesting_overflow_panic
    ret

And if we only need three levels of nesting we could get away with reserving two registers instead. Also, the push/pop code could be an assembler macro.

This solution would waste some text section space with the extra instructions, but is more maintainable than trying to pick specific register usage for specific functions.

[athoelke]

I'm not sure there are enough functions used at this stage in the code to warrant a systematic solution. I think step one is to fully review the current situation and make a proposal (or set of proposals for discussion. I would definitely like to make sure this code is not a maintenance hazard - by better coding and/or documentation.

[tixy]

Also, bear in mind some of these early boot functions are implemented in platform specific code, so whatever convention is used should be as clear and robust as possible for people doing porting work. People who quite possibly have never looked at the TF code before and have been given just a few weeks to port it.