Platform

Overview Get the final files into a directory eg. target and treat it as root(/) directory of target board/system. Generate users eg. root, admin, ssh, etc Generate device lists Clean few files Generate ext image using mkfs Taking reference from buildroot common.mk and ext2.mk scripts/makedevs -d output/build/buildroot-fs/full_devices_table.txt output/build/buildroot-fs/ext2/target mkfs.ext4 -d output/build/buildroot-fs/ext2/target -r 1 -N 0 -m 5 -L rootfs -O ^64bit output/images/rootfs.ext2 2G # Fakeroot execution complete /opt/rk3588_nvrx/host/sbin/resize2fs -M output/images/rootfs.ext2 /opt/rk3588_nvrx/host/sbin/e2fsck -fy /output/images/rootfs.ext2 /opt/rk3588_nvrx/host/sbin/resize2fs -M /output/images/rootfs.ext2 Fakeroot Script #!/bin/sh set -ex chown -h -R 0:0 $(TARGET) $(HOST_DIR)/bin/makedevs -d full_devices_table.txt $(TARGET) $(HOST_DIR)/sbin/mkfs.ext4 -d $(TARGET) -r 1 -N 0 -m 5 -L "rootfs" -O ^64bit rootfs.ext2 "2G" Post EXT4 $(HOST_DIR)/sbin/resize2fs -M rootfs.ext2 $(HOST_DIR)/sbin/e2fsck -fy rootfs.ext2 $(HOST_DIR)/sbin/tune2fs -m 5 rootfs.ext2 $(HOST_DIR)/sbin/resize2fs -M rootfs.ext2 Testing on Host sudo mount -o loop path/to/rootfs.ext4 /tmp/fs_path Makedevs Creates a batch of special files as specified in a device table. ...

Basics of I2C Overview Synchronous, multi-master, multi-slave serial bus. Half-duplex communication (bidirectional SDA line). Uses 2 wires: SCL (clock), SDA (data). Speeds: Standard (100 kHz), Fast (400 kHz), High-Speed (3.4 MHz). Physical Layer Open-drain outputs – requires pull-up resistors. 7-bit or 10-bit addressing (supports up to 128/1024 devices). Data Frame Structure Start condition: SDA ↓ while SCL is high. Address frame: 7/10-bit address + R/W bit. ACK/NACK: Slave pulls SDA low to acknowledge. Data frames (8-bit chunks, MSB-first). Stop condition: SDA ↑ while SCL is high. Start | Address | Read/Write | ACK/NACK | Data | Stop Key Features Clock stretching: Slaves can hold SCL low to pause communication. Multi-master arbitration: Masters detect collisions via SDA monitoring. Speeds: Standard (100 kbps), Fast (400 kbps), High-Speed (3.4 Mbps). Use Cases Sensors (temperature, accelerometers). EEPROMs, RTC (Real-Time Clock) modules. Device Tree TODO Writing client device drivers TODO I2C-Tools Package in Userspace Useful for debugging, testing, some simple prototyping Accesses the I²C bus via /dev/i2c-0, /dev/i2c-1… Assume devices have registers, SMBus-like i2cdetect scan an I2C bus for devices No guarantee it works (I²C is not discoverable by the spec) [rishav] ➜ ~ i2cdetect -l i2c-0 i2c i915 gmbus dpc I2C adapter i2c-1 i2c i915 gmbus dpb I2C adapter i2c-2 i2c i915 gmbus dpd I2C adapter i2c-3 i2c AUX A/DDI A/PHY A I2C adapter i2c-4 unknown Synopsys DesignWare I2C adapter N/A i2c-5 unknown Synopsys DesignWare I2C adapter N/A i2c-6 unknown SMBus I801 adapter at f040 N/A [rishav] ➜ ~ i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- 28 -- -- -- -- -- -- -- 30: -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- No response 28 Response from address 28 UU Address in use (by driver) i2cget, i2cset i2cget: read a register value i2cset: set a register value Can use various types of SMBus and I2C transactions Limited to 8-bit register address # i2cget -y 2 0x28 0x1b 0x21 # i2cset -y 2 0x28 0x55 # i2cdump dump value of all registers i2ctransfer i2ctransfer: the “swiss army knife of Linux I2C”, in userspace Example: reimplement the i2cget -y 2 0x28 0x1b command: # i2ctransfer -y 2 w1@0x28 0x1b r1@0x28 0x21 # w1@0x28 Write transaction, 1 byte, client address 0x28 0x1b Data to send in the write transaction r1@0x28 Read transaction, 1 byte, client address 0x28 Troubleshooting Return code from i2c_*() functions — Never ignore errors! Kernel logs i2c-tools Oscilloscope or logic analyzer No ACK from client - systematic Problem: a client never responds to transactions ...

Example Image Tree Source (.its) file /dts-v1/; / { description = "U-Boot FIT source file for arm"; images { uboot { data = /incbin/("uboot.img.enc"); type = "standalone"; arch = "arm64"; compression = "none"; load = <0xffffff00>; hash { algo = "sha256"; }; }; }; configurations { default = "conf"; conf { rollback-index = <0x00>; uboot = "uboot"; board-type = "MU_BOARD"; signature { algo = "sha256,rsa2048"; padding = "pss"; key-name-hint = "dev"; sign-images = "uboot"; }; }; }; }; References https://devicetree-specification.readthedocs.io/en/stable/index.html

Device Tree Standard Properties compatible The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. ...

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

Preparation Install Dependencies sudo pacman -S base-devel xmlto kmod inetutils bc libelf git --needed Downloading source and local setup It is recommended to create a separate build directory for your kernel(s). In this example, the directory kernelbuild will be created in the home directory: mkdir ~/kernelbuild cd ~/kernelbuild Goto kernel.org and download kernel source wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.14.5.tar.xz Note: you can verify signature of the downloaded tarball if you want Extract tarball tar -xvJf linux-5.14.5.tar.xz Check ...