Kevin,
SeaBIOS initializes my VGA correctly the first time through, but if I do ctrl-alt-delete, the screen is no longer updated. Do you have any suggestions as to how to fix it?
Here's the snippet: Attempting to map option rom on dev 02:00.0 Option rom sizing returned f5000000 fffe0000 Inspecting possible rom at 0xf5000000 (dv=014110de bdf=200) Copying option rom (size 63488) from 0xf5000000 to c0000 Checking rom 0x000c0000 (sig aa55 size 124) Found option rom with bad checksum: loc=0x000c0000 len=63488 sum=7e
The last line is the only new one. The others are exactly the same.
This is another difference, but it is apparently unrelated to VGA:
powerup iobase=1f0 st=50 powerup iobase=1f0 st=50 ata_detect ataid=0 sc=55 sn=aa dh=a0
The first time, st=0.
Thanks, Myles
On Thu, Oct 08, 2009 at 09:28:58AM -0600, Myles Watson wrote:
Kevin,
SeaBIOS initializes my VGA correctly the first time through, but if I do ctrl-alt-delete, the screen is no longer updated. Do you have any suggestions as to how to fix it?
Here's the snippet: Attempting to map option rom on dev 02:00.0 Option rom sizing returned f5000000 fffe0000 Inspecting possible rom at 0xf5000000 (dv=014110de bdf=200) Copying option rom (size 63488) from 0xf5000000 to c0000 Checking rom 0x000c0000 (sig aa55 size 124) Found option rom with bad checksum: loc=0x000c0000 len=63488 sum=7e
That's very odd. It seems the second time it is copied from the pci card it isn't copied correctly. To verify, you could add:
--- a/src/optionroms.c +++ b/src/optionroms.c @@ -124,6 +124,7 @@ is_valid_rom(struct rom_header *rom) if (! rom->size) return 0; u32 len = rom->size * 512; + hexdump(rom, len); u8 sum = checksum(rom, len); if (sum != 0) { dprintf(1, "Found option rom with bad checksum: loc=%p len=%d sum=%x\n"
and then compare the results of the two roms (it will probably take a long time to transfer all the data though).
I can see a couple of ways corruption could occur:
- something might be also using the memory space the rom is at (0xf5000000) causing corruption during the read
- maybe caching got enabled at the pci rom space?
- something could have locked the ram at 0xc000 (though that would be weird).
-Kevin
Hi,
That's very odd. It seems the second time it is copied from the pci card it isn't copied correctly. To verify, you could add:
Maybe because the decoders can be shared. Maybe a fix would be to disable the decoding of the BARs 0,1...?
Rudolf
On Fri, Oct 09, 2009 at 11:26:44AM +0200, Rudolf Marek wrote:
Hi,
That's very odd. It seems the second time it is copied from the pci card it isn't copied correctly. To verify, you could add:
Maybe because the decoders can be shared. Maybe a fix would be to disable the decoding of the BARs 0,1...?
Good catch Rudolf - that could be the problem.
Does coreboot disable all BARs at start? Would SeaBIOS have to remember which BARs it disabled and then reenable them after the optionrom is copied?
Also, does anyone know a reliable way to reset the machine? It might be simpler to have SeaBIOS just do a full reset when it detects a partial reset.
-Kevin
Does coreboot disable all BARs at start? Would SeaBIOS have to remember which BARs it disabled and then reenable them after the optionrom is copied?
The BARs are enabled when coreboot passes control to SeaBIOS. The expansion ROM may be an exception to that.
Since it works the first time, it seems like it must be something SeaBIOS or the expansion ROM code is doing to break it. Does the control pass to anyone else?
Also, does anyone know a reliable way to reset the machine? It might be simpler to have SeaBIOS just do a full reset when it detects a partial reset.
I actually like the partial reset, but maybe I'm in the minority.
At least on some K8-based machines coreboot will cause a reset if you jump to 0xfffffff0 because the reset bits weren't set correctly. I don't know if others work that way.
Thanks, Myles
Myles Watson wrote:
Since it works the first time, it seems like it must be something SeaBIOS or the expansion ROM code is doing to break it. Does the control pass to anyone else?
Maybe try doing the VGA BIOS init twice already on the first boot.
//Peter
On Fri, Oct 9, 2009 at 4:43 PM, Peter Stuge peter@stuge.se wrote:
Myles Watson wrote:
Since it works the first time, it seems like it must be something SeaBIOS or the expansion ROM code is doing to break it. Does the control pass to anyone else?
Maybe try doing the VGA BIOS init twice already on the first boot.
Good idea. That worked fine. It must be something else that I'm doing.
Thanks, Myles
On Fri, Oct 09, 2009 at 04:22:21PM -0600, Myles Watson wrote:
Does coreboot disable all BARs at start? Would SeaBIOS have to remember which BARs it disabled and then reenable them after the optionrom is copied?
The BARs are enabled when coreboot passes control to SeaBIOS. The expansion ROM may be an exception to that.
On closer read the spec says:
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.
It looks okay to have other BARs enabled while copying from the expansion rom - they just can't be used while copying. So, I don't think this would be the problem.
Since it works the first time, it seems like it must be something SeaBIOS or the expansion ROM code is doing to break it. Does the control pass to anyone else?
At what point do you hit ctrl-alt-delete? Can you send the full log of a session where you hit ctrl-alt-delete at the boot menu prompt?
Also, does anyone know a reliable way to reset the machine? It might be simpler to have SeaBIOS just do a full reset when it detects a partial reset.
I actually like the partial reset, but maybe I'm in the minority.
At least on some K8-based machines coreboot will cause a reset if you jump to 0xfffffff0 because the reset bits weren't set correctly. I don't know if others work that way.
I'd be a little leary of using a "trick" to reboot for fear of it causing more problems than it solves. If the above is a supported though, then it may be a simpler solution.
-Kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Kevin
You can do good old "keyboard reset" trick. kbd_wait(); outb(0xfe, 0x64);
This know working good.
Or throuh port 92h (less likely)
Or triple fault, which generates shutdown cycle.
load_idt(&no_idt); _asm__ __volatile__("int3");
Or port cf9 which seems bit like chipset standard at least VIA/Intel has it. Linux enables it if type 2 or 1 PCI config works.
u8 cf9 = inb(0xcf9) & ~6; outb(cf9|2, 0xcf9); /* Request hard reset */ udelay(50); outb(cf9|6, 0xcf9); /* Actually do the reset */ udelay(50);
Or we could provide a ACPI 3.0 reset register, so SeaBIOS can read this and do reset ;)
Rudolf
-
Kevin O'Connor -
Myles Watson -
Peter Stuge -
Rudolf Marek