[Beowulf] Re: Any industry-standards that allow automated BIOS modifications and dumping? IPMI cannot do it, can it?
hahn at mcmaster.ca
Thu Oct 22 15:34:24 PDT 2009
>> 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...)
More information about the Beowulf