On Wed, 2003-03-19 at 01:07, Jon Smirl wrote:

Here is a description of how to control the shadow
write protect for a SIS chipset. It is done by writing
to PCI config space. There is a slim chance that this
is a standard procedure.

http://www.missl.cs.umd.edu/Projects/sebos/winint/index1.html

I tried this part, and it doesn't work with the chipset I'm using. 
Plus, PCI config space register 0x70 is device specific, only the first
64 bytes is defined generically.

When you copied to 8000 ot 9000, did you copy the ROM
or the image at C000? I compared a dump of C000 to the
ROM and they don't match. ATI may have overlaid some
code during the init procedure.

I copied the actual ROM (pointed to by Expansion ROM base address 0x30)
and placed it in 0xc000 and 0x8000.  0xc000 of course is write protected
by the BIOS, and it won't run in 0x8000.

Yes, the final BIOS image can be different from the initial image.  Most
of the time, the initial image is larger, or needs decompression.  Some 
of the newer ROM's may even use the POST Memory Manager Specification
(kinda like a POST-specific malloc and family) during INIT, but this is
available only during POST, and memory allocated by the PMM is
unavailable after POST.

So I guess we are stuck with a user space daemon.
Athlon-64 and IA64 will require the entire VM86
emulator. Last I checked the scitech emulator (ver8)
han't implemented all of the instructions needed to
run the ATI ROMs so it will need some work.

How do the Transmeta tools work? Could we turn the
ROMs into a C program and compile them again? Or use
something like use an emulator to capture the reset
sequence and then compile it for protected mode. 

That's another problem.  Some of the BIOS services used during INIT may
become unavailable after POST, so emulating ROM's can either be caused
by this or by an incomplete emulator.
 

I tried a couple of reverse engineering tools on the
ROMs but I didn't get very far. I don't have access to
the ATI Radeon documentation so it is hard for me to
tell what is going on.  

Our best hope is for graphics manufacturer to drop VGA :-) which should
allow for relocatable ROM's and therefore initialization of multiple
graphics adapters.  Second best hope is for manufacturer's to open up
the source for initializing devices without having to initialize the VGA
BIOS. 

Anyway, attached is the code I'm using.  It basically saves the video
state, disables all VGA controllers, disables VGA routing on PCI-PCI
bridges, searches for valid expansion ROM addresss on VGA class devices,
copies it into a scratch segment, verifies the ROM, copies the verified
ROM to 0xc000 and call 0xc000:0003.  Of course, the "copies the verified
ROM to 0xc000" part will fail, so the "call 0xc000:0003" will just
warmboot your primary display again.

You have to place the file in linux/arch/i386/boot

Then in setup.S

add "include detect.S"

and 

call init_video #preferably before or after 'call video'

I'll probably drop effort on this (for now) and concentrate on adding a
userspace daemon.

Tony