[Beowulf] Re: Any industry-standards that allow automated BIOS modifications and dumping? IPMI cannot do it, can it?

[Mark Hahn]

>> definitely not in general.  a vendor could certainly provide IPMI
>> extensions that manipulate bios settings.  but the market doesn't seem to
>> find this kind of HPC-mostly concern worthwhile :(
>
> Well, it's not just for HPC anymore, all the warehouse computing guys
> (cloud) want this, too.

sorry, I thought it was understood that "Cloud" is just a new name 
for the degenerate, low-end component of HPC, formerly known as 
"serial farming".  ;)

yes, I wouldn't be surprised if Google/Amazon/etc have good traction.

> I believe someone explained to me a long time
> ago that there is a standard way to read and write (but not interpret)
> the BIOS flash saved state, but the state is now too large to fit into
> the standard-sized area.

indeed, there is a definition for PC-AT-vintage settings.  but that 
doesn't really include anything interesting (ie, does include floppy
config, but does not include ECC scrub settings...)

>> I wonder though, whether it would kill vendors just to publish the source
>> for their bios.
>
> Yes, it would. Not only is the source owned by AMI & Phoenix, and not
> mobo vendors,

my understanding is that AMI/Phoenix sell essentially a bios SDK,
and that the board vendor assembles their own "app" based on that.

> but it includes licensed stuff, and also secret
> workarounds to hardware bugs in lots of devices.

well, I'm really talking only about the basic MB bios, and really only
the POST portion.  so not PXE-related stuff, or code for add-in devices.
is the memory count-up licensed?  the display-splash-image code secret?
for CPU/chipset workarounds, I'm skeptical about the secrecy, since 
AMD and Intel both disclose quite a lot in their chip eratta and bios
developer's guides.  for instance, I'm pretty sure the AMD doc is 
detailed enough to fully configure dram detect/config, HT and IO config,
SMP bringup, etc.

> Even IBM's BIOS
> (still used in a few high-end IBM x86 servers) is probably polluted
> that way.

I wonder how hard it is to actually read the raw bios.  for instance, 
under linux, could there not be a /dev/flash device driver that handled
the access interface (I2C, I guess)?  having at least a read/write 
char dev would open up some possibilities, like diffing the flash image
when you change one setting.  (hell, just being able to write the 
flash image from linux with a single, simple, non-proprietary tool 
would be a huge step...)