Messages in this thread | | | Date | Fri, 30 Jul 2004 21:14:48 +0200 | From | Vojtech Pavlik <> | Subject | Re: Exposing ROM's though sysfs |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |