Fam10h support for Tyan S2912-E

[Arne Georg Gleditsch]

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,

[Marc Jones]

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

[Arne Georg Gleditsch]

Marc Jones  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!

[Marc Jones]

Arne Georg Gleditsch wrote:
> Marc Jones  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

[Arne Georg Gleditsch]

Marc Jones  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?

[Peter Stuge]

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

[Arne Georg Gleditsch]

Peter Stuge  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.

[Peter Stuge]

On Fri, Aug 08, 2008 at 03:50:05PM +0200, Arne Georg Gleditsch wrote:
> Peter Stuge  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

[Arne Georg Gleditsch]

Peter Stuge  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.

[Marc Jones]

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

[Arne Georg Gleditsch]

Marc Jones  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 Georg Gleditsch  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

[Marc Jones]

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  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]

Marc Jones  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.)

[Ward Vandewege]

On Thu, Aug 14, 2008 at 11:20:20AM +0200, Arne Georg Gleditsch wrote:
> Marc Jones  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.

[Arne Georg Gleditsch]

Ward Vandewege  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.

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[Arne Georg Gleditsch]

Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.

Signed-Off-By: Arne Georg Gleditsch

[Ward Vandewege]

On Fri, Aug 15, 2008 at 03:34:42PM +0200, Arne Georg Gleditsch wrote:
> Ward Vandewege  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.

[PATCH] Fam10h support for Tyan S2912-E (2/2)

[Arne Georg Gleditsch]

Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes.
Port functional.

Signed-Off-By: Arne Georg Gleditsch

[PATCH] Fam10h support for Tyan S2912-E (2/2)

[Marc Jones]

Arne Georg Gleditsch wrote:
> Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes.
> Port functional.
>
> Signed-Off-By: Arne Georg Gleditsch

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

[PATCH] Fam10h support for Tyan S2912-E (2/2)

[Arne Georg Gleditsch]

Marc Jones  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

[PATCH] Fam10h support for Tyan S2912-E (2/2)

[Marc Jones]

Arne Georg Gleditsch wrote:
> Marc Jones  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

Thanks Arne!

Acked-by: Marc Jones

r3526

[PATCH] Fam10h support for Tyan S2912-E (2/2)

[Marc Jones]

Arne Georg Gleditsch wrote:
> Adjust s2912_fam10 port according to serengeti_cheetah_fam10 changes.
> Port functional.
>
> Signed-Off-By: Arne Georg Gleditsch

Thanks Arne!

Acked-by: Marc Jones

r3526

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[Marc Jones]

Arne Georg Gleditsch wrote:
> Create new tyan/s2912_fam10 target as verbatim copy of tyan/s2912.
>
> Signed-Off-By: Arne Georg Gleditsch

Thanks Arne!

Acked-by: Marc Jones

r3526

[PATCH] Fam10h support for Tyan S2912-E (2/2)

[Peter Stuge]

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

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[Peter Stuge]

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

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[Marc Jones]

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

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[ron minnich]

On Tue, Sep 30, 2008 at 8:57 AM, Marc Jones  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

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[Peter Stuge]

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

[PATCH] Fam10h support for Tyan S2912-E (1/2)

[Carl-Daniel Hailfinger]

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