Because of a need to be compatible with other systems I'm seeing a requirement to support SMBIOS tables. I did some quick searching and didn't find much regarding this subject on the LinuxBIOS web site or the source code.
Specifically, the _SM_ pattern (SMMBIOS spec) needs to be embedded along with DMI blocks such as System Information (0x01), Base Board Information (0x02), System Encloser or Chassis (0x03) at a minimum. The commandline utility dumpSmbios (or similar) would be used to retrieve this information.
From an application perspective this is important information. The same
application needs to run on platforms having different BIOSes -- some commercial, some LinuxBIOS. The hardware type and version information is important for maintaining and deploying the application. Because of this, the application needs a consistent mechanism for retrieving the information I listed above.
Any suggestions or alternatives?
Thanks,
Steve
On Tue, Dec 18, 2007 at 01:39:19PM -0800, Steve Isaacs wrote:
Because of a need to be compatible with other systems I'm seeing a requirement to support SMBIOS tables. I did some quick searching and didn't find much regarding this subject on the LinuxBIOS web site or the source code.
LB does not try to support legacy stuff like this by design.
(LB does not try to be "BIOS compatible" if you will.)
From an application perspective this is important information. The same application needs to run on platforms having different BIOSes -- some commercial, some LinuxBIOS. The hardware type and version information is important for maintaining and deploying the application. Because of this, the application needs a consistent mechanism for retrieving the information I listed above.
Any suggestions or alternatives?
Yes, I suggest using an alternative. There isn't really much ready-made though.
Can you explain in more detail what information it is your application needs, that is so far unavailable?
//Peter
Steve Isaacs wrote:
Because of a need to be compatible with other systems I'm seeing a requirement to support SMBIOS tables. I did some quick searching and didn't find much regarding this subject on the LinuxBIOS web site or the source code.
Specifically, the _SM_ pattern (SMMBIOS spec) needs to be embedded along with DMI blocks such as System Information (0x01), Base Board Information (0x02), System Encloser or Chassis (0x03) at a minimum. The commandline utility dumpSmbios (or similar) would be used to retrieve this information.
From an application perspective this is important information. The same
application needs to run on platforms having different BIOSes -- some commercial, some LinuxBIOS. The hardware type and version information is important for maintaining and deploying the application. Because of this, the application needs a consistent mechanism for retrieving the information I listed above.
Any suggestions or alternatives?
Thanks,
Steve
Steve,
I don't think that anyone has implemented SMBIOS for LinuxBIOS since it is a "legacy" BIOS feature and not required to boot Linux. Also, LinuxBIOS doesn't leave any code resident which would be required for SMBIOS. Maybe a payload or a custom driver would be the way to go.
Marc
On 19.12.2007 01:35, Marc Jones wrote:
Steve Isaacs wrote:
Because of a need to be compatible with other systems I'm seeing a requirement to support SMBIOS tables. I did some quick searching and didn't find much regarding this subject on the LinuxBIOS web site or the source code.
Specifically, the _SM_ pattern (SMMBIOS spec) needs to be embedded along with DMI blocks such as System Information (0x01), Base Board Information (0x02), System Encloser or Chassis (0x03) at a minimum. The commandline utility dumpSmbios (or similar) would be used to retrieve this information.
From an application perspective this is important information. The same
application needs to run on platforms having different BIOSes -- some commercial, some LinuxBIOS. The hardware type and version information is important for maintaining and deploying the application. Because of this, the application needs a consistent mechanism for retrieving the information I listed above.
Any suggestions or alternatives?
I don't think that anyone has implemented SMBIOS for LinuxBIOS since it is a "legacy" BIOS feature and not required to boot Linux. Also, LinuxBIOS doesn't leave any code resident which would be required for SMBIOS. Maybe a payload or a custom driver would be the way to go.
AFAICS Steve is talking about SMBIOS, not SMI. SMBIOS is sort of an asset management helper. With a chassis type, serial number and some information about the base baord you can use management applications to determine where a specific machine is used (generate a list of serial numbers from all machines, look which machine has the wanted serial number). It should be possible to generate the SMBIOS structure in a similar way to how we generate e820 tables.
Regards, Carl-Daniel
On Wed, 2007-12-19 at 11:17 +0100, Carl-Daniel Hailfinger wrote:
On 19.12.2007 01:35, Marc Jones wrote:
Steve Isaacs wrote:
AFAICS Steve is talking about SMBIOS, not SMI. SMBIOS is sort of an asset management helper. With a chassis type, serial number and some information about the base baord you can use management applications to determine where a specific machine is used (generate a list of serial numbers from all machines, look which machine has the wanted serial number). It should be possible to generate the SMBIOS structure in a similar way to how we generate e820 tables.
Yes, thank you. That is precisely what I'm referring to.
The requirement I'm struggling with is for our Linux based applications to be able to identify the hardware and firmware (part numbers and revision numbers) it is running on for support and update reasons. The applications I'm referring to will be running on LinuxBIOS and commercial BIOS machines with custom hardware. A consistent means of identifying either is needed. SMBIOS (System Management BIOS http://www.dmtf.org/standards/smbios/) can be used for this purpose.
In short, the SMBIOS spec says that the pattern "_SM_" along with a check-sum is embedded within the BIOS code and in the normal BIOS image address range. There is also a pointer to a linked list of structures (similar to PCMCIA config structures) which identify the hardware and its characteristics including serial numbers and revision number (what I need). Utilities named getSystemId and dumpSmbios can be installed in Linux and used to retrieve this information or applications can scan the address range themselves.
Fortunately, it is not a requirement for me to itemize all of the devices. For example, the serial ports, sata drives, pci devices or usb devices do not need DMI blocks. There are other mechanisms for handling those. I believe the scope can (and should) be limited to part numbers, serial numbers and revisions.
That said, from what I've seen in other replies, if I want to conform to SMBIOS specifications in LinuxBIOS I'll need to figure out how to implement it. Right now I'm trying to understand how difficult it would be to support this standard or find another way. Since this is not actually used until after Linux is running there are other options but at the moment I'm thinking from a user space and kernel space perspective a single mechanism that comes with the hardware (so to speak) is best and simplest.
Thanks,
Steve
On Wed, 2007-12-19 at 07:44 -0800, Steve Isaacs wrote:
On Wed, 2007-12-19 at 11:17 +0100, Carl-Daniel Hailfinger wrote:
On 19.12.2007 01:35, Marc Jones wrote:
Steve Isaacs wrote:
The requirement I'm struggling with is for our Linux based applications to be able to identify the hardware and firmware (part numbers and revision numbers) it is running on for support and update reasons. The applications I'm referring to will be running on LinuxBIOS and commercial BIOS machines with custom hardware. A consistent means of identifying either is needed. SMBIOS (System Management BIOS http://www.dmtf.org/standards/smbios/) can be used for this purpose.
A followup: I'm going to use an alternative approach -- the needed information is already there or can be easily embedded just use a different mechanism to access it. SMBIOS just complicates things.
Steve
-
Carl-Daniel Hailfinger -
Marc Jones -
Peter Stuge -
Steve Isaacs