• Andrew Morton's avatar
    [PATCH] i386 probe_roms(): preparation · 816d6073
    Andrew Morton authored
    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.
    816d6073
std_resources.h 272 Bytes