[PATCH 05/10] powerpc: mpc8xx: Reorganise init RAM
Joakim Tjernlund
Joakim.Tjernlund at infinera.com
Thu May 4 13:28:21 CEST 2023
On Thu, 2023-05-04 at 10:17 +0000, Christophe Leroy wrote:
>
> Le 04/05/2023 à 12:07, Joakim Tjernlund a écrit :
> > On Thu, 2023-05-04 at 10:56 +0200, Christophe Leroy wrote:
> > > Using SMC relocation microcode patch or USB-SOF microcode patch
> > > will disable DPRAM memory from 0x2000 to 0x2400 and from 0x2f00
> > > to 0x3000.
> > >
> > > At the time being, init RAM is setup to use 0x2800-0x2e00, but
> > > the stack pointer goes beyond 0x2800 and even beyond 0x2400.
> > >
> > > For the time being we are not going to use any microcode patch
> > > that uses memory about 0x3000, so reorganise setup to use:
> > > - 0x2800 - 0x2e00 for init malloc and global data and CPM buffers
> > > - 0x3000 - 0x3c00 for init stack
> > >
> > > For more details about CPM dual port ram, see
> > > commit b1d62424cb ("powerpc: mpc8xx: redistribute data in CPM dpram")
> > >
> > > Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
> > > ---
> > > arch/powerpc/cpu/mpc8xx/start.S | 9 +++++----
> > > arch/powerpc/include/asm/cpm_8xx.h | 16 ++++++++--------
> > > include/configs/cmpc885.h | 1 +
> > > include/configs/mcr3000.h | 1 +
> > > 4 files changed, 15 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/arch/powerpc/cpu/mpc8xx/start.S b/arch/powerpc/cpu/mpc8xx/start.S
> > > index 0aa73fca12..41f12021c8 100644
> > > --- a/arch/powerpc/cpu/mpc8xx/start.S
> > > +++ b/arch/powerpc/cpu/mpc8xx/start.S
> > > @@ -141,14 +141,15 @@ in_flash:
> > > mtspr DER, r2
> > >
> > > /* set up the stack on top of internal DPRAM */
> > > + lis r1, CFG_SYS_INIT_SP at h
> > > + ori r1, r1, CFG_SYS_INIT_SP at l
> > > + stwu r0, -4(r1)
> > > + stwu r0, -4(r1)
> >
> > Changing stack ptr incrementally is likely to confuse gdb which may do stack accesses if you single step
> > over this code. It is better to setup the stack in a different reg and the just assign r1 when done.
> >
>
> Ok, I can change that. But we are at the very begining and r1 is
> undefined until now so it shouldn't matter.
Yes, but gdb will see r1 change and will try to parse stack when it changes. This only matters
when single stepping code in question.
I am unlikely to debug 8xx these days, just wanted to mention my past experience.
Jocke
More information about the U-Boot
mailing list