[coreboot] H8QME-2+ boot problems on different machines.

Myles Watson mylesgw at gmail.com
Thu May 6 13:14:38 CEST 2010



> -----Original Message-----
> From: Knut Kujat [mailto:knuku at gap.upv.es]
> Sent: Thursday, May 06, 2010 2:20 AM
> To: Myles Watson
> Cc: 'ron minnich'; 'coreboot'
> Subject: Re: [coreboot] H8QME-2+ boot problems on different machines.
> 
> Myles Watson escribió:
> >
> >
> >>> I think this can be problematic, since by the time you can dump the
> >>>
> >> factory
> >>
> >>> BIOS resource allocation has already occurred.  The resource map is
> only
> >>> good for early initialization, before resource allocation, right?
> >>>
> >> hmm. I had always used the bios map as a starting point and it had
> >> worked well for me.
> >>
> >
> > I think most of the time it should work fine, but we have some hard-
> coded
> > addresses where the chipset is expected to live in early setup routines,
> and
> > they might break.
> >
> > My resource map sets:
> > DRAM mappings for each node
> > MMIO mappings for each HT chain
> > PCI IO mappings for each HT chain
> > PCI Bus numbers for each HT chain
> >
> > I think they should only be needed for things like
> ck804_early_setup_car.c,
> > where I/O is being used and set up.  If the mappings aren't configured
> the
> > reads and writes don't reach the chipset.
> >
> >
> >> But maybe things are much harder now. It is true that you need to do a
> bit
> >> of
> >> interpretation of the map once the factory BIOS has set it up.
> >>
> >> Does resource allocation get all the bits, even legacy ones? Are there
> >> not some resource map values that
> >> a resource allocator can not figure out?
> >>
> >
> > I don't know.  Once resource allocation is done you should know where
> your
> > VGA card is, and where your Southbridge is.  I'm probably missing
> something,
> > but I think once resource allocation is done all of the registers that
> are
> > touched in the resource map have been rewritten.
> >
> > Thanks,
> > Myles
> >
> >
> >
> Sorry I forgot to add the showroutes output:
Thanks for sending it.

> For the good working CPU and the resource map adopted from H8DMR it this:
> AFTER  setup_mb_resource
> DRAM(40)0000000000-0000ffffff, ->(0), R, W, No interleave, 0
> MMIO(90)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(98)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(a8)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(b8)0000000000-033e26ffff, ->(5,1), , , CPU disable 0, Lock 0, Non
> posted 1
> PCIIO(c0)0000000-1ffffff, ->(0,2), R, W,VGA 1 ISA 1
> PCIIO(c8)0000000-0000fff, ->(0,0), , ,VGA 0 ISA 0
> PCIIO(d0)0000000-0000fff, ->(0,0), , ,VGA 0 ISA 0
> CONFIG(e0)00-3f ->(0,2),R W (bus numbers)
> 
> And for the Not so good working CPU:
> AFTER  setup_mb_resource
> DRAM(40)0000000000-0000ffffff, ->(0), R, W, No interleave, 0
> MMIO(80)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(90)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(98)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(a0)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(a8)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
> MMIO(b0)0000000000-000000ffff, ->(0,0), , , CPU disable 0, Lock 0, Non
> posted 0
I wonder why all those registers show up.  They shouldn't print if they're
zeroed.  Maybe you could print the raw register values, too.  The docs are
available, and most of the meanings are copied into resourcemap.c.

> MMIO(b8)0000000000-9686b0ffff, ->(1,0), , , CPU disable 0, Lock 0, Non
> posted 1


> PCIIO(c0)0000000-1ffffff, ->(0,2), R, W,VGA 1 ISA 1
> CONFIG(e0)00-3f ->(0,2),R W (bus numbers)
> 
> Notice that I haven't switched CPU but used 2 different boards for this
> capture.
Were these both for a cold boot?  The first one looks like a lot fewer
registers changed.

You could compare what happens with the other resource map that works for
you.

Good luck,
Myles





More information about the coreboot mailing list