Hi
I have put coreboot+seabios on an old Tyan S2895 I have just retired when the 2nd CPU socket stopped working probably because some of the caps are bulging... it is stable anyways on 1 CPU with Tyan BIOS.
Booting into Linux 3.2 amd64 on SATA - grub works fine and the drives are detected by the kernel but then I get lots of SATA errors, the USB root hubs are detected but no devices, I get no onboard ethernet...
One potential issue is when I booted the board under systemrescuecd flashrom can no longer see the chip... I shelled out $10 for a new chip but that may take a couple of weeks to wing it's way here from the USA.
I should put some new caps in but there is a chance I will brick the board very permanently doing that so if there is anything I can do to help fixup the S2985 port beforehand let me know, as maybe the board will end up in the trash if I can't use it for anything interesting.
Maybe I can hotswap and reflash the chip in another Tyan Opteron board of a similar vintage (I have a couple); is there a point in time where I can roll back to and have a better chance of building a coreboot that works better?
thanks
Andrew
On 02/03/13 17:54, Andrew Basterfield wrote:
Hi
I have put coreboot+seabios on an old Tyan S2895 I have just retired when the 2nd CPU socket stopped working probably because some of the caps are bulging... it is stable anyways on 1 CPU with Tyan BIOS.
Booting into Linux 3.2 amd64 on SATA - grub works fine and the drives are detected by the kernel but then I get lots of SATA errors, the USB root hubs are detected but no devices, I get no onboard ethernet...
One potential issue is when I booted the board under systemrescuecd flashrom can no longer see the chip... I shelled out $10 for a new chip but that may take a couple of weeks to wing it's way here from the USA.
I should put some new caps in but there is a chance I will brick the board very permanently doing that so if there is anything I can do to help fixup the S2985 port beforehand let me know, as maybe the board will end up in the trash if I can't use it for anything interesting.
Maybe I can hotswap and reflash the chip in another Tyan Opteron board of a similar vintage (I have a couple); is there a point in time where I can roll back to and have a better chance of building a coreboot that works better?
thanks
Andrew
I have been able to flash it back using the Tyan tool under FreeDOS, this is what the dmesg looks like with the Tyan BIOS
Andrew
On 02/03/13 22:27, Andrew Basterfield wrote:
On 02/03/13 17:54, Andrew Basterfield wrote:
Hi
I have put coreboot+seabios on an old Tyan S2895 I have just retired when the 2nd CPU socket stopped working probably because some of the caps are bulging... it is stable anyways on 1 CPU with Tyan BIOS.
Booting into Linux 3.2 amd64 on SATA - grub works fine and the drives are detected by the kernel but then I get lots of SATA errors, the USB root hubs are detected but no devices, I get no onboard ethernet...
One potential issue is when I booted the board under systemrescuecd flashrom can no longer see the chip... I shelled out $10 for a new chip but that may take a couple of weeks to wing it's way here from the USA.
I should put some new caps in but there is a chance I will brick the board very permanently doing that so if there is anything I can do to help fixup the S2985 port beforehand let me know, as maybe the board will end up in the trash if I can't use it for anything interesting.
Maybe I can hotswap and reflash the chip in another Tyan Opteron board of a similar vintage (I have a couple); is there a point in time where I can roll back to and have a better chance of building a coreboot that works better?
thanks
Andrew
I have been able to flash it back using the Tyan tool under FreeDOS, this is what the dmesg looks like with the Tyan BIOS
Andrew
As requested I have attached output of lspci under OEM BIOS and coreboot.
Due to the lack of CPU in socket #2 the board becomes a little crippled; 2nd PCIe slot and 2nd ethernet no are longer available; maybe coreboot would work OK with both sockets populated but the single socket configuration has not been encountered?
--Andrew
On 03/03/13 14:04, Andrew Basterfield wrote:
Due to the lack of CPU in socket #2 the board becomes a little crippled; 2nd PCIe slot and 2nd ethernet no are longer available; maybe coreboot would work OK with both sockets populated but the single socket configuration has not been encountered?
--Andrew
You took one CPU out because the board misbehaved. All bets are off. I would blame the lack of 2nd PCIe slot and 2nd ethernet on the same hardware fault that caused the 2nd CPU to misbehave. Different firmware is not going to fix faulty hardware. It may be just a fault in the single CPU configuration but you have no way to tell. The only thing you know for sure is that there is a hardware fault.
Andrew
On 03/03/13 14:18, Andrew Goodbody wrote:
On 03/03/13 14:04, Andrew Basterfield wrote:
Due to the lack of CPU in socket #2 the board becomes a little crippled; 2nd PCIe slot and 2nd ethernet no are longer available; maybe coreboot would work OK with both sockets populated but the single socket configuration has not been encountered?
--Andrew
You took one CPU out because the board misbehaved. All bets are off. I would blame the lack of 2nd PCIe slot and 2nd ethernet on the same hardware fault that caused the 2nd CPU to misbehave. Different firmware is not going to fix faulty hardware. It may be just a fault in the single CPU configuration but you have no way to tell. The only thing you know for sure is that there is a hardware fault.
Andrew
Hi Andrew
The lack of 2nd PCIe and ethernet is expected behavior when the 2nd socket is empty - please see the following
ftp://ftp.tyan.com/manuals/m_s2895_101.pdf
Please see 2nd 'NOTE' section 2.4 page 18
Looking at the system architecture section 2.2, page 9, it becomes clear why this is so.
I think I will have to re-cap the board to restore the 2nd CPU socket to eliminate this variable.
--Andrew
On 03/03/13 14:28, Andrew Basterfield wrote:
Hi Andrew
The lack of 2nd PCIe and ethernet is expected behavior when the 2nd socket is empty - please see the following
ftp://ftp.tyan.com/manuals/m_s2895_101.pdf
Please see 2nd 'NOTE' section 2.4 page 18
Looking at the system architecture section 2.2, page 9, it becomes clear why this is so.
Ooh, ugly. Sorry, I misunderstood what you were saying was the problem.
I think I will have to re-cap the board to restore the 2nd CPU socket to eliminate this variable.
--Andrew
You say it is stable with one CPU using the Tyan BIOS so it is at least possible to use the board as is. There is certainly code in the S2895 devtree and mptable to allow for the missing devices caused by a missing 2nd CPU but I have no idea how well tested that is. How does it behave if you boot with ACPI disabled?
Andrew
Am 03.03.2013 17:48 schrieb Andrew Goodbody:
On 03/03/13 14:28, Andrew Basterfield wrote:
I think I will have to re-cap the board to restore the 2nd CPU socket to eliminate this variable.
You say it is stable with one CPU using the Tyan BIOS so it is at least possible to use the board as is. There is certainly code in the S2895 devtree and mptable to allow for the missing devices caused by a missing 2nd CPU but I have no idea how well tested that is. How does it behave if you boot with ACPI disabled?
Can you try someting completely different? Make sure the total amount of RAM is 2 GB or less. Retry.
Failing SATA/USB was a symptom of some bug we hit on some AMD boards with configurations of more than 2 GB RAM a few years ago. Nobody ever managed to find out what was broken (the issue may also have fallen through the cracks in the big employment reshuffle which affected a few coreboot contributors back then). I simply gave up and used 2 GB.
If reducing the amount of RAM to 2 GB works for you, we can retry to debug this.
Regards, Carl-Daniel
On 03/03/13 16:48, Andrew Goodbody wrote:
On 03/03/13 14:28, Andrew Basterfield wrote:
Hi Andrew
The lack of 2nd PCIe and ethernet is expected behavior when the 2nd socket is empty - please see the following
ftp://ftp.tyan.com/manuals/m_s2895_101.pdf
Please see 2nd 'NOTE' section 2.4 page 18
Looking at the system architecture section 2.2, page 9, it becomes clear why this is so.
Ooh, ugly. Sorry, I misunderstood what you were saying was the problem.
I think I will have to re-cap the board to restore the 2nd CPU socket to eliminate this variable.
--Andrew
You say it is stable with one CPU using the Tyan BIOS so it is at least possible to use the board as is. There is certainly code in the S2895 devtree and mptable to allow for the missing devices caused by a missing 2nd CPU but I have no idea how well tested that is. How does it behave if you boot with ACPI disabled?
Andrew
Hi
It is much much better with ACPI disabled for the kernel; debian boots, I get SATA and USB although no onboard ethernet.
On 04/03/13 20:46, Andrew Basterfield wrote:
On 03/03/13 16:48, Andrew Goodbody wrote:
You say it is stable with one CPU using the Tyan BIOS so it is at least possible to use the board as is. There is certainly code in the S2895 devtree and mptable to allow for the missing devices caused by a missing 2nd CPU but I have no idea how well tested that is. How does it behave if you boot with ACPI disabled?
Andrew
Hi
It is much much better with ACPI disabled for the kernel; debian boots, I get SATA and USB although no onboard ethernet.
Looking at the two boot logs, the PCI resources allocated are very different. My big worry is about the reported differences on the IRQs in use. I'm not sure what more help I can be. I doubt that the missing CPU is affecting things too much, I just think that this board support code simply needs fixing. It would be helpful if anyone knew of any previous revision where it used to work?
Did you try Carl-Daniel's suggestion of booting with 2GB or less?
Andrew
On 04/03/13 23:21, Andrew Goodbody wrote:
On 04/03/13 20:46, Andrew Basterfield wrote:
On 03/03/13 16:48, Andrew Goodbody wrote:
You say it is stable with one CPU using the Tyan BIOS so it is at least possible to use the board as is. There is certainly code in the S2895 devtree and mptable to allow for the missing devices caused by a missing 2nd CPU but I have no idea how well tested that is. How does it behave if you boot with ACPI disabled?
Andrew
Hi
It is much much better with ACPI disabled for the kernel; debian boots, I get SATA and USB although no onboard ethernet.
Looking at the two boot logs, the PCI resources allocated are very different. My big worry is about the reported differences on the IRQs in use. I'm not sure what more help I can be. I doubt that the missing CPU is affecting things too much, I just think that this board support code simply needs fixing. It would be helpful if anyone knew of any previous revision where it used to work?
Did you try Carl-Daniel's suggestion of booting with 2GB or less?
Andrew
Hi
I have tried with 1GB and ACPI enabled and I got the same symptoms as all the RAM and ACPI enabled; i.e. it didn't help
thanks
Andrew
-
Andrew Basterfield -
Andrew Goodbody -
Carl-Daniel Hailfinger