[coreboot] [workaround found] locking...

Ward Vandewege ward at gnu.org
Wed Jun 24 21:02:01 CEST 2009

On Wed, Jun 24, 2009 at 12:51:29PM -0600, Myles Watson wrote:
> > So, I got it to boot by setting CONFIG_AP_CODE_IN_CAR to off. That way the
> > APs don't stumble over one another, and the machine boots just fine.
> > 
> > Here's the boot log:
> > 
> >   http://ward.vandewege.net/coreboot/h8dme/minicom-20090624g.cap
> > 
> > You'll see a couple garbled lines, but I think that's just each of the APs
> > saying they are ready.
> I'm glad it works, but it still looks broken to me.  Those lines look like
> ... TrainDQS RdWrPos1: ... in there.  

I think you are right. So, we really need to get some sort of printk locking in
there so that we can diagnose what's going on with less guesswork.

There's this comment in src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c:

  /* wait for all the APs core0 started by finalize_node_setup. */
  /* FIXME: A bunch of cores are going to start output to serial at once.
   * It would be nice to fixup prink spinlocks for ROM XIP mode.
   * I think it could be done by putting the spinlock flag in the cache
   * of the BSP located right after sysinfo.

I got a little lost in the whole locking discussion; is the above a way to
ungarble the output in this particular case?


Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator

More information about the coreboot mailing list