Kevin,
I have two sizes of flash chips because I have a BIOS savior. My 512K chip works fine, but my 1M chip doesn't.
Here's my setting from config.h
// When option roms are not pre-deployed, SeaBIOS can copy an optionrom // from flash for up to 2 devices. #define OPTIONROM_VENDEV_1 0x47521002 #define OPTIONROM_MEM_1 0xfff00000 /* 512K uses 0xfff80000 */
Either way it looks at fff80000 for the ROM. I did a hexdump of both builds, and the only difference is
1M: 00003590 04 50 ff 74 24 04 68 22 4b 0f 00 e8 b6 dd ff ff |.P.t$.h"K.......| 000035a0 83 c4 0c 81 7c 24 04 52 47 02 10 75 14 b8 00 00 |....|$.RG..u....| 000035b0 f0 ff e8 5f ff ff ff 89 c3 85 c0 0f 85 76 01 00 |..._.........v..| 000035c0 00 ff 34 24 68 4e 4b 0f 00 e8 88 dd ff ff 89 f0 |..4$hNK.........| 000035d0 0d 0c 00 00 80 ba f8 0c 00 00 ef b2 fe ec 0f b6 |................|
512K: 00003590 04 50 ff 74 24 04 68 22 4b 0f 00 e8 b6 dd ff ff |.P.t$.h"K.......| 000035a0 83 c4 0c 81 7c 24 04 52 47 02 10 75 14 b8 00 00 |....|$.RG..u....| 000035b0 f8 ff e8 5f ff ff ff 89 c3 85 c0 0f 85 76 01 00 |..._.........v..| 000035c0 00 ff 34 24 68 4e 4b 0f 00 e8 88 dd ff ff 89 f0 |..4$hNK.........| 000035d0 0d 0c 00 00 80 ba f8 0c 00 00 ef b2 fe ec 0f b6 |................|
Notice the byte at 35b0. I checked to make sure that the 1M version is the one in the 1M chip, but it won't work unless I put the video BIOS at fff80000. I put it in both places with dd since there was plenty of space, but I couldn't see a reason why it isn't working.
Do you have any debugging suggestions?
Thanks, Myles
PS I think a comment about the order of OPTIONROM_VENDEV_* would be helpful, since it is device then vendor ID. I know it matches the hardware, but I got it wrong the first time.
On Thu, Apr 16, 2009 at 11:35:56AM -0600, Myles Watson wrote:
I have two sizes of flash chips because I have a BIOS savior. My 512K chip works fine, but my 1M chip doesn't.
Here's my setting from config.h
// When option roms are not pre-deployed, SeaBIOS can copy an optionrom // from flash for up to 2 devices. #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".
Notice the byte at 35b0. I checked to make sure that the 1M version is the one in the 1M chip, but it won't work unless I put the video BIOS at fff80000. I put it in both places with dd since there was plenty of space, but I couldn't see a reason why it isn't working.
Do you have any debugging suggestions?
I committed a couple of more debug statements to the option rom scan. Can you do a "git pull", set the debug level to 6, and provide the output?
PS I think a comment about the order of OPTIONROM_VENDEV_* would be helpful, since it is device then vendor ID. I know it matches the hardware, but I got it wrong the first time.
I advise anyone using SeaBIOS to go over to CBFS. Having to recompile SeaBIOS just to use an option rom is a real chore. With CBFS that should be a thing of the past.
-Kevin
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:
I have two sizes of flash chips because I have a BIOS savior. My 512K chip works fine, but my 1M chip doesn't.
Here's my setting from config.h
// When option roms are not pre-deployed, SeaBIOS can copy an optionrom // from flash for up to 2 devices. #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.
myles@flying:svn$ lspci -nx -s 1:06 01:06.0 0300: 1002:4752 (rev 27) 00: 02 10 52 47 87 00 90 02 27 00 00 03 10 40 00 00 10: 00 00 00 fc 01 10 00 00 00 00 02 fd 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 08 80 30: 00 00 f8 ff 5c 00 00 00 00 00 00 00 00 01 08 00
myles@flying:svn$ lspci -x -s 1:06 01:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00: 02 10 52 47 87 00 90 02 27 00 00 03 10 40 00 00 10: 00 00 00 fc 01 10 00 00 00 00 02 fd 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 08 80 30: 00 00 f8 ff 5c 00 00 00 00 00 00 00 00 01 08 00
output: Attempting to init PCI bdf 00000130 (dev/ven 47521002) Attempting to map option rom on dev 00000130 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
Reading this output again makes me wonder if the problem I'm seeing with the address has to do with sizing the ROM register even though I provided an address.
Notice the byte at 35b0. I checked to make sure that the 1M version is the one in the 1M chip, but it won't work unless I put the video BIOS at fff80000. I put it in both places with dd since there was plenty of space, but I couldn't see a reason why it isn't working.
Do you have any debugging suggestions?
I committed a couple of more debug statements to the option rom scan. Can you do a "git pull", set the debug level to 6, and provide the output?
Will do.
PS I think a comment about the order of OPTIONROM_VENDEV_* would be helpful, since it is device then vendor ID. I know it matches the hardware, but I got it wrong the first time.
I advise anyone using SeaBIOS to go over to CBFS. Having to recompile SeaBIOS just to use an option rom is a real chore. With CBFS that should be a thing of the past.
Sounds good.
Thanks, Myles
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:
I have two sizes of flash chips because I have a BIOS savior. My 512K chip works fine, but my 1M chip doesn't.
Here's my setting from config.h
// When option roms are not pre-deployed, SeaBIOS can copy an optionrom // from flash for up to 2 devices. #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.
myles@flying:svn$ lspci -nx -s 1:06 01:06.0 0300: 1002:4752 (rev 27) 00: 02 10 52 47 87 00 90 02 27 00 00 03 10 40 00 00 10: 00 00 00 fc 01 10 00 00 00 00 02 fd 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 08 80 30: 00 00 f8 ff 5c 00 00 00 00 00 00 00 00 01 08 00
myles@flying:svn$ lspci -x -s 1:06 01:06.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 00: 02 10 52 47 87 00 90 02 27 00 00 03 10 40 00 00 10: 00 00 00 fc 01 10 00 00 00 00 02 fd 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 02 10 08 80 30: 00 00 f8 ff 5c 00 00 00 00 00 00 00 00 01 08 00
output: Attempting to init PCI bdf 00000130 (dev/ven 47521002) Attempting to map option rom on dev 00000130 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
Reading this output again makes me wonder if the problem I'm seeing with the address has to do with sizing the ROM register even though I provided an address.
Notice the byte at 35b0. I checked to make sure that the 1M version is the one in the 1M chip, but it won't work unless I put the video BIOS at fff80000. I put it in both places with dd since there was plenty of space, but I couldn't see a reason why it isn't working.
Do you have any debugging suggestions?
I committed a couple of more debug statements to the option rom scan. Can you do a "git pull", set the debug level to 6, and provide the output?
Will do.
Scan for VGA option rom Attempting to init PCI bdf 00000130 (dev/ven 47521002) Attempting to map option rom on dev 00000130 Option rom sizing returned fff80000 fffe0000 Inspecting possible rom at fff80000 (dv=47521002 bdf=00000130) No option rom signature (got 0000ffff) Turning on vga console Starting SeaBIOS
I don't think it's worth pursuing. Let's just use cbfs.
Thanks, Myles
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:
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.
-Kevin
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
-
Kevin O'Connor -
Myles Watson