BootLoader on Rishav's Digital Garden

Problem - fw_printenv does not print bootloader env variables

Wed, 04 Dec 2024 17:20:00 +0000

Problem

In bootloader the environment variables are accessible. The values could be accessed and modified perfectly from bootloader cli (hush shell). When booting to the linux kernel and accessing from bash shell (userspace) through fw_printenv the environment variables are not accessible. Getting following logs:

Warning: Bad CRC, using default environment

Setup:

Using MMC storage
The /etc/fw_env.config file has following entry and the offset and size are same from uboot’s .config file

/dev/mmcblk0p2 0x3f8000 0x8000

Uboot Environment in RK3588

Uboot Config

config ENV_OFFSET
 hex "Environment offset"
 depends on !ENV_IS_IN_UBI
 depends on !ENV_IS_NOWHERE || ENVF
 default 0x0 if ENVF
 default 0x3f8000
 help
 Offset from the start of the device (or partition)

config ENV_SIZE
 hex "Environment size"
 default 0x8000
 help
 Size of the environment storage area

Parameters

CONFIG_ENV_SIZE=0x8000 --> 32K
CONFIG_ENV_OFFSET=0x3f8000 --> 4096-32=4064 4096K=4M

u-boot/tools/env/fw_env.c Either crc0_ok = (crc0 == *environment.crc); is invalid

mkimage

Tue, 05 Nov 2024 12:17:00 +0000

Overview

U-Boot expects all bootable files (kernel, device tree blobs, initramfs, scripts, etc.) to have a specific image format called U-Boot Image Format (uImage format). mkimage generates this format.

Signing images

Generate signed image

build/uboot/tools/mkimage -k config/keys/secureboot -f boot.its boot.img

Dump information

dumpimage -l boot-temp.img

Resign the image

build/uboot/tools/mkimage -F -k config/keys/secureboot boot.img

Directory Structure Expected by `-k`

/path/to/keys/
├── dev.key <-- Private key (used by mkimage)
├── dev.crt <-- X.509 certificate (optional)
├── dev.pub <-- Public key (for embedding in U-Boot, or image)

The filename prefix (dev) maps to the key-name in the .its file.

RSA

Fri, 18 Oct 2024 10:46:00 +0000

RSA (Rivest–Shamir–Adleman) is an asymmetric cryptographic algorithm, widely used for secure data transmission, especially for signing and encrypting data.

In the RSA signing process, a private key is used to sign the message, while a public key is used to verify the signature. Here’s how the signing and verification process works:

1. Public and Private Keys

Private Key: This key is kept secret and is used to sign data. Only the entity that owns the private key should be able to generate the signature.
Public Key: This key is shared with others. It is used to verify that the data was indeed signed by the corresponding private key holder.
Key Pair: RSA works on a pair of keys(one private and one public). A unique public/private key pair is generated together. There cannot be multiple private keys for a given public key.

For embedded systems, where resources (CPU, memory) are limited, RSA’s asymmetric nature means that only the private key holder can sign, while anyone with the public key can verify. This is useful in secure boot processes or authenticating firmware updates, as the system can verify code signed by the vendor.