About Hardreset on Opteron MB

Eric W. Biederman ebiederman at lnxi.com
Tue Nov 18 17:39:00 CET 2003


Stefan Reinauer <stepan at suse.de> writes:

> * YhLu <YhLu at tyan.com> [031118 22:50]:
> > I have checked the latest code again for Opteron MB. The MB still needs to
> > reset three times to get it done.
> 
> > Can we only reset the MB only time to make the HT work at the need
> > speed/width?
>  
> It should be enough to set a global variable "reset_needed" (maybe even
> in CMOS) and check this, probably after all device drivers have been
> executed and thus had the chance to set that flag.
> 
> > I mean only enable the reset in 
> > PCI: 00:19.3 init
> > NB: Function 3 Misc Control.. resetting cpu
>   
> When changing the parameters on Solo I always got it to one of the
> reboots - My best result was to get it to the Misc Control reset before
> it would hang hard.

Reducing the number of reboots definitely needs to happen.  I only coded
the way it is currently because that generates obviously correct code.

Right now I am looking at how to reduce problems when a board has
a noisy smbus.  So far I have not seen a single board without one.
In the noisy smbus the more traffic you have the more chances there
are you will have problems because of it.

So it might make sense to set everything up in a very early pass before
memory reset.  Reset the system, and then let the existing resets will
not trigger.

Either that or Stefans delayed scheme.   At this point I am not certain
which will be easier to maintain.  If we do implement the delayed reset
I want to move the memory clear code up into the generic framework so we
don't have to clear memory twice.  But if we can get the resets over with
before we initialize memory we are in better shape.  That plus something
like the kernels quirk interface to handle the various know bits of buggy
hardware and we should be ok.

Eric



More information about the coreboot mailing list