[PATCH] i386 probe_roms(): preparation
From: Rene Herman <rene.herman@keyaccess.nl> The i386 probe_roms() function has a fair number of problems currently: - When you actually have an adapter ROM in the machine, your video ROM disappears. This is due to the pc9800 subarch merge that split it up in probe_video_rom(int roms) and probe_extension_roms(int roms), but expects a "roms++" in probe_video_roms() to have an effect outside of that function. - The majority of VGA adapters these days host a ROM larger then 32K, yet the current code hardcodes a 32K ROM. The VGA BIOS "length" byte is normally valid (it in fact needs to be for a regular mainboard BIOS to accept it) and I've verified on a few dozen very new to very old VGAs that it is. However, assuming someone actually did not check for the length and checksum there for a reason, the safe thing to do here is accept the length byte when we also get a valid checksum. - The current code scans 0xc0000 to 0xdffff for a video ROM while the standard PC thing to do (that which the BIOS does) is only scan for a video ROM starting between 0xc0000 and 0xc7fff. This means that on a headless- (or BIOS-less monochrome adapter-) box, the first adapter ROM found triggers the registration of a 32K "Video ROM" at hardcoded address 0xc0000, even when _nothing_ is present between 0xc0000 and 0xc7fff. - The current adapter ROM scan stops at 0xdffff, whether or not an extension ROM is present at 0xe0000. The PC thing to do is scan 0xc8000 upto 0xdffff if an extension ROM is present, and upto 0xeffff when it's not (it's not/hardly ever). - Adapter ROMs are called "Extension ROM", but the latter term is really better reserved for a motherboard extension ROM. - Currently, the code happily starts scanning through a ROM it just registered looking for the next one (just does += 2048, even when that's inside the previous ROM) which is at least silly. Unfortunately, this code is "subarched" between mach-default and mach-pc9800, meaning the patch got a bit involved. Currently all this code, and gobs of data, is defined (not just declared) in the header: include/asm-i386/mach-{default,pc9800}/mach_resources.h which isn't nice. That .h really wants to be a .c. The first patch, in the next message, does not change any code but only undoes the probe_video_rom / probe_extension_roms split and moves the code to a new file arch/i386/mach-{default,pc9800}/std_resources.c with a header include/asm-i386/std_resources.h for the prototypes only. The second patch overhauls the code itself for mach-default. Please see comments on top of that patch for (yet more) comments. It's tested on various machines, with and without adapter ROMs. I haven't touched pc9800. Nothing should have changed though. The pc9800 author, as given in the code, is CCed. Also, x86-64 inherits the probe_roms() code from 2.4, and while it doesn't have the subarch specific problems, it has all others. I'll convert it to if this i386 version is deemed desirable. This patch doesn't change any code, just moves stuff from the "mach_resources.h" header to a "std_resources.c" subarch specific file, and introduces a "std_resources.h" header for the prototypes.
Showing
Please register or sign in to comment