Patchwork SeaBIOS VGA failure after ctrl-alt-delete

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:


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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrQgRQACgkQ3J9wPJqZRNXcqgCgsx2YEaSb+KzYrJiekpIdxtrW
exMAoJ9JWBxQrFUaTTYsk55m4BBLwrh3
=HXyC
-----END PGP SIGNATURE-----