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 <[email protected]>
> > > ---
> > >   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@h
> > > + ori     r1, r1, CFG_SYS_INIT_SP@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

Reply via email to