Gecko/20110221 Thunderbird/3.1.8   
   UTC)   
   omp.os.os2.beta:33 comp.os.os2.misc:2970   
   From: Jonathan de Boyne Pollard    
      
   >> Once again: It's not an operating system or an operating system    
   >> loader. It's replacement firmware.   
   >>   
   > What about the reversed situation, changing/checking certain    
   > BIOS-settings from within the OS? Not just because of the better UI,    
   > but also to allow e.g. a driver to reboot ASAP if a BIOS-setting was    
   > wrong for the eCS environment. [...]   
   >   
      
   The thing is that such "BIOS settings" of that type are, in actual fact,    
   usually values read from NVRAM and programmed into bus chipset and I/O    
   chip registers by the firmware at startup.  The (obviously little known)    
   secret is that such things are *re*-programmable by device drivers.  One    
   doesn't need to know what the internal details of the firmware's NVRAM    
   variable storage is.  One has one's own persistent storage for    
   configuration data, and one simply programs the chip registers how one    
   wants them, overriding the programming by the firmware.  (I say "little    
   known". It's well-known by device driver writers. There are books on    
   this stuff that go into detail of the designs -- where the operating    
   system provides persistent storage for device settings, and what things    
   one should and shouldn't expect about hardware state in a device driver.)   
      
   An example: The "native mode" setting for PCI-to-ATA bridges.  It's    
   programmable, and indeed programmed, by firmwares into the chipset    
   registers at POST.  It's *re*-programmed by operating system device    
   drivers when they initialize, according to values configured in    
   operating system settings storage.  DOS-Windows 9x and Windows NT device    
   drivers read a setting from the Windows Registry, for example.  Linux    
   device drivers (would) respect a kernel command-line option, that's    
   stored in the bootloader configuration database.  Even in humble OS/2    
   such a thing (were an equivalent to exist) would be a command line    
   option to a DANIS506.ADD line with CONFIG.SYS being the persistent    
   storage mechanism. The operating systems and their device drivers don't    
   need to know how the firmware decides whether "native mode" is on or    
   off, and knowing the internals of how the firmware works is completely    
   irrelevant to the task.  They have their own "on/off" flags and their    
   own persistent storage and configuration mechanisms.   
      
   Many "BIOS settings" are only relevant because of this to DOS-like    
   operating systems.  In operating systems like Windows NT, the design is    
   often to merely assume that the firmware has left each device in some    
   reasonably "safe" state, and do one's own initialization and    
   programming, independent of what the firmware may or may not have done.     
   As such, the internals of what any firmware does is completely    
   irrelevant.  What is *highly* relevant, in contrast, is the datasheet(s)    
   for the device concerned.   
      
   In other words: To tweak a device into a "good" state that one likes as    
   a device driver, one doesn't need to restart the system and re-run the    
   firmware.  One doesn't need to know how the firmware works, but how the    
   device works.  And one just programs the device directly.  After all,    
   one *is* the device driver, and that *is* one's job.  (-:   
      
   --- Internet Rex 2.31   
    * Origin: virginmedia.com (1:261/20.999)