# CBFS SMBIOS hooks

The document describes the coreboot options how to make CBFS files populate platform-unique SMBIOS data.

## SMBIOS Serial Number

The DMTF SMBIOS specification defines a field in the type 1 System Information and type 2 Baseboard Information called Serial Number. It is a null-terminated string field assumed to be unique per platform. Certain mainboard ports have SMBIOS hooks to generate the Serial Numbers from external data, e.g. Lenovo Thinkpads (see DRIVER_LENOVO_SERIALS). This driver aims to provide an option to populate the Serial Numbers from CBFS for boards that can’t generate the it from any source.

### Usage

In the coreboot configuration menu (`make menuconfig`) go to `Generic Drivers` and select an option `Serial number in CBFS`. The Kconfig system will enable `DRIVERS_GENERIC_CBFS_SERIAL` and the relevant code parts will be compiled into coreboot image.

After the coreboot build for your board completes, use the cbfstool to include the file containing the serial number:

    ./build/cbfstool build/coreboot.rom add -n serial_number -t raw -f /path/to/serial_file.txt

Where `serial_file.txt` is the unterminated string representation of the SMBIOS type 1 or type 2 Serial Number, e.g. `5Q4Q7Y1`. If you use vboot with 1 or 2 RW partitions you will have to specify the RW regions where the file is going to be added too. By default the RW CBFS partitions are truncated, so the files would probably not fit, one needs to expand them first.

    ./build/cbfstool build/coreboot.rom expand -r FW_MAIN_A
    ./build/cbfstool build/coreboot.rom add -n serial_number -t raw \
    	-f /path/to/serial_file.txt -r FW_MAIN_A
    ./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_A

    ./build/cbfstool build/coreboot.rom expand -r FW_MAIN_B
    ./build/cbfstool build/coreboot.rom add -n serial_number -t raw \
    	-f /path/to/serial_file.txt -r FW_MAIN_B
    ./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_B

By default cbfstool adds files to COREBOOT region only, so when vboot is enabled and the platform is booting from RW partition, the file would not be picked up by the driver.

One may retrieve the Serial Number from running system (if it exists) using one of the following commands:

    # Type 1
    echo -n `sudo dmidecode -s system-serial-number` > serial_file.txt
    # OR Type 2
    echo -n `sudo dmidecode -s baseboard-serial-number` > serial_file.txt

Ensure the file does not end with whitespaces like LF and/or CR. The above commands will not add any whitespaces. The driver automatically terminates the Serial Number with the NULL character. If the CBFS file is not present, the driver will fall back to the string defined in `MAINBOARD_SERIAL_NUMBER` build option.

Please note that this driver provides `smbios_mainboard_serial_number` hook overriding the default implementation which returns `MAINBOARD_SERIAL_NUMBER` build option. If you wish to populate only type 2 Serial Number field your board code needs to implement `smbios_system_serial_number`, otherwise the weak implementation of `smbios_system_serial_number` will call `smbios_mainboard_serial_number` from the `DRIVERS_GENERIC_CBFS_SERIAL` implementation overriding it. So selecting the `DRIVERS_GENERIC_CBFS_SERIAL` has a side-effect of populating both SMBIOS type 1 and type 2 Serial Numbers if the board does not implement its own `smbios_system_serial_number`.

There is also SMBIOS type 3 Chassis Information Serial Number, but it is not populated by `DRIVERS_GENERIC_CBFS_SERIAL` nor by the default weak implementation (returns empty string). If you wish to populate type 3 Serial Number, your board code should override the default `smbios_chassis_serial_number` weak implementation.

## SMBIOS System UUID

The DMTF SMBIOS specification defines a field in the type 1 System Information Structure called System UUID. It is a 16 bytes value compliant with RFC4122 and assumed to be unique per platform. Certain mainboard ports have SMBIOS hooks to generate the UUID from external data, e.g. Lenovo Thinkpads (see DRIVER_LENOVO_SERIALS). This driver aims to provide an option to populate the UUID from CBFS for boards that can’t generate the UUID from any source.

### Usage

In the coreboot configuration menu (`make menuconfig`) go to `Generic Drivers` and select an option `System UUID in CBFS`. The Kconfig system will enable `DRIVERS_GENERIC_CBFS_UUID` and the relevant code parts will be compiled into coreboot image.

After the coreboot build for your board completes, use the cbfstool to include the file containing the UUID:

    ./build/cbfstool build/coreboot.rom add -n system_uuid -t raw -f /path/to/uuid_file.txt

Where `uuid_file.txt` is the unterminated string representation of the SMBIOS type 1 UUID, e.g. `4c4c4544-0051-3410-8051-b5c04f375931`. If you use vboot with 1 or 2 RW partitions you will have to specify the RW regions where the file is going to be added too. By default the RW CBFS partitions are truncated, so the files would probably not fit, one needs to expand them first.

    ./build/cbfstool build/coreboot.rom expand -r FW_MAIN_A
    ./build/cbfstool build/coreboot.rom add -n system_uuid -t raw \
    	-f /path/to/uuid_file.txt -r FW_MAIN_A
    ./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_A

    ./build/cbfstool build/coreboot.rom expand -r FW_MAIN_B
    ./build/cbfstool build/coreboot.rom add -n system_uuid -t raw \
    	-f /path/to/uuid_file.txt -r FW_MAIN_B
    ./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_B

By default cbfstool adds files to COREBOOT region only, so when vboot is enabled and the platform is booting from RW partition, the file would not be picked up by the driver.

One may retrieve the UUID from running system (if it exists) using the following command:

    echo -n `sudo dmidecode -s system-uuid` > uuid_file.txt

The above command ensures the file does not end with whitespaces like LF and/or CR. The above command will not add any whitespaces. But the driver will handle situations where up to 2 additional bytes like CR and LF will be included in the file. Any more than that will make the driver fail to populate UUID in SMBIOS.