Hi,
I have a strange problem trying to install/flash my Coreboot to several machines in the cluster some worked just fine and other hang at a really early moment. The machines are identical: H8QME-2+ with 16 GB RAM and 4 quadcore AMD Opterons 8350.
I guess that from the point where it hangs that it must be some kind of CPU issue (I haven't switched CPUs yet).
here the serial output:
coreboot-4.0-r5224M Wed Apr 28 12:50:59 CEST 2010 starting...
BSP Family_Model: 00100f22 *sysinfo range: [000cc000,000cdfa0] bsp_apicid = 00 cpu_init_detectedx = 00000000 After Set_sysinfo_in_ram microcode: equivalent rev id = 0x1022, current patch id = 0x00000000 microcode: patch id to apply = 0x01000095 microcode: updated to patch id = 0x01000095 success
After update_microcode cpuSetAMDMSR done After cpuSetAMDMSR Enter amd_ht_init() AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 00 01 AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 00 01 02 AMD_CB_EventNotify() event class: 05 event: 1004 data: 04 01 01 03 AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 00 02 ff AMD_CB_ManualBUIDSwapList() AMD_CB_EventNotify() event class: 05 event: 2006 data: 04 01 02 00 Exit amd_ht_init() After amd_ht_init cpuSetAMDPCI 00 done cpuSetAMDPCI 01 done cpuSetAMDPCI 02 done cpuSetAMDPCI 03 done Prep FID/VID Node:00 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001815 F3xDC: 00005428 Prep FID/VID Node:01 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001815 F3xDC: 00005428 Prep FID/VID Node:02 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001815 F3xDC: 00005428 Prep FID/VID Node:03 F3x80: e600a681 F3x84: a0e641e6 F3xD4: c3310f24 F3xD8: 03001815 F3xDC: 00005428 setup_remote_node: 01 done Start node 01 done. se tucpor_ere0:mo t e--_-no {de : A 0PI2C IdoDn =e 0S4 tNarODt EnIDod =e 0012 dCOoRnEeI. Dc or=see 00t0u: }p _ -r---e-m- o{t emi _cnAProIdocCeo:IDd 0e =3: ed08oqu nieNOvD alESetIDna rt =tr 0en2ov d iCed OR 0E3 =I Dd o0=nx1 e c.0020o2 }re,A -0 fct-: ue- rrr --efmi-nicn t{ ra lpoc iatzoAPcedeIh_:nC Ii oDddeq e u_== is e0v0ctxal u00peNO0ntD0 0 EArIF00eDT0Ev =R i d 0m si3 ecrtC= ouOR0cpo_Ex1dmID0eb _2:2 =r,ep 0 sato0cucu} rhr-cr ei-end-t tM poema sicstaprcapgoh leco iy dAd =e= :0 Mxee0x0squs010ia000vg0e0a0l0 90e0052nt0
rMmeeimiscvcsr oiracgdo coe ode=0de: 30: ux pp1M0eada2stct2shae,d g ecidt ur0 o r4tope anttaMce pphspasl itay dcg=e h= 0i0x04d b0x0=101 0M000x0e0s0090s00a5950g 0e 0m0is004curccoc c emioMsscdesreo: sca ogupdece dpu:0atS 4edeptadA t tMMcheoDM s psSidaaR tgcet d oh o0a5inepd p
Can someone please give me an advice on even how to start to narrow down the problem? I already started to put a 0 in Config Logical CPUs but no changes. :(
Thx,
Knut Kujat.
Hi,
I now know that I'm having the same trouble Ward had with his h8dme board: http://www.mail-archive.com/coreboot@coreboot.org/msg20923.html
Could anyone tell if and how he solved his problem?
Thanks,
Knut Kujat.
Hi Knut,
On Fri, Apr 30, 2010 at 10:29:59AM +0200, Knut Kujat wrote:
I now know that I'm having the same trouble Ward had with his h8dme board: http://www.mail-archive.com/coreboot@coreboot.org/msg20923.html
Could anyone tell if and how he solved his problem?
I have not. Unfortunately, I have had very little time for coreboot in the past few months, but I do still need fam10 support for h8dme - we have bunch of those machines that I need to upgrade to coreboot.
It's odd that you are seeing this only on some machines. I only have one h8dme test box; the others are in production. I have this problem 100% of the time on my test box. Perhaps figuring out why the problem occurs on only some of your machines would give a clue as to what could be going wrong?
Does it consistently happen on the machines where you see the hangs? And never on the others? And the hardware is identical?
Thanks, Ward.
Hi,
We 64 identical machines here for now I only tried to boot coreboot on 11 of them where 4 of them got this early hang. I switched the bootstrap processor from a machine that fails and put it into one that always boots with coreboot, now the machine which was failing before now boots perfectly and the other fails. Conclusion: Its the CPU!!
All machines here came with the B2 revision of the Opteron 8350 which has this weird TLB failure but we also have B3 revision processors here, so I installed a newer one and coreboot refuses to boot as well! :(
So the question is what could possibly be the difference between an Opteron 8350 B2 and another Opteron 8350 B2? I started to dump registers, and I'm not done yet, but so far they are all identical.
Ward Vandewege escribió:
Hi Knut,
On Fri, Apr 30, 2010 at 10:29:59AM +0200, Knut Kujat wrote:
I now know that I'm having the same trouble Ward had with his h8dme board: http://www.mail-archive.com/coreboot@coreboot.org/msg20923.html
Could anyone tell if and how he solved his problem?
I have not. Unfortunately, I have had very little time for coreboot in the past few months, but I do still need fam10 support for h8dme - we have bunch of those machines that I need to upgrade to coreboot.
It's odd that you are seeing this only on some machines. I only have one h8dme test box; the others are in production. I have this problem 100% of the time on my test box. Perhaps figuring out why the problem occurs on only some of your machines would give a clue as to what could be going wrong?
Does it consistently happen on the machines where you see the hangs? And never on the others? And the hardware is identical?
I have machines which boot with coreboot but after 4-5 tries (and when not booting they hang at the same spot), then I have machines that boots without any problem and directly and others which don't even after 20 and more restarts (switching machine off and on again).
Thanks, Ward.
Btw, thanks to your work on the h8dmr-fam10 I was able to even boot my machines, thanks for that! :)
Bye!
On 4/30/10 6:26 PM, Knut Kujat wrote:
Hi,
We 64 identical machines here for now I only tried to boot coreboot on 11 of them where 4 of them got this early hang. I switched the bootstrap processor from a machine that fails and put it into one that always boots with coreboot, now the machine which was failing before now boots perfectly and the other fails. Conclusion: Its the CPU!!
Is this the PCI access race condition?
How are the CPUs different?
Stefan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
There is a plenty of bugs as in all modern CPUs ;)
http://support.amd.com/us/Processor_TechDocs/41322.pdf
Quick look to coreboot shows they are not handled?
Some are easy to fix just to set some MSR, some are microcode fixes.
Thanks Rudolf
On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
There is a plenty of bugs as in all modern CPUs ;)
http://support.amd.com/us/Processor_TechDocs/41322.pdf
Quick look to coreboot shows they are not handled?
Some are easy to fix just to set some MSR, some are microcode fixes.
That Fam10 bugs should be handled in cpuSetAMDMSR as well as the microcode.
If it is a race condition, it should pass CONFIG_LOGICAL_CPUS = 0.
Marc
Marc Jones escribió:
On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
There is a plenty of bugs as in all modern CPUs ;)
http://support.amd.com/us/Processor_TechDocs/41322.pdf
Quick look to coreboot shows they are not handled?
Some are easy to fix just to set some MSR, some are microcode fixes.
That Fam10 bugs should be handled in cpuSetAMDMSR as well as the microcode.
If it is a race condition, it should pass CONFIG_LOGICAL_CPUS = 0.
Marc
Hi,
thx for your comments.
I already set Config_Logical_CPUS = 0 and set physical and logical CPUs to 1. This gets me a little further but still hangs before warm reset. As I already set I have the exact same problem as Ward reported some time ago.
Thanks, Knut Kujat.
Hi, I finally got it working, but I don't like my solution!
I noticed that after setup_mb_resource_map(); the board hang at outb and inl instructions. So I commented it out to see how far this will bring me. For my surprise the board booted right into Linux without further problems. Now my questions are:
- I now know that my resource map must be some kind of faulty. But why does it work on one CPU and doesn't on another, complete identical, one? - How do i manage to correct my resource map? Or how do I create a good resource map? - Since it seems to boot fine without resource map. Do I really need one? - And the last one, If I don't setup the res. map, who does it?
Thanks and sorry for the whole bunch of questions, Knut Kujat.
Knut Kujat escribió:
Marc Jones escribió:
On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.marek@assembler.cz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
There is a plenty of bugs as in all modern CPUs ;)
http://support.amd.com/us/Processor_TechDocs/41322.pdf
Quick look to coreboot shows they are not handled?
Some are easy to fix just to set some MSR, some are microcode fixes.
That Fam10 bugs should be handled in cpuSetAMDMSR as well as the microcode.
If it is a race condition, it should pass CONFIG_LOGICAL_CPUS = 0.
Marc
Hi,
thx for your comments.
I already set Config_Logical_CPUS = 0 and set physical and logical CPUs to 1. This gets me a little further but still hangs before warm reset. As I already set I have the exact same problem as Ward reported some time ago.
Thanks, Knut Kujat.
On Wed, May 5, 2010 at 12:39 AM, Knut Kujat knuku@gap.upv.es wrote:
- I now know that my resource map must be some kind of faulty. But why
does it work on one CPU and doesn't on another, complete identical, one?
It's not about the CPU, it is more about how the mainboard is wired up. And, it is not surprising that it might be wired differently on two mainboards with identical part #s. Supermicro does this type of change frequently. You would really need to boot the factory bios and dump the config registers on all cpus to see if they mainboard has changed somehow.
- How do i manage to correct my resource map? Or how do I create a good
resource map?
dump the factory bios.
- Since it seems to boot fine without resource map. Do I really need one?
you really need one.
- And the last one, If I don't setup the res. map, who does it?
nobody.
ron
I've had questions about resource maps too.
- I now know that my resource map must be some kind of faulty. But why
does it work on one CPU and doesn't on another, complete identical, one?
It's not about the CPU, it is more about how the mainboard is wired up. And, it is not surprising that it might be wired differently on two mainboards with identical part #s. Supermicro does this type of change frequently. You would really need to boot the factory bios and dump the config registers on all cpus to see if they mainboard has changed somehow.
The reason he got to that conclusion was that the same motherboard boots differently with a different CPU and the identical BIOS. I don't understand how it could be a wiring issue.
If the failure is consistent, can you use showallroutes(BIOS_INFO, PCI_DEV(0, 0x18, 1)); right before your resource map gets set. I think that might help us figure it out.
- How do i manage to correct my resource map? Or how do I create a good
resource map?
dump the factory bios.
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?
- Since it seems to boot fine without resource map. Do I really need
one?
I think the problem comes if values happen to be left over from a previous boot. I guess it could happen with different "default" values for different processors, too. Then devices that should be reachable won't respond.
you really need one.
- And the last one, If I don't setup the res. map, who does it?
nobody.
At least until resource allocation.
Thanks, Myles
On Wed, May 5, 2010 at 7:44 AM, Myles Watson mylesgw@gmail.com wrote:
The reason he got to that conclusion was that the same motherboard boots differently with a different CPU and the identical BIOS. I don't understand how it could be a wiring issue.
I went back and managed to misunderstand the post, I thought it was same motherboard type but two different boards.
Sorry.
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. 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?
ron
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
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
Hi, and thx for your replies so far. For what I understand now is that the resource map is needed for early initialization work and if I'm booting my boards without one it is just luck when they work?! Furthermore I understand that I can't use setpci to dump the vendor BIOS registers once booted into Linux. Then, unfortunately, my question still remains about how to set up a correct resource map for my board? Could anyone who has done one explain how he/she did it?
In the meantime I tried a different resource map from a fam10 board and it seems to work, but just because sun were shinning ??
Thanks and again sorry for all the question marks, Knut Kujat.
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
Since all of your devices are on the same HT chain in your devicetree.cb, a resourcemap should be pretty easy to do.
DRAM - All 0, but make sure to include the correct node numbers. MMIO - All (0xc0000000-0xffffffff) down link 2 of node 0. PCI-IO - All (0x0000-0xffff) on link 2 of node 0 PCI Bus numbers - All on link 2 of node 0
Hi, and thx for your replies so far. For what I understand now is that the resource map is needed for early initialization work and if I'm booting my boards without one it is just luck when they work?! Furthermore I understand that I can't use setpci to dump the vendor BIOS registers once booted into Linux.
In your case you can get most of it from Linux, just enable the whole ranges, and don't touch the DRAM registers unless you know how they interact with CAR.
Then, unfortunately, my question still remains about how to set up a correct resource map for my board? Could anyone who has done one explain how he/she did it?
I think the process should be: 1. Look at the register values from Linux 2. Set up the registers so that there is some MMIO, PCI I/O, bus resources for each link you want to touch before device enumeration (anything named early, especially). For ck804_early... It assumes that you allocate PCI I/O resources to each link in 16K blocks. Again, since you only have one non-coherent HT link, allocating the whole range there should work fine.
In the meantime I tried a different resource map from a fam10 board and it seems to work, but just because sun were shinning ??
Have you done showallroutes() before and after setting up your resource map? It will make it obvious why you need it on cold boot, and it could help you figure out what's missing. Try it on a working board and one that doesn't. I'd like to see the differences.
It would also help to know what address range is failing on inb and outb. That would tell you which register you need to play with.
Thanks, Myles
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: For the good working CPU and the resource map adopted from H8DMR it this: After finalize_node_setup 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), , ,VGA 0 ISA 0 PCIIO(c8)0000000-0000fff, ->(0,0), , ,VGA 0 ISA 0 PCIIO(d0)0000000-0000fff, ->(0,0), , ,VGA 0 ISA 0 CONFIG(e0)00-05 ->(0,2),R W (bus numbers) 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 finalize_node_setup DRAM(40)0000000000-0000ffffff, ->(0), R, W, No interleave, 0 DRAM(48)0000000000-f800ffffff, ->(2), , , No interleave, 0 DRAM(50)0000000000-26acffffff, ->(0), , , No interleave, 0 DRAM(58)0000000000-a725ffffff, ->(4), , , No interleave, 0 DRAM(60)0000000000-c520ffffff, ->(0), , , No interleave, 1 DRAM(68)0000000000-7861ffffff, ->(3), , , No interleave, 3 DRAM(70)0000000000-0c84ffffff, ->(1), , , No interleave, 2 DRAM(78)0000000000-4992ffffff, ->(3), , , No interleave, 1 MMIO(80)0000000000-0bf611ffff, ->(6,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(88)0000000000-05d30cffff, ->(7,1), , , CPU disable 0, Lock 0, Non posted 1 MMIO(90)0000000000-1100b9ffff, ->(5,2), , , CPU disable 0, Lock 0, Non posted 1 MMIO(98)0000000000-a0d18effff, ->(1,1), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)0000000000-584dd4ffff, ->(2,0), , , CPU disable 0, Lock 0, Non posted 1 MMIO(a8)0000000000-3a9903ffff, ->(3,3), , , CPU disable 0, Lock 0, Non posted 1 MMIO(b0)0000000000-1f36f0ffff, ->(5,1), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)0000000000-9686b0ffff, ->(1,0), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)0000000-0e20fff, ->(6,0), , ,VGA 0 ISA 0 PCIIO(c8)0000000-1e65fff, ->(2,2), , ,VGA 0 ISA 0 PCIIO(d0)0000000-0782fff, ->(4,3), , ,VGA 0 ISA 0 PCIIO(d8)0000000-0819fff, ->(1,1), , ,VGA 0 ISA 0 CONFIG(e0)00-05 ->(0,2),R W (bus numbers) 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 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. thanks and bye, Knut Kujat.
-----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
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.
It looks like your resourcemap.c is for k8, not fam10. There's an extra bit in fam10 that controls ganged links. Since it's listed as reserved in your resource map, it should never get cleared, which could cause you problems, but only sporadically (depending on how that bit floats).
That's probably the reason all the 0 registers show up.
Thanks, Myles
On 5/3/10 12:59 AM, Rudolf Marek wrote:
Hi,
There is a plenty of bugs as in all modern CPUs ;)
http://support.amd.com/us/Processor_TechDocs/41322.pdf
Quick look to coreboot shows they are not handled?
Some are easy to fix just to set some MSR, some are microcode fixes.
Thanks Rudolf
I thin we should look into this during the Fam10/RS780 porting GSoC, too. Stefan
-
Knut Kujat -
Marc Jones -
Myles Watson -
ron minnich -
Rudolf Marek -
Stefan Reinauer -
Ward Vandewege