Specifications

Design Discussion
23
• There are security problems in having multiple entities maintaining flash or
NVRAM.
• Compatibility16 code is chipset hardware neutral.
• CompatibilitySmm code is not chipset hardware neutral.
Having no updates has several ramifications to the Compatibility16 code, as follows:
• No ESCD
• No processor patches
• No update of SMBIOS structures
• No CMOS save to flash
2.6.2.2 SMBIOS
All SMBIOS functions are read only, and both OEMs and manufacturing must use EFI
utilities to write asset tags.
SMBIOS version 2.3 is supported in a limited manner, as follows:
• Table entry only.
• No Plug and Play interface.
• Static information only, no flash updates.
2.6.2.3 Other Internal Assumptions
• The boot HDD needs to be INT13 drive 0x80. Other drives can be assigned
numbers in any order.
• USB legacy is supported from INT19 on. Pre-INT19 is EFI via any required
drivers or via CompatibilitySmm and is CSM implementation specific. This
requirement includes keyboard and mouse.
• EFI is sufficient for S3. No legacy code is required.
• EFI drivers, EfiCompatibility drivers, or ACPI ASL are used to program
traditional devices. There are no Plug and Play device nodes.
• EFI provides the ASL code.
• There is no APM support. Only ACPI-aware OSs are supported.
• There is no BIOS Setup. EFI provides this functionality.
• There is no POST. EFI provides this functionality.
Design Assumptions
The CSM design assumes the following:
• The major assumption is that large sections of the BIOS IBV’s current
runtime assembly code will be ported directly to the Compatibility16. EFI
interfaces extract information from the EFI modules and translate it into
Compatibility16 equivalents.
• The traditional BIOS (Compatibility16) consists of a single module.
• The traditional BIOS is a compiled feature. It is not dynamically controlled
via Setup or any other mechanism.