-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I obtained some SAS PCIe card. I have some good and bad news ;)
1) it does not work at all, PCI ROM signature wrong. 2) it does work with some help glitch 3) it does not work as expected
I solved 1) with a simple hack patch (attached) The PCI ROM BARs should not be relocated. The K8 processor has some PCI hole resource and imho there is a problem that even the PCI hole starts at TOPMEM, it still hits RAM because of video framebuffer for integrated VGA.
I fixed this isssue by not touching PCI ROM base, check the patch.
2) It does work! PCI option rom get executed. This particular ROM has "press space to skip" option, and if I do that I get to grub/linux whatever.
3) If I do not press space, the PCI option rom is supposed to init the HW.
it just freezes somewhere inside, but keyboard IRQ still delivered.
With original BIOS, some other screen is printed with another screen mode, but it freezes too ;)))
Some remark to the end. I'm not sure if next_rom pointer should be adjusted before the rom is copied.
In my case VGA has someting like 36KB and with 2K align it gets to 0xCA000 for next ROM. I tried with ALIGN of 64KB but it does not help that particular silly option rom :) Maybe the align should be handled also depending on actual rom size. I mean "allow spaces for aligns between roms".
Rudolf
Here are some debug messages:
Attempting to find coreboot table Copying ACPI RSDP from 1bff0000 to 000ff330 init SMBIOS tables Found 1 cpu(s) SMBIOS table addr=0x000ff350 ram_size=0x1bff0000 Scan for VGA option rom Attempting to init PCI bdf 00000100 Copying option rom from fff80000 (ROM) to 000c0000 (RAM) Running option rom at 0000c000:00000003 fail handle_155fXX:47(00000086): a=00005f18 b=000002e4 c=00000000 d=000003c3 si=00000000 di=0000e261 ds=00000000 es=0000f000 ip=00008c26 cs=0000c000 f=00000006 r=00007926 Turning on vga console Starting SeaBIOS ... ... Attempting to map option rom on dev 000000c3 Option rom sizing returned 00000000 00000000 Attempting to init PCI bdf 00000200 Attempting to map option rom on dev 00000200 Option rom sizing returned f1100000 fffc0000 Card 00000200 option rom mapped at f1100000 Copying option rom from f1100000 (ROM) to 000d0000 (RAM) Running option rom at 0000d000:00000003 Changing serial settings was 00000003/00000002 now 00000003/00000000 Attempting to init PCI bdf 00000408 Attempting to map option rom on dev 00000408 Option rom sizing returned 00000000 00000000 Press F12 for boot menu.
Some example of PCI/MEMORY resources, from another computer via the k8resdump (check Coreboot util)
DRAM map: #0 0x0000000000 - 0x003fffffff Access: R/W IntlvEN:0x0 IntlvSEL:0x0 Dstnode:0 DRAM map: #1 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:1 DRAM map: #2 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:2 DRAM map: #3 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:3 DRAM map: #4 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:4 DRAM map: #5 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:5 DRAM map: #6 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:6 DRAM map: #7 0x0000000000 - 0x0000ffffff Access: / IntlvEN:0x0 IntlvSEL:0x0 Dstnode:7 MMIO map: #0 0x0000000000 - 0x000000ffff Access: / Dstnode:0 DstLink 0 MMIO map: #1 0x0000000000 - 0x000000ffff Access: / Dstnode:0 DstLink 0 MMIO map: #2 0x0000000000 - 0x000000ffff Access: / Dstnode:0 DstLink 0 MMIO map: #3 0x0000000000 - 0x000000ffff Access: / Dstnode:0 DstLink 0 MMIO map: #4 0x0000000000 - 0x000000ffff Access: / Dstnode:0 DstLink 0 MMIO map: #5 0x0000000000 - 0x000000ffff Access: / Dstnode:0 DstLink 0 MMIO map: #6 0x00000a0000 - 0x00000bffff Access: R/W Dstnode:0 DstLink 0 MMIO map: #7 0x0040000000 - 0x00ff70ffff Access: R/W Dstnode:0 DstLink 0 IO map: #0 0x000000 - 0x000fff Access: / Dstnode:0 DstLink 0 IO map: #1 0x001000 - 0x0fffff Access: R/W VGA Dstnode:0 DstLink 0 IO map: #2 0x000000 - 0x000fff Access: / Dstnode:0 DstLink 0 IO map: #3 0x000000 - 0x000fff Access: / Dstnode:0 DstLink 0
On Tue, Nov 25, 2008 at 12:15:48AM +0100, Rudolf Marek wrote:
Hello,
I obtained some SAS PCIe card. I have some good and bad news ;)
- it does not work at all, PCI ROM signature wrong.
- it does work with some help glitch
- it does not work as expected
I solved 1) with a simple hack patch (attached) The PCI ROM BARs should not be relocated. The K8 processor has some PCI hole resource and imho there is a problem that even the PCI hole starts at TOPMEM, it still hits RAM because of video framebuffer for integrated VGA.
Thanks. Does coreboot setup the option rom bar with a valid value? If so, this makes things easy - I can just enable the existing value. I didn't see any code in coreboot that did this though.
I fixed this isssue by not touching PCI ROM base, check the patch.
- It does work! PCI option rom get executed. This particular ROM has "press
space to skip" option, and if I do that I get to grub/linux whatever.
- If I do not press space, the PCI option rom is supposed to init the HW.
it just freezes somewhere inside, but keyboard IRQ still delivered.
Note that your patch doesn't seem to disable the mapping after the copy. This is definitely necessary. Maybe add something like:
pci_config_writel(bdf, PCI_ROM_ADDRESS, orig & ~PCI_ROM_ADDRESS_ENABLE);
Also, since the initial SeaBIOS support, I found the pci spec (google for "PCI Firmware Specification v3.0 (2005-06-20).pdf"), and it indicates that multiple firmware images can be in the rom - the BIOS needs to walk the list and find the right one depending on the PCI headers. Sigh - this stuff's never simple.
With original BIOS, some other screen is printed with another screen mode, but it freezes too ;)))
Some remark to the end. I'm not sure if next_rom pointer should be adjusted before the rom is copied.
In my case VGA has someting like 36KB and with 2K align it gets to 0xCA000 for next ROM. I tried with ALIGN of 64KB but it does not help that particular silly option rom :) Maybe the align should be handled also depending on actual rom size. I mean "allow spaces for aligns between roms".
As near as I can tell, the code that updates next_rom is correct. We don't want to increase next_rom until after the pnp init function is called, because that function can resize the rom.
The option roms should only require 2K alignment. The docs are pretty clear on that.
Thanks again, -Kevin
Thanks. Does coreboot setup the option rom bar with a valid value?
Yes it does.
If so, this makes things easy - I can just enable the existing value.
I think it may be enabled. Linux will disable the BAR.
here is a tip how to read option rom in linux:
cd /sys/bus/pci/devices/0000:02:00.0 echo enable > rom hexdump -C rom
Note that your patch doesn't seem to disable the mapping after the copy. This is definitely necessary. Maybe add something like:
pci_config_writel(bdf, PCI_ROM_ADDRESS, orig & ~PCI_ROM_ADDRESS_ENABLE);
Why we need it to disable? Just curious. Coreboot has assigned the address to it so we are sure we won't be hit by something else.
Also, since the initial SeaBIOS support, I found the pci spec (google for "PCI Firmware Specification v3.0 (2005-06-20).pdf"), and it indicates that multiple firmware images can be in the rom - the BIOS needs to walk the list and find the right one depending on the PCI headers. Sigh - this stuff's never simple.
Yep ok.
As near as I can tell, the code that updates next_rom is correct. We don't want to increase next_rom until after the pnp init function is called, because that function can resize the rom.
OK the behavior did not change anyway.
I can try to test with mine PCIe SATA card. Do you think it will correctly patch the BIOS so I will be at the end able to boot from it?
Rudolf
On Tue, Nov 25, 2008 at 11:38:29AM +0100, Rudolf Marek wrote:
Note that your patch doesn't seem to disable the mapping after the copy. This is definitely necessary. Maybe add something like:
pci_config_writel(bdf, PCI_ROM_ADDRESS, orig & ~PCI_ROM_ADDRESS_ENABLE);Why we need it to disable? Just curious. Coreboot has assigned the address to it so we are sure we won't be hit by something else.
PCI cards aren't required to support option rom BAR accesses at the same time as regular BAR accesses. So, one can't leave the option rom mapped while accessing the other mapped areas.
OK the behavior did not change anyway.
I can try to test with mine PCIe SATA card. Do you think it will correctly patch the BIOS so I will be at the end able to boot from it?
Well, it should work. :-)
-Kevin
On Tue, Nov 25, 2008 at 9:40 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Tue, Nov 25, 2008 at 11:38:29AM +0100, Rudolf Marek wrote:
Note that your patch doesn't seem to disable the mapping after the copy. This is definitely necessary. Maybe add something like:
pci_config_writel(bdf, PCI_ROM_ADDRESS, orig & ~PCI_ROM_ADDRESS_ENABLE);Why we need it to disable? Just curious. Coreboot has assigned the address to it so we are sure we won't be hit by something else.
PCI cards aren't required to support option rom BAR accesses at the same time as regular BAR accesses. So, one can't leave the option rom mapped while accessing the other mapped areas.
Not sure what this means, but the explanation is simpler. The coreboot code maps in the option rom by enabling the register, runs the ROM, and disables it.
Why disable it? Because we map all option ROMs at the same address -- see the code. What if there is more than one?
ron
On Wed, Nov 26, 2008 at 07:49:23AM -0800, ron minnich wrote:
On Tue, Nov 25, 2008 at 9:40 PM, Kevin O'Connor kevin@koconnor.net wrote:
PCI cards aren't required to support option rom BAR accesses at the same time as regular BAR accesses. So, one can't leave the option rom mapped while accessing the other mapped areas.
Not sure what this means, but the explanation is simpler.
I didn't do a good job of explaining the restriction. If one googles for "PCI Local Bus Specification v3.0 (2004-02-03).pdf" you'll find in section 6.2.5.2:
In order to minimize the number of address decoders needed, a device may share a decoder between the Expansion ROM Base Address register and other Base Address registers. When expansion ROM decode is enabled, the decoder is used for accesses to the expansion ROM and device independent software must not access the device through any other Base Address registers.
The coreboot code maps in the option rom by enabling the register, runs the ROM, and disables it.
Why disable it? Because we map all option ROMs at the same address -- see the code. What if there is more than one?
That is indeed an even simpler reason.
Thanks, -Kevin
On Wed, Nov 26, 2008 at 8:39 AM, Kevin O'Connor kevin@koconnor.net wrote:
In order to minimize the number of address decoders needed, a device may share a decoder between the Expansion ROM Base Address register and other Base Address registers. When expansion ROM decode is enabled, the decoder is used for accesses to the expansion ROM and device independent software must not access the device through any other Base Address registers.
Wow, I hope no hardware ever implemented that bad idea :-)
Anybody know? how is an expansion rom supposed to actually get to the hardware at that point, I wonder. ...
ron
On Wed, Nov 26, 2008 at 08:46:43AM -0800, ron minnich wrote:
On Wed, Nov 26, 2008 at 8:39 AM, Kevin O'Connor kevin@koconnor.net wrote:
In order to minimize the number of address decoders needed, a device may share a decoder between the Expansion ROM Base Address register and other Base Address registers. When expansion ROM decode is enabled, the decoder is used for accesses to the expansion ROM and device independent software must not access the device through any other Base Address registers.
Wow, I hope no hardware ever implemented that bad idea :-)
Anybody know? how is an expansion rom supposed to actually get to the hardware at that point, I wonder. ...
The steps are: enable option rom decode, copy option rom to memory, disable option rom decode, run option rom. So, the option rom runs when it can access the device.
If you're curious - google for "PCI Firmware Specification v3.0 (2005-06-20).pdf" and read section 5.2.
-Kevin
On Wed, Nov 26, 2008 at 8:58 AM, Kevin O'Connor kevin@koconnor.net wrote:
On Wed, Nov 26, 2008 at 08:46:43AM -0800, ron minnich wrote:
On Wed, Nov 26, 2008 at 8:39 AM, Kevin O'Connor kevin@koconnor.net wrote:
In order to minimize the number of address decoders needed, a device may share a decoder between the Expansion ROM Base Address register and other Base Address registers. When expansion ROM decode is enabled, the decoder is used for accesses to the expansion ROM and device independent software must not access the device through any other Base Address registers.
Wow, I hope no hardware ever implemented that bad idea :-)
Anybody know? how is an expansion rom supposed to actually get to the hardware at that point, I wonder. ...
The steps are: enable option rom decode, copy option rom to memory, disable option rom decode, run option rom. So, the option rom runs when it can access the device.
Yes, my mistake in the early days of this was assuming XIP for option roms ...
ron
On Tue, Nov 25, 2008 at 12:15:48AM +0100, Rudolf Marek wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I obtained some SAS PCIe card. I have some good and bad news ;)
Hi Rudolf,
Can you do a "git pull" of SeaBIOS and retry?
The latest code uses the memory address already setup in the option rom bar and I've added in support for detecting the PCI header in the option rom.
Also, as an aside, I finally fixed the keyboard LED problem and added support for ctrl+alt+del.
-Kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Can you do a "git pull" of SeaBIOS and retry?
Yes I did. I want to report success with a SAS card. At least now it goes through it. I can even enter the card setup. This is much better then with legacy BIOS, it will just HANG ;)
Great work! Thanks. I will test with some real HDD connected in some point in the future.
Rudolf
can someone start accumulating these "works with seabios/doesn't work with factory BIOS" examples? I'm working up a talk for SCALE feb. 22 and would love to have some slides on just this issue.
BTW, we have a table at SCALE! I'd love to have as many of you there as can make it.
thanks
ron
ron minnich wrote:
BTW, we have a table at SCALE! I'd love to have as many of you there as can make it.
What's the URL for the expo again?
//Peter
On Mon, Dec 8, 2008 at 4:48 PM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
BTW, we have a table at SCALE! I'd love to have as many of you there as can make it.
What's the URL for the expo again?
http://scale7x.socallinuxexpo.org/ and see this! http://scale7x.socallinuxexpo.org/conference-info/exhibitors
On Mon, Dec 08, 2008 at 04:56:29PM -0800, ron minnich wrote:
On Mon, Dec 8, 2008 at 4:48 PM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
BTW, we have a table at SCALE! I'd love to have as many of you there as can make it.
What's the URL for the expo again?
http://scale7x.socallinuxexpo.org/ and see this! http://scale7x.socallinuxexpo.org/conference-info/exhibitors
The benefits of having a 'brand' that starts with a letter low in the alphabet :)
Thanks, Ward.
On 09.12.2008 01:56, ron minnich wrote:
On Mon, Dec 8, 2008 at 4:48 PM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
BTW, we have a table at SCALE! I'd love to have as many of you there as can make it.
What's the URL for the expo again?
http://scale7x.socallinuxexpo.org/ and see this! http://scale7x.socallinuxexpo.org/conference-info/exhibitors
Cool. Which laptop will be running coreboot?
Regards, Carl-Daniel
On Tue, 09 Dec 2008 02:15:04 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
On 09.12.2008 01:56, ron minnich wrote:
On Mon, Dec 8, 2008 at 4:48 PM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
BTW, we have a table at SCALE! I'd love to have as many of you there as can make it.
What's the URL for the expo again?
http://scale7x.socallinuxexpo.org/ and see this! http://scale7x.socallinuxexpo.org/conference-info/exhibitors
Cool. Which laptop will be running coreboot?
We have a laptop that runs coreboot? Where have I been?
Also what is the "Safe Open Laptop project" I have heard anything about this?
ron minnich wrote:
can someone start accumulating these "works with seabios/doesn't work with factory BIOS" examples? I'm working up a talk for SCALE feb. 22 and would love to have some slides on just this issue.
Next is SMM issues with Xenomai. It creates unpredictable latencies.
Random link: http://www.captain.at/xenomai-smi-high-latency.php
Rudolf
-
Carl-Daniel Hailfinger -
Joseph Smith -
Kevin O'Connor -
Peter Stuge -
ron minnich -
Rudolf Marek -
Ward Vandewege