-----Original Message----- From: Knut Kujat [mailto:knuku@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