Re: Exposing ROM's though sysfs

[Vojtech Pavlik <vojtech@suse.cz>]

On Fri, Jul 30, 2004 at 10:24:33AM -0700, Jon Smirl wrote:
> --- Torrey Hoffman <thoffman@arnor.net> wrote:
> > This sounds interesting, but I'm curious...  why?  That is, what
> > problem are you solving by making ROMs exposed?
> > 
> > Or is this just for fun?  (That's a legitimate reason IMO...)
> 
> Secondary video cards need to have code in their ROMs run to reset
> them. When an x86 PC boots it only reset the primary video device, the
> secondary ones won't work until their ROMs are run.
> 
> Another group needing this is laptop suspend/resume. Some cards won't
> come back from suspend until their ROM is run to reinitialize them.

Another trick laptops can do is that after a resume the card is in
uninitialized state _and_ the video ROM is not there, because the system
BIOS didn't copy it to the right location (when it's stored in a shared
flash). Then you definitely need your own copy from the real boot.

> A third group is undocumented video hotware where the only way to set
> the screen mode is by calling INT10 in the video ROMs. (Intel
> i810,830,915 for example).
> 
> Small apps are attached to the hotplug events. These apps then use vm86
> or emu86 to run the ROMs. emu86 is needed for ia64 or ppc when running
> x86 ROMs on them.

I'm starting to think that using emu86 always (independent on the
architecture) would be best. It's not like the execution speed is the
limit with video init, and it'll allow to find more bugs in emu86 when
it's used on i386 as well. It'll be needed for x86-64 (AMD64 and intel
EM64T) anyway.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR