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...)
_______________________________________________
Beowulf mailing list, [email protected] sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
