[PATCH v4 2/9] board_f: Correct stack reservation

[Simon Glass]

Hi Heinrich,

On Sun, 3 Nov 2024 at 10:23, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 11/3/24 01:28, Simon Glass wrote:
> > The reserve_stack_aligned() function already ensures that the resulting
> > address is aligned to a 16-byte boundary. The comment seems to suggest
> > that 16 is passed reserve_stack_aligned() to make it aligned.
> >
> > Change the value to 0, since the stack can start at the current address,
> > if it is suitably aligned already.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> > (no changes since v1)
> >
> >   common/board_f.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/common/board_f.c b/common/board_f.c
> > index 98dc2591e1d..677e37d93c0 100644
> > --- a/common/board_f.c
> > +++ b/common/board_f.c
> > @@ -601,7 +601,7 @@ __weak int arch_reserve_stacks(void)
> >   static int reserve_stacks(void)
> >   {
> >       /* make stack pointer 16-byte aligned */
> > -     gd->start_addr_sp = reserve_stack_aligned(16);
> > +     gd->start_addr_sp = reserve_stack_aligned(0);
>
> In 1938f4a5b62f ("Introduce generic pre-relocation board_f.c") you wrote:
>
> /* setup stack pointer for exceptions */
> gd->dest_addr_sp -= 16;
> /* leave 3 words for abort-stack, plus 1 for alignment */
> gd->dest_addr_sp -= 16;
>
> Is that not relevant anymore?

Well that looks like ARM code that has moved to arch_reserve_stacks()
some time ago.

>
> Does all and every U-Boot architecture decrement the stack pointer
> before writing values to the stack?
>
> E.g. Microblaze, MIPS, RISC-V, and Super-H do not have a dedicated PUSH
> instruction.

I'm not sure about that, but they certainly need to. I see that
powerpc seems to write to values above the stack top! I don't think we
have enough people on this patch to look into powerpc, at least.

For RISC-V, does it use a full-descending stack, or empty? Looking at
relocate_code() I don't see it subtracting anything from the
stack-pointer that is passed in.

Regards,
SImon