[coreboot] Strange corruption with printk

[Myles Watson]

> -----Original Message-----
> From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net]
> Sent: Monday, March 08, 2010 7:56 PM
> To: Myles Watson
> Cc: 'coreboot'
> Subject: Re: [coreboot] Strange corruption with printk
> 
> On 09.03.2010 03:16, Myles Watson wrote:
> >
> >> On 09.03.2010 00:18, Myles Watson wrote:
> >>
> >>> I divided the CAR copy into pieces to debug memory corruption that I'm
> >>> seeing.  It seems to fit a pattern, but I'm not sure what would be
> >>>
> >> causing
> >>
> >>> it.  Any ideas would be appreciated.
> >>>
> >>>
> >> To be honest, if post_cache_as_ram() works at all on K8, it is mostly
> >> luck.
> >>
> > :)
> >
> >
> >> The memory copy is not inline asm (will lead to subtle
> >> corruption), the memory copy and the stack switching are not in one
> >> inline asm block (gcc is free to insert arbitrary code in between), and
> >> the stack is switched in the middle of a function (gcc may use some
> >> non-clobbered regs to access the old stack, or simply die).
Interestingly enough, the corruption is before the stack switch.  I guess
you're saying that gcc is reordering instructions so that it corrupts part
of the loop?

I'll try adding some post codes before and after the copy.  gcc shouldn't
reorder around serializing instructions, right?

> >> Throwing out the complete v2 K8 CAR disabling code and replacing it
> with
> >> the v3 code is one of the possible fixes.
> >>
> > Unfortunately, v3 never worked for K8.
> >
> 
> IIRC CAR disable worked for K8 in v3, but later K8 init failed.
> Maybe it makes more sense to modify my suggestion above to "replace some
> of the code with v3". The three-stage-CAR-disable-jump design in v3 is
> something I believe to be superior to the stack switching in v2.
> Anyway, I think that having the stack copy inside the same asm statement
> as the stack switch could probably help.
I'll look into it.

Thanks,
Myles