Oskar Enoksson wrote:
Myles Watson wrote:
I think Myles was right, there is a i2c mux in this server that somehow multiplexes DIMM devices on the i2c bus. I was able to guess which i2c ports contain the DIMM info, and which port is the mux, then added the mux to devicetree.cb and the DIMM ports under it. Now I'm able to use memory from both CPU's, at least for the combination of DIMM's I have (2x2x1GB and 2x2x512MB).
I'm glad it worked out!
So I'm basically able to use these servers now. I would love to have ACPI and Cool'nQuiet of course, perhaps I'll try to do that later.
Thanks very much for all help! If you want me to commit the new mainboard to your svn repository let me know.
Yes, please. If you'll send your latest patch with a Signed-off-by: line, I'll take it from there.
Thanks, Myles
I hope this file is the way you want it. I did "svn cp src/mainboard/tyan/s2881 src/mainboard/hp/dl145_g1" and then modified the files, then "svn diff src/mainboard" so I assume you should do the same svn cp operation, then apply my patch, then commit to retain the original files' history.
I have fixed several problems and now it boots reliably for both and older dual Opteron 248 server and an upgraded dual Opteron 280 server.
memtest86+ doesn't work, but according to another mailinglist thread memtest cannot handle tables in high memory, so that seems to be a memtest issue.
Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.
Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.
Rev 5723.
Thanks for contributing! Myles
On 08/20/2010 10:39 PM, Myles Watson wrote:
Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.
Rev 5723.
Thanks for contributing! Myles
Hi. One year after contributing the port to HP DL145 G1 motherboard code I decided to see if I could improve it a little. However, now I can't make it work. I still have my compiled rom image from August 2010 (and it works fine) but when I try to compile a new image I get all kinds of problems.
Checking out and compiling the latest git-version of coreboot yields no output whatsoever on the serial console. Something is definitely very broken and there is no clue.
Checking out the version just after my commit 2010-08-20 compiles and seems to boot, but depending on how much debugging messages I choose in "make menuconfig" I get different problems such as just one of my two CPU's initializing, or just strange lockups. In general more debugging messages makes it more stable.
Since I believe I tried exactly the same sourcecode as I did successfully use one year ago I suspect something changed in my toolchain. I now use gcc 4.5.1 and binutils 2.21. I think I used an older version last year.
Question1: is there any known version of gcc/binutils that is known to work well with coreboot? Question2: is there any known revision of coreboot after 2010-08-20 that is known to work well on amdk8 platforms?
Thanks! /Oskar
Am Donnerstag, den 22.09.2011, 12:53 +0200 schrieb Oskar Enoksson:
[…]
Since I believe I tried exactly the same sourcecode as I did successfully use one year ago I suspect something changed in my toolchain. I now use gcc 4.5.1 and binutils 2.21. I think I used an older version last year.
Question1: is there any known version of gcc/binutils that is known to work well with coreboot?
coreboot even provides a know working tool chain [1].
Question2: is there any known revision of coreboot after 2010-08-20 that is known to work well on amdk8 platforms?
I heard the current HEAD works with ASUS M2V-MX SE.
Good luck. Thanks,
Paul
Oskar Enoksson wrote:
Checking out the version just after my commit 2010-08-20 compiles and seems to boot, but depending on how much debugging messages I choose in "make menuconfig" I get different problems such as just one of my two CPU's initializing, or just strange lockups. In general more debugging messages makes it more stable.
First I would recommend you to build the reference toolchain. Run
make crossgcc
in the top-level coreboot directory, with a recent checkout. The toolchain will be built in util/crossgcc/xgcc and will be automatically used from there next time you run make.
Next, please make sure to rm -rf build whenever you do git checkout. I don't think the Makefile dependencies are to be trusted completely.
Then, with fresh toolchain, and no build directory, please try the latest code again. If it does not work, then I would suggest trying your original commit. If that does work, as it should, then you can use git bisect to identify the point where things broke.
//Peter
Am 22.09.2011 12:53, schrieb Oskar Enoksson:
Checking out and compiling the latest git-version of coreboot yields no output whatsoever on the serial console. Something is definitely very broken and there is no clue.
It's possible that things are _very_ slow. This sometimes happens if printk is used before serial is properly setup. In this case, coreboot sometimes drives some semi-random IO port as serial, waiting for time outs all the time. Alternatively, the right IO ports are used, but the wrong configuration (eg. 1200baud, while everything else expects 115200).
It's also possible that things just hang at some point. Do you have a POST card? It should help you figure out if things move at all, and if not, where it hangs.
Checking out the version just after my commit 2010-08-20 compiles and seems to boot, but depending on how much debugging messages I choose in "make menuconfig" I get different problems such as just one of my two CPU's initializing, or just strange lockups.
You could try to use git bisect to figure the revision that breaks for you. For this, you'll need to find the git commit id for the svn rev of last year (see commit log, each git commit that was converted from svn contains the svn rev id there).
r5723 is git commit 37106a762a2158003c6267873fd6ebc1ec5d685e
In general, I think the best approach is to have upstream work at all again first (even with only one processor or strange lock ups), and then improve from there.
In general more debugging messages makes it more stable.
That indicates timing problems. The console code should ensure that side-effects by printk arguments are always executed.
Question1: is there any known version of gcc/binutils that is known to work well with coreboot?
The one built by "make crossgcc" (or entering util/crossgcc and running buildgcc there) is supposed to work.
Patrick
On 08/20/2010 10:39 PM, Myles Watson wrote:
Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.
Rev 5723.
Thanks for contributing! Myles
Hi. One year after contributing the port to HP DL145 G1 motherboard code I decided to see if I could improve it a little. However, now I can't make it work. I still have my compiled rom image from August 2010 (and it works fine) but when I try to compile a new image I get all kinds of problems.
First I checked out and compiled the latest git-version of coreboot. The result: no output whatsoever on the serial console. Something is very broken and there is no clue.
Checking out the version just after my commit 2010-08-20 compiles and seems to boot, but depending on how much debugging messages I choose in "make menuconfig" I get different problems. Sometimes one of my two CPU's will not initialize. Sometimes I just get unexplicable lockups. More debugging messages seems to make it more stable.
Since I believe I tried exactly the same sourcecode as I did successfully use one year ago I suspect a bug in my toolchain. I use gcc 4.5.1 and binutils 2.21. I think I used an older version last year.
Question1: is there any particular version of gcc/binutils that is recommended with coreboot? Any versions one should avoid?
Question2: is there any revision of coreboot after 2010-08-20 that is recommended to work well on amdk8 platforms?
Thanks! /Oskar
On 09/22/2011 07:45 PM, Oskar Enoksson wrote:
On 08/20/2010 10:39 PM, Myles Watson wrote:
Attached is a cleaned-up patch. Thanks to Myles and others for excellent help and support. I hope someone finds the result useful.
Rev 5723.
Thanks for contributing! Myles
Hi. One year after contributing the port to HP DL145 G1 motherboard code I decided to see if I could improve it a little. However, now I can't make it work. I still have my compiled rom image from August 2010 (and it works fine) but when I try to compile a new image I get all kinds of problems.
First I checked out and compiled the latest git-version of coreboot. The result: no output whatsoever on the serial console. Something is very broken and there is no clue.
Checking out the version just after my commit 2010-08-20 compiles and seems to boot, but depending on how much debugging messages I choose in "make menuconfig" I get different problems. Sometimes one of my two CPU's will not initialize. Sometimes I just get unexplicable lockups. More debugging messages seems to make it more stable.
Since I believe I tried exactly the same sourcecode as I did successfully use one year ago I suspect a bug in my toolchain. I use gcc 4.5.1 and binutils 2.21. I think I used an older version last year.
Question1: is there any particular version of gcc/binutils that is recommended with coreboot? Any versions one should avoid?
Question2: is there any revision of coreboot after 2010-08-20 that is recommended to work well on amdk8 platforms?
Update: moving forward a few days from 2010-08-20 made the debug-message-dependent lockup behaviour go away.
As for the "dead" behaviour in recent versions I bisected my way down to commit 1f7d3c5672ec90f8d71907b1a07c8a87fa461047 (svn 6124). That commit adds "TINY_BOOTBLOCK support" to AMD-8111 southbridge. I understand that this commit splits up things into a "romstage" and "coreboot_ram". But what is going wrong, and what should I do? All hints appreciated.
Thanks.
Am Freitag, 23. September 2011 01:45:09 schrieb Oskar Enoksson:
As for the "dead" behaviour in recent versions I bisected my way down to commit 1f7d3c5672ec90f8d71907b1a07c8a87fa461047 (svn 6124). That commit adds "TINY_BOOTBLOCK support" to AMD-8111 southbridge. I understand that this commit splits up things into a "romstage" and "coreboot_ram". But what is going wrong, and what should I do? All hints appreciated.
Try a smaller image size (and write it into flash top-aligned). If things work then, the bootblock doesn't correctly set up ROM mapping correctly.
Check src/northbridge/amd/amdfam10/bootblock.c and adapt that for your northbridge (amdk8, right?). For that you'll also need to add BOOTBLOCK_NORTHBRIDGE_INIT to amdk8's Kconfig (similar to amdfam10) to make the build system use it. Also check src/southbridge/amd/amd8111/bootblock.c - maybe the PCI ID doesn't match?
Patrick
Patrick Georgi wrote:
]Am Freitag, 23. September 2011 01:45:09 schrieb Oskar Enoksson: ]> As for the "dead" behaviour in recent versions I bisected my way down ]> to commit 1f7d3c5672ec90f8d71907b1a07c8a87fa461047 (svn 6124). That ]> commit adds "TINY_BOOTBLOCK support" to AMD-8111 southbridge. I ]> understand that this commit splits up things into a "romstage" and ]> "coreboot_ram". But what is going wrong, and what should I do? All ]> hints appreciated. ]Try a smaller image size (and write it into flash top-aligned). If ]things work then, the bootblock doesn't correctly set up ROM mapping ]correctly.
Hello Patrick,
That is a good point about rom mapping. According to the 8111 document, only the top 64KB is decoded by default. Simnow confirms this, and won't boot the DL145 G1coreboot image. Dumping the start of the 512KB image shows it is not decoded:
-d fff80000 FFF80000-FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
If I manually issue these PCI config writes while execution is still in the top 64KB, the entire 512KB is decoded and simnow will boot the coreboot image:
// write to AMD 8131 Link Command Register BUID field (bits 16-20) // with value 2 so that the 8111 can be accessed: -epcid 0 0 0 c0 00420008 // bus 0, dev 0, fun 0, reg 0xc0
// write to AMD 8111 Rom Decode Control Register and set bit 7 // to enable LPC memory decoding of the top 4MB of 4GB space: -epcib 0 1 0 43 80 // bus 0, dev 1, fun 0, reg 0x43
-d fff80000 FFF80000-4C 41 52 43 48 49 56 45 00 00 06 F0 00 00 01 AA LARCHIVE........
A couple of PCI config writes similar to these should get it going.
Thanks, Scott
Scott Duplichan wrote:
]the bootblock doesn't correctly set up ROM mapping correctly.
That is a good point about rom mapping. According to the 8111 document, only the top 64KB is decoded by default. Simnow confirms this, and won't boot the DL145 G1coreboot image.
Good find.
If I manually issue these PCI config writes while execution is still in the top 64KB, the entire 512KB is decoded and simnow will boot the coreboot image:
// write to AMD 8131 Link Command Register BUID field (bits 16-20) // with value 2 so that the 8111 can be accessed: -epcid 0 0 0 c0 00420008 // bus 0, dev 0, fun 0, reg 0xc0
Is it safe to blindly write this word in src/northbridge/amd/amdfam10/bootblock.c ? I think this is what is missing.
// write to AMD 8111 Rom Decode Control Register and set bit 7 // to enable LPC memory decoding of the top 4MB of 4GB space: -epcib 0 1 0 43 80 // bus 0, dev 1, fun 0, reg 0x43
This is already done in src/southbridge/amd/amd8111/bootblock.c for device id 1022:7468 - is this the correct device for that board?
amd8111/Kconfig has
config SOUTHBRIDGE_AMD_AMD8111 bool select IOAPIC select TINY_BOOTBLOCK
..and always pulls in bootblock.c. The function should get called. But I think the northbridge config that Scott points to may be missing.
//Peter
Peter Stuge wrote:
]> // write to AMD 8131 Link Command Register BUID field (bits 16-20) ]> // with value 2 so that the 8111 can be accessed: ]> -epcid 0 0 0 c0 00420008 // bus 0, dev 0, fun 0, reg 0xc0 ] ]Is it safe to blindly write this word in ]src/northbridge/amd/amdfam10/bootblock.c ? I think this is what is ]missing.
I am not sure if that is a good enough way or not. It has been a while since I worked with that generation chipset. This way also works with simnow:
dev = PCI_DEV(0, 0, 0); byte = pci_io_read_config8(dev, 0xc2); byte |= 2; /* set BUID in 8131 Link Command Register */ pci_io_write_config8(dev, 0xc2, byte);
]> // write to AMD 8111 Rom Decode Control Register and set bit 7 ]> // to enable LPC memory decoding of the top 4MB of 4GB space: ]> -epcib 0 1 0 43 80 // bus 0, dev 1, fun 0, reg 0x43 ] ]This is already done in src/southbridge/amd/amd8111/bootblock.c for ]device id 1022:7468 - is this the correct device for that board?
Oh yes, you are correct. That code runs very early, just a few instructions after reset. Adding only the above AMD8131 write lets it find and program the 8111 rom decode. The weird thing is that in simnow, it runs all the way through then loops in cbfs. If I remove this line: byte |= (1 << 6); /* Enable 0xFFB00000-0xFFBFFFFF (1MB). */ , then it continues. I suspect this is a simnow problem, because the FFB00000 range decode is needed for programming some LPC flash chip models.
Thanks, Scott
Following Patricks advice I created a file src/northbridge/amd/amdk8/bootblock.c and added the necessary config BOOTBLOCK_NORTHBRIDGE_INIT section to src/northbridge/amd/amdk8/Kconfig.
The only thing done in my northbridge bootblock.c is calling enumerate_ht_chain(). (I also removed that call from my mainboard's romstage.c).
And voila ... it works.
I'm guessing that the order in which things happened was wrong - enumerate_ht_chain must be called before amd8111_enable_rom. After 1f7d3c5672ec90f8d71907b1a07c8a87fa461047 (svn 6124) that order was reversed.
I will try to prepare a patch and submit to gerrit.
On 09/27/2011 04:46 AM, Scott Duplichan wrote:
Peter Stuge wrote:
]> // write to AMD 8131 Link Command Register BUID field (bits 16-20) ]> // with value 2 so that the 8111 can be accessed: ]> -epcid 0 0 0 c0 00420008 // bus 0, dev 0, fun 0, reg 0xc0 ] ]Is it safe to blindly write this word in ]src/northbridge/amd/amdfam10/bootblock.c ? I think this is what is ]missing.
I am not sure if that is a good enough way or not. It has been a while since I worked with that generation chipset. This way also works with simnow:
dev = PCI_DEV(0, 0, 0); byte = pci_io_read_config8(dev, 0xc2); byte |= 2; /* set BUID in 8131 Link Command Register */ pci_io_write_config8(dev, 0xc2, byte);
]> // write to AMD 8111 Rom Decode Control Register and set bit 7 ]> // to enable LPC memory decoding of the top 4MB of 4GB space: ]> -epcib 0 1 0 43 80 // bus 0, dev 1, fun 0, reg 0x43 ] ]This is already done in src/southbridge/amd/amd8111/bootblock.c for ]device id 1022:7468 - is this the correct device for that board?
Oh yes, you are correct. That code runs very early, just a few instructions after reset. Adding only the above AMD8131 write lets it find and program the 8111 rom decode. The weird thing is that in simnow, it runs all the way through then loops in cbfs. If I remove this line: byte |= (1<< 6); /* Enable 0xFFB00000-0xFFBFFFFF (1MB). */ , then it continues. I suspect this is a simnow problem, because the FFB00000 range decode is needed for programming some LPC flash chip models.
Thanks, Scott
-
Myles Watson -
Oskar Enoksson -
Patrick Georgi -
Paul Menzel -
Peter Stuge -
Scott Duplichan