Blog from May, 2021

The programming tool AFU-AMI Firmware Update is distributed in the following versions:

• AfuEfix64.efi EFI Shell programming utility;

• EtaAfuOemLnx32 Linux 32-bit programmer;

• EtaAfuOemLnx64 Linux 64-bit programmer;

• AFUWIN.EXE Windows 32-bit BIOS programmer;

• AFUWINx64.EXE Windows 64-bit BIOS programmer.

INDEX

EFI Shell utility

• Copy the updater tool and the BIOS binary inside the USB drive.

• Then, turn on the system and enter in the Aptio Setup Utility pressing the [ESC] key.

• From the Save & Exit page select the USB drive created, generally named as “UEFI: Built-in EFI Shell” or similar.

• From the Device mapping table identify the filesystem of the USB drive fs* (marked as a Removable HardDisk).

• Enter in the USB drive file system fs*:. For example, if the USB drive is fs1 the command will be fs1:.

• Move to the folder where AFU utility and the binary file are located and launch the command:

bios_update.nsh BIOSbinary.XXX

where BIOSbinary.XXX is the name of the BIOS you would like to flash.

• After the program advises the correctness of operation, the board can be rebooted.

Linux utility

• Copy the updater tool and the BIOS binary file in a folder of the Linux Disk.

• Open a new terminal as super user and move to the folder where AFU utility and the firmware file are located. From inside here:

• Make the script executable through the following command:

  chmod +x bios_updater_YYY.sh

  where YYY changes for 32-bit or 64-bit Linux version;

• To update your BIOS execute the command:

  ./bios_updater_YYY.sh BIOSbinary.XXX

  where BIOSbinary.XXX is the name of the BIOS you would like to flash.

• After the program advises the correctness of operation, the board can be rebooted.

Windows utility

• Copy the updater tool and the BIOS binary file in a folder of the Windows Disk.

• Run the cmd shell with Administrator privileges, then move to the folder where AFU utility and the firmware file are placed.

• From inside here, to update your BIOS execute the command:

./bios_updater_YYY.bat BIOSbinary.XXX

where YYY changes for 32-bit or 64-bit Linux version and BIOSbinary.XXX is the name of the BIOS you want to flash.

Notes

SECO logo is always displayed by default during the boot phase. In particular, there are two different logos:

• splash logo: large icon centered in the screen when quiet boot is enabled;

• small logo: small icon in the top right corner of the screen when quiet boot is disabled.

The AMI ChangeLogo utility allows both to replace SECO logo(s) with custom one(s) and to remove it.
The utility is distribuited in the following versions:

• ChangeLogoWin.exe for Windows 32-bit

• ChangeLogoWin64.exe for Windows 64-bit

INDEX

Where can I find ChangeLogo utility?

ChangeLogo is part of the Bios tools package, it is available in the download section of each X86 product.

How can I replace BIOS logo?

In order to replace SECO logo in the BIOS binary with a custom image, follow the steps below.

First, copy the logo files and the original BIOS in the folder where the ChangeLogo utility is located.

Then run the cmd shell and move to the folder where the utility, the binary and the image are located.

• To change the splash logo execute the following command:

  ChangeLogoWinYY /i inROMFile /o outROMFile /r logofile [/f]

• To change the small logo execute the following command:

  ChangeLogoWinYY /i inROMFile /o outROMFile /r logofile /s [/f]

In both commands above:

• YY changes for 32-bit or 64-bit Windows version;

• /i specifies the BIOS binary used as input;

• /o specifies the BIOS binary that will be generated;

• /r selects the image file to upload in the BIOS.

• /s selects the small logo;

• /f forces the destination file (optional).

Once the utility displays a success message, you binary is ready to be updated following the procedure shown in the module page.

How can I delete BIOS logo?

In order to delete SECO or custom logo in the BIOS binary, follow the steps below.

Run the cmd shell and move to the folder where the utility, the binary and the image are located.

• To delete the splash logo execute the following command:

  ChangeLogoWinYY /i inROMFile /o outROMFile /d [/f]

• To delete the small logo execute the following command:

  ChangeLogoWinYY /i inROMFile /o outROMFile /d /s [/f]

In both commands above:

• YY changes for 32-bit or 64-bit Windows version;

• /i specifies the BIOS binary used as input;

• /o specifies the BIOS binary that will be generated;

• /d removes the logo in the BIOS binary;

• /s selects the small logo;

• /f forces the destination file (optional).

Once the utility displays a success message, you binary is ready to be updated through following the procedure shown in the module page.

The SMBIOS-System Management BIOS specification defines data structures (and access methods) that can be used to read information stored in the BIOS of a computer.
By parsing this table it is possible to access information about the system and its capabilities.
AptioV DmiEdit is a tool that allows to read the SMBIOS tables and edit their content. In particular, the System Information table, containing data like the manufacturer of the system, the product name and the version can be extracted.

The utility is distributed in the following versions:

• AmiDeWin32.exe for Windows 32-bit

• AmiDeWin64.exe for Windows 64-bit

• AmiDeLnx32 for Linux 32-bit

• AmiDeLnx64 for Linux 64-bit

INDEX

Where can I find DmiEdit utilities?

Latest version of DmiEdit utilities are available HERE

What about Linux utility?

The following operations allow to edit the Type1-System Information table of the SMBIOS with custom strings and values.

• Copy the DmiEdit tool in a folder inside the disk;

• Open a new terminal as super user and move to the folder where the DmiEdit utility is located;

• Make the program executable through the following command:

  chmod +x AmiDeLnxYY

  where YY changes for 32-bit or 64-bit Linux version

• To customize SMBIOS execute the following command:

  ./AmiDeLnxYY [command][value]

  where YY changes for 32-bit or 64-bit Linux version, while commandand value can be the following:

What about Windows utility?

The following operations allow to edit the Type1-System Information table of the SMBIOS with custom strings and values.

• Copy the DmiEdit tool in a folder inside the disk:

• Open a new terminal as super user and move to the folder where the DmiEdit utility is located;

• To customize SMBIOS execute the following command:

  AmiDeWinYY.exe [command][value] 

  where YY changes for 32-bit or 64-bit Windows version, while command and value can be the following:

In embedded systems, the Board Support Package (BSP) is the layer of the software that contains hardware-specific drivers and other routines that allow a particular operating system to work in a specific hardware environment, integrated with the software itself.
BSPs are typically customizable, allowing the user to specify which drivers and routines should be included in the build based on their selection of hardware and software options.
SECO also provides a toolchain to build programs to run on the embedded system and other utilities needed to configure the device (while running) along with the BSP.

INDEX

How can I configure my environment with Docker?

To avoid the time consuming setup of the building environment, we distribute it inside a Docker container.

The following table contains the instructions to create the building environment from the Docker container, depending on the product family of the device used.

How can I build SECO U-Boot?

Clone SECO U-Boot from SECO repository

For BSP 10 boards:
$ git clone https://git.seco.com/pub/i.mx/yocto/5.x/uboot-seco-imx.git -b seco/release/imx_5.4.70_2.3.0 --depth=1

For BSP 9 boards:
$ git clone https://git.seco.com/pub/i.mx/yocto/4.x/u-boot-seco.git

Procedure for i.MX6-based boards

For i.MX6 Quad, DualLite and Solo CPUs there’s a specific defconfig file for each RAM configuration.
i.MX6 SoloX, on the other hand, has dynamic RAM setup implemented in U-Boot.
U-boot will allocate the RAM memory based on your board configuration with the correct default defconfig file.

The table below shows the correct association RAM Configuration/defconfig file.

Choose the right defconfig file from table below using the following command. After having chosen the right defconfig file, you can build SECO U-Boot.

cd u-boot-seco
make <board_defconfig_filename> 
# eg: make mx6qdl_seco_Q7_928_2G_4x512M_defconfig 
# compile u-boot
make spl_imx

Procedure for i.MX8-based boards

For i.MX8 CPUs, dynamic RAM management has been implemented at U-Boot level.

Choose the right defconfig file from table below using the following command for BSP9:

cd u-boot-seco
make <board_defconfig_filename>
# eg: make seco_imx8mq_c12_defconfig
# compile u-boot
make 

Choose the right defconfig file from table below using the following command for BSP10:

mv uboot-seco-imx u-boot-seco-imx
cd u-boot-seco-imx
make <board_defconfig_filename>
# eg: make seco_imx8mm_c72_defconfig
# compile u-boot
make 

u-boot.bin and spl/u-boot-spl.bin will be available as outputs.

Now you are ready to combine U-boot with other firmware to build the final binary.

Go in the same folder level of U-Boot and execute following command:

For BSP 10 boards:
$ git clone https://git.seco.com/pub/i.mx/yocto/5.x/imx-mkimage.git -b seco/release/imx_5.4.70_2.3.0 --depth=1

For BSP 9 boards:
$ git clone https://git.seco.com/pub/i.mx/yocto/4.x/imx-mkimage.git 

Move inside the imx-mkimage folder:

cd imx-mkimage/

You can build the binary flash.bin launching the script:

./mk_imximage <board> <options>
# eg: ./mk_imximage c12 or ./mk_imximage c20 dp..etc

The table below summarizes the eligible values to insert in the script, according to the device used.

Procedure for Rockchip RK3399 based boards

For Rockchip RK3399 based boards:

$ git clone https://git.seco.com/pub/rockchip/u-boot-seco-rk2017.09.git -b master
$ https://secostorage.blob.core.windows.net/secosoftware-public/rockchip/c31/seco-rk3399-c31_uboot-rkbin_4.19.111_v1-00-00_20211217.tar.gz
$ tar xzvpf seco-rk3399-c31_uboot-rkbin_4.19.111_v1-00-00_20211217.tar.gz -C ./

For Rockchip RK3399 Flexy boards:

$ git clone https://git.seco.com/pub/rockchip/u-boot-seco-rk2017.09.git -b flexy-c31
$ https://secostorage.blob.core.windows.net/secosoftware-public/rockchip/c31/seco-rk3399-c31_uboot-rkbin_4.19.111_v1-00-00_20211217.tar.gz
$ tar xzvpf seco-rk3399-c31_uboot-rkbin_4.19.111_v1-00-00_20211217.tar.gz -C ./

For Rockchip RK3399 IPC boards:

$ git clone https://git.seco.com/pub/rockchip/u-boot-seco-rk2017.09.git -b ipc-c31
$ https://secostorage.blob.core.windows.net/secosoftware-public/rockchip/c31/seco-rk3399-c31_uboot-rkbin_4.19.111_v1-00-00_20211217.tar.gz
$ tar xzvpf seco-rk3399-c31_uboot-rkbin_4.19.111_v1-00-00_20211217.tar.gz -C ./

Now jump inside u-boot folder and modify in make.sh script the TOOLCHAIN_ARM64 variable with the right toolchain path from this:

TOOLCHAIN_ARM64=../prebuilts/gcc/linux-x86/aarch64/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin

To this path if you use docker:

TOOLCHAIN_ARM64=/opt/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/

Then build it using the following command:

cd u-boot-seco-rk2017.09
./make.sh seco_rk3399_c31_linux

How can I build SECO Kernel?

First, clone SECO Kernel from SECO repository executing one of the following command:

• for i.MX6 and i.MX8-based boards:

For BSP 10 boards:
$ git clone https://git.seco.com/pub/i.mx/yocto/5.x/linux-seco-imx.git -b seco/release/imx_5.4.70_2.3.0 --depth=1

For BSP 9 boards: 
$ git clone https://git.seco.com/pub/i.mx/yocto/4.x/linux-seco.git 

• for Rockchip PX30 based boards:

$ git clone https://git.seco.com/arm/rockchip/linux-seco-rk4.4.git

• for Rockchip RK3399 based boards:

$ git clone https://git.seco.com/pub/rockchip/linux-seco-rk4.19.111 -b master

• for Rockchip RK3399 Flexy boards:

$ git clone https://git.seco.com/pub/rockchip/linux-seco-rk4.19.111 -b flexy-c31

• for Rockchip RK3399 IPC boards:

$ git clone https://git.seco.com/pub/rockchip/linux-seco-rk4.19.111 -b ipc-c31

Now, depending on your device, choose the right defconfig from Kernel configs folder and build it using the following command:

For Rockchip RK3399 based boards:

cd linux-seco
export CROSS_COMPILE=/opt/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-
export ARCH=arm64
make <defconfig>
make
make modules_install INSTALL_MOD_PATH=modules

For NXP i.MX6 based boards:

cd linux-seco
export ARCH=arm
make <defconfig>
make
make modules_install INSTALL_MOD_PATH=modules

For NXP i.MX8 based boards:

cd linux-seco
export ARCH=arm64
make <defconfig>
make
make modules_install INSTALL_MOD_PATH=modules

The compiled files are inside of the following folder:

How can I setup my BSP?

To setup the custom hardware configuration, please follow https://secospa.atlassian.net/wiki/spaces/SECOTech/blog/2021/09/20/770703361 .

How can I build Buildroot filesystem image for Rockchip RK3399?

To build Rockchip RK3399 Buildroot Image please follow these steps inside an ubuntu 18.04:

• first fetch the rk_rockchip tarball and prepare the environment:

sudo apt-get update
sudo apt-get -y install git time aria2 wget make lsb-release openssh-client vim tree exfat-fuse exfat-utils u-boot-tools mediainfo \
    libasound2-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libxcb-xinerama0 libxcb-xinerama0-dev \
    libopenal-dev libalut-dev libpulse-dev libuv1-dev libmicrohttpd-dev libssl-dev bridge-utils ifplugd \
    libbluetooth3-dev libjpeg8 libjpeg8-dev libjpeg-turbo8 libjpeg-turbo8-dev libvpx-dev \
    libgtk2.0-dev libnss3 libgconf-2-4 gconf2 gconf2-common libx11-dev libxext-dev libxtst-dev \
    libxrender-dev libxmu-dev libxmuu-dev libxfixes-dev libxfixes3 libpangocairo-1.0-0 \
    libpangoft2-1.0-0 libdbus-1-dev libdbus-1-3 libusb-0.1-4 libusb-dev \
    bison build-essential gperf flex ruby python libasound2-dev libbz2-dev libcap-dev \
    libcups2-dev libdrm-dev libegl1-mesa-dev libgcrypt11-dev libnss3-dev libpci-dev libpulse-dev libudev-dev \
    libxtst-dev gyp ninja-build  \
    libssl-dev libxcursor-dev libxcomposite-dev libxdamage-dev libxrandr-dev \
    libfontconfig1-dev libxss-dev libsrtp0-dev libwebp-dev libjsoncpp-dev libopus-dev libminizip-dev \
    libavutil-dev libavformat-dev libavcodec-dev libevent-dev libcups2-dev libpapi-dev \
    gcc-aarch64-linux-gnu g++-aarch64-linux-gnu gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf \
    qemu-user-static debootstrap whiptail bsdtar bc device-tree-compiler \
    swig python-dev python3-dev liblz4-tool expect-dev
sudo apt-get -y install kmod cpio rsync patchelf

wget https://azure.com/rk_rockchip_20201116.tar.gz
wget https://azure.com/seco_sdk_rockchip_package_20201116.tgz
wget https://azure.com/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu.tgz

mkdir /opt/rk3399

tar xzvpf gcc-linaro-6.3.1-2017.05-x86_64_aarch64-linux-gnu.tgz -C /opt/rk3399/
tar xzvpf rk_rockchip_20201116.tar.gz -C /<destination folder>
tar xzvpf seco_sdk_rockchip_package_20201116.tgz -C /<destination folder>/rk_rockchip/

cd /<destination folder>/

• then cd into rk_rockchip folder and start the filesystem build:

cd /<destination folder>/rk_rockchip/
./build.sh rootfs
You're building on Linux
Lunch menu...pick a combo:

0. default BoardConfig.mk
1. BoardConfig-rk3399-evb-ind-lpddr4.mk
2. BoardConfig-rk3399-firefly.mk
3. BoardConfig-rk3399-sapphire-excavator-lp4.mk
4. BoardConfig-rk3399-sapphire-excavator.mk
5. BoardConfig.mk
Which would you like? [0]:4

How can I build Yocto image?

To build the Yocto Image, for i.MX soc based board please follow:

Build Yocto distribution for ARM i.MX products

To build the Yocto Image, for Rockchip soc based board please follow:

Build Yocto distribution for ARM Rockchip products

INDEX

Format the device

A bootable device where to flash BSP binaries needs a specific partitioned storage.

The device must have at least two partitions:

• the first formatted as FAT32 and with size at least 32MB;

• the second formatted as EXT4 and big enough to decompress the filesystem as explained later.

You can use many different tools to create the partitions, such as gparted, which has a graphical interface, or sfdisk on the command line.

If you want to use the command line sfdisk tool instead, you need to:

• first create a text file called devicepart.sfdisk, copying the following content inside it

start=        8192, size=       67584, name="bootfs", type=b
start=       75776, name="rootfs"

• create the boot device with the commands

sfdisk --force /dev/<device> < devicepart.sfdisk

#format the first partition as FAT32
mkfs.vfat /dev/<device>1
#format the second partition as EXT4
mkfs.ext4 /dev/<device>2

Flash the BSP inside the bootable device

In order to flash BSP Linux distribution inside the formatted bootable device, the following binaries are required:

• U-Boot image

• dtb file (device tree blob) file and dtbo (device tree overlay) files

• Kernel image

• filesystem, Linux Filesystem (Yocto Filesystem)

In the following sections you will be guided in flashing your bootable device using the pre-compiled binaries that you can find in the board page. If you want to compile binaries on your own, please follow https://secospa.atlassian.net/l/c/a0PFeQpc to generate them.

Flash u-boot

To flash the U-Boot image, choose the right image for your board and execute the proper command to flash bootloader. Every board (depending on the processor) has a different command to be executed:

• for all i.MX6 product
  sudo dd if=<u-boot-filename>.imx of=/dev/<device> bs=512 seek=2 conv=fsync

• for i.MX8 products, follow this table

Flash kernel and filesystem

Choose the right binaries from the board page. You need to download a kernel and a filesystem tarball.

In the command below we suppose two device partitions, mounted respectively as /media/<device>1 and /media/<device>2. If your situation is different, please change the path accordingly.

First, extract the filesystem inside the second partition, with the command:

tar xjpf <filesystem-file>.tar.bz2 --numeric-owner -C /media/<device>2

Extract the kernel tarball provided: inside it there are 2 folders, named boot and lib. You need to copy all the content of the boot folder inside the root of the first partition of the device, e.g.:
cp boot/* /media/<device>1

Copy the content of the lib/modules folder of the tarball inside the lib/modules folder inside the second partition, e.g.:
cp -r lib/modules/* /media/<device>2/lib/modules

Now unmount the device and you are ready to go.

This section contains the instructions on how to setup a serial console, in order to establish a serial connection with the boards.

Before starting, make sure that the host PC and the SBC or the carrier board are connected via a UART serial null modem cable.

There are several software applications that allow you to serial connect with the board. The most common are Minicom, Cutecom, Gkterm. We will show you how to install and configure Minicom.

The BSP tools are routinely tested in house on Ubuntu LTS (20.04) and Debian testing.

Required packages are natively distributed inside Ubuntu distros, but you may install them using the following commands:

sudo apt-get install fdisk dosfstools e2fsprogs coreutils

Almost all the available SECO solutions can be interfaced to the end user terminal using a debugging UART with a baudrate of 115200; to achieve that a TTL-to-RS232 transceiver must be connected first to the host PC, then to the serial port adapter exposed by the target device.

Once the connection between the host PC and the target device has been established, you have to install a serial communication program on your host PC. A common solution for this purpose is Minicom.

Minicom is a serial communication program that connects to the device through a GNU/Linux PC’s serial ports.

Executing the following command:

sudo apt-get install minicom

Minicom will be available on your host PC.

The EFI-Extensible Firmware Interface system partition is a partition on a data storage device (usually a hard disk driver or a solid state drive) that is used by computers adhering to the UEFI-Unified Extensible Firmware Interface. The purpose of this guide is to explain:

• how to load a UEFI Shell on a target hard drive;

• how to use this shell to perform automatic operations during the system boot (as UEFI driver loading) before the OS.

INDEX

Preliminary operations

On a system with an installed operating system, the boot manager that exists as part of the motherboard UEFI firmware will have an EFI file location stored in the BootOrder variable. This might actually be another boot manager if you have an installed multi-boot tool but is usually just the EFI boot loader for your operating system.
Most of the time, this EFI file is stored on a special EFI system partition. Usually it is this one:

EFI\Boot\Bootx64.efi

The easiset way to perform modifications in the boot sequence is to use a bootable UEFI USB device.
If you need to create a device from zero, please follow the guide https://secogroup.atlassian.net/l/c/Kvry6Eos

What about Linux?

The first step is creating a script that will be called during the EFI Shell boot from the hard disk.

Create a file named startup.nsh and modify it to add custom commands that will be executed automatically during the boot. These command may be default EFI Shell commands or callback to custom EFI application.
The only mandatory commands are: the first line that will be used to open hard drive file system (by default should be fs0) and the last line that must be the called to grub bootloader:

fs0:	
customoperations 
EFI\ubuntu\grubx64_org.efi

Once this file is ready save it and copy to the root directory of the USB EFI device that will be used for the modification. Turn on the system and boot from EFI USB device. The EFI shell will be launched and Device mapping table will be displayed (if not, use the command map to show it).

In the picture, for example, we have two filesystems: one referring to the SATA hard disk where we want to apply the modification (fs0), and another one referring to the USB drive with the EFI Shell that we have booted (fs1).

Now open the target hard disk filesystem and move to the folder where EFI bootloader is placed:

fs0:	
cd EFI\Boot

Rename bootx64.efi as bootx64_org.efi:

mv bootx64.efi bootx64_org.efi

Copy both the EFI Shell from the USB drive and the startup script to the hard drive boot folder:

cp fs1:\EFI\Boot\bootx64.efi fs0:\EFI\Boot\bootx64.efi
cp fs1:\startup.nsh fs0:\EFI\Boot\startup.nsh

Move to the EFI\ubuntu folder and rename grubx64.efi as grubx64_org.efi:

mv grubx64.efi grubx64_org.efi

Now poweroff the system. On the next boot the EFI Shell will be launched before loading Ubuntu OS and the requested operations will be performed.

What about Windows?

The first step is creating a script that will be called during the EFI Shell boot from the hard disk. Create a file named startup.nsh and modify it to add custom commands that will be executed automatically during the boot. These command may be default EFI Shell commands or callback to custom EFI application.
The only mandatory commands are: the first line that will be used to open hard drive file system (by default should be fs0), and the last line that must be the called to Windows bootloader.

fs0:	
customoperations 
EFI\ubuntu\bootmgfw_org.efi

Once this file is ready save it and copy to the root directory of the USB EFI device that will be used for the modification. Turn on the system and boot from EFI USB device. The EFI shell will be launched and Device mapping table will be displayed (if not, use the command map to show it).

In the picture, for example, we have two filesystems: one referring to the SATA hard disk where we want to apply the modification (fs0), and another one referring to the USB drive with the EFI Shell that we have booted (fs1).

Open the target hard disk filesystem and move to the folder where EFI bootloader is placed:

fs0:	
cd EFI\Boot

Copy both the EFI Shell from the USB drive and the startup script to the hard drive boot folder:

cp fs1:\EFI\Boot\bootx64.efi fs0:\EFI\Boot\bootx64.efi
cp fs1:\startup.nsh fs0:\EFI\Boot\startup.nsh

Move to the Microsoft\Boot folder and rename bootmgr.efi as bootmgr_org.efi and bootmgfw.efi as bootmgfw_org.efi:

mv grubx64.efi grubx64_org.efi

Now power off the system. On the next boot the EFI Shell will be launched before loading Ubuntu OS and the requested operations will be performed.

In Standard Boot process, when turning on the computer the first step executed is POST-Power On Self-Test, then BIOS is initialized. At this stage hardware is initialized and its firmware is loaded to the memory.
Subsequently the bootloader is called. The problem is that firmware, bootloader and other components loaded until then are not verified.

In Secure Boot process, after passing the POST test, UEFI firmware is loaded.
UEFI firmware is responsible, during the boot process, for verifying components (UEFI drivers, EFI Shell applications, boot manager, UEFI bootloaders etc.) before they are loaded.

INDEX

Glossary

PK-Platform Key, establishes a trust relationship between the platform owner and the platform firmware.
KEK-Key Exchange Key, establishes a trust relationship between the operating system and the platform firmware.
db-Authorized Signature Database, contains public keys and certificates that represent trusted firmware components and operating system loaders.
dbx-Forbidden Signature Database, contains hashes of malicious and vulnerable components as well as compromised keys and certificates and blocks execution of those malicious components.
GUID-Globally Unique Identifier, a 128-bit number used to identify information in computer systems.
DER-Distinguished Encoding Rules, format containing the X.509 certificate in binary form.
PFX-Personal Information Exchange, signs digitally applications.
PVK-Private Key File, signs digitally applications (similar to PFX format).
ESL-EFI Signature List, certificates’ format KeyTool and/or firmware.
AUTH certificates format with authentication header (i.e. a signed certificate update file) for KeyTool and/or firmware.

What about Linux?

How can I generate my own keys?

In order to generate your own keys, you should install OpenSSL, efitools and sbsigntool, if not present:

sudo apt-get install openssl

Make sure that the Secure Boot is disabled:

mokutil --sb-state

Create a GUID for owner identification:

uuidgen --random > GUID.txt

Create a Platform Key with OpenSSL

Open a new terminal and execute the following commands:

openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 365 -subj "/CN=My Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth

• openssl req -newkey rsa:2048 -nodes -keyout PK.key -new -x509 -sha256 -days 365 -subj "/CN=My Platform Key/" -out PK.crt generates a self-signed certificate. In this particular case the certificate will be valid for 365 days, but typing a proper number under the heading -days, a different period of validity will enter into force. Under the heading -subj "/CN= … /" you can insert the name you prefer. This name will appear in the Certificate Legend section in your BIOS;

• openssl x509 -outform DER -in PK.crt -out PK.cer changes the PEM format certificate PK.crt into the DER format certificate for firmware PK.cer. This format is the one you should update on your BIOS;

• cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl changes the PEM format certificate PK.crt into a certificate in EFI Signature List PK.esl;

• sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth produces an output file with an authentication header for direct update to a secure variable PK.auth. Please note that PK.auth is signed by the private key in PEM format PK.key and the related signing certificate PK.crt.

Create a Key Exchange Key with OpenSSL

Open a new terminal and execute the following commands:

openssl req -newkey rsa:2048 -nodes -keyout KEK.key -new -x509 -sha256 -days 365 -subj "/CN=My Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth

Create an Authorized Signatures Database with OpenSSL

Open a new terminal and execute the following commands:

openssl req -newkey rsa:2048 -nodes -keyout db.key -new -x509 -sha256 -days 365 -subj "/CN=My Signature Database Key/" -out db.crt
openssl x509 -outform DER -in db.crt -out db.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

How can I sign bootloaders?

Open a new terminal from the folder containing your own keys.

To sign your EFI Shell execute the following commands:

sbsign --key db.key --cert db.crt --output /media/seco/EFISHELL/EFI/Boot/bootx64.efi /media/seco/EFISHELL/EFI/Boot/bootx64.efi
sbverify --cert db.crt /media/seco/EFISHELL/EFI/boot/bootx64.efi

The command sbverify allows to control which certificate is related to your XXX.efi.
Likewise, to sign your grubx64.efi execute the following commands:

sbsign --key db.key --cert db.crt --output /boot/efi/EFI/ubuntu/grubx64.efi /boot/efi/EFI/ubuntu/grubx64.efi

How can I update my keys?

There are two possible ways to update the keys you just generated in your BIOS (so to enable Secure Boot):

1. Enter your BIOS and follow the instructions contained in How can I update my keys on BIOS?

2. Open a new terminal as super user and execute the following commands:

mokutil --password
mokutil --enable-validation

mokutil --import /home/seco/Desktop/SBLinux/PK.cer
mokutil --import /home/seco/Desktop/SBLinux/KEK.cer
mokutil --import /home/seco/Desktop/SBLinux/db.cer

Rebooting your system, enter your BIOS; under the Security menu, select the Secure Boot option and enable it (Restore Factory Keys is enough)

The MOK Management screen will be displayed before Linux. Now you can confirm the keys you want to enroll through Enroll MOK, as shown in the pictures below.

Continue the boot. Your system will start autonomously.

Now you can verify that Secure Boot is on through:

mokutil --sb-state

How can I sign drivers and update BIOS?

The following example will show you how to update your BIOS.

Create a new folder named Bios_Updater, containing bios_updater_x64.sh (or bios_updater_x32.sh), afulnx_64 (or afulnx_32) and the BIOS you want to update mynewbios.bin. To sign your driver or application, first of all make sure to have all the authorisations. To verify it, open a new terminal and type the following command ls -l *. If a similar message appears

at the moment afulnx_64 will not run because you have to set all executable flag through:

chmod +x *

Alternatively, if it is necessary to set executable flag just for a specific element, type chmod +x element_name as super user.

Build AFU driver executing the following command:

./afulnx_64 /MAKEDRV

The driver will be generated in the current directory with the name amifldrv_mod.o.
Open a new terminal as super user from the folder containing your generated keys. Sign your amifldrv_mod.o executing the following commands:

usr/src/kernels/$(uname -r)/scripts/sign-file sha256 db.key db.cer /home/seco/Desktop/Bios_updater/amifldrv_mod.o

Now enable Secure Boot following the instructions in How can I update my keys? or How can I update my keys on BIOS? and reboot the system. Install the signed driver using insmod and verify that font amifldrv_od.o has been loaded through lsmod.

Open a new terminal as super user and execute the following command:

./bios_updater_x64.sh mynewbios.bin

Enter your BIOS and verify if it has been updated.

What about Windows?

How can I generate my own keys?

In order to generate your own keys, you should install Windows SDK, if not present. Windows SDK contains, in particular, makecert.exe, signtool.exe, pvk2pfx.exe and certmgr.exe that will be usefull for our purposes. Using Windows 10, these applications are in the directory C:\Program Files (x86)\Windows Kits\10\bin\....

Create a new folder containing these applications.
Make sure that the Secure Boot is disabled (your status is Setup mode). Open your Start menu, type System Information and launch it.

Create a Platform Key with makecert

Open a new command prompt as adiministrator from the Secure Boot folder and execute the following command:

makecert.exe -n "CN=My Platform Key" -r -sv PK.pvk PK.cer -a sha256

where:

• -n "CN=Your Name" gives the name Your name to your certificate;

• -r generates a self-signed certificate;

• -sv specifies the PVK file related to the private key;

• -a specifies the algorithm used (by defult is sha1).

Automatically, new windows will be displayed and you will have to type a password. Subsequently your PK.pvk and PK.cer will be created.

Create a Key Exchange Key with makecert

makecert.exe -n "CN=My Key Exchange Key" -iv PK.pvk -ic PK.cer -sv KEK.pvk KEK.cer -a sha256

where:

• -iv downloads the issuer's PVK private key file;

• -ic specifies the certificate.

Create an Authorized Signatures Database with makecert

makecert.exe -n "CN=My Signature Database Key" -iv KEK.pvk -ic KEK.cer -sv db.pvk db.cer -a sha256

Transform your db.pvk in PFX format executing the following commands:

pvk2pfx.exe -pvk db.pvk -pi your_password -spc db.cer -pfx db.pfx -f

Opening your XXX.cer, similar windows will be displayed.

In order to validate these certificates, we use the Certificate Manager Tool certmgr.exe that manages certificates, certificate trust lists(CTLs), and certificate revocation lists (CRLs).
Execute the following commands:

certmgr.exe /add /c PK.cer /s my
certmgr.exe /c /add /c PK.cer /s root

Automatically, new windows will be displayed and you will have to accept.

How can I sign bootloaders?

Open a new command prompt as administrator from the folder containing your own keys. To sign your EFI Shell execute the following commands:

signtool.exe sign /ac db.cer /f db.pfx /p your_password /fd SHA256 D:\EFI\Boot\bootx64.efi

How can I update my keys?

Enter your BIOS. From the Security menu select the Secure Boot option.
In the Secure Boot sub-menu select the option Custom under Secure Boot Customization. Then select Key Management. Select Restore DB Defaults. At this stage, under Authorized Signatures two keys will be displayed (selecting Details you will be able to see them): Microsoft Corporation UEFI CA 2011 and Microsoft Windows Production PCA 2011.

The one you need to let Windows start is Microsoft Windows Production PCA 2011. Select Delete option, press No (otherwise you will delete both the keys) and choice Microsoft Corporation UEFI CA 2011. To update the keys just generated in your BIOS (so to enable Secure Boot), enter your BIOS and follow the instructions contained in How can I update my keys on BIOS?

To add the db.cer you have created, you have to select Append, otherwise your db.cer will replace Microsoft Windows Production PCA 2011.

Now you can verify that Secure Boot is on: open a new Windows PowerShell as administrator and execute the following command:

Confirm-SecureBootUEFI

How can I update BIOS?

If you use Windows it is not necessary to sign drivers. However, we will show you how to update your BIOS. Create a new folder named Bios_Updater containing bios_updater_x64.bat (or bios_updater_x32.bat),  AFUWINx64.EXE (or AFUWINx32.EXE) and the BIOS you want to update mynewbios.bin.

Open a new cmd and update your BIOS through the following command:

bios_updater.bat mynewbios.bin

Enter your BIOS and verify if it has been updated.

How can I update my keys on BIOS?

The certificates PK.cer, KEK.cer and db.cer are ready to be included in your BIOS. Add them in your USB keys and reboot the system.
Now enter your BIOS. From the Security menu, select the Secure Boot option.

In the Secure Boot sub-menu select the option Custom under Secure Boot Customization. Then select Key Management.

Add your Platform Key following these instructions:

• Select Platform Key (PK) and click Update;

• When a message appears, press No;

• Select the USB key containing your keys;

• Select the folder where your keys are;

• Select the option PK.cer;

• Select Public Key Certificate;

• When a message appears, select Yes;

In the same way, add your KEK.cer and db.cer.

Once you will have added your certificates, your status will change from Setup Mode to User Mode.

Now save the configuration and reboot the system.

Notes

• dbx with latest revocation certificate list is required to be present in all Windows 10 ready out-of-box systems. Default dbx variable contains latest version of Microsoft revocation package with SHA256 Certifcates with the hashes that have already been revoked.
  So, set default dbx. From Secure Boot sub-menu select Restore Factory Keys, automatically Forbidden Signatures will be updated.

• OpenSSL exists also for Windows and it can be downloaded here. However, the steps to follow to create your keys with OpenSSL are quite different from the ones presented for Linux in How can I generate my own keys?.

• If Secure Boot is on with default keys, new Linux distributions are automatically signed with them during their installation (in particular the shimx64.efi file is signed). So both Windows and Linux will start correctly.

• In How can I generate my own keys? we have created the XXX.auth. It can be updated to your BIOS in place of the XXX.cer, as alreday described in How can I update my keys on BIOS?
  But if you are updating your XXX. auth keys from BIOS you have just to configure them as Authenticated Variable in place of Public Key Certificate.

INDEX

What about UEFI mode?

Enter your BIOS. Under the Advanced menu select the Network Stack Configuration submenu and enable the Network Stack option.

 A new menu will appear. From here, enable the PXE Support you desire. In the example below, we enabled both Ipv4 and Ipv6 PXE Support.

Save this configuration and exit.

Now enter your BIOS again. The network drives will now be displayed under the Advanced menu, and from the Save&Exit menu you can select the bootable device.

Save this configuration and exit. A new window will automatically open confirming the completion of the operation.

What about Legacy mode?

Enter your BIOS. Under the Advanced menu select the Network Stack Configuration submenu and enable the Network Stack option.

 A new menu will appear. From here, enable the PXE Support you desire. In the example below, we enabled both Ipv4 and Ipv6 PXE Support.

From the Advanced menu go to the CSM Configuration submenu and enable the CSM Support option.

Now a new menu will appear. Set:

• Legacy only in Boot option filter;

• Legacy in Network option;

• Legacy in Video option.

From Boot menu, set LEGACY in Boot mode select.

Save this configuration and exit. A network drive is now in the list of connected and bootable devices and from Boot menu you can change both the general boot and the network drives’ ones. Select the one you desire, then save and exit.
A new window will automatically open confirming the completion of the operation.

The EFI-Extensible Firmware Interface system partition is a partition on a data storage device (usually a hard disk driver or a solid state drive) that is used by computers adhering to the UEFI-Unified Extensible Firmware Interface.
Since most of the tools we provide are EFI, this guide will help you to create a bootable USB drive with UEFI Shell.

INDEX

How can I format my media to FAT32?

Linux

First of all, insert your USB drive and select it from all the drives connected to your computer.

Now umount your USB drive and select Settings.

The Volume Name field allows you to enter a name for the drive. This label will appear when the drive is connected to devices. You need to select For use with all systems and device (FAT), while it is not necessary to set Erase: ON.

When a new window appears, select Format. You will be prompted to confirm that you want to delete everything on the drive.

Windows

Insert your USB drive and select it from all the drives connected to your computer. Right-click on your USB drive and select Format. A new window will appear.

The Volume label field allows you to enter a name for the drive. This label will appear when the drive is connected to devices.

Click Start to begin the formatting process. You will be prompted to confirm that you want to delete everything on the drive. For most drives, the formatting should only take few moments. Performing a full formatting will take longer.

What’s next?

In our BIOS update package you can find the EFI folder where the EFI Shell bootloader is placed:

EFI/Boot/Bootx64.efi

Directly copy the EFI folder in your USB key.