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 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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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: For the good working CPU and the resource map adopted from H8DMR it this: After finalize_node_setup DRAM(40)00-ff, -(0), R, W, No interleave, 0 MMIO(90)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-033e26, -(5,1), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, -(0,2), , ,VGA 0 ISA 0 PCIIO(c8)000-fff, -(0,0), , ,VGA 0 ISA 0 PCIIO(d0)000-fff, -(0,0), , ,VGA 0 ISA 0 CONFIG(e0)00-05 -(0,2),R W (bus numbers) AFTER setup_mb_resource DRAM(40)00-ff, -(0), R, W, No interleave, 0 MMIO(90)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-033e26, -(5,1), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, -(0,2), R, W,VGA 1 ISA 1 PCIIO(c8)000-fff, -(0,0), , ,VGA 0 ISA 0 PCIIO(d0)000-fff, -(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)00-ff, -(0), R, W, No interleave, 0 DRAM(48)00-f800ff, -(2), , , No interleave, 0 DRAM(50)00-26acff, -(0), , , No interleave, 0 DRAM(58)00-a725ff, -(4), , , No interleave, 0 DRAM(60)00-c520ff, -(0), , , No interleave, 1 DRAM(68)00-7861ff, -(3), , , No interleave, 3 DRAM(70)00-0c84ff, -(1), , , No interleave, 2 DRAM(78)00-4992ff, -(3), , , No interleave, 1 MMIO(80)00-0bf611, -(6,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(88)00-05d30c, -(7,1), , , CPU disable 0, Lock 0, Non posted 1 MMIO(90)00-1100b9, -(5,2), , , CPU disable 0, Lock 0, Non posted 1 MMIO(98)00-a0d18e, -(1,1), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-584dd4, -(2,0), , , CPU disable 0, Lock 0, Non posted 1 MMIO(a8)00-3a9903, -(3,3), , , CPU disable 0, Lock 0, Non posted 1 MMIO(b0)00-1f36f0, -(5,1), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-9686b0, -(1,0), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-0e20fff, -(6,0), , ,VGA 0 ISA 0 PCIIO(c8)000-1e65fff, -(2,2), , ,VGA 0 ISA 0 PCIIO(d0)000-0782fff, -(4,3), , ,VGA 0 ISA 0 PCIIO(d8)000-0819fff, -(1,1), , ,VGA 0 ISA 0 CONFIG(e0)00-05 -(0,2),R W (bus numbers) AFTER setup_mb_resource DRAM(40)00-ff, -(0), R, W, No interleave, 0 MMIO(80)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(90)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b0)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-9686b0, -(1,0), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, -(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
Re: [coreboot] H8QME-2+ boot problems on different machines.
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 (0xc000-0x) down link 2 of node 0. PCI-IO - All (0x-0x) 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
-Original Message- From: Knut Kujat [mailto:kn...@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)00-ff, -(0), R, W, No interleave, 0 MMIO(90)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b8)00-033e26, -(5,1), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, -(0,2), R, W,VGA 1 ISA 1 PCIIO(c8)000-fff, -(0,0), , ,VGA 0 ISA 0 PCIIO(d0)000-fff, -(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)00-ff, -(0), R, W, No interleave, 0 MMIO(80)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(90)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b0)00-00, -(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)00-9686b0, -(1,0), , , CPU disable 0, Lock 0, Non posted 1 PCIIO(c0)000-1ff, -(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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
And for the Not so good working CPU: AFTER setup_mb_resource DRAM(40)00-ff, -(0), R, W, No interleave, 0 MMIO(80)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(90)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(98)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a0)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(a8)00-00, -(0,0), , , CPU disable 0, Lock 0, Non posted 0 MMIO(b0)00-00, -(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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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.ma...@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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
On Wed, May 5, 2010 at 12:39 AM, Knut Kujat kn...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
On Wed, May 5, 2010 at 7:44 AM, Myles Watson myle...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
Marc Jones escribió: On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.ma...@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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
-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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkveA98ACgkQ3J9wPJqZRNUdLgCfccGDWGCy2LwChVO8f3W8m/aO DYwAn1NaRs7lm26RDHvGI5bBxilCEoZd =0bW1 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
On Sun, May 2, 2010 at 4:59 PM, Rudolf Marek r.ma...@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 -- http://se-eng.com -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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. -- Ward Vandewege w...@fsf.org Free Software Foundation - Senior Systems Administrator -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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! -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] H8QME-2+ boot problems on different machines.
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 -- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: i...@coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] H8QME-2+ boot problems on different machines.
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 =
After Set_sysinfo_in_ram
microcode: equivalent rev id = 0x1022, current patch id = 0x
microcode: patch id to apply = 0x0195
microcode: updated to patch id = 0x0195 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: 5428
Prep FID/VID Node:01
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
Prep FID/VID Node:02
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
Prep FID/VID Node:03
F3x80: e600a681
F3x84: a0e641e6
F3xD4: c3310f24
F3xD8: 03001815
F3xDC: 5428
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{ ralpoc 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.
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
