Hi,
I have a S2912 system that I'd like to run coreboot on. As I understand it, both the S2912 and Fam10h is supported seperately, but some porting is required to make the combination work. I'd like to work on getting this configuration operational. If anyone has any pointers on how to tackle it, that would be more than welcome.
Thanks in advance,
Arne Georg Gleditsch wrote:
Hi,
I have a S2912 system that I'd like to run coreboot on. As I understand it, both the S2912 and Fam10h is supported seperately, but some porting is required to make the combination work. I'd like to work on getting this configuration operational. If anyone has any pointers on how to tackle it, that would be more than welcome.
Thanks in advance,
Hi Arne,
If you are prepared to do firmware development (socketed ROM, etc) the port should not be too difficult. The amd/serengeti_cheetah_fam10 mainboard should be a good example to work from. It is helpful if you have access to motherboard and chipset documents.
Marc
Marc Jones Marc.Jones@amd.com writes:
Hi Arne,
If you are prepared to do firmware development (socketed ROM, etc) the port should not be too difficult. The amd/serengeti_cheetah_fam10 mainboard should be a good example to work from. It is helpful if you have access to motherboard and chipset documents.
I have a RD1-PMC4 BIOS savior from a previos project that I've installed on the system. The vendor BIOS is twice the size of the BIOS Savior flash, but I'm not sure if this is important or not. The BIOS Savior has had coreboot installed previously.
I was kind of hoping that the presence of a regular S2912 port would make the need for mb/chipset docs less pressing. Pointers to relevant docs would be much appreciated. (I think I have most of what I need as far as platform/AMD docs go.)
Do you think it would make more sense to start out from the cheetah_fam10 codebase or the regular s2912 codebase? My initial impulse was to adapt the s2912 codebase according to the diff between the cheetah and cheetah_fam10 targets and see how far that got me.
Thanks!
Arne Georg Gleditsch wrote:
Marc Jones Marc.Jones@amd.com writes:
I have a RD1-PMC4 BIOS savior from a previos project that I've installed
My initial impulse was to adapt the s2912 codebase according to the diff between the cheetah and cheetah_fam10 targets and see how far that got me.
I think that is a good way to go. Marc
Marc Jones Marc.Jones@amd.com writes:
I think that is a good way to go.
That seems to have worked reasonably well. I can now get to
[..] PCI: 01:04.0 init rom address for PCI: 01:04.0 = fc000000 Incorrect Expansion ROM Header Signature 7070 Devices initialized i=0 bus range: [0, 4] bus_isa=5 Writing IRQ routing tables to 0xf0000...done. PCI: 00:01.0 missing resource: 14
which I'm not sure how to deal with, but by neutering find_resource I can actually get it to load FILO. Now, if I could just get FILO to find my disks...
Also, does anyone know if the VGA BIOS for the onboard ATI ES1000 is available anywhere?
Nice progress!
On Thu, Aug 07, 2008 at 04:02:29PM +0200, Arne Georg Gleditsch wrote:
Now, if I could just get FILO to find my disks...
Please enable DEBUG_PCI and DEBUG_IDE, and rebuild FILO.
Optionally also apply my pio4+debug6 patch for better IDE debugging:
http://stuge.se/filo.r49.ide_ext2_pio4_debug6.patch or http://stuge.se/filo.r52.ide_ext2_pio4_debug6.patch
And please send the output from that to the list.
//Peter
Peter Stuge peter@stuge.se writes:
Now, if I could just get FILO to find my disks...
Please enable DEBUG_PCI and DEBUG_IDE, and rebuild FILO.
It appears that PCI enumeration ordering issues were the root cause of FILO not finding the disks; I'm now able to get the kernel loaded. IRQ issues appear to throw the nv SATA driver off, though, so I'm not all the way there yet. I'll look into this more on Monday.
On Fri, Aug 08, 2008 at 03:50:05PM +0200, Arne Georg Gleditsch wrote:
Peter Stuge peter@stuge.se writes:
Now, if I could just get FILO to find my disks...
Please enable DEBUG_PCI and DEBUG_IDE, and rebuild FILO.
It appears that PCI enumeration ordering issues were the root cause of FILO not finding the disks; I'm now able to get the kernel loaded.
I'm glad you found the problem!
Could you share some details?
I committed a fix for one ordering problem in r49 of FILO, are you using an older version without that fix?
//Peter
Peter Stuge peter@stuge.se writes:
I'm glad you found the problem!
Could you share some details?
I committed a fix for one ordering problem in r49 of FILO, are you using an older version without that fix?
I was unclear; the problems were in coreboot, not FILO. For some reason the PCI device numbers were assigned in a fashion that was one off compared to the information in the Config.lb file I'd copied from the s2912 target. Not sure why, but once I corrected that (and dealt with the fallout), FILO found the disks ok.
Arne,
Please send the entire serial output with DEFAULT_CONSOLE_LOGLEVEL=8. I would like to see if there are any issues with the CPU init.
Thanks, Marc
Marc Jones Marc.Jones@amd.com writes:
Please send the entire serial output with DEFAULT_CONSOLE_LOGLEVEL=8. I would like to see if there are any issues with the CPU init.
Here you go. My current status is as follows:
* SATA controller: works, but only if vendor BIOS is allowed to run once after poweron. Not sure what the issue can be here, since the controller seems to work flawlessly both in FILO and Linux when the vendor BIOS is replaced with coreboot in flight and hard reset is applied. * Network controllers: work, but only with pci=nomsi kernel option. * PCIe addon cards are not discovered.
Attached: log from (failing) poweron run and (working) post-vendor cold reset run, as well as my diffs (initial copying of s2912 sources omitted for brevity).
The first issue is for me the most serious one, so any pointers on how to get that resolved would be appreciated.
Arne Georg Gleditsch arne.gleditsch@dolphinics.no writes:
Here you go. My current status is as follows:
- SATA controller: works, but only if vendor BIOS is allowed to run once after poweron. Not sure what the issue can be here, since the controller seems to work flawlessly both in FILO and Linux when the vendor BIOS is replaced with coreboot in flight and hard reset is applied.
As an additional data point, this is what the Linux kernel (here loaded from IDE cdrom) has to say about the SATA ports when they're not working:
[ 359.158098] sata_nv 0000:00:06.0: version 3.3 [ 359.158124] PCI: Setting latency timer of device 0000:00:06.0 to 64 [ 359.158182] ata1: SATA max UDMA/133 cmd 0x0000000000012cc0 ctl 0x0000000000013032 bmdma 0x0000000000012c90 irq 20 [ 359.158319] ata2: SATA max UDMA/133 cmd 0x0000000000012cd0 ctl 0x0000000000013042 bmdma 0x0000000000012c98 irq 20 [ 359.158435] scsi0 : sata_nv [ 359.473303] ata1: SATA link down (SStatus 0 SControl 300) [ 359.484085] ATA: abnormal status 0x7F on port 0x0000000000012cc7 [ 359.484172] scsi1 : sata_nv [ 359.796672] ata2: SATA link down (SStatus 0 SControl 300) [ 359.807446] ATA: abnormal status 0x7F on port 0x0000000000012cd7 [ 359.807572] PCI: Setting latency timer of device 0000:00:06.1 to 64 [ 359.807601] ata3: SATA max UDMA/133 cmd 0x0000000000012ce0 ctl 0x0000000000013052 bmdma 0x0000000000012ca0 irq 23 [ 359.807736] ata4: SATA max UDMA/133 cmd 0x0000000000012cf0 ctl 0x0000000000013062 bmdma 0x0000000000012ca8 irq 23 [ 359.807849] scsi2 : sata_nv [ 360.120043] ata3: SATA link down (SStatus 0 SControl 300) [ 360.130812] ATA: abnormal status 0x7F on port 0x0000000000012ce7 [ 360.130895] scsi3 : sata_nv [ 360.443414] ata4: SATA link down (SStatus 0 SControl 300) [ 360.454183] ATA: abnormal status 0x7F on port 0x0000000000012cf7 [ 360.454290] PCI: Setting latency timer of device 0000:00:06.2 to 64 [ 360.454315] ata5: SATA max UDMA/133 cmd 0x0000000000012d00 ctl 0x0000000000013072 bmdma 0x0000000000012cb0 irq 21 [ 360.454448] ata6: SATA max UDMA/133 cmd 0x0000000000013000 ctl 0x0000000000013082 bmdma 0x0000000000012cb8 irq 21 [ 360.454559] scsi4 : sata_nv [ 360.766785] ata5: SATA link down (SStatus 0 SControl 300) [ 360.777557] ATA: abnormal status 0x7F on port 0x0000000000012d07 [ 360.777640] scsi5 : sata_nv [ 361.090155] ata6: SATA link down (SStatus 0 SControl 300) [ 361.100932] ATA: abnormal status 0x7F on port 0x0000000000013007
Arne,
The log looks good from the CPU side. I didn't look at the diff. When it is ready you should submit it with a signed-off-by.
Marc
Arne Georg Gleditsch wrote:
Marc Jones Marc.Jones@amd.com writes:
Please send the entire serial output with DEFAULT_CONSOLE_LOGLEVEL=8. I would like to see if there are any issues with the CPU init.
Here you go. My current status is as follows:
- SATA controller: works, but only if vendor BIOS is allowed to run once after poweron. Not sure what the issue can be here, since the controller seems to work flawlessly both in FILO and Linux when the vendor BIOS is replaced with coreboot in flight and hard reset is applied.
- Network controllers: work, but only with pci=nomsi kernel option.
- PCIe addon cards are not discovered.
Attached: log from (failing) poweron run and (working) post-vendor cold reset run, as well as my diffs (initial copying of s2912 sources omitted for brevity).
The first issue is for me the most serious one, so any pointers on how to get that resolved would be appreciated.
Marc Jones marc.jones@amd.com writes:
The log looks good from the CPU side. I didn't look at the diff. When it is ready you should submit it with a signed-off-by.
Yep. I'd like to get some input on the SATA issues before I do so, though. If there's anyone with previous experience with the MCP55, ideally on the same mainboard, who could comment on how things work for them, that'd be great. It would be helpful to get some indication of whether the SATA issues in particular are caused by my changes or are inherent to the mainboard. (Unfortunately, I haven't got an appropriate CPU at hand myself, so I can't readily test the mainboard with the existing revF coreboot port.)
On Thu, Aug 14, 2008 at 11:20:20AM +0200, Arne Georg Gleditsch wrote:
Marc Jones marc.jones@amd.com writes:
The log looks good from the CPU side. I didn't look at the diff. When it is ready you should submit it with a signed-off-by.
Yep. I'd like to get some input on the SATA issues before I do so, though. If there's anyone with previous experience with the MCP55,
Oh wait, this is mcp55 too? I must have misread the datasheet for the board, somehow I thought it was serverworks.
ideally on the same mainboard, who could comment on how things work for them, that'd be great. It would be helpful to get some indication of whether the SATA issues in particular are caused by my changes or are inherent to the mainboard. (Unfortunately, I haven't got an appropriate CPU at hand myself, so I can't readily test the mainboard with the existing revF coreboot port.)
Right. I don't have your board, but I do have several different mcp55 boards (gigabyte m57sli, supermicro h8dmr) and sata works on both those boards (though I may not have tested quite all ports).
What was the issue you're seeing?
Thanks, Ward.
Ward Vandewege ward@gnu.org writes:
Right. I don't have your board, but I do have several different mcp55 boards (gigabyte m57sli, supermicro h8dmr) and sata works on both those boards (though I may not have tested quite all ports).
What was the issue you're seeing?
The ports were detected, but didn't work. It turns out, though, that this was caused by a rather embarrassing bug: I'd commented out the call to mcp55_early_setup_x during the transitional phase, and not added it back in again... Things seem to work much better now. :) I'll followup with my current patches.
Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
Signed-Off-By: Arne Georg Gleditsch arne.gleditsch@numascale.com
Arne Georg Gleditsch wrote:
Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
Signed-Off-By: Arne Georg Gleditsch arne.gleditsch@numascale.com
Thanks Arne!
Acked-by: Marc Jones marc.jones@amd.com
r3526
Arne Georg Gleditsch wrote:
Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
Why? Isn't it better to only have one target that supports both CPU types?
//Peter
Peter Stuge wrote:
Arne Georg Gleditsch wrote:
Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
Why? Isn't it better to only have one target that supports both CPU types?
The target has different build and cpu init requirements. We want to work towards a combined ROM that supports both CPUs but that doesn't exist yet.
Marc
On Tue, Sep 30, 2008 at 8:57 AM, Marc Jones Marc.Jones@amd.com wrote:
Peter Stuge wrote:
Arne Georg Gleditsch wrote:
Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
Why? Isn't it better to only have one target that supports both CPU types?
The target has different build and cpu init requirements. We want to work towards a combined ROM that supports both CPUs but that doesn't exist yet.
that should be a v3 effort anyway. It's fine to clone because it is easier to see the differences.
ron
Marc Jones wrote:
Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
Why?
The target has different build and cpu init requirements.
Ah targets/ is a copy, but src/mainboard/ has differences. Ok.
We want to work towards a combined ROM that supports both CPUs but that doesn't exist yet.
No problem. :)
//Peter
On 30.09.2008 19:17, Peter Stuge wrote:
Marc Jones wrote:
We want to work towards a combined ROM that supports both CPUs but that doesn't exist yet.
No problem. :)
I have combined K8+Fam10h CAR code on my disk. Expect a patch real soon now.
Regards, Carl-Daniel
On Fri, Aug 15, 2008 at 03:34:42PM +0200, Arne Georg Gleditsch wrote:
Ward Vandewege ward@gnu.org writes:
Right. I don't have your board, but I do have several different mcp55 boards (gigabyte m57sli, supermicro h8dmr) and sata works on both those boards (though I may not have tested quite all ports).
What was the issue you're seeing?
The ports were detected, but didn't work. It turns out, though, that this was caused by a rather embarrassing bug: I'd commented out the call to mcp55_early_setup_x during the transitional phase, and not added it back in again... Things seem to work much better now. :) I'll followup with my current patches.
Excellent! Look forward to them.
Thanks, Ward.
Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes. Port functional.
Signed-Off-By: Arne Georg Gleditsch arne.gleditsch@numascale.com
Arne Georg Gleditsch wrote:
Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes. Port functional.
Signed-Off-By: Arne Georg Gleditsch arne.gleditsch@numascale.com
I think that there is a missing file in this patch.
/home/marcj/svn/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c:249:22: error: spd_addr.h: No such file or directory
Marc
Marc Jones Marc.Jones@amd.com writes:
I think that there is a missing file in this patch.
/home/marcj/svn/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c:249:22: error: spd_addr.h: No such file or directory
Indeed, sorry. Patch appended; this file's derived more directly from the cheetah fam10 target.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numascale.com
Arne Georg Gleditsch wrote:
Marc Jones Marc.Jones@amd.com writes:
I think that there is a missing file in this patch.
/home/marcj/svn/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c:249:22: error: spd_addr.h: No such file or directory
Indeed, sorry. Patch appended; this file's derived more directly from the cheetah fam10 target.
Signed-off-by: Arne Georg Gleditsch arne.gleditsch@numascale.com
Thanks Arne!
Acked-by: Marc Jones marc.jones@amd.com
r3526
Arne Georg Gleditsch wrote:
Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes.
Arne Georg Gleditsch wrote:
I think that there is a missing file in this patch.
Indeed, sorry. Patch appended; this file's derived more directly from the cheetah fam10 target.
These two commits seem like really excellent candidates for a wiki page on adding fam10 support to k8 ports. If nothing else, just the revs would be useful.
//Peter
Arne Georg Gleditsch wrote:
Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes. Port functional.
Signed-Off-By: Arne Georg Gleditsch arne.gleditsch@numascale.com
Thanks Arne!
Acked-by: Marc Jones marc.jones@amd.com
r3526