Platform/BootLoader

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 ...

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 (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. ...