On Fri, Apr 17, 2009 at 6:34 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Fri, Apr 17, 2009 at 10:56:25AM -0600, Myles Watson wrote:
On Fri, Apr 17, 2009 at 7:59 AM, Myles Watson mylesgw@gmail.com wrote:
On Thu, Apr 16, 2009 at 6:52 PM, Kevin O'Connor kevin@koconnor.net wrote:
On Thu, Apr 16, 2009 at 11:35:56AM -0600, Myles Watson wrote:
#define OPTIONROM_VENDEV_1 0x47521002 #define OPTIONROM_MEM_1 0xfff00000 /* 512K uses 0xfff80000 */
Looks like you have that backwards. If "lspci -vnn" reports 1002:4752 then you should set OPTIONROM_VENDEV_1 to "0x10024752".
That's what I thought the first time. 0x47521002 works for me, 0x10024752 doesn't.
[...]
output: Attempting to init PCI bdf 00000130 (dev/ven 47521002) Attempting to map option rom on dev 00000130
You're seeing an interesting coreboot/seabios interaction here. Since you didn't specify VENDEV correctly (it needs to be 0x10024752), SeaBIOS doesn't try to fetch the rom from the MEM location. Instead, SeaBIOS tries to map the rom in from the pci device. It looks like Coreboot set the PCI_ROM_ADDRESS field of the device to 0xfff80000:
Yes. I hadn't realized that Coreboot would set that field to the value in Config.lb.
Option rom sizing returned fff80000 fffe0000 Inspecting possible rom at fff80000 (dv=47521002 bdf=000001300) Copying option rom from fff80000 to 000c0000 Running option rom at 0000c000:00000003
When SeaBIOS mapped the rom of the card, it was actually completing reads from flash and things appeard to work correctly.
I should probably just ban PCI rom addresses that look like flash addresses. Anyone know if it is safe to ban the last 16MiB of virtual address space (0xff000000 - 0xffffffff)?
It's not clear why it was not working with VENDEV set to 0x10024752 - if you want to find out, send the log with it set.
I probably just messed something up. It works now. Sorry for the confusion.
Thanks, Myles