[coreboot] OPTIONROM_MEM settings problem
kevin at koconnor.net
Sat Apr 18 02:34:27 CEST 2009
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 at gmail.com> wrote:
> > On Thu, Apr 16, 2009 at 6:52 PM, Kevin O'Connor <kevin at 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:
> > 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.
More information about the coreboot