Text 2460, 60 rader
Skriven 2011-03-04 21:01:37 av Jonathan de Boyne Pollard
Ärende: Re: AMD releases open source boot code
==============================================
Gecko/20110221 Thunderbird/3.1.8
UTC)
comp.os.os2.beta:33 comp.os.os2.misc:2970
From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>

>> 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)