What is expansion ROM for BIOS ?
The purpose of the BIOS is to initialize the system before calling the boot loader to start the OS.
After completing the motherboard initialization, the BIOS start scanning for option ROM modules (expansion ROM) on the various devices. The expansion ROM includes device-specific initialization code. Once the BIOS identifies a compatible expansion ROM, it will simply call it. After the device specific code is executed, it will return the control back to the BIOS.
What changed with the introduction of UEFI?
Unified Extensible Firmware Interface (UEFI) is replacing and extending the traditional BIOS.
Traditional BIOS does not specify the behavior of the vendor’s code on the expansion ROM, so different vendors may have very different implementation. In contrast, UEFI’s spec clearly defines division of labor between the BIOS itself and the expansion ROMs. The standard defines a variety of functionalities or Services.
Each module manufacturer can implement any subset of these Services, so the behavior becomes uniform across vendors.
Once the UEFI BIOS identifies a compatible expansion ROM, it will use the API as defined in the spec to query the module’s capabilities and utilize the implemented functionalities.
Common functionalities can be implemented by the BIOS itself, e.g. significant parts of PXE boot.
How does Mellanox utilize expansion ROM ?
Mellanox support both traditional BIOS and UEFI (depends on the adapter and firmware loaded). The expansion ROM for traditional BIOS is called Flexboot and is our implementation of Preboot Execution Environment (PXE).
The support of UEFI includes the following services:
- UNDI – implementation of PXE calls. Since the UEFI infrastructure is in place, the implementation of UNDI is much simpler then Flexboot since most of the work is done by the UEFI BIOS itself
- HII - Human Interface Infrastructure: provide Mellanox-specific parameters with the same look and fill of the BIOS
- FMP - FW management protocol allows the user to check and burn FW during the BIOS phase.
- Driver binding – allow driver and controllers to be managed.
- Driver diagnostics – used to perform diagnostics on a controller that the UEFI driver is managing
- Driver health – retrieves various aspects of the health of the controller
- flint –d <dev> brom <rom image> - burn (or replace) the specified ROM file to the flash
- flint –d <dev> drom - delete the ROM section from the flash
- flint … rrom <file> - read the ROM image into a file (can be used with –i <image> or –d <dev>)
- flint … q – provide info (including ROM info) for a given device or image.
For more info refer to MFT User Manual.
Read current UEFI version:
# flint -d /dev/mst/mt4113_pciconf0 q
Image type: FS3
FW Version: 10.10.4020
FW Release Date: 31.8.2014
Rom Info: type=UEFI version=10.4.19 proto=IB
Description: UID GuidsNumber Step
Base GUID1: 0002c90300fbfc50 8 1
Base GUID2: 0002c90300fbfc58 8 1
Base MAC1: 00000002c9fbfc50 8 1
Base MAC2: 00000002c9fbfc58 8 1
Note: In case UEFI is not part of the firmware image, it will be listed in the output.