Programmer's Hideaway

RISC-V Privilege Levels

2026-09-06T00:30:12+05:30

Hello everyone. It has been a while since my last post. Recently, I encountered some missing functionality in Zephyr that led me down a rabbit hole into RISC-V privilege levels. While I was vageuly aware that CPUs have privilege levels, I never had any reason to get a deeper understanding regarding the subject. Since I ended up working closely on something related to it, I figured I should document things for my future self.

Background

BeagleV-Fire is a SBC by BeagleBoard.org with Microchip® Polarfire® MPFS025T SoC. Unlike most other BeagleBoard.org boards, the initial Zephyr support for it was upstreamed by Conor Paxton rather than of me.

Recently, I started exploring Zephyr on BeagleV-Fire, and found that the only supported way to boot a Zephyr image was to build a custom image and write it to the board's eMMC.

On boards like PocketBeagle 2, I normally use u-boot to launch the Zephyr firmware. Having the ability to use u-boot also allows loading firmware over nfs or tftp, which makes development much faster. So I wanted a similar development setup for BeagleV-Fire.

Initially, I assumed it would come down to a few devicetree and Kconfig changes. However, I soon discovered that Zephyr simply lacked the ability to launch in Supervisory mode in RISC-V. It always assumed that it would be entered in Machine Mode, even with RISCV_S_MODE set. All the option did was to make Zephyr perform an M-mode to S-mode transition, and run a piece of code (a crude SBI implementation) in M-Mode to service M-mode only functionality.

In this post, I will go over the different privilege modes and why they are required.

Why have privilege levels at all

The idea behind privilege levels is simple: code that is more trusted gets to touch more of the machine. An application should not be able to reprogram the interrupt controller. A kernel should not be able to accidentally reconfigure the memory protection that firmware set up around it. Each level down the stack is handed a smaller machine than the one above it, and the boundaries are enforced by hardware rather than by convention.

There is a second, less obvious reason, and it is the one that matters most for this post: portability. Everything that is genuinely SoC specific, or that vendors can get wrong, can be kept in a small firmware blob at the highest privilege level. The OS below it talks to that firmware through a stable interface instead of poking vendor registers directly. On RISC-V that interface is the Supervisory Binary Interface.

Privilege levels in RISC-V

RISC-V defines three privilege modes:

Level	Encoding	Name	Abbreviation
0	`00`	User/Application	U
1	`01`	Supervisor	S
2	`10`	Reserved
3	`11`	Machine	M

Higher encoding means higher privilege.

There is no CSR that tells you which mode you are currently running in. The current privilege level is the internal state of the hart. Software is expected to already know, because in practice each piece of software is built for a particular level.

Machine mode (M-mode)

M-mode is the highest privilege level and the only mandatory one. Every RISC-V hart comes out of reset in M-mode. Code here has unrestricted access to the entire physical address space, every CSR, and all of the platform hardware. Nothing below it can constrain it, and there is no mechanism to sandbox it.

This is where firmware lives: DDR and clock bring-up, errata workarounds, and the runtime that serves the OS. Because M-mode cannot be restricted, the goal is to run as little as possible in it.

For a small MCU-class RTOS, M-mode is often the only mode implemented on the target, which is exactly the world Zephyr was originally written for.

Supervisor mode (S-mode)

S-mode is where an OS kernel runs: Linux, the BSDs, u-boot proper, and now Zephyr. It gets virtual memory through satp and the MMU, its own set of trap handling CSRs, its own interrupt enable and pending bits, and access to whatever physical memory M-mode decided to leave open to it.

What it does not get is any view of M-mode. S-mode cannot read mhartid, cannot write mtvec. As far as S-mode is concerned, those registers do not exist.

S-mode is optional, and it is only meaningful together with U-mode. A system with S-mode but no U-mode would have a kernel and nothing to isolate it from.

User mode (U-mode)

The least privileged level, where application code runs. U-mode has no trap CSRs of its own, so every trap it takes is handled by a higher level. Paired with the MMU under S-mode this is what gives you process isolation.

The CSRs

Most of the trap handling machinery exists twice, once per mode, with an m or s prefix:

Purpose	M-mode	S-mode
Status	`mstatus`	`sstatus`
Trap vector	`mtvec`	`stvec`
Exception PC	`mepc`	`sepc`
Trap cause	`mcause`	`scause`
Interrupt enable/pending	`mie` / `mip`	`sie` / `sip`
Scratch	`mscratch`	`sscratch`
Address translation	—	`satp`
Hart ID	`mhartid`	—

More CSRs exist, but I am only mentioning the ones I encountered during my work.

The two asymmetric entries are the interesting ones. satp only exists in S-mode, because M-mode never uses address translation. And there is no shartid, so an S-mode payload cannot ask the hardware which hart it is running on. Instead, the RISC-V boot protocol hands the payload a0 = hartid and a1 = DTB pointer, and it is expected to hold on to them.

The access rule is worth stating explicitly, because it caused me some confusion. CSR address bits [9:8] encode the lowest privilege level allowed to access that CSR. Attempting to read mhartid from S-mode raises an illegal instruction exception. This is the reason why the Zephyr would just throw an exception when I naively tried launching it from u-boot.

Ending Thoughts

That is all for this post. In a future post I will cover how a hart actually moves between these modes, the Supervisor Binary Interface (SBI), openSBI, and how S-mode code talks to the firmware sitting above it. After that, I will come back to BeagleV-Fire and go through what it took to make Zephyr boot as an S-mode payload from u-boot.

Consider supporting me if you like my work.

Helpful links

Fedora on BeagleY-AI

2025-12-28T00:30:12+05:30

Hello everyone. Today I will be going over getting Fedora Minimal Rawhide running on BeagleY-AI. I will also talk about the motivation behind this little adventure and the future plans for this little side project.

Motivation

Since starting work at BeagleBoard.org, I’ve tried to follow an upstream-first approach for both Linux and Zephyr RTOS. This philosophy has worked well for Zephyr, but applying it to Linux has been more challenging due to the sheer complexity of upstream Linux development and limited resources.

The Debian images currently provided by BeagleBoard include a significant number of downstream patches (kernel, Mesa, and others). While these patches are often necessary, they make it difficult to accurately assess the true upstream status of a given board.

Fedora Linux, on the other hand, is well known for its upstream-first mindset and is widely used by kernel and platform developers. Supporting Fedora—even if initially just as a development-oriented setup—feels like a natural fit.

On a more personal note, I’ve been using Fedora on my own machines for quite some time. It strikes a good balance between the bleeding-edge nature of Arch Linux and the slower cadence of Ubuntu LTS. Ideally, I’d like to see Fedora IoT or Fedora Server images become viable options on BeagleBoard SBCs.

Prepare SD Card

For this setup, I used the Fedora Minimal Rawhide (2025-12-28) build. Rawhide composes are pruned after a few weeks, so that exact image is no longer available; the equivalent current build lives in the Rawhide aarch64 Spins images directory.

Flash the Fedora image to the SD card. As described in Fedora docs, using arm-image-installer.

sudo arm-image-installer --target=beagleplay \
                         --image=Fedora-Minimal-Rawhide-20251228.n.0.aarch64.raw.xz \
                         --media=/dev/sdx --resizefs --norootpass --showboot \
                         --args "console=ttyS2,115200n8 selinux=0"

NOTE: I am using beagleplay as a target since there is no beagley-ai target in upstream right now.

Copy proper U-Boot binaries to the SD Card BOOT partition. Prebuilt binaries are available here.

cd /pat/to/boot
wget https://github.com/beagleboard/u-boot-beagley-ai/releases/download/v2025.07-Beagle-11.01.05/tiboot3.bin
wget https://github.com/beagleboard/u-boot-beagley-ai/releases/download/v2025.07-Beagle-11.01.05/tispl.bin
wget https://github.com/beagleboard/u-boot-beagley-ai/releases/download/v2025.07-Beagle-11.01.05/u-boot.img

Fix Initramfs

The initramfs shipped with current Fedora images is missing the irq-ti-sci-intr driver, which causes the kernel to fail during early boot. I’ve already opened an upstream PR to address this. Until that lands, the workaround is to regenerate the initramfs manually. This can be done from an x86_64 host.

Mount SD-Card.

sudo mount /dev/sdx3 /mnt
sudo mount /dev/sdx2 /mnt/boot
sudo mount /dev/sdx1 /mnt/boot/efi
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys  /mnt/sys

Chroot into the SD-Card root.

sudo chroot /mnt

Regenerate initramfs:

dracut --regenerate-all --force --no-hostonly --tmpdir /tmp --add-drivers "irq-ti-sci-intr" -L 5

Exit and eject the SD card.

Boot Fedora

Insert the SD card into the BeagleY-AI and power it on. Once the kernel boots, you’ll see the Fedora first-boot setup wizard over UART. After completing the setup, you should land at a shell prompt:

Fedora Linux 44 (Rawhide Prerelease)
Kernel 6.18.0-65.fc44.aarch64 on aarch64 (ttyS2)

localhost login: beagle
Password:
[beagle@localhost ~]$ uname -a
Linux localhost.localdomain 6.18.0-65.fc44.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Dec  1 22:47:35 UTC 2025 aarch64 GNU/Linux
[beagle@localhost ~]$

Future Plans

This exercise uncovered more missing pieces than I initially expected. In no particular order:

Some binary blobs required to build U-Boot for AM67A are missing from the upstream linux-firmware repository. This prevents U-Boot for BeagleY-AI (and boards like BeaglePlay) from being built as part of Fedora’s uboot-images-armv8 package.
The initramfs issue described above.
Wi-Fi support is currently broken in Fedora on this platform.

The short-term goal is to streamline the Fedora bring-up experience:

Proper U-Boot builds in upstream Fedora
Native support in arm-image-installer
A fixed initramfs by default

Once these fundamentals are solid, attention can shift to Wi-Fi, display, and other peripherals.

Ending Thoughts

That is all for this post. Hopefully, this helps with improving the upstream status of BeagleBoard Linux SBCs.

Consider supporting me if you like my work.

Helpful links

PocketBeagle 2 Zephyr DFU

2025-11-15T00:30:12+05:30

Hello everyone. It has been a while since my last post. Today, I will go over using DFU over USB on PocketBeagle 2. I will only be loading the firmware to RAM, since that should be the normal use case when doing Zephyr development. It is possible to do DFU to MMC or SD Card, so I might cover it in the future.

Motivation

During normal Zephyr development for PocketBeagle 2 A53, one has to copy the firmware to the SD card (using some sort of MicroSD reader). This is fine for deployment, but it can become cumbersome when doing rapid changes.

Using DFU over USB allows bypassing the requirement of an SD Card, thus providing a much better setup for rapid prototyping. Using DFU, it is possible to go from scratch to a Zephyr application without having an SD Card plugged in, and with minimal user input.

Working Demo

Steps

Download the DFU u-boot binaries. I am using v2025.10-am62-pocketbeagle2-11.02.04 for the demo.

wget https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/tiboot3-usbdfu.bin
wget https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/tispl.bin
wget https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/u-boot-zephyrdfu.img

Install dfu-util CLI.
Plug in PocketBeagle 2 and check if it is available.

dfu-util -l

Upload tiboot3-usbdfu.bin:

dfu-util -R -a bootloader -D ./tiboot3-usbdfu.bin

Upload tispl.bin:

dfu-util -R -a tispl.bin -D ./tispl.bin

Upload u-boot-zephyrdfu.img:

dfu-util -R  -a u-boot.img -D ./u-boot-zephyrdfu.img

Upload zephyr.bin. I am using MicroPython firmware here.

wget https://github.com/beagleboard/micropython-builder/releases/download/continuous-release/pocketbeagle_2-am6254-a53.bin.xz
xz -d pocketbeagle_2-am6254-a53.bin.xz
dfu-util -R  -a zephyr.bin -D pocketbeagle_2-am6254-a53.bin

Logs

Here are the logs from both host and device to help with the process.

Host

❯ wget https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/tiboot3-usbdfu.bin
                                                                                                                                       
HTTP response 302  [https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/tiboot3-?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A54%3A12Z&rscd=attachment%3B+filename%3Dtiboot3-usbdfu.bin&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A54%3A06Z&ske=2025-11-15T04%3A54%3A12Z&sks=b&skv=2018-11-09&sig=KFlqUGcd0puVvVrY31Sa%2BclfnTVG%2FlmvDDhCjlC5Ssc%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU0NCwibmJmIjot-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A54%3A06Z&ske=2025-11-15T04%3A54%3A12Z&sks=b&skv=2018-11-09&sig=KFlqUGcd0puVvVrY31Sa%2BclfnTVG%2FlmvDDhCjlC5Ssc%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU0NCwibmJmIjoSaving 'tiboot3-usbdfu.bin'                                                                                                            HTTP response 200  [https://release-assets.githubusercontent.com/github-production-release-asset/972828200/cf85b54e-eea3-4648-905f-c09fe970d4e1?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A54%3A12Z&rscd=attachment%3B+filename%3Dtiboot3-usbdfu.bin&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A54%3A06Z&ske=2025-11-15T04%3A54%3A12Z&sks=b&skv=2018-11-09&sig=KFlqUGcd0puVvVrY31Sa%2BclfnTVG%2FlmvDDhCjlC5Ssc%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU0NCwtiboot3-usbdfu.bin   100% [====================================================================================>]  304.80K  165.75KB/si

❯ wget https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/tispl.bin
                                                                                                                                       
HTTP response 302  [https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/tispl.bi?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A53%3A50Z&rscd=attachment%3B+filename%3Dtispl.bin&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A53%3A28Z&ske=2025-11-15T04%3A53%3A50Z&sks=b&skv=2018-11-09&sig=kSXoqxRhMuW3y9Hw40CAJKevVgyjWtyQDwbZ1RQ5czI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU1OSwibmJmIjoxNzYzMTgwMjU5skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A53%3A28Z&ske=2025-11-15T04%3A53%3A50Z&sks=b&skv=2018-11-09&sig=kSXoqxRhMuW3y9Hw40CAJKevVgyjWtyQDwbZ1RQ5czI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU1OSwibmJmIjoxNzYzMTgwMjU5Saving 'tispl.bin'                                                                                                                     HTTP response 200  [https://release-assets.githubusercontent.com/github-production-release-asset/972828200/8d57a55b-5bd2-4b9d-b391-909781bda7b8?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A53%3A50Z&rscd=attachment%3B+filename%3Dtispl.bin&rsct=application%2Foctet
-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A53%3A28Z&ske=2025-11-15T04%3A53%3A50Z&sks=b&skv=2018-11-09&sig=kSXoqxRhMuW3y9Hw40CAJKevVgyjWtyQDwbZ1RQ5czI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU1OSwibmJmIjoxNzYztispl.bin            100% [====================================================================================>]  924.72K  376.88KB/se-content-disposition=attac[Files: 1  Bytes: 924.72K [145.76KB/s] Redirects: 1  Todo: 0  Errors: 0               ]
                                                                                                                                       
❯ wget https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/u-boot-zephyrdfu.img
                                                                                                                                       
HTTP response 302  [https://github.com/beagleboard/u-boot-pocketbeagle2/releases/download/v2025.10-am62-pocketbeagle2-11.02.04/u-boot-zAdding URL: https://release-assets.githubusercontent.com/github-production-release-asset/972828200/73c288ae-6ed1-4ca4-b1d8-8e2b8ff7a479?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A54%3A51Z&rscd=attachment%3B+filename%3Du-boot-zephyrdfu.img&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A54%3A12Z&ske=2025-11-15T04%3A54%3A51Z&sks=b&skv=2018-11-09&sig=V%2FIQP9oBpZQ658Q1onytLpGWaYJ4BuKYNYSr%2FShfJyI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU2NywibmJmIAdding URL: https://release-assets.githubusercontent.com/github-production-release-asset/972828200/73c288ae-6ed1-4ca4-b1d8-8e2b8ff7a479?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A54%3A51Z&rscd=attachment%3B+filename%3Du-boot-zephyrdfu.img&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A54%3A12Z&ske=2025-11-15T04%3A54%3A51Z&sks=b&skv=2018-11-09&sig=V%2FIQP9oBpZQ658Q1onytLpGWaYJ4BuKYNYSr%2FShfJyI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU2NywibmJmISaving 'u-boot-zephyrdfu.img'HTTP response 200  [https://release-assets.githubusercontent.com/github-production-release-asset/972828200/73c288ae-6ed1-4ca4-b1d8-8e2b8ff7a479?sp=r&sv=2018-11-09&sr=b&spr=https&se=2025-11-15T04%3A54%3A51Z&rscd=attachment%3B+filename%3Du-boot-zephyrdfu.img&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2025-11-15T03%3A54%3A12Z&ske=2025-11-15T04%3A54%3A51Z&sks=b&skv=2018-11-09&sig=V%2FIQP9oBpZQ658Q1onytLpGWaYJ4BuKYNYSr%2FShfJyI%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2MzE4MDU2Nu-boot-zephyrdfu.img 100% [====================================================================================>]  875.71K  327.64KB/sDXwtXH4&response-content-di[Files: 1  Bytes: 875.71K [195.34KB/s] Redirects: 1  Todo: 0  Errors: 0               ]tion%2Foctet-stream]

❯ sudo dfu-util -l
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0451:6165] ver=0200, devnum=11, cfg=1, intf=0, path="3-1", alt=1, name="SocId", serial="01.00.00.00"
Found DFU: [0451:6165] ver=0200, devnum=11, cfg=1, intf=0, path="3-1", alt=0, name="bootloader", serial="01.00.00.00"
 
❯ sudo dfu-util -R -a bootloader -D ./tiboot3-usbdfu.bin
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 512
Copying data from PC to DFU device
Download        [=========================] 100%       312122 bytes
Download done.
DFU state(6) = dfuMANIFEST-SYNC, status(0) = No error condition is present
dfu-util: unable to read DFU status after completion (LIBUSB_ERROR_IO)

❯ sudo dfu-util -R -a tispl.bin -D ./tispl.bin
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from PC to DFU device
Download        [=========================] 100%       946923 bytes
Download done.
DFU state(7) = dfuMANIFEST, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to Run-Time mode

❯ sudo dfu-util -R  -a u-boot.img -D ./u-boot-zephyrdfu.img
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #1 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from PC to DFU device
Download        [=========================] 100%       896735 bytes
Download done.
DFU state(7) = dfuMANIFEST, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to Run-Time mode

❯ sudo dfu-util -R  -a zephyr.bin -D pocketbeagle_2-am6254-a53.bin
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 0451:6165
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from PC to DFU device
Download        [=========================] 100%       459192 bytes
Download done.
DFU state(7) = dfuMANIFEST, status(0) = No error condition is present
DFU state(2) = dfuIDLE, status(0) = No error condition is present
Done!
Resetting USB to switch back to Run-Time mode

PocketBeagle 2 UART

❯ tio /dev/ttyACM0
[09:56:45.642] tio 3.9
[09:56:45.642] Press ctrl-t q to quit
[09:56:45.643] Connected to /dev/ttyACM0
�
 U-Boot SPL 2025.10-gebc75819ab98 (Nov 11 2025 - 19:33:39 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.3--v11.02.03 (Fancy Rat)')
Changed A53 CPU frequency to 1400000000Hz (T grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from DFU
dwc3-am62 dwc3-usb@f900000: unable to get ti,syscon-phy-pll-refclk regmap
####DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed
Authentication passed
Loading Environment from nowhere... OK
init_env from device 10 not supported!
Authentication passed
Authentication passed
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.12.8(release):lts-v2.12.8
NOTICE:  BL31: Built : 19:32:42, Nov 11 2025
I/TC:
I/TC: OP-TEE version: 4.8.0 (gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)) #1 Tue Nov 11 19:33:32 UTC 2025 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: GIC redistributor base address not provided
I/TC: Assuming default GIC group status and modifier
I/TC: SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.3--v11.02.03 (Fancy Rat)')
I/TC: HUK Initialized
I/TC: Disabling output console

U-Boot SPL 2025.10-gebc75819ab98 (Nov 11 2025 - 19:34:58 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.2.3--v11.02.03 (Fancy Rat)')
SPL initial stack usage: 2048 bytes
Trying to boot from DFU
dwc3-am62 dwc3-usb@f900000: unable to get ti,syscon-phy-pll-refclk regmap
####DOWNLOAD ... OK
Ctrl+C to exit ...
Authentication passed
Authentication passed


U-Boot 2025.10-gebc75819ab98 (Nov 11 2025 - 19:35:36 +0000)

SoC:   AM62X SR1.0 HS-FS
Reset reason: POR
Model: BeagleBoard.org PocketBeagle2
DRAM:  448 MiB (total 512 MiB)
Core:  88 devices, 31 uclasses, devicetree: separate
MMC:   mmc@fa10000: 0, mmc@fa00000: 1
Loading Environment from nowhere... OK
In:    serial@2860000
Out:   serial@2860000
Err:   serial@2860000
Net:   No ethernet found.
Press SPACE to abort autoboot in 0 seconds
##DOWNLOAD ... OK
Ctrl+C to exit ...
## Starting application at 0x80200000 ...
*** Booting Zephyr OS build 8a72d776c5af ***
Secondary CPU core 1 (MPID:0x1) is up
Secondary CPU core 2 (MPID:0x2) is up
Secondary CPU core 3 (MPID:0x3) is up
MicroPython 9999553aae on 2025-10-20; zephyr-pocketbeagle_2 with am6254
Type "help()" for more information.
>>>

Bonus

I have added initial support for DFU in bb-imager. While the GUI support is not ready yet, it is possible to use the bb-imager-cli.

bb-imager-cli flash dfu "03:01:0451:6165" \
	"bootloader" ./tiboot3-usbdfu.bin \
	"tispl.bin" ./tispl.bin \
	"u-boot.img" ./u-boot-zephyrdfu.img \
	"zephyr.bin" ./pocketbeagle_2-am6254-a53.bin

Here, 03:01:0451:6165 is the device identifier. This can be obtained by using the command bb-imager-cli list-destinations dfu. The identifier might feel a bit awkward, but it seems to be the most stable way to identify a DFU device in a cross-platform manner, since libusb does not expose any path.

Ending Thoughts

That is all for this post. Hopefully, this serves as an example for anyone trying DFU on PocketBeagle 2.

Consider supporting me if you like my work.

Helpful links

MCUboot with BeagleConnect Freedom

2025-08-18T00:30:12+05:30

Hello everyone. It has been a while since my last post. Today, I will go over using MCUboot based serial OTA on BeagleConnect Freedom. Everything required has already been merged to upstream Zephyr now, so no special considerations should be required.

Introduction

BeagleConnect Freedom contains a simple bootloader in ROM, which boots the Zephyr application from the Flash. However, this minimal bootloader does not support advanced functionality such as OTA updates, rollbacks, etc.

Zephyr supports MCUboot, which is a secure bootloader for 32-bits microcontrollers. It helps add support for advanced production usecases such as secure boot, OTA, rollbacks, etc.

In this post, I will only be going over OTA over serial. However, it is possible to support OTA over IEEE802154g and other transport protocols.

MCUboot storage use

When using MCUboot with BeagleConnect Freedom, 56KiB is reserved for MCUboot. This leaves 640KiB of main flash for use by the Zephyr application.

The on-board SPI flash is used to store the secondary image. So outof 2MiB, 1280KiB is available for Zephyr application use.

Demo

For the demo application, I will be using the smp_svr example provided by Zephyr.

Setup Zephyr

Follow the Getting Started Guide to set up Zephyr on your machine. Currently, mainline Zephyr is required for out-of-the-box MCUboot support on BeagleConnect Freedom.

Setup AuTerm

Download and set up AuTerm as described in its repository.

Build Zephyr Application

Build smp_svr + MCUboot using sysbuild.

west build -p -b beagleconnect_freedom --sysbuild samples/subsys/mgmt/mcumgr/smp_svr -- \
    -DEXTRA_CONF_FILE="overlay-serial.conf"

Combine the MCUboot and application binary. The application offset should be 56KiB.

cp build/mcuboot/zephyr/zephyr.bin zephyr.bin
dd conv=notrunc bs=1024 seek=56 if=build/smp_svr/zephyr/zephyr.signed.bin of=zephyr.bin

Flash the application.

cc1352_flasher --bcf zephyr.bin

Check serial output.

❯ tio /dev/ttyACM0
[11:52:04.720] tio 3.9
[11:52:04.720] Press ctrl-t q to quit
[11:52:04.720] Connected to /dev/ttyACM0
** Booting MCUboot v2.2.0-104-gbf5321bb6906 ***
*** Using Zephyr OS build v4.2.0-1763-gffb28eed1da9 ***
*** Booting Zephyr OS build v4.2.0-1763-gffb28eed1da9 ***
[00:00:00.004,699] <inf> smp_sample: build time: Aug 18 2025 11:51:48

Perform Serial OTA

Launch AuTerm.

Select BeagleConnect Freedom Port.

Verify the port.

Open the Port. This will drop you into the Terminal tab. Take note of the build time.

Press the reset button on BeagleConnect Freedom and verify the serial output.

Rebuild the firmware as described above
Navigate to the MCUmgr tab.

Select the newly built signed firmware.

Switch action from Test to Confirm.

Press the Go button to start firmware upload.

Wait for the firmware upload to finish.

Navigate to the Terminal tab to verify that the build time has changed.

Ending Thoughts

That is all for this post. Hopefully, this serves as an example for anyone trying to have OTA working with BeagleConnect Freedom.

Consider supporting me if you like my work.

Helpful links

Running Linux Kernel for Development on PocketBeagle 2

2025-07-13T00:30:12+05:30

Hello everyone. In this post, I will go over the setup I use when doing Linux Kernel development. I will be using PocketBeagle 2 in this post, but the same instructions should work with most other BeagleBoard.org Boards.

Setup

The first step is to fetch the kernel repo. I am going to use linux-next in this post, but the instructions stay the same for other kernel forks.

Clone the repo

git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
cd linux-next

Since we are cross-compiling here, we need to set some environment variables. I personally use direnv, so I set them in the .envrc file:

export ARCH=arm64
# The CROSS_COMPILE binary might be different on Ubuntu based systems. I am using Fedora.
export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu-

Create default config.

make -j$(nproc) defconfig

(Optional) Use menu config to enable more config options.

make -j$(nproc) menuconfig

Building

Build the kernel.

make -j$(nproc)

Copying to SD Card

The partitions on SD Card are mounted at /run/media/ayush/.

Copy Kernel

cp arch/arm64/boot/Image /run/media/ayush/BOOT/ImageDev

Install kernel modules into SD Card.

sudo make -j$(nproc) modules_install INSTALL_MOD_PATH=/run/media/ayush/rootfs

Add entry to extlinux.conf

cat <<'EOF' >> /run/media/ayush/BOOT/extlinux/extlinux.conf
label kernDev
    kernel /ImageDev
    append console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x02860000 root=/dev/mmcblk1p3 ro rootfstype=ext4 rootwait net.ifnames=0 modprobe.blacklist=pocktbeagle_connector
    fdtdir /
    # fdt /ti/k3-am6232-pocketbeagle2-dev.dtb
EOF

(Optional) It is possible to use a custom devicetree along with the kernel. Just copy the devicetree to /run/media/ayush/BOOT/ti/k3-am6232-pocketbeagle2-dev.dtb and uncomment the fdt line in the above entry.

Eject the SD Card.

Booting into the new kernel

U-Boot will now show a menu to select the kernDev boot entry during boot. It is also possible to set the kernDev entry be the default boot entry in extlinux.conf

Once boot up is successful, the running kernel can be checked using uname -r.

Ending Thoughts

That is all for this post. Hopefully, this helps people get an idea regarding running custom kernels without replacing the default one. There are also ways like network booting, which can be specially useful for development, but I will leave those for some other time.

Consider supporting me if you like my work.

Helpful links

BeagleBoard

Introducing BeagleBoard Imager Flatpak

2025-07-12T00:30:12+05:30

Hello everyone. It's been a while since my last post. Instead of doing the normal weekly update, I have decided to try writing something a bit more in-depth. Recently, I have been successful in publishing BeagleBoard Rust Imager to Flathub. So I thought it might be best to go over the development and publishing process.

Why Flatpak?

Flatpak is a cross-distribution packaging format for Linux. It aims to solve the fragmentation of Linux packaging for GUI (and sometimes terminal) applications. However, it is important to note that it doesn't really replace the distribution packages since many low-level packages cannot be packaged as Flatpak. For more information, check out Flatpak Documentation.

I have been using Fedora Sway Atomic for a while now. Being an immutable distribution, I prefer using Flatpaks instead of installing things on the base image using rpm-ostree. Additionally, I already have some experience with Flatpaks due to being a maintainer of Zola flatpak. So, it felt like a good idea to start distributing BeagleBoard Rust Imager as a flatpak.

Being on Flathub might also help attract more people to the project, so that's a bonus.

Install from Flathub

While the main goal of the post is to build the Flatpak locally, it is important to note that anyone not trying to do development should just use the builds available on Flathub.

flatpak install flathub org.beagleboard.imagingutility

Basics of Packaging Rust Applications as Flatpak

Let's go over the basics of what is required to build a Flatpak package for Rust applications.

Dependencies

The build step on Flathub does not have access to the internet. This is a problem because it means we cannot download dependencies from crates.io during the build process. Depending on the level of access to the main project, I have found two ways to package Rust applications as Flatpak.

Create dependency list from Cargo.lock

This method involves creating a list of crates.io dependencies ahead of time, which allows the flatpak builder to download them. This can be done using the scripts provided in the flatpak-builder-tools.

The upsides to this approach are that it does not need any changes to the upstream repo. Thus, it is useful when the package is being created by someone other than the original developers.

However, the dependency list needs to be updated for every new release. Flatpak has some bots that allow watching for new releases in a repository. If used properly, these bots will also create PRs, thus automating the whole update process. However, due to the requirement to regenerate the dependency list, the process now requires manual changes from the Flatpak maintainer.

Use cargo vendor

This is the method I am using for BeagleBoard Rust Imager. Simply put, it uses the cargo vendor command to create a local copy of the dependencies, which is then released as part of the normal release. These vendored dependencies are then downloaded in the flatpak build process and are used for the dependencies instead of downloading them from crates.io.

Since I am the author of BeagleBoard Rust Imager, adding vendored dependencies to the release was not a problem. So I went this route. For every release, I am now building a tar.gz for vendored dependencies.

Files

Let's now go over the main files involved in building the Flatpak.

Metinfo File

The Metinfo file contains all the information that is shown on the Flathub page for the application. It includes things like various URLs related to the project, screenshots, etc. Here is the metainfo file at the time of writing this blog:

<?xml version="1.0" encoding="utf-8"?>

<component type="desktop-application">
	<id>org.beagleboard.imagingutility</id>

	<name>BeagleBoard Imager</name>
	<summary>BeagleBoard Imaging Utility</summary>
	<developer id="org.beagleboard">
		<name>BeagleBoard.org Developers</name>
	</developer>

	<metadata_license>CC0-1.0</metadata_license>
	<project_license>MIT</project_license>

	<description>
		<p>
			Notice: Please download the udev permissions for fixing permission errors when working with BeagleConnect Freedom.
		</p>
		<p>
			The easiest way to install the latest operating system images for your Beagle.
		</p>
	</description>

	<launchable type="desktop-id">org.beagleboard.imagingutility.desktop</launchable>

	<branding>
		<color type="primary" scheme_preference="light">#aa5137</color>
		<color type="primary" scheme_preference="dark">#aa5137</color>
	</branding>

	<categories>
		<category>Development</category>
	</categories>

	<url type="homepage">https://www.beagleboard.org/bb-imager</url>
	<url type="bugtracker">https://github.com/beagleboard/bb-imager-rs/issues</url>
	<url type="donation">https://github.com/sponsors/beagleboard</url>
	<url type="contact">https://www.beagleboard.org/collaborate</url>
	<url type="contribute">https://github.com/beagleboard/bb-imager-rs/blob/main/CONTRIBUTING.md</url>
	<url type="vcs-browser">https://github.com/beagleboard/bb-imager-rs</url>

	<content_rating type="oars-1.1" />

	<screenshots>
		<screenshot type="default">
			<image>https://media.githubusercontent.com/media/beagleboard/bb-imager-rs/refs/tags/v0.0.11/assets/screenshots/home.webp</image>
			<caption>Home</caption>
        	</screenshot>
        	<screenshot>
        		<image>https://media.githubusercontent.com/media/beagleboard/bb-imager-rs/refs/tags/v0.0.11/assets/screenshots/config.webp</image>
			<caption>Image customization</caption>
        	</screenshot>
        	<screenshot>
        		<image>https://media.githubusercontent.com/media/beagleboard/bb-imager-rs/refs/tags/v0.0.11/assets/screenshots/flash.webp</image>
			<caption>Flashing progress</caption>
        	</screenshot>
	</screenshots>

	<releases>
		<release version="0.0.10" date="2025-07-05">
			<url>https://github.com/beagleboard/bb-imager-rs/releases/tag/v0.0.10</url>
		</release>
		<release version="0.0.9" date="2025-07-04">
			<url>https://github.com/beagleboard/bb-imager-rs/releases/tag/v0.0.9</url>
		</release>
		<release version="0.0.8" date="2025-06-26">
			<url>https://github.com/beagleboard/bb-imager-rs/releases/tag/v0.0.8</url>
		</release>
	</releases>
</component>

Check out the Flathub metainfo guidelines for details regarding the metainfo file. This file currently lives in the bb-imager-rs repo.

Flatpak Manifest

The manifest file describes how to build the Flatpak. Let's look at the manifest file at the time of writing this post:

id: org.beagleboard.imagingutility
runtime: org.freedesktop.Platform
runtime-version: '24.08'
sdk: org.freedesktop.Sdk
sdk-extensions:
  - org.freedesktop.Sdk.Extension.rust-stable
command: bb-imager-gui

build-options:
  append-path: /usr/lib/sdk/rust-stable/bin
  env:
    CARGO_HOME: /run/build/bb-imager-gui/cargo

finish-args:
  - --share=ipc
  - --share=network
  - --socket=wayland
  - --socket=fallback-x11
  # SD Card permissions
  - --system-talk-name=org.freedesktop.UDisks2
  # BeagleConnect Freedom
  - --device=all

modules:
  - name: bb-imager-gui
    buildsystem: simple
    build-commands:
      - cargo --offline fetch --verbose --manifest-path bb-imager-gui/Cargo.toml
      - cargo --offline build --release --verbose -p bb-imager-gui -F bcf_cc1352p7
        -F bcf_msp430
      - install -Dm755 ./target/release/bb-imager-gui -t /app/bin/
      - install -Dm644 ./bb-imager-gui/assets/packages/linux/BeagleBoardImager.desktop
        /app/share/applications/${FLATPAK_ID}.desktop
      - desktop-file-edit --set-icon=${FLATPAK_ID} /app/share/applications/${FLATPAK_ID}.desktop
      - install -Dm644 ./bb-imager-gui/assets/icons/icon.png /app/share/icons/hicolor/128x128/apps/${FLATPAK_ID}.png
      - install -Dm644 ./bb-imager-gui/assets/packages/linux/flatpak/org.beagleboard.imagingutility.metainfo.xml
        $FLATPAK_DEST/share/metainfo/${FLATPAK_ID}.metainfo.xml
    sources:
      - type: archive
        url: https://github.com/beagleboard/bb-imager-rs/archive/refs/tags/v0.0.10.tar.gz
        sha256: 485fe37fe8c75946efb4b6e36afc0f20a5aac8dcf47549dc43a4298fbae231cd
        x-checker-data:
          type: json
          url: https://api.github.com/repos/beagleboard/bb-imager-rs/releases/latest
          version-query: .tag_name | sub("^v"; "")
          url-query: '@uri "https://github.com/beagleboard/bb-imager-rs/archive/refs/tags/\(.tag_name).tar.gz"'
          timestamp-query: .published_at
      - type: archive
        url: https://github.com/beagleboard/bb-imager-rs/releases/download/v0.0.10/cargo-vendor.tar.gz
        sha256: 0aee5838110c46d2409adf32a8319581418758fb48dd70faf7d5b463e428f438
        dest: vendor
        x-checker-data:
          type: json
          url: https://api.github.com/repos/beagleboard/bb-imager-rs/releases/latest
          version-query: .tag_name | sub("^v"; "")
          url-query: '@uri "https://github.com/beagleboard/bb-imager-rs/releases/download/\(.tag_name)/cargo-vendor.tar.gz"'
          timestamp-query: .published_at
      - type: file
        path: config.toml
        dest: .cargo/

The Rust-specific things to note here are the following:

It is using 3 files: the source tarball, the vendored dependencies tarball, and a cargo config file. The config file is basically there to tell Cargo to use a local folder for dependency resolution instead of trying to download from crates.io.
The x-checker-data is for Flatpak external data checker. It can be used to automatically check for updates to external sources in the Flatpak manifest. This allows us to automate updates since the checker will create the PR for us when it detects a new release.

Building the Package Locally

Now we have a basic idea regarding all the files involved, let's build and test the flatpak locally.

The first tool we need is flatpak-builder. I like installing it as a flatpak, but it is also possible to install it from the distribution repos.

flatpak install org.flatpak.Builder

Clone the repository

git clone https://github.com/flathub/org.beagleboard.imagingutility.git
cd org.beagleboard.imagingutility

Build and install the Flatpak.

flatpak run org.flatpak.Builder --force-clean --user --repo=repo --install builddir \
    org.beagleboard.imagingutility.yaml

It should now be installed as a flatpak in the system for the current user. Go ahead and test things.

Ending Thoughts

That is all for this post. Hopefully, this helps other people understand how to build and test Flatpak locally.

Consider supporting me if you like my work.

Helpful links

My Week in Code #34

2025-06-08T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

Fix MicroBlocks CI

Recently, the MicroBlocks CI which builds microblocks dev and pilot branches have been failing. After a bit of testing, I found that a cmsis_6 zephyr module is now required by BeagleConnect Freedom. The CI was fixed by allowing the module in the custom west.yml.

Checkout the patch for more details.

BeagleBoard Rust Imager

Improve Windows Performance

For a while, the Windows implementation of flashing images has been different from Linux and macOS. On Linux and macOS, customization was performed after writing the image. However, on Windows, I was not able to open the sysconf.txt file for some reason. So on Windows, I was using the following hack:

Create a temporary copy of the image, or extract to a temporary copy (if the image is compressed).
Perform customization on this temporary file.
Write the modified file to the SD Card.

One of the major reasons for not fixing the problem was that I did not have a Windows machine on hand, and my previous machine was too slow to do things in VM. Recently, I got my hands on an old laptop, which while not fast, is ok enough for testing. So after testing various things, and going through the Raspberry Pi imager source, I was able to conclude that Windows does not like non-aligned reads/write on SD Card. Taking inspiration from the Raspberry Pi imager, I created a wrapper that always accesses data in blocks of 4096 bytes. This seems to fix the Windows issue, allowing removing the need for a temporary working copy. Hopefully, it will provide a noticeable speedup in windows flashing.

Check out the full PR for more details.

Disable customization for local images

Recently, it was pointed out that some of the old Beagle images do not have support for sysconf.txt. Additionally, it can be confusing for new users to have customization options present in local images, since there is nothing to check if customization is supported on such images. So, I have disabled customization options for all local images for now. I am planning to add a toggle to allow developers to apply customization options on local images, but it should be labeled as experimental since it can lead to flashing errors.

Check out the full PR for more details.

Enable PocketBeagle 2 A53 GPIOs

The GPIO subsystem right now has a limitation of only supporting 32 pins per port. While this is a problem that needs to be fixed, all the built-in LEDs in PocketBeagle 2 use pins that are in the supported range. So I have enabled the LEDs for now. This should also help in future PRs that make changes to the GPIO subsystem since PocketBeagle 2 will be used as the testbed.

Check out the full PR for more details.

Previous Property support in devicetree compiler

Since I got some feedback on the v2 of previous-property patches, I have posted Patch v3 to address the comments. This patch series allows constructing devicetree property from previously defined values, enabling things like append, pre-append, etc.

Fix Armbian config overwrite

There has been a lot of work to get Armbian working on BeagleBoard boards. Recently, it was discovered that the Armbian kernel had ext4 support built as a module instead of being built-in. This was a problem since the rootfs is ext4. After a bit of testing, I found that the Armbian build script was overwriting the config for docker, and converting the ext4 support from built-in to a module.

To fix this, I have created a PR that ensures that ext4 (and other drivers) are built as modules only if they are disabled. In case they are set as built-in by some prior config, they are not touched.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #33

2025-06-01T00:30:12+05:30

Hello everyone. I ended up skipping some weekly updates since there was not much to talk about. Maybe I should make this series a bi-weekly thing instead of weekly updates. Anyway, I will be going over things from all the missed weeks as well. Let's get started.

Zephyr

Add MAIN domain USARTs for PocketBeagle 2 M4F

The initial support for PocketBeagle 2 M4F landed a while ago. This support was quite limited, and is being expanded with time. Initially, I thought that the M4F, which is from MCU domain, did not have access to the MAIN domain peripherals. However, this assumption turned out to be wrong.

The cross-domain peripheral support varies a bit, but for the most part, it is possible to use MAIN domain peripherals from MCU domain. This meant that more of the PocketBeagle 2 header functionality could be used from the M4F core. However, the current base devicetree for AM62x M4F did not define nodes for the MAIN domain peripherals.

Since the initial support for M4F was limited to MCU domain UARTs, I started by adding support for MAIN domain USARTs. It is important to note that the M4F does not have access to the interrupts for the MAIN domain USARTs. Thus, only polling based usage is supported.

I have also started following the Linux kernel devicetree nomenclature of having the domain prefix in the peripherals. I will rename the already existing peripheral nodes in the future.

Checkout the full PR for more details.

Add I2C support for PocketBeagle 2 A53

The initial support for PocketBeagle 2 A53s was merged recently. This allows running ZephyrRTOS on the main A53 cores instead of Linux. It uses the same u-boot as Linux, but can be great in very special purpose and high performance real-time use cases.

The initial support was limited to just USARTs. However, I have created a PR to enable I2C pins on the header. Checkout the PR for more details.

BeagleBoard Imaging Utility

macOS signing

For the longest time, the BeagleBoard imaging utility was not signed on any platform. This was a big problem in the case of macOS since without proper signing and notarization, it can be quite confusing and difficult for non-tech savvy people to get it to launch. Since I do not own a mac, it was also quite difficult to test, and thus, I have been mostly ignoring it.

However, with the help from Deepak, I was able to get the macOS packages properly signed and notarized. So, hopefully, this will help attract more users, which in turn might become contributors.

The first release with proper signing is v0.0.6.

Ubuntu 22.04 support

Since switching the development to GitHub, I have been using ubuntu-24.04 runner for Linux builds. However, it was recently brought to my attention that this makes the package not work on older systems such as Ubuntu 22.04, due to glibc. For now, I have switched to building on ubuntu-22.04 runners. However, maybe it would be a good idea to either use Debian docker containers to build the image, or use musl rust targets and do static linking of libc.

GPT partition table support

Most of the BeagleBoard Linux images used the MBR partition table, so GPT partition table was not supported in the BeagleBoard Rust Imager. However, it recently came to my attention that the BeagleV-Fire images use the GPT partition table, and thus was failing. However, I have now added initial support for GPT, so hopefully everything works fine (I have only done Linux testing).

Checkout the PR for more details.

USB DHCP Option

Thanks to the amazing work by Robert, network sharing over USB works great on Windows and macOS. However, it might not always be desirable to have USB NCM support. Thus, it is not possible to enable or disable this from both the CLI and GUI.

Checkout the PR for more details.

Refresh button for Image list

BeagleBoard Imager downloads the list of images and firmwares at the start of each run. This sometimes can go wrong because network requests can fail. Earlier, the only real way to fix this was to relaunch the application, after ensuring a working network. However, I have now added a refresh button in the image selection page that allows manually refreshing the list.

This ended up being a bit more complicated than it might first appear since the distro list is not a single remote list. Instead, it is a result of merging multiple seperate lists. So the refresh button only appears at the first image selection page (no sub-pages).

Checkout the PR for more details.

SSH Auth key support

BeagleBoard Imager now supports specifying authorized ssh keys in the UI, similar to Raspberry Pi imager. Most people using ssh will love this option.

Checkout the PR for full details.

BeaglePlay CC1325P7 Micropython support

Unofficial builds for Micropython on BeaglePlay CC1325P7 have existed for a while. However, since the version of Zephyr in upstream Micropython has been updated, I have created an upstream PR to add support for this MCU. Hopefully, people will find it useful.

Checkout the PR for more details.

Rust Standard Library for UEFI

TCP4 write support

Recently, the initial support for TCP4 (which just included connect support) was merged in upstream Rust. Following on the initial PR, I have created a PR that implements support to send data over the TCP4 connection. Let's hope that it gets merged soon.

Random generation fallback

It was reported in a github issue that some UEFI firmwares do not support the EFI_RNG_PROTOCOL. This causes HashMaps to fail on such systems. I have created a PR to fall back to rdrand on x86 and x86_64 systems if the protocol is missing. This seems to work for the tested systems. I will try adding a similar fallback for ARM systems if someone reports a similar problem.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #32

2025-05-04T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

Use extlinux in Armbian images

Thanks to all the amazing work by Andrei Aldea, PocketBeagle 2 and other BeagleBoard.org boards support Armbian. By default, it seems Armbian uses the old uEnv.txt file to specify the boot entry. This is fine, but the newer extlinux.conf is much more powerful, and is already used in normal BeagleBoard.org Debian images.

There are a few reasons to use extlinux.conf:

First-class support in U-boot.
Allows multiple boot entries: Great when doing kernel development.
Allows fallback to option 1 in case of boot failure.

I have created a PR to use extlinux.conf in PocketBeagle 2 as a start. I will expand to other boards soon.

Linux Kernel

I tried moving the needle forward regarding connector + addon-board setups upstream. Not much progress, but well, what else is new.

Send of_platform_populate abstractions patch series

Since I have decided to write the Beagle cape driver in Rust, I was trying to upstream some of the abstractions I need. As a part of this work, I tried sending abstractions for of_platform_populate and of_platform_depopulate in the following patch series. However, it seems like that function is semi-deprecated. Additionally, it seems like it would be better to send a driver patch with all the abstractions before trying to send the abstractions individually since it is an untested driver.

So the upstreaming rust abstractions are probably on hold for a while. I guess if someone else wants to pick up the abstractions for their drivers, they are in my tree.

Start discussion for connector + addon-board setups

I have mostly worked with the assumption that any connector + addon-board setup will need to only do manipulation of the tree inside the connector node, rather than the global tree. This was derived from some of the other discussions I have had in the past. However, it seems like not everyone agrees regarding that. So I have created a discussion thread to come to a consensus once and for all. I do not want to repeat the same discussion in every thread.

Hopefully, things get resolved soon one way or the other.

BeagleConnect Freedom

Enable watchdog timer in base devicetree

Since MicroPython now supports Zephyr v4.0.0, I was working on adding beagleplay/cc1352p7 support. However, it turns out, that BeagleConnect Freedom is currently broken in upstream MicroPython. This is due to a new requirement of MicroPython for a watchdog timer in devicetree. This was disabled in the upstream BeagleConnect Freedom devicetree. I have created a PR to enable it.

I should also probably create a weekly GitHub action to ensure that BeagleBoard boards do not break, similar to what I am doing for MicroBlocks. There are also plans for maintaining an upstream Zephyr tree specifically for BeagleBoard boards. Stay tuned for that.

Enable ADC Support in MicroPython

I have also enabled ADC support in upstream MicroPython for BeagleConnect Freedom now. Here is the PR.

Improve init format handling in BeagleBoard Imaging Utility

Last week, I introduced Zephyr SD Card images for PocketBeagle 2. These images are intended for running ZephyrRTOS on PocketBeagle 2 A53 cores instead of Linux and thus do not need rootfs. This also means that sysconf.txt based customization options are not useful for these images.

I added a hacky workaround for these images last week to get initial support in BeagleBoard Imaging Utility. But since I had some time, I have added proper support for specifying init_format in the config.json. This is the same as the Rpi config, so things are still backward compatible.

The changeset can be found in the PR.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #31

2025-04-27T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

Zephyr support for PocketBeagle 2

PocketBeagle 2 is a single board computer with AM62xx soc, and the primary supported OS is Linux. We provide Debian-based images for the board, with initial support for Armbian. This is what most people will be using it with.

However, PocketBeagle 2 is a pretty compact SBC, which can work well in cases where running full Linux might not be required. For such use cases, supporting an RTOS such as Zephyr can provide a great way to get the most performance out of the hardware.

So, continuing the work from M4F, I have created a PR to add Zephyr support for A53s. Currently, only revision A0 is supported.

The current setup of running Zephyr involves loading Zephyr from U-boot, similar to how the normal Linux images work. However, since Zephyr does not need the Linux rootfs, I have added a new repository to build SD card images for Zephyr. These images are a FAT32 boot partition with u-boot, tiboot3, tispl, and custom extlinux.conf. Initially, I was planning to use debos to build these images. However, I was still getting the same problem as described in the issue. So, I switched to using mtools-based image building, which works completely in userspace (and thus inside docker).

The initial support only includes support for UART (on the debug port), but I will slowly add support for more peripherals. The goal is to have a MicroPython image for PocketBeagle 2.

Zephyr SD Card image support in BeagleBoard Rust Imager

Since I am now building Zephyr SD Card images for PocketBeagle 2, I have added support for these images to BeagleBoard Rust Imager. They are the same as Linux SD Card images but just don't have extra customization options.

The full changeset can be found in the PR.

Rust overlay abstractions patch

I have been working on adding Beagle Cape support for PocketBeagle 2, using a combination of export-symbols, i2c-extension, and other proposals. I decided to write the driver in Rust, which meant I had to also write a bunch of missing abstractions. Since the initial work on the driver is done, I have started the process of upstreaming the abstractions.

The first abstraction on the list is overlay abstractions, which allows applying and removing fdt overlays from Rust. I will also be submitting other abstractions (such as sysfs, platform populate, etc) soon.

Rust std r-efi update

The PR to bump r-efi version in r-efi-alloc has been merged now. So r-efi can now finally be updated to r-efi 5.2.0 in the Rust std.

Check out the PR for the full changeset.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #30

2025-04-20T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

PocketBeagle 2 M4 GPIO Support

Initial ZephyrRTOS support for PocketBeagle 2 M4 core was merged last week. This only included tested support for UART (RX: P2.05, TX: P2.07). It is possible to enable GPIO and I2C using overlays, but there are no examples at the moment.

I have created a new PR that enables GPIO in the blinky example (pin P2.09). It should serve as a good example of how to use GPIO from the M4 core.

It is important to note that to use any pins from the M4 core, they must first be disabled in the Linux kernel devicetrees. Hopefully, once an upstream connector driver exists, this can be fixed using a special cape for M4 GPIOs, but for now, the user needs to investigate it.

I am also planning to add ZephyrRTOS support for the A53 cores as soon as M4 core support reaches a stable point. Additionally, I also plan to add all possible pinmuxes to the Zephyr devicetree, similar to how we have it in the Linux devicetree. This should allow easier usage of these pins using overlays. Maybe we can even have a GUI to generate overlays at some point.

PocketBeagle 2 Connector Driver

Since there seem to be some real usage concerns regarding export-symbols, I have been working on an initial PocketBeagle 2 connector driver. To have some fun, I decided to write the driver in Rust, which in the hindside ended up being a bit more work than initially expected.

The current driver is pretty simple. There are some simple principles I am following:

Anything attached to the connector is a single cape. It does make non-cape usage a bit more involved right now, but it should be fixable with a simple GUI to generate the required overlay using a few simple toggles.
The cape devicetree changes should be concentrated on the connector node. This should help with isolation, and curb the concerns regarding security.
Load overlays from /lib/firmware. Should help with security concerns upstream.

There is no support for reading cape EEPROM right now. Instead, some sysfs entries are provided to allow adding and removing a cape using the devicetree overlay (present in /lib/firmware) name.

Since it is written in Rust, I ended up having to write a lot of Rust abstractions (devicetree overlay application, sysfs, etc). I will start with sending patches for the abstractions first since I am a bit unsure if all the assumptions made in my abstractions are correct. Check out my working tree for the latest status.

BeagleBoard Rust Imager

Some bugs were reported in the BeagleBoard Rust Imager which have been fixed now:

Allow FAT16 BOOT Partition: This is used in some BeagleBone Black images.

Additionally, thanks to the work by Sahil Jaiswal, the UI now uses an indeterminate progress bar for non-progress states.

Overhaul Rust UEFI Time

Originally, the implementation of SystemTime for UEFI was using Duration, which was anchored to 1970-01-01-00:00:00 (UNIX EPOCH). This meant that date-time before this was simply unrepresentable in the current implementation.

I have rewritten the implementation with 1900-01-01-00:00:00 as the anchor. This date was chosen, since it is the earliest date supported by UEFI internally, according to the UEFI specification. Additionally, some additional checks were added to ensure that the results of calculations on SystemTime is representable by UEFI time.

Checkout the PR for more details.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #29

2025-04-13T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

PocketBeagle 2 Examples

More work went to make the PocketBeagle 2 Examples as educational as possible. The goal of the examples is to teach Linux APIs. Thus the examples try to use the kernel drivers for the different devices as much as possible.

Make Blinky example lower level

The Blinky example now uses the sysfs entries in the example file. This should help people understand the sysfs LED subsystem interface.

Make Seven Segments example lower level

The Seven Segments example now uses the sysfs entries in the example file. This should help people understand the sysfs Seven Segments interface.

Add more RGB LED Examples

The initial RGB LED example produced different color hues using the pwm-leds-multicolor driver. However, this was a bit overwhelming when converting to sysfs abstractions. This is because there are quite a few sysfs entries for Multicolor LEDS. So it was decided to add some more straightforward examples for the device.

Fade Brightness

The fade brightness example uses the brightness sysfs entries to perform a PWM fade for a single color in the RGB LED. This helps show how the brightness sysfs entry affects the RGB Led.

Fade Intensity

The fade intensity example uses the multi_intensity sysfs entry to perform a PWM fade for the single color in the RGB LED. This helps show how multi_intensity can be used to simulate the same behavior as the brightness sysfs entry.

Color Circle

The color circle example demonstrates generating different colors in the color circle. It only generates basic colors, instead of the different color shades.

Hue

The hue example is the original RGB LED example, and generates various color hues in the RGB LED, giving a nice visual appearance.

Use GPIO Keys for Buttons

In the original examples, I was using libgpiod to read Techlab Cape button inputs. However, I have switched the new examples to use GPIO keys. The buttons now emit RIGHT and LEFT keycodes.

Make EEPROM example lower level

The EEPROM parsing is not handled in the example itself rather than hiding in the beagle_helper. This allows the example to serve as a good demonstration of how to parse ffi structures in Rust and Python.

Use PWM Beeper driver for Buzzer

The Buzzer example now uses the PWM Beeper driver, which allows interacting with the character device, similar to GPIO Keys.

Send v3 of Export Symbols patch

I have sent Patch v3 for Export Symbols. I will also be sending a patch for Beagle Capes soon. The reason for Beagle Capes over MikroBUS is that the capes have a much cleaner history with upstream patches. Additionally, I have a cape that exposes a MikroBUS port (TechLab Cape), which should help ensure that board chaining works well.

Allow specifying Debian package name in Cargo Packager

I have been using a patched version of Cargo Packager for bb-imager-rs since it was missing some features. Since the patch to disable Linux desktop entry has been merged, I have created a PR to allow manually specifying the name for Debian packages. Once it is merged, I can go back to using the upstream cargo packager.

Null stdin for UEFI Command

According to the docs in Command::output:

By default, stdout and stderr are captured (and used to provide the resulting output). Stdin is not inherited from the parent and any attempt by the child process to read from the stdin stream will result in the stream immediately closing.

This was being violated by UEFI which was inheriting stdin by default. While the docs don't explicitly state that the default should be NULL, the behavior seems like reading from NULL.

I have created a PR to implement Stdio::Null and Stdio::Inherit for UEFI.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #28

2025-04-06T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

BeagleBoard Rust Imager

BeagleConnect Freedom Fixes

My last updates seem to have caused BeagleConnect Freedom (both CC1352P7 and MSP430) flashing to break. This was reported by @OhioMeasurementDevices on Discord. I have pushed the fixes to crates.io as version 1.0.2. Additionally, I have also yanked the broken version (1.0.1).

Release v0.0.5

I have also created a new release for bb-imager-rs, which has BeagleConnect Freedom Flashing working again. Additionally, it also fixes links to MicroBlocks firmware, which were broken previously due to some SHA256 problems.

Zephyr Support for PocketBeagle 2 M4 Core

PocketBeagle 2 features the TI AM62x SoC based around an Arm Cortex-A53 multicore cluster with an Arm Cortex-M4F microcontroller, Imagination Technologies AXE-1-16 graphics processor (from revision A1), and TI programmable real-time unit subsystem microcontroller cluster coprocessors.

The PR brings ZephyrRTOS support for the Arm Cortex-M4F microcontroller. This core can be used to offload time-sensitive workflows (PWM bit-banging, Light handling, etc) allowing the A53 cores with Linux to focus on other heavier tasks.

Only UART support is present in the initial PR. However, I will slowly be adding support for other peripherals to be used from the M4F core.

Migrate MicroBlocks to GitHub

As might be visible, there has been an effort to move a lot of BeagleBoard.org development to GitHub. This week, I migrated MicroBlocks to our GitHub. Since the CI for MicroBlocks was already broken on openbeagle.org, it just felt like a good project to migrate.

PocketBeagle 2 Examples

Migrate to GitHub

The development of PocketBeagle 2 Examples will mostly happen on GitHub now. Hopefully, this will make the examples more discoverable.

Make the accelerometer example less abstracted

In a recent discussion, it was decided that the examples should try more to teach using Linux APIs instead of just how to use a library to access various peripherals. So as a start, I have added a small abstraction to make interacting with the sysfs entries a bit easier, while keeping things mostly transparent.

The accelerometer example was the first to be switched to the sysfs abstraction. The full diff can be found in the PR.

Make the light-sensor example less abstracted

Following the footsteps of the accelerometer example, I have also switched the light-sensor example to use the sysfs abstraction. The full diff can be found in the PR.

Make blinky example less abstracted

The blinky example was a bit different since it is the first example that requires writing to a sysfs entry. It is still in the draft stage, waiting for review from everyone, but can be found here.

Intial TCP4 socket support for UEFI

I have finally created a PR to add initial support for TCP sockets to Rust std for UEFI. It marks the start of UEFI networking in Rust std and is required for running Rust test suite on UEFI using the remote-test-server and remote-test-client setup as described here.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #27

2025-03-30T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

BeagleBoard Rust Imager

GitHub Migration

The migration of BeagleBoard Rust Imager to GitHub has now been completed. I have also created v0.0.4 release which brings a lot of fixes and marks the end of the migration.

Eject After flashing

In prior versions of BeagleBoard Rust Imager, I did not eject the SD card after flashing. This would cause weird issues on Linux like not being able to remount the SD card without removing it first. So, the flasher now ejects the SD card after flashing on Linux.

Windows and MacOS still do not eject after flashing.

Windows Customization Fixing

Last week Maique Correa Garcia created an issue regarding flashing failure on Windows. On investigating it further, I found that the customization step (which sets username, hostname, etc) was causing the failure on Windows.

I was able to figure out the initial error quickly. It seems that Windows does not seem to know the size of the SD card which does not have a valid partition table. This meant that when mbrman crate was trying to guess the size by seeking to the end, it would fail on Windows. The solution to that was to only try reading the MBR partition table.

However, after fixing that, I quickly ran into another problem. To give some context, the flow of bb-imager SD card flashing is as follows:

Open the SD card as std::fs::File in platform dependent manner.
Write the OS image to the SD Card File.
Read the MBR table from the SD Card File.
Open/create sysconf.txt in the FAT32 BOOT parition of the SD Card.
Append the entries to sysconf.txt.

For some reason, Windows would fail on step 4. In fact, I was not able to read anything from the BOOT partition on Windows, even though the same code worked fine on Linux.

I did try various things, and tried looking at RPI-imager for inspiration, but was not able to solve the problem. Maybe the problem is something with the way fatfs works.

I then moved onto alternative approaches like having a memory layer on top of the base image which would allow applying customizations in memory, before writing to an SD card. However, this turned out to be a dead end since that would mean needing to have Seek support in the Os Image file, which is not always possible (since the images can be compressed as XZ). I also did not want to create a temporary copy of the extracted image, since that is problematic on devices with limited storage (The flasher can be run on our boards as well).

In the end, I settled on having a separate flashing implementation for Windows, which creates a temporary copy of the extracted OS Image, applies customizations to this copy, and then writes the modified Os Image to an SD Card. I feel like if your machine is running something as heavy as Windows, it should probably be fine to use 8G of temporary file storage.

Update Crates

I have pushed new versions of the following crates:

Isaac Parker's Contributions

I would like to thank Isaac Parker for his contributions last week. Hopefully, BeagleBoard Rust Imager will attract more external contributions with time.

UI Code Improvement

I am using iced as the GUI toolkit for BeagleBoard Rust Imager. It is a cross-platform GUI library for Rust, inspired by Elm. Since the UI code in iced is also just normal Rust (as opposed to Slint which has a separate language for UI), it can be a bit daunting for new contributors, especially the ones who only want to contribute to the UI.

While I have no plans to change the toolkit right now, I decided to isolate the code to a single module, to hopefully make the code more readable and maintainable in the long run. Checkout the PR for more details.

Implement File Times for UEFI

I have created a PR to implement fs File Times for UEFI. This involves adding conversion methods from Unix Time to UEFI Time. I would like to thank everyone involved with the algorithms present here.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #26

2025-03-23T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

BeagleBoard Rust Imager

I am gearing up for a v1 release of BeagleBoard Rust Imager soon. As such, a lot of work went into it this week.

BB-Downloader

While working on BeagleBoard Rust Imager, I initially tried searching for crates that provided the kind of downloading functionality I needed. The features I needed were the following:

Cache downloads to a specific location.
Use SHA256 for caching.
Live progress
Async

I did not find something that met all the criteria, so I ended up rolling my own. Initially, it was just part of bb-imager, but it was overdue for a refactor, so I thought might as well spin it up as its own crate. It is now in crates.io.

BB-Config

BeagleBoard.org maintains a distros.json which contains information regarding the distro images available for each board. The format is defined by Raspberry Pi Imager (old bb-imager was a fork of it), and is still being used by the Rust imager.

I have created a data structure (using serde) to parse and generate this config format. It was initially part of bb-imager, but since it was also in need of refactor, I have spun it off as an independent crate.

Note: While the config format used by bb-imager-rs is compatible with the old bb-imager, it is strictly speaking more of a subset. So it should probably not be used for working with the old imager.

BB-Flasher

With all the refactoring of bb-imager library, the only functionality that was left in the crate was for flashing. So, I have renamed the crate to bb-flaser and just made a lot of general improvements in the code. Additionally, BeagleConnect Freedom and MSP430 support is now optional features. This is nice since that functionality does not work on macOS right now.

Some of the individual flashers (bb-flasher-bcf and bb-flasher-sd) have already been pushed to crates.io. These aim to provide lower level functionality in a simple manner.

The bb-flasher crate acts as a wrapper over the lower level crates, while adding the following stuff:

Support for parsing xz compressed files.
Providing common trait based interface over different flashers.
Providing common trait based interface over different types of Os Images.
Async adapters

I have not pushed bb-flaser to crates.io yet since PocketBeagle 2 MSPM0 flasher is still not ready to be pushed to crates.io. Let's see when the time comes for it.

GitHub Migration

As an experiment to attract more contributors, I have decided to migrate BeagleBoard Rust Imager to GitHub.

I am still in the middle of figuring out the migration to GitHub Actions, but things seem to be working decently well. GitHub CI has a lot of friendly actions, so it has been pretty simple. However, I feel like GitLab CI is still much easier to test locally, since there are no magic actions.

I also now have a continuous integration pre-release, which is quite useful. I also ended up simplifying the CI quite a bit (no longer building packages in PR CLIs) to avoid going over the free CI limits.

Let's hope that GitHub migration proves fruitful.

Cargo Packager

As a part of GitHub migration, I ended up revisiting how I was generating the different packages. I was aware of the existence of cargo-packager for a while, but I had been bitten by cargo-dist in the past, so I was a bit cautious regarding switching to something generic again.

However, since I was doing a huge migration anyway, I thought I might as well use something standard for packaging. I was pleasantly surprised to see how simply I was able to do migration for the GUI. Here are the things I like about it:

Much simpler that my custom Makefile/justfile solution.
Does not need me to create the deb package inside the cross container.
AppImage creation works flawlessly as well.
Now have a Windows installer using Wix.

However, I am not currently using it for the CLI. The reason is that there is no way to disable generating desktop entry right now. CLIs like bb-imager-cli should not have a desktop entry in the package, so this poses a problem. I have created a PR to disable it, so hopefully, I can complete my migration soon.

I also think that it should probably migrate to the newer go-appimage tools for generating AppImages (it currently uses linuxdeployqt). Hopefully, I will get time to create PR regarding this soon.

Export Symbols Patch

Since there was almost no discussion in the v1 Export Symbols Patch, I have sent v2 with better examples, and trailers. Hopefully, I will get some feedback this time. Feel free to check it out in the mailing list.

Rust std for UEFI

Some more work went into Rust std for UEFI this week.

Implement some basics in UEFI fs

I have created a PR to add some basic std::fs for UEFI:

Adds fs::canonicalize. Should be same as absolute in case of UEFI since there is no symlink support and absolute path is guaranteed to be uniqe according to spec.
Make fs::lstat same as fs::stat. Should be same since UEFI does not have symlink support.
Implement OptionOptions.

mkdir

I have created a PR to add support for std::fs::create_directory. Just a small self-contained part for std::fs since I have been trying to keep the PRs small enough to review.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #25

2025-03-16T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

BeagleBoard Rust Imager

I am gearing up for a v1 release of BeagleBoard Rust Imager soon. As such, a lot of work went into it this week.

Justfiles

I have been using Makefiles for all the building and packaging tasks in BeagleBoard Rust Imager. Back when I started using makefiles, I did consider some alternatives:

cargo xtask: I am using xtasks for things which require interacing with Rust code (for example generating manpage using clap_mangen). However, it did not seem like a great fit for a general-purpose task runner since it is somewhat verbose to invoke shell commands. Additionally, compiling Rust isn't exactly the fastest, especially the first compilation which is the case in CI.
just: Did not seem to be better enough than make, especially since make is pre-installed in most unix systems.

Additionally, the initial plan was to keep makefiles somewhat short, so readability was not among the top priorities. I was also much less familiar with make back then, and thus less aware of its pitfalls.

However, with time, the make based system grew quite a bit. Since makefile recipes did not have support for real arguments, a lot of recipes were based on pattern matching, which while being clever, ended up being difficult to understand and document. Additionally, while I did find some hacks to auto-generate help pages using a combination of sed, it was clunky and did not work as expected. There were also a lot of variables in Makefile that could change the build process in interesting ways, but none of them were documented.

Finally, I was essentially using make for running shell commands (aka tasks) and not as a build system to generate files. This meant that essentially, all makefile recipes were PHONY (see this if you do not know what PHONY refers to in make).

It was somewhat clear that I needed to rewrite the makefile-based system from scratch, with good discoverability. So I thought, might as well re-evaluate the alternatives. In the end, I chose just because of its simplicity and comment-based documenting (similar to Rust). Additionally, since it is written in Rust, I can contribute any new features or fix bugs much more easily.

The porting was surprisingly simpler, and overall, the justfiles look much more maintainable. Additionally, anyone new to the project can easily get a handle on the build system now:

❯ just
Available recipes:
    default                                        # default recipe to display help information
    generate-cli-manpage                           # Generate Manpage for CLI
    generate-shell-completion SHELL                # Generate Shell completion for CLI

    [build]
    build-cli TARGET=_HOST_TARGET                  # Release build for Beagle Board Imager CLI. Should be used for final testing
    build-gui TARGET=_HOST_TARGET                  # Release build for Beagle Board Imager GUI. Should be used for final testing
    build-service TARGET=_HOST_TARGET              # Release build for Beagle Board Imager GUI. Should be used for final testing

    [housekeeping]
    check                                          # Run code checks
    clean                                          # Clean Artifacts
    test                                           # Run tests on workspace

    [packaging]
    package-cli-darwin-zip TARGET=_HOST_TARGET     # Create compressed CLI package for macOS
    package-cli-linux-xz TARGET=_HOST_TARGET       # Create compressed CLI package for Linux
    package-cli-windows-zip TARGET=_HOST_TARGET    # Create compressed CLI package for Windows
    package-gui-darwin-dmg TARGET=_HOST_TARGET     # Create macOS dmg package
    package-gui-linux-appimage TARGET=_HOST_TARGET # Create Appimage package for GUI
    package-gui-linux-deb TARGET=_HOST_TARGET      # Create debian package for GUI
    package-gui-windows-zip TARGET=_HOST_TARGET    # Create Windows portable zip package
    package-service-linux-deb TARGET=_HOST_TARGET  # Create debian package for Beagle Board Imager Service
    package-service-linux-xz TARGET=_HOST_TARGET   # Create compressed Beagle Board Imager service package for Linux
    release TARGET=_HOST_TARGET                    # Generate all supported packages for the target

    [run]
    run-cli FLAGS=''                               # Run CLI for quick testing on host. Flags can be used to modify the build
    run-gui FLAGS=''                               # Run GUI for quick testing on host. Flags can be used to modify the build

    [setup]
    setup-appimage INSTALL_DIR=_EXE_DIR            # Setup for building appimages
    setup-deb                                      # Setup for building debian packages
    setup-dmg                                      # Setup for building dmg
    setup-rust                                     # Setup rust toolcahin

❯ just --variables
APPIMAGETOOL PB2_MSPM0 RUST_BUILDER VERSION

I do have some problems with just, namely there does not seem to be a way to have conditional dependencies (I was able to do this in make by using some clever hacks). Additionally, I have not been able to get syntax highlight to work in neovim. So will try to fix those in the future. Overall, I am quite happy with the migration.

Loading Spinners

Since config (and its children) can be remote JSON files, which need to be downloaded, I have been hoping to add loading spinner screens for some much-needed visual oomph.

I was hoping for some third-party widget library with a loading spinner, but I could not find any such crate. Instead, I found an example. I have added it as a crate to the workspace for now, and it seems to be working well. However, I probably should clean up the code at some point.

Checkout the PR for the exact diffs.

Persistent Customization

Raspberry Pi imaging utility has the ability to save any customization settings applied by the user. This is useful since a lot of people using the GUI would probably prefer having the same settings be used for most of their SD card flashing. As such, I have added persistence to the customization settings, along with options to reset and abort the customizations.

The settings are stored in the platform-specific app config directories ($HOME/.config/imagingutility/config.json for Linux) in JSON format. While it is not intended to be modified by the end user, it is possible to do so fairly easily.

Remove remote image support in CLI

I added the ability to download and flash images from URL in CLI in the last update. However, it ended up being somewhat limited since there are cases when one would not want to perform a sha256 check on the downloaded image. Additionally, the CLI interface required using non-positional arguments (--img-local and --img-remote) which felt a bit weird.

Finally, it also seemed a bit unnecessary since anyone using CLI is probably already familiar with wget, and thus should use it for the downloading job. If there are any arguments regarding why remote image support would be useful, feel free to create an issue.

PocketBeagle 2 Accelerometer Examples

TechLab Cape contains an accelerometer, connected over I2C. I have added a simple Python and Rust example just reading the raw x, y, and z values from the accelerometer using iio sysfs entries. Checkout the PR for full details.

In practice, it looks as follows:

debian@pocketbeagle2:~/vsx-examples/PocketBeagle-2/accelerometer/python$ python main.py
X =  -5 , Y =  -1 , Z =  258
X =  -4 , Y =  0 , Z =  258
X =  -5 , Y =  -1 , Z =  258
...

Previous symbol dtc patches

I have sent the 2nd revisio of the previous symbol dtc patches. Here is the list of changes in this patch:

Compare against expected dtb instead of checking each property individually in tests.
Use xstrdup when copying refs so each marker has its own copy.
Pass struct data by value, not by pointer.
Add srcpos_free helper to properly free srcpos which have been extended previously.
Remove open items since my original choices seem correct.

Let's wait for responses in the mailing list now.

Target support in fdtoverlay

Linux kernel provides support to apply devicetree overlays to specific nodes. This can allow drivers to dynamically apply and remove overlays, which can be used to add support for connector + addon board setups.

However, currently, there is no way to do the same thing with fdtoverlay. This means to change the target node for the overlay, the devicetree overlay source needs to be modified. This is somewhat inconvenient since any addon board overlays will be created assuming that they will be applied on the connector node directly, instead of the base tree. So the same overlays cannot be used with fdtoverlay.

Additionally, having support to specify the target node in fdtoverlay will also allow using the same overlays in static configurations for such connectors (since the overlay can be applied using u-boot).

In practice, it looks as follows:

base.dts:

/dts-v1/;

/ {
        my_node: my-node {
                prop = "hello";
        };
};

overlay.dtso:

/dts-v1/;
/plugin/;
/ {
	fragment@1 {
		target-path = "";
		__overlay__ {
			baz: baznode {
				baz-property = "baz";
			};
		};
	};
};

Apply overlay:

fdtoverlay -t "/my-node" -i base.dtb overlay.dtbo -o final.dtb

Result:

/ {
    my-node {
        prop = "hello";
        phandle = <0x00000001>;
        baznode {
            phandle = <0x00000002>;
            baz-property = "baz";
        };
    };
    __symbols__ {
        baz = "/baznode";
        my_node = "/my-node";
    };
};

It was a bit difficult to implement cleanly since libfdt does not allow allocations. However, it is working well now. Checkout the patch series for more details. All that's left is to wait for someone to review the patches.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #24

2025-03-09T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

BeagleBoard Rust Imager

I have been planning to make BeagleBoard Rust Imager more modular, and extract some of its functionality to other crates. This was to clean up bb-imager (library that powers the GUI and CLI), which now had a lot of platform specific functionality.

The cleanup also helped get some significant performance improvements, which is always nice to see. Let's go over the crates that are now in crates.io.

bb-drivelist

I have been using a patched version of rs-drivelist for a while in bb-imager. This was because the version published in crates.io did not have macOS support. I did contribute the patches upstream, and they were merged. However, it seems that due to some personal issues, the original author cannot push a new release.

Additionally, I also wanted to drop dependencies on the old json crate, and instead use a serde based solution. So I finally decided to make a hard fork and publish a new release.

It would be nice if I could also drop wiapi in favor of windows, but that seems a bit more work that I have the time for right now. So if anyone wants to take a crack at it, feel free to try.

bb-flasher-bcf

Support for BeagleConnect Freedom was the main reason for the creating BeagleBoard Rust Imager. It has been present for a while, so, was straightforward to extract. The bb-flasher-bcf crate contains support for both CC1352P7 and MSP430F5503, which serves as the USB to UART bridge.

I have also made the flashing sync, since I feel that most of the flashing should be done in separate threads. The flashing still includes support for real-time progress and early cancellation.

The library has only been tested on Linux and Windows.

bb-flasher-sd

For the longest time, SD card flashing in BeagleBoard Rust Imager was slower than Raspberry Pi Imager. However, with all the cleanup while creating bb-flasher-sd, the flashing got a huge speed-up, and should now be similar to Raspberry Pi Imager. Additionally, I have drastically cut down on the stack usage, so that should also help.

Finally, I have moved SD card flashing to a separate OS thread instead of tokio thread. This is because it is better to use OS threads for such long-running tasks.

The library should allow SD card flashing of OS images (even non Beagle ones) from Linux, Windows and macOS.

PocketBeagle 2 Examples

More work went into improving PocketBeagle 2 Examples. They are almost at the point where they can serve as nice getting started to teach new people about embedded programming.

Sysfs LED

The original LED abstraction in Beagle Helper library only supported GPIO pins. However, some LEDs (like USR_LED{1-4} in PocketBeagle 2) are defined in the devicetree and use the Kernel LED driver.

I have added support in LED abstraction to allow using LEDs defined in the devicetree using the sysfs entry. I have also modified the PocketBeagle 2 blinky example to use USR_LED4, since it seemed better to not require external LED for a simple blinky example.

Update README

The README of all the examples for PocketBeagle 2 have been greatly improved. They now follow a common structure with the following sections:

Goal: Goals of the example
Overview: Details regarding the background of the example.
Challenges: Some challenges to get better acquainted with the example.

They should provide a better start for creating tutorials using the examples.

CI Testing

All the Rust examples were already being built in CI to ensure that at least everything builds fine. However, I was not certain how to do it for an interpreted language like Python. However, I have now started using pylint, which seems to provide at least a basic level of guarantees regarding all python examples.

Rust Std for UEFI

I am still waiting on DevicePathNode PR to move forward with File I/O implementation. However, I have decided to start pushing some other independent PRs to well, maybe speed things up.

OwnedEvent Abstraction

Since Service Binding Protocol PR was merged last week, the next abstraction required for UEFI networking implementation is Events. This is because all UEFI networking protocols are non-blocking, and thus need the use of Events to be used in a blocking fashion.

Since the rudimentary pieces for events already existed to handle Exit Boot Services event, I just replaced it to use a more strict OwnedEvent type, which closes the event on drop. Once it is merged, I will continue the work on implementing TCP4 socket connect.

Implement basic File I/O Types

Since the other pending PRs make it somewhat hard to work on a lot of other possible parts (I do not want to have to rebase the PRs after each merge), I ended up adding the basic File I/O types such as FileType, FilePermissions and FileAttr. It should help reduce future time waiting around for the basic abstractions to be merged.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #23

2025-03-02T00:30:12+05:30

Hello everyone. A typical work week. Let's go over everything.

PocketBeagle 2 Examples

Continuing the work from last week, I finished adding Python examples for all the prior Rust examples. I have also added a lot of new examples, mostly centered around the hardware available in TechLab cape for PocketBeagle 2.

EEPROM

I already had a Rust example to parse Beagle EEPROM contents. A python version for the example has also been added. I have also introduced BeagleEeprom type in both the Rust and Python helper libraries to make it easier for other people to extend. I also ended up learning about struct module in python, which ended up being better than I expected. I still prefer Rust and C for packed structs, but at least python has something.

Here is the Python example running:

debian@pocketbeagle2:~/vsx-examples/PocketBeagle-2/eeprom/python$ python main.py
BeagleEeprom(magic_number=(170, 85, 51, 238),
             hdr1=Header(hdr_id=1, length=55),
             hdr2=Header(hdr_id=16, length=46),
             board_info=BoardInfo(name='POCKETBEAGL2A00G',
                                  version='A0',
                                  proc_number='0000',
                                  variant='0G',
                                  pcb_revision='A0',
                                  schematic_bom_revision='A0',
                                  software_revision='00',
                                  vendor_id='01',
                                  build_week='02',
                                  build_year='25',
                                  serial='PB20000183'),
             hdr3=Header(hdr_id=17, length=2),
             ddr_info=4776,
             termination=254)

Photo Diode

TechLab cape has a Photo Diode attached to pin P1.19. I have added Python and Rust examples to use the Photo Diode to detect whether it is dark or light, based on a threshold. The helper library also contains LightSensor for general usage. The full details can be found in the following PR.

It would be nice to write a Photo Diode kernel driver at some point, since currently the examples are directly reading ADC values.

Seven Segments

TechLab cape has two 7-segment displays. The displays are connected to MCP23S18, an IO extender, which is connected to PocketBeagle 2 over SPI. After a bit of grepping, I found that the upstream kernel already has a driver for seven segment displays, so I am using it instead of driving the GPIOs from userspace. The full details can be found in the following PR.

Currently, both the 7-segment displays are driven by separate drivers, since there does not exist a 14-segment GPIO driver for now. The subsystem seems to have support for 14 segment, so maybe it would be useful to write one.

Tonal Buzzer

TechLab cape has a buzzer connected to pin P2.30. Since the pin does not have hardware PWM, and producing notes only really needs 50% duty cycle at comparatively low frequencies, I am using the pwm-gpio driver. The full details can be found in the following PR.

The example currently plays Hedwig's theme from the Harry Potter Movies, which is ported from an Arduino example. I might end up adding the buzzer as an alsa device in the future, but let's see how that goes.

RGB LED

TechLab cape has an RGB LED. I am using the led-pwm-multicolor driver. The full details can be found in the following PR.

The example cycles through different hues.

TechLab Cape Devicetree Overlay

The PocketBeagle 2 examples, specially when using TechLab Cape need a devicetree overlay for some specific pinmux and devices such 7-segments, RGB Led, etc. The overlay can be found in the following PR. This overlay will be present in new distro images going forward.

Devicetree Compiler support for /./

Normally, node properties in devicetree can only be replaced with new ones. A lot of hardware devicetrees actually include base devicetrees for SOCs, etc. However, to add some new values to properties, such as adding some extra clocks, pinumx, etc. would require copying all the values from the included devicetree. This could become inconvenient and can allow things to go out of sync.

A few months ago, I sent a patch series a few months ago to add capability to append properties instead of overriding them. In that patch series, there was discussion regarding something more flexible, with a popular option being able to use the old value to construct the new property value. This will allow a lot of usecases such as appending, pre-appending, duplicating, etc.

In practice, it looks as follows:

dts-v1/;

/ {
    str-prop = "0";
};

/ {
    /* append */
    str-prop = /./, "1";
};

/ {
    /* pre-append */
    str-prop = "1", /./;
};

/ {
    /* duplicate */
    str-prop = /./, /./;
};

The full patch series can be found here.

Devicetree Specification export-symbols

I have been pursuing various possible methods to allow upstream drivers for connector add-on-board setups such as MikroBUS, Beagle Capes, etc. The current favorite seems to be export-symbols.

It was initially proposed by Herve Codina and seems to be quite useful even outside add-on-board setups. At the basic level, export-symbols provide a way to define symbols local to the node, and can be used by any overlay or devicetree include that uses the node as target.

This in turn allows creating overlays for add-on-boards using generic names for the nodes such SPI, I2C, etc. instead of knowing about the device it is being applied to. Thus, the same overlay can be used across multiple connectors in different devices.

The initial proposal was for Linux kernel, but since I would like to use the same setup in ZephyrRTOS as well, I have been trying to make export-symbols a standard devicetree node. I already had patch series to add support to dtc and fdtoverlay as a proof of concept.

The full patch for adding it to the devicetree secification can be found here. Feel free to chime in if the topic interests you.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #22

2025-02-23T00:30:12+05:30

Hello everyone. This was a light week since I had college exams. Let's go over everything.

PocketBeagle 2 Examples

I have been working on Rust examples for PocketBeagle 2 as evident from my past posts. However, a lot of examples ended up being more complicated than they should be, specially for new users. Additionally, Rust being a compiled language might not be suitable for fast prototyping. Maybe cranelift, can solve this problem, but I have not explored it enough to say yet. Additionally, it seems to require nightly, which I do not want to impose right now.

So, following the industry, I have also started adding examples in Python. Being probably one of the most popular scripting language, it seemed like the safe choice.

Additionally, I have started working on beagle_linux_sdk libraries for both Rust and Python. They are inspired by gpiozero for Raspberry Pi. Since beagle_linux_sdk is intentionally designed to be as high level and easy to use as possible, it allows making both the Rust and Python examples a lot more simple and readable. The plan is to push the libraries to PYPI and crates.io once things are bit more stable.

As of writing this post, the updated examples are still in open PR. But they should be merged quite soon.

Dynamic Devicetree overlays from userspace

While working on PocketBeagle 2 examples, I have started to realize how useful userspace application for devicetree overlays can be for single board computers. Some of the z that I envision are as follows:

Dynamic Pin muxing: A lot of SBC's aimed for creating hardware projects expose headers, where each pin can be used for multiple things like GPIO, I2C, PWM, etc, depending on the pinmux. I think Raspberry Pi has it's own solution to do userspace pinmux, but if userspace devicetree application was a thing, it could probably be used for this. Additionally, being able to use dynamic devicetree overlays for pin muxing would allow much easier transition to use proper device trees during production.
Dynamic Sensors/Devices: Using devices such as sensors, external ADCs, EEPROMs, etc are also a common usecase in SBC's. A lot of current solutions seem to be designed around using user-space drivers in such cases. This is a bit of a shame since Linux kernel already has drivers for a lot of these drivers, and they are probably going to be of higher quality than most user space drivers.

There have been attempts in the past(OF: DT-Overlay configfs interface (v3) and of/overlay: sysfs based ABI for dt overlays), but it seems like they never went anywhere.

I have started a discussion to see if I can find out what the reasons for the rejection were. Maybe things have changed by now, since the last patch series seems to be from 2017.

Rust std for UEFI

DevicePathNode Abstractions

In the fs::exists, I was asked to move the DevicePathNode abstractions to a seperate PR for easier review. It took a while due to my limited bandwidth, but I have created the PR now. Hopefully, it will be merged soon, so that the initial fs support can finally land.

Efi Service Bindings Abstractions

I have also started work on upstreaming networking with the net stubs PR. Continuing that, I have created PR to add EFI service bindings abstractions.

UEFI Protocols such as TCP4/6, UDP4/6, etc use the EFI Service Binding protocol to create and destroy new instances. More information regarding this can be found in UEFI Specification.

I will try to keep all PRs as short as possible to make the process of upstreaming networking support move faster.

Zola flatpak update

I am one of the maintainers of Zola Flatpak Package. Since it seems like everyone else was busy, I ended up updating the flatpak to v0.20.0 that was released recently.

I also found that the metainfo upstream was out of date. So I also created PR upstream to fix it.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #21

2025-02-16T00:30:12+05:30

Hello everyone. Another typical week. Let's go over everything.

BeagleBoard Image Builder

After much deliberation last week, I decided to go ahead with trying to use debos for image generation. I was able to create debos recipes for BeagleY-AI and PocketBeagle 2. However, the image generated by debos does not seem to boot on either board. More specifically, it does not seem like the soc is able to find the bootloader (u-boot) present in the BOOT partition.

I did cross-check everything with the current images, and the partitions seem to be in order. So not sure what is going on here. I also went through the debos source code to see how it was creating the partitions, but recreating it in normal shell scripts does seem to work as expected. I also tried generating empty images using debos and copying the boot partition to the appropriate partition, but still could not get it to work.

I have created an issue regarding this, with some scripts that generate the image properly. Let's see if it can be resolved soon.

PocketBeagle 2 Examples

Some work also went into cleaning up the current examples for PocketBeagle 2. I will be getting my PocketBeagle 2 and TechLab Cape delivered by the end of the week, so hopefully, the examples will be greatly expanded in the upcoming weeks.

Refactor Dependencies

The examples were pulling some unnecessary dependencies, so I removed most of them. Now, there are only 6 dependencies, which is always nice.

I have switched to gpiod for GPIO handling. This is because I went through the source code of both gpiod and gpio-cdev, and felt that gpiod was superior. Additionally, gpiod supports both v1 and v2 of GPIO Character Device Userspace API, while gpio-cdev only supports v1.

I can always write any shim that might be required for interop with embedded_hal myself.

Add blinky ioctl example

I have also added a blinky example, that directly uses GPIO Character Device Userspace API instead of gpiod library. This should help anyone curious peek behind the curtain and get an idea of how the GPIO libraries work behind the scenes.

I am also thinking of creating a blinky example that does not have any dependencies, although I am a bit unsure if it should be another example, or just do that in this example.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #20

2025-02-09T00:30:12+05:30

Hello everyone. I ended up experimenting more than getting results, so not much to write. Let's go over everything.

PocketBeagle 2 Examples

Continuing the work from last week, more PocketBeagle 2 examples have been added.

Feel free to create issues regarding the examples you would like to be added.

Button

Simple example to detect button presses. Uses Pin P1_20 by default.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p button
   Compiling button v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/button)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.05s
     Running `target/debug/button`
Chip: gpiochip2 [600000.gpio] (92 lines), offset: 50
Button pressed
Button pressed
Button pressed
Button pressed

Fade

Simple example to fade an LED in and out using PWM. Also contains abstractions to use PWM using sysfs.

Uses P1.36. In case of TechLab Cape, this PIN is connected to RGB.B

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p fade -r
   Compiling fade v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/fade)
    Finished `release` profile [optimized] target(s) in 3.85s
     Running `target/release/fade`

BeagleBoard Image Builder

Currently, the image build process for all BeagleBoard images involves a collection of scripts singlehandedly maintained by Robert Nelson. Thanks to his amazing work on both handling the management of openbeagle runners and image building, things have been working relatively well.

However, this also means that all the burden of pushing and maintaining new images falls on one person. Additionally, the images cannot currently be built in openbeagle, which limits the experimentation and having very special purpose images.

To hopefully improve the current situation, I have been working on trying to get image build working on openbeagle CI. I initially started with trying to get debootstrap directly working in CI, but while I could get it somewhat working (defining working very loosely here), it failed in CI.

Currently, I have 2 possible solutions I am exploring:

debos: Seems quite promising. Has good performance, and should work fine in CI. Additionally, it also can work with just user-mode-linux, so quite portable. Moreover, it already has a recipe system pretty similar to what I want in the final solution.
Using docker: This was mostly inspired from yasib. I was able to build rootfs for the most part, but there were quite a few warnings for systemlevel packages like systemd.

I am still experimenting with both of the above approaches. However, I have started leaning more towards debos. It can have much better performance than docker in docker, and already has been tested quite a bit. Additionally, I can always add support for 2nd approach to debos in the future.

Hopefully, I will have working images by next week.

Optimize linux-embedded-hal dependencies

I have been using linux-embedded-hal in some of the PocketBeagle 2 GPIO examples. When working with it, I observed that it was pulling some unnecessary dependencies even when default-features were disabled. I created a PR to fix it, which has now been merged.

Rust UEFI Std Networking stubs

I was a bit bored, so I created the PR to add the Networking stubs for UEFI. This will make the future networking PRs smaller and easier to review.

Hopefully, I will get around to working on it soon.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #19

2025-02-02T00:30:12+05:30

Hello everyone. Since PocketBeagle 2 has launched, most of the development was focused on it. Let's go over everything.

Enable Greybus BeaglePlay driver in defconfig

As per suggestion of Nishanth Menon, I have added gb_beagleplay to the defconfig. Here is the latest version of the patch.

Export Symbols RFC

As alluded to in my prior posts, I have been working on using export-symbols in devicetree to add support for add-on connectors such as MikroBUS. This was first proposed by Herve Codina in the following Linux kernel patches. Since then, I have sent patches to add support to devicetree compiler and fdtoverlay.

The overall goal is to make export-symbols part of devicetree specification instead of just a Linux specific extension. This is to allow sharing of add-on board overlays with ZephyrRTOS, which has boards like BeagleConnect Freedom with support for MikroBUS.

To that end, I have sent an RFC in the devicetree specification mailing list to see if anyone has any objections/flaws to point out. I will be sending a patch adding the node to the specification in a week or 2, if there are no objections.

Pocketbeagle 2

Pocketbeagle 2 is now available for purchase. While, everything is mostly working now, I have been working on adding a few things to just make the support as good as possible.

Debug Port

In the early phases of development, most people were using PocketBeagle® TechLab with PocketBeagle 2, and thus using the UART exposed by it. However, PocketBeagle 2 has a debug UART (compatible with Raspberry Pi Debug Probe) on board.

There were some issues to get U-Boot working with this UART, but other than U-Boot R5 logs, everything is redirected to use the Debug Port. We are actively working on getting R5 to also use the debug port, but it should not affect general usage, since the boot selection menu is shown by A53 core.

Examples

In a recent discussion, it was also decided to add examples for beginners to get started quickly. Initially, I was going to use Python, but given that Beagle Boards seem to attract a lot of people in Kernel and U-Boot space, it was decided that I should go ahead with writing examples in Rust.

With Rust support in Linux kernel finally reaching a good enough state, this means the same language can be used for both userspace IoT projects and Kernel space drivers.

Rust is also quite popular nowadays, so it might help attract new potential contributors. The examples can be found here. Hopefully, they will start being shipped in default images, and will be accessible with the Theia local Theia editor.

Feel free to create issues regarding the examples you would like to be added.

Hello Beagle

Simple example to test that Rust has been set up correctly.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p hello_beagle
   Compiling hello_beagle v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/hello_beagle)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 5.64s
     Running `target/debug/hello_beagle`
Hello, World! From PocketBeagle2

EEPROM

Read and parse EEPROM contents in Rust.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p eeprom
   Compiling eeprom v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/eeprom)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.99s
     Running `target/debug/eeprom`
EEPROM Data: Contents {
    magic_number: [
        170,
        85,
        51,
        238,
    ],
    hdr1: Header {
        id: 1,
        len: 55,
    },
    hdr2: Header {
        id: 16,
        len: 46,
    },
    board_info: BoardInfo {
        name: "POCKETBEAGL2A00G",
        version: "A0",
        proc_number: "0000",
        variant: "0G",
        pcb_revision: "0G",
        schematic_bom_revision: "A0",
        software_revision: "00",
        vendor_id: "01",
        build_week: "34",
        build_year: "24",
        serial: "PB20000001",
    },
    hdr3: Header {
        id: 17,
        len: 2,
    },
    ddr_info: 4776,
    termination: 254,
}

Blinky

Simple example to toggle GPIOs. Uses Pin P1_20 by default.

Also provides a simple helper function to find PIN by name.

Usage

debian@pocketbeagle2:~/vsx-examples/PocketBeagle2$ cargo run -p blinky
   Compiling blinky v0.1.0 (/home/debian/vsx-examples/PocketBeagle2/blinky)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.50s
     Running `target/debug/blinky`
ON
OFF
ON
OFF
..

MSPM0 Firmware

PocketBeagle 2 contains an MSPM0, which is used as ADC and EEPROM. The MSPM0 firmware can be found here.

Here are the instructions to flash MSPM0:

Download the firmware:

wget https://openbeagle.org/api/v4/projects/249/packages/generic/mspm0_adc_eeprom/0.13/mspm0_adc_eeprom.txt

Download bb-imager-rs latest version. Currently, that is v0.0.3:

wget https://openbeagle.org/api/v4/projects/832/packages/generic/bb-imager-cli/0.0.3/bb-imager-cli-aarch64-unknown-linux-gnu.tar.xz
tar -xvf bb-imager-cli-aarch64-unknown-linux-gnu.tar.xz
cd usr/bin

Flash

./bb-imager-cli flash pb2 --img-local /path/to/firmware --no-eeprom

It is also possible to flash any other custom firmware in Ti-TXT or iHex format.

Rust std for UEFI

I have been having an issue with building and testing toolchain reliably. Here is the link to Zulip discussion regarding it. However, I have yet to find a solution, so things might get delayed a bit. Still, there is a lot of backlog still left to merge, so things should be fine for a while.

Process Args

While trying to add environment variable support to std::process::Command, I found out that args support was broken. The PR to fix it has now been merged.

Process Env

Std process has been missing environment variables till now. This is because environment variable support was missing in general at the time I add support for process. However, since environment variable support has been merged, I have created a PR to add environment variables to std::process::Command.

The implementation closely resembles UEFI Shell Execute, which basically applies any environment changes before executing the binary, and rolls back the changes after execution concludes.

Path support

Support for UEFI paths has now been merged, this makes it much easier to construct absolute paths, from relative as well as UEFI shell mappings.

It also implements support for checking if the path is absolute, which should work correctly now thanks to an earlier PR.# Ending Thoughts

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #18

2025-01-26T00:30:12+05:30

Hello everyone. A typical week for development. Let's go over everything.

GitLab CI Components

I have been using GitLab Package Registry for most of my projects. It allows a permanent registry to store packages and create releases, in a persistent fashion. Initially, I started with manually uploading the packages in the CI. However, this turned out to be difficult to maintain in bb-imager-rs, which has a lot of release packages.

Since I wanted the solution to be shareable across different repositories, I started looking around for solutions. I stumbled across GitLab CI Components. I would have preferred using GitLab CI Steps, but since it is still experimental, I went with CI components.

Initially, I wanted to write the actual functionality in Python but quickly realized that it is not possible to depend on external files in CI components. You can download any external script in the CI from a URL, or you can create a custom container that already includes the script, but I decided to just go with writing everything in bash.

The CI Components are being used in bb-imager-rs and MicroBlocks and working pretty well. It should be fairly simple for other projects to start using them as well.

Let us now go over different CI Components present in the repository.

Package Registry Upload

Upload all files in the directory following proper conventions to GitLab Package Registry.

The release directory packages should follow the following format: {RELEASE_DIR}/{PACKGE_NAME}/{PACKAGE_VERSION}/{PACKAGE_FILE}. Here is an example of a release directory:

release/testpkg/0.0.1/abc.txt
release/testpkg/0.0.1-alpha/abc.txt
release/testpkg/0.0.1-alpha/abc.txt.bb.imager.json

Note: Any packages in a directory other than depth 3 will just be ignored.

The CI component also does some extra stuff:

Generate and upload sha256 checksum for all files.
Generate release.yml file which can be used by release-from-file to create a release.

Here is an example of using the CI component:

include:
  - component: openbeagle.org/ayush1325/ci-components/package-registry-upload@$<VERSION>
    inputs:
      job-name: package-registry-upload-job
      job-stage: deploy
      job-needs: ["test-build"]
      release_dir: ${CI_PROJECT_DIR}/release
      release_template: ${CI_PROJECT_DIR}/release.yml

Input	Default Value	Description
job-name	package-registry-upload-job	Name of the upload job
job-stage	deploy	Job stage
job-needs	[]	Job dependencies
release_dir	release	The directory containing packages to push to package registry
release_template		Template with basic release information

Release from file

Create a release using release-cli from the yaml file. It is possible to either use the file generated by package-registry-upload or just supply one manually.

The format of the file is not all that well defined, but I used the following testfile in the repository as reference.

The component optionally also supports generating Changelog entries which is controlled by changelog_generation boolean variable.

Here is an example of using the CI component:

include:
  - component: openbeagle.org/ayush1325/ci-components/release-from-file@$<VERSION>
    inputs:
      job-name: package-registry-upload-job
      job-stage: deploy
      job-needs: ["test-build"]
      release_file: ${CI_PROJECT_DIR}/release.yml

Input	Default Value	Description
job-name	release-from-file-job	Name of the job
job-stage	deploy	Job stage
job-needs	[]	Job dependencies
release_file		File to use to generate release
changelog_generation	false	Enable changelog generation

Os List

Create OS Lists subitems for use with bb-imager config. This should prove useful for the subitems list of testing packages, which would need to be updated much more than stable images.

Note: Entries are only created for packages having associated {package}.bb.imager.json files with the following fields:

name
description
icon
devices
tags

Here is an example of using the CI component:

- component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/os-list@$CI_COMMIT_SHA
  inputs:
    job-name: os-list-template
    job-needs: ["build-release-dir"]
    job-stage: deploy
    release_dir: release
    os_list_template: release/os_list_template.json
    os_list_suffix: "os_list/stable/os_list_template.json"

Input	Default Value	Description
job-name	package-registry-upload-job	Name of the upload job
job-stage	deploy	Job stage
job-needs	[]	Job dependencies
release_dir	release	The directory containing packages to push to package registry
os_list_template		Template with entries that will be appended to final os_list
os_list_url_suffix		Suffix used to generate Package Registry URL for OS List

BeagleBoard Rust Imager

More work went into the BeagleBoard Rust imager this week. I hope to get the v1.0.0 release out by the end of this month and replace the old bb-imager.

Remote Subitems

Similar to Raspberry Pi Imager, BeagleBoard Rust Imager now supports having subitems JSON list in a remote location. Os List Component can be used to generate the subitems JSON list in CI.

Release v0.0.3

To test the new CI components (and since a new release has been long overdue), BeagleBoard Rust Imager v0.0.3 was released.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #17

2025-01-19T00:30:12+05:30

Hello everyone. A typical week for development. Let's go over everything.

Zephyr Ti Hal Updates

A few weeks ago, I created a PR to update the Simplelink SDK version in hal_ti from 4.40.04.04 to 7.41.00.17. Now that it has been merged, hopefully, I can start working on adding Bluetooth support using the BLE5 Stack in the SDK.

BeagleBoard Rust Imager

More work went into the BeagleBoard Rust imager this week. I hope to get the v1.0.0 release out by the end of this month and replace the old bb-imager.

Introducing bb-imager-service

As mentioned last week, I was searching for how to allow PocketBeagle2 MSPM0 firmware update from the GUI. To reiterate the problem, sysfs entries for Firmware Upload API is owned by root user and thus cannot be opened from the GUI without some kind of privilege escalation mechanism. As a reference, in case of SD card flashing, I am using UDisk2 D-Bus APIs to open the SD card, which internally uses polkit for privileged management.

After some googling, I came across the following stack overflow answer:

You could, of course, write your own D-Bus service which does that and install the D-Bus .service config to have it run as a system service with root privileges. (Try to keep the operations as limited and fine-grained as is reasonable; e.g. "enable global mode foo" – not "write arbitrary data to arbitrary file".)
Failing that, one common method is to spawn pkexec to perform operations, which is… really just su with a nicer password prompt. Note that some distributions have recently removed pkexec.
If your app is allowed to use either GNOME's GLib or KDE's KIO libraries, then both of those already have PolicyKit integration built-in for privileged file updates – the app could open admin:///etc/foo and GLib or KIO would elevate as needed.

Since I could not find much regarding the 3rd approach, and the 2nd approach seemed to be on the way out, I ended up going with a custom D-Bus service. I will probably need similar functionality for BeaglePlay cc1352p7, BeagleY-AI, etc., so it is not a bad idea to have a custom d-bus service.

Using zbus was pretty nice, and I have a better understanding of Linux systems, so it ended up being quite a learning experience. I am building a Debian package for the service for now since it is only supposed to be used in PocketBeagle2 right now. It also contains systemd service which activates on D-Bus connection.

The following articles were a lot of help in figuring everything out:

Overhaul config format

The config format I initially started with differed from RPI-imagers since I thought it would be more efficient. However, after adding a lot of boards and flasher types, I realized that every flashing target is not really a board. For example, having different board entries for PocketBeagle2 and PocketBeagle2 MSPM0 seemed weird.

While browsing rpi-imager last week, I found out that it seems to support bootloader updates in different rpi versions. The GUI presentation seemed nice, so after some deliberation, I adopted a format compatible with the RPI-imager's format. Since the os_list is a self-referential structure in the RPI-imager's config, it is possible to have a lot of sub-menus in the image selection menu, which is quite nice.

To elaborate, now there are only base boards (e.g., PocketBeagle2) in the Board Selection menu, and the Image Selection menu will have a sub-menu for MSPM0 Firmware support.

Check out the PR for implementation details.

Live destinations refresh

Similar to RPI-imager, destination refresh is now automatic using subscriptions. Check out the PR for implementation details.

Better defaults in Extra Configuration

The application now queries the user's current system for the default suggestions regarding username, keyboard layout, timezone, etc. Check out the PR for details.

Include udev rules

I have added udev rules to the Linux package of GUI to allow flashing BeagleConnect Freedom without needing superuser privileges. They also make development easier and allow using commands like tio without root.

Rust std for UEFI

Since the PRs from the last post (is_absolute refactoring and OwnedDevicePath) have been merged, I have created a PR to implement support for std::path for UEFI. Hopefully, it will be merged soon, making way for future PRs for std::fs support for UEFI.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #16

2025-01-12T00:30:12+05:30

Hello everyone. A typical week for development. Let's go over everything.

BeagleBoard Rust Imager

Pocketbeagle2 MSPM0 support

Pocketbeagle2 uses MSPM0 as both EEPROM and ADC. The EEPROM is used to store board-specific information in all BeagleBoard boards for easier debugging and differentiation of different revisions.

While the pb2_mspm0 driver supports updating firmware, it isn't suitable to be used directly by new people:

Does not persist EEPROM contents.
Does not support Ti-TXT directly.

To solve this, I have added pb2_mspm0 support directly to bb-imager-cli. There is also a flag to control if EEPROM contents should be preserved (since it is possible to flash firmware other than the default one). Additionally, since bb-imager-rs supports Ti-TXT and iHex by default, we get that support for free.

I am still trying to figure out how to add support to the GUI since the flashing requires access to sysfs entries, which are owned by root (and probably should stay that way). I think I am supposed to use polkit, but not completely sure.

Contribution and Packaging Instructions

I have added instructions regarding Contribution and Packaging to hopefully make it easier for newcomers to get started. It also helped be document a lot of stuff that even I forget, so it should prove useful.

Better cross-compilation support

For pocketbeagle2 testing, I wanted to be able to cross-compile from my main machine without needing to tinker too much. I had used cross in the past, but it turns out that the container cross uses by default is based on Ubuntu 20.04, which contains libssl1. Pocketbeagle2 images have libssl3, which means that I could not use the default images for cross-compiling.

I have added custom image dockerfiles, so cross-compiling should be as simple as setting RUST_BUILDER=cross and running a make recipe.

Note: cross compiling is only supported for the following targets right now:

x86_64-unknown-linux-gnu
aarch64-unknown-linux-gnu
armv7-unknown-linux-gnueabihf

Windows should support can probably be added with a custom dockerfile (or the default cross windows container might work), but I do not need it much, so haven't really tried adding it.

Export Symbols Devicetree Support

A few weeks ago, Herve Codina sent patches to the kernel mailing list for supporting export-symbols as another possible way to support addon board overlays. Since adding support for path references to overlays ended up being a dead end (see here), I have starting working on export-symbols based approach for mikroBUS.

As a part of that effort, I am working on adding export-symbols support to the base devicetree compiler, to hopefully make it part of devicetree specification instead of just a Linux specific thing. That way, it should be possible to support the same addon-board overlays in Zephyr in the future.

Base devicetree compiler

I started work with adding support to the base devicetree compiler. The patch series does not contain tests right now since this is more of an RFC for now.

fdtoverlay

Similarly, I also sent the patch series for support in fdtoverlay. The tests will be added to future versions of the patch.

Future work

As discussed in the original patch series, to make use with fdtoverlay possible, we need to add a way to pass the target path to fdtoverlay, which is not supported right now. I will try to work on it this week. Hopefully, addon board support will be merged before 2026.

Rust fs support for UEFI

After some discussion in Zulip, I have broken up the original std::fs PR into smaller chunks to make reviewing simpler.

Unsupported fs support

The first PR as a part of this series was just to add the sys::pal::uefi::fs module with everything left to unsupported. It has been merged now.

Implement `fs::exists`

I have also created a PR just to add fs::exists support since it allows testing the File::open algorithm without implementing other parts of File API. However, it was still quite big, so I split it into smaller PRs.

OwnedDevicePath

Branching off from fs::exists PR, the OwnedDevicePath PR adds support for the abstractions common to the already merged std::process module. This can hopefully reduce noise and make review easier from the fs::exists PR.

is_absolute Refactoring

I am also planning to split the absolute path creation support present in fs::exists PR into it's own PR implementing std::path::absolute. However, the current internal structure of std::path APIs cannot support UEFI style paths well (see here). This causes a problem that any absolute path constructed for UEFI will return false for std::fs::Path::is_absolute, which can be quite confusing.

In an attempt to fix this, I have created a PR to move the logic for is_absolute into std::sys, and make it platform dependent (which it already kind of was, but was pretending not to be). I'm not sure if this will get merged, though, so let's see.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #15

2025-01-05T00:30:12+05:30

Happy New Year, everyone! 🎉 2024 was a fantastic year for my coding journey, and I’m thrilled to carry that energy into 2025.

Let's jump into the weekly updates and kick off another exciting year of coding adventures. 🚀

BeagleBoard Rust Imager

A lot of work went into the BeagleBoard Rust Imager this week. I still haven't figured out Macos completely, but at least other platforms are moving along well. At this point, I will probably release v1.0 without MacOS support since there is not much I can do about it.

CLI Improvements

Most of the past work concentrated on improving the GUI and making it as user-friendly as possible. However, as a terminal enjoyer, I prefer to use the CLI when possible. In lieu of that, I spent most of the past week bringing up the CLI to the point of being great to use, at least on Linux. Let us now go over some of the work:

Allow post-flash customization

The GUI has an option to perform some customization (e.g., setting user name and password, setting wifi ssid and password, etc.) after flashing the SD card. This ability in CLI would allow much easier automation when one needs to flash multiple devices. So, the CLI is now able to perform all the customization options available in the GUI.

Support for remote os images

Since it might be useful to be able to flash OS images from the internet, I ended up adding an option to flash remote OS images. I am a bit unsure regarding this one since one could just use wget, but it might end up being useful once I add an option to browse remote images using the default distros.json that the GUI uses.

Improved Help

One area that saw massive improvements is the help messages for the CLI (along with all the subcommands). It should be fairly simple for people to understand how to use the CLI now.

Shell Completion

The CLI now supports generating shell completions at both runtime and compile-time. I am using clap_complete to achieve this. The compile-time generation is done using xtask instead of build.rs, since it allows me to generate the completion on demand.

Manpage

I am also generating manpage(s) for the CLI and all of its subcommands at compile time using clap_mangen. Similar to shell completion, I am using xtask for this.

Xtask

While working on shell completion and manpage support, I came across cargo xtask spec, which allows adding free-form automation to a Rust project. It's pretty neat since it does not need anything extra (other than cargo and rustc) and gives the power of full-fat Rust. It's especially nice for cases like shell completion and manpage generation since they need to interact with Rust code and cannot be done with just Makefile recipe.

My current policy will be to use xtask when I need something that requires bash scripting but will stick to Makefile when just calling POSIX utilities is sufficient for the job. I have seen projects use xtask for CI, but I still prefer Makefile for that kind of functionality.

Showcase

Here are some showcases for the CLI.

Home Help

❯ bb-imager-cli --help
A streamlined tool for creating, flashing, and managing OS images for BeagleBoard devices.

Usage: bb-imager-cli [OPTIONS] <COMMAND>

Commands:
  flash                Command to flash an image to a specific destination
  list-destinations    Command to list available destinations for flashing based on the selected target
  format               Command to format SD Card
  generate-completion  Command to generate shell completion
  help                 Print this message or the help of the given subcommand(s)

Options:
      --quiet    Suppress standard output messages for a quieter experience
  -h, --help     Print help
  -V, --version  Print version

Flashing SD Card Help

❯ bb-imager-cli flash sd --help
Flash an SD card with customizable settings for BeagleBoard devices
Usage: bb-imager-cli flash <DST> sd [OPTIONS]

Options:
      --no-verify                      Disable checksum verification post-flash
      --hostname <HOSTNAME>            Set a custom hostname for the device (e.g., "beaglebone")
      --timezone <TIMEZONE>            Set the timezone for the device (e.g., "America/New_York")
      --keymap <KEYMAP>                Set the keyboard layout/keymap (e.g., "us" for the US layout)
      --user-name <USER_NAME>          Set a username for the default user. Requires `user_password`.
                                       Required to enter GUI session due to regulatory requirements.
      --user-password <USER_PASSWORD>  Set a password for the default user. Requires `user_name`.
                                       Required to enter GUI session due to regulatory requirements.
      --wifi-ssid <WIFI_SSID>          Configure a Wi-Fi SSID for network access. Requires `wifi_password`
      --wifi-password <WIFI_PASSWORD>  Set the password for the specified Wi-Fi SSID. Requires `wifi_ssid`
  -h, --help                           Print help

Flashing Remote image

❯ bb-imager-cli flash --image-remote $IMG_URL --image-sha256 $IMG_SHA256 /dev/ttyACM0 bcf
[1] Preparing
[2] Verifying    [█████████████████████████████████████████████████████████████████████████████████████████████████████████████] [100 %]
[3] Flashing     [█████████████████████████████████████████████████████████████████████████████████████████████████████████████] [100 %]
[4] Verifying

Flashing Local image

❯ bb-imager-cli --quite flash $DESTINATION $IMG_PATH /dev/ttyACM0 bcf

GUI Improvements

While putting the GUI alongside the Raspberry Pi Imager, I observed that my GUI and its elements, like buttons, were a lot bigger. After some discussion, I ended up deciding to match the rpi-imager size. So, the default window size is now 680x450, with the buttons and other UI elements scaled down accordingly.

I also added some rounded corners since they look nicer in the scaled-down UI. The buttons and text are still a bit bigger than the RPI-imager, but since it fits fine, I am keeping it like this.

Home Screenshot

Future

I have been working on utilizing Gitlab issues as much as possible in the bb-imager-rs to make it easier for anyone wishing to start contributing. Hopefully, I can get some new contributors this way.

Ending Thoughts

That is all for the week. Hopefully, 2025 will be a good year for me and BeagleBoard.org.

Consider supporting me if you like my work.

Helpful links

My Week in Code #14

2024-12-29T00:30:12+05:30

Hello everyone. I have been traveling for the last few weeks due to some family functions. Due to this, I could not post My Week in Code. Additionally, I was primarily working on Pocketbeagle2 stuff, which wasn't public yet, so I also lacked content. Now that Pocketbeagle2 has been announced, I can start talking about it. So, let's get to it.

Pocketbeagle2 MSPM0 Driver

In Pocketbeagle2, instead of using dedicated EEPROM and ADC, we are using MSPM0L1105 with specilized firmware that acts as EEPROM and ADC.

While it is possible to use a userspace flasher, it is much easier to perform firmware updates with an upstream driver. Additionally, it also allows doing some custom pinmux and overlay stuff, which might be required due to a problem with the nRST line.

While the MSPM0L1105 is intended to be used as EEPROM and ADC by default, it can be used as a dedicated co-processor for IO and communicate over I2C or SPI. I will also try to add Zephyr support in the future.

The driver is currently in my kernel tree.

Update Ti simplelink SDK in hal_ti

A while ago, I found an issue with BeagleConnect Zephyr support, where everything freezes if both PWM and SUBg are enabled at the same time. Thanks to help from Arthur, I was able to confirm that this does not happen in Ti-RTOS and is thus a problem with Zephyr implementation. However, I was not able to find the root cause, even with JTAG debugging. The complete discussion can be found in e2e.

Fast forward to last week, and I thought I should try tackling it again before starting work on Arduino support using LLEXT. One of the possibilities I came up with was that it might be a bug in the version of simplelink SDK that was being used in hal_ti. The SDK being used currently is 4.40.04.04, which is quite old at this point. Additionally, I wanted to use the latest SDK before attempting to tackle Bluetooth again.

While working on it, I realized that it is currently not possible to automate SDK updates since we need to make some modifications manually. In the end, it turned out that the SDK version was not the cause of the freeze, but it helped me figure out the real cause.

Hopefully, I can figure out a more sustainable way moving forward, but I just went with the manual route for now.

It also seems like GPIO APIs have completely changed, and I had to fix some stuff in the Zephyr GPIO driver. Here are the open PRs: hal_ti and zephyr.

Fix BeagleConnect Freedom Freeze Bug

As discussed above, I was finally able to pinpoint the cause of the freeze. It turns out that the Zephyr power management was at fault. Both the PWM driver and RF core driverlib can put and release constraints on the suspend state of cc1352p7. However, at least the PWM code would release the constraint without checking if PWM placed the constraint in the first place.

I have created an initial PR to fix the problem by ensuring that PWM keeps track of the suspend constraint. This ensures that PWM does not cause the processor to go to suspend even if it has been disabled by subg code.

Rust UEFI varargs function support

For the longest time, Rust ffi had the annoying limitation of not supporting varargs in ABIs other than C. However, recently extended_varargs_abi_support was stablised. So finally, it is possible to have correct function signatures for BootServices->{Install/Uninstall}MultipleProtocolInterfaces. Here is the PR in r-efi.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #13

2024-12-08T00:30:12+05:30

Hello everyone. I was busy with the Linux kernel for most of the week. Let's go over everything.

MicroBlocks Updates

MicroBlocks dev branch recently broke the MicroBlocks Zephyr Port. I sent a patch to the Discord channel, and it has been fixed.

Devicetree Compiler

A lot of work this week was focused on the device tree compiler. I have been working on adding support for path references in devicetree overlays. In the initial patch, some parts of the initial patch series can be sent as independent patches. So last week mostly involved getting those merged.

setprop namelen variants

Previously, all the setprop variants calculated length of property length from strlen. However, devicetree __fixups__ contains information regarding the position of a property to resolve, and thus cannot use these normal variants. Additionally, it is not allowed to use heap memory in many places in the devicetree compiler and related tools, and thus, there was a need for setprop_namelen_* variants of functions similar to how these exist for getprop_namelen_*.

The patch series has been merged now.

Clang format config

While working on the devicetree compiler code, I was using the clang-format config from the Linux kernel. As suggested by David Gibson, I sent a patch to add the clang-format config which has now been merged.

Path Reference support in Devicetree overlays

Since the related patch for setprop namelen variants has been merged, I have been working on version 2 of the path reference support patch. Since it is not allowed to use dynamic allocation, I have been able to get things working with adjusting offsets while growing. I still need to fix some tests and add new ones, but I should be able to post the patches this week.

BeagleBoard Rust Imager

As per the suggestion in the issue, I have been experimenting with moving around the configuration screen flow. A prototype can be found here. I have not yet finalized whether this should be merged.

Arch Linux

While working with docker containers, I found out that systemd-networkd is enabled by default, which conflicts with NetworkManager. I did consider just using systemd-networkd and removing NetworkManager, but it seems NetworkManager is better for laptops. Additionally, I did not find good GUIs for systemd-networkd, so I have deactivated it for now.

Ending Thoughts

That is all for the week. Hopefully, this series will keep people updated about my work and attract potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #12

2024-12-01T00:30:12+05:30

Hello everyone. I switched my linux distro this week. So lots of updates regarding it. Let's go over everything.

BeagleBoard Rust Imager

Since CI was broken last week, these changes have yet to be merged.

Improve Cancel Messages

As pointed out by Deepak here, the messages when the cancel button was used were not particularly informative regarding which step of the flashing process was canceled. This was due to the initial quick and dirty implementation for everything. This has now been fixed to provide better messages for each stage of flashing. Here are the messages:

Preparation canceled by user
Downloading canceled by the user
Flashing canceled by user
Verification canceled by user
Customization canceled by the user

Speedup SD card verification

After some testing for verification, I found out that a 4K buffer length seems to be the fastest for reading SD card contents for SHA256 verification. This gives a modest performance boost. However, verification is still not as fast as I would like. I may try vectored reads in the future.

Appimage CI broken

Last week, appimagetool got a new update that broke my CI. I have not yet found the time to figure out the issue, but let's see if I can reproduce it in a local docker. I have created an issue for the time being.

ArchLinux Switch

I have been using Fedora Sway Atomic since Fedora 36. It has been a good experience for the most part. I appreciated how rock-stable it was. I have even rebased to the KDE atomic variant in the past and was surprised at how painless it ended up being. Since I used Neovim, working inside containers was not particularly difficult either. All in all, it was a pretty great experience.

While I can come up with a lot of excuses regarding why I switched back to ArchLinux, the honest one was that I was bored. In the past few years, I have become much more comfortable contributing to random projects. Additionally, I have also gained a lot more knowledge regarding the general design of Linux systems, along with the basics of debugging. Along with the fact that I do a lot of Linux kernel development nowadays (most for embedded systems), I am okay with my system breaking.

The great thing about Fedora Atomic is that I could just switch to a previous deployment if something broke. However, it also meant that I had less incentive to go and create upstream issues and dive into the source to see if I could fix the problem myself. This was great when I was just getting started with open-source and did not have the time or knowledge to just try fixing anything broken I found. However, as someone who is a decent developer now, I have found that fixing problems in random stuff is actually quite a good way to improve my skills.

What I like about Arch

PKGBUILD

I love the Arch PKGBUILD based system. While I like AUR, the real reason I love PKGBUILD is because how easy it allows me to manage things like custom local kernels and some other experimental software with pacman instead of having to remember where I put all the files.

This makes working on development builds much simpler since, well, even if I forget or lose the exact way I installed the package (which I do more than I should), I do not need to worry that I might have forgotten some man page files while manually removing the software.

Arch User Repository

Almost every piece of software available on Linux can be installed on Arch Linux thanks to AUR. While the stability of AUR packages can be a bit questionable, if you can read PKGBUILD, it is much better than using Fedora Copr or Ubuntu PPAs. Additionally, AUR also provides simple access to git versions of packages, which is great in cases where some functionality is not yet available in the stable version of the software.

Arch Wiki

I do not think I need to explain this point much. Arch Wiki is probably the best documentation for any Linux distribution. I have used it a lot, even when dealing with problems in Fedora.

My Setup

I am using SwayWM with Wayar. I took a lot of applications and configs from Fedora Sway Atomic since I think the defaults are pretty good on it. I also switched to fuzzel from rofi, and it seems enough for my needs since it does support dmenu style runner.

All my configs can be found here.

Challenges

While the initial install was quite simple thanks to archinstall, there were some issues that I had to deal with. I probably will encounter more as time goes on.

Systemd initial ramdisk

The default configuration generated by archinstall uses busybox-based initial ramdisk. While it works fine, I was intrigued by system-based init. I have heard that systemd initial ramdisk can be faster in a lot of cases, but I have not done any testing either way.

The mkinitcpio page documents the different hooks that are needed for systemd init. However, I was not aware that I needed to edit systemd entry to use systemd based decryption. This led me to have a broken initial ramdisk, which could not even drop me into some root shell (since the root still needed to be unlocked).

I was able to fix this by fixing the system-boot entry using an arch live iso as described here.

Locale Problems

During archinstall, I selected en_IN as my locale. It generated locales fine, but it is recommended to also generate en_US.UTF-8 as a backup. While most things worked fine, I had weird problems with some software like fuzzel, which did not like my LANG to be set to en_IN without specifying the encoding. I was able to fix this by setting LANG=en_IN.UTF-8 in /etc/locale.conf.

Nvidia dGPU

I have a laptop with an AMD CPU + Nvidia GPU. I was able to get everything setup with regular amdgpu drivers and nvidia-open. Nvidia Prime works fine for OpenGL. However, I have not really been able to control Vulkan applications well. It seems like vkcube and dxvk always try to run on Nvidia dGPU instead of iGPU, even without prime-run.

The AMD iGPU does show up in vulkaninfo, and I can probably get things to run on the GPU I want by using a hack and preventing it from seeing my Nvidia dGPU. But it is weird that things do not launch on GPU 0 by default.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #11

2024-11-24T00:30:12+05:30

Hello everyone. Another light week here. Let's go over everything.

BeagleY-AI SD Card support

While hacking on my BeagleY-AI, I found that my HP SD card did not work with BeagleY-AI for some reason. On digging a bit further, some SD cards were not working on BeagleY-AI due to some issues with signal voltage switching on the am62x platform. This has now been fixed, as seen in the following patch series. By switching out the Linux kernel to mainline, I was able to get the HP SD card to work. So, the SD card compatibility of BeagleY-AI will improve soon.

BeagleBoard Rust Imager

BeagleBoard Rust imager got lots of love this week.

AppimageLauncher Problem

As pointed out by Jason here, the BeagleBoard Rust imager appimage is not usable with AppimageLauncher. The issue seems to be that appimagetool uses ZSTD compression now, while AppimageLauncher does not support it yet. Moreover, it seems like AppimageLauncher makes the appimage unusable. For now, the recommendation is to either remove AppimageLauncher or at least deactivate it for the BeagleBoard Rust imager.

More information regarding the upstream issue can be found here.

SD Card Flashing Performance Improvements

While the SD card flashing worked, it was much slower than the original bb-imager. After some tinkering with the buffer size while flashing and using parallel decompression of xz images, SD card flashing should be much faster (flashing time decreases by 57%).

It is still a bit slower than the original bb-imager (about 1 min), but it seems related to the internals of QFile, so that would be much more work than just a day.

Debian Packages

BeagleBoard Rust imager now builds Debian packages in CI using cargo-deb. While the goal is to eventually have an upstream package using debcargo, there is not much point until bb-imager-rs hits v1.0.0. Additionally, since debcargo only seems to support building stuff already present in cartes.io, it does not seem suitable for experimental builds (although I could be wrong about that).

Experimental Builds

Builds from the latest main branch are now pushed to Package Registry rather than just being stored as build artifacts. This makes grabbing the latest development version of bb-imager-rs much simpler.

Note: Only the most recent build is kept around.

UEFI Process Args in Rust std

Initial support for Rust std::process was merged upstream a while back. However, at the time, it was missing support for passing arguments to the spawned process to keep the PR easier to review. Finally, the support for arguments has now been merged to make the API somewhat feature-complete.

UEFI process is one of the more important APIs since it is used by Rust to spawn tests, thereby bringing us closer to being able to run all of Rust's testing infrastructure on UEFI. This will help make Rust much easier to use in the UEFI space.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #10

2024-11-17T00:30:12+05:30

Hello everyone. I was busy with the Linux kernel for most of the week. Let's go over everything.

Devicetree append properties support

Currently, devictree supports creating and deleting properties but not appending to existing properties. This functionality is vital for complex uses like MikroBUS. I have been working on this for a while and posted Patch v3 last week.

To understand what it allows, let's take an example:

dts-v1/;

/ {
    node {
        str-prop = "0";
    };
};

/ {
    node {
        /append-property/ str-prop = "1";
    };
};

The above devictree will produce the following output:

dts-v1/;

/ {
    node {
        str-prop = "0", "1";
    };
};

Devicetree overlays path reference support

Devicetree allows references in two contexts:

Integer context: In this case the references are resolved to phandle.

foo = <&bar>;

String context: In this case, the references are resolved to paths.

foo = &bar;

Runtime overlays only support the former but not the latter. I have created a patch series to fix this asymmetry.

Additionally, __symbols__ does not support phandles, which makes overlays modifying __symbols__ somewhat limiting. More context regarding this patch can be found here.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #9

2024-11-10T00:30:12+05:30

Hello everyone. Another light week here. Let's go over everything.

BeagleBoard Rust Imager

Continuing the trend from previous weeks, many developments took place in BeagleBoard Rust Imager.

MacOS

Thanks to help from Zain, BeagleBoard Rust Imager SD card flashing finally works on MacOS. With this, it is now possible to flash Linux images to an SD card on MacOS.

Any developers requiring similar functionality should look at the PR. Here are the steps in brief:

Unmount the sd card using diskutil.
Create pipes using std::os::unix::net::UnixStream::pair().
Create a MacOS Authorization external form using security_framework::authorization.
Launch authopen with the -extauth argument using std::process::Command with the send pipe as stdout.
Send the MacOS authorization external form to the process stdin.
Read the SCM_RIGHTS control message from the receive pipe and get the file descriptor.

Sd card formatting

SD card formatting is now supported on both Windows and Linux. MacOS support is still pending. This is useful for making the bootable SD cards usable again.

Offline support

Offline use of BeagleBoard Rust imager for all supported boards is now possible. The base configuration now includes definitions for all boards.

MicroBlocks

Since MicroBlocks IDE v2 has been released, there has been a new release of MicroBlocks stable firmware. You can grab the latest firmware for BeagleBoard Freedom from here.

GPIO Nexus Node Schema

While working on MikroBUS patches, I encountered devicetree nexus nodes. It allows the ability to create proxy GPIO controller thereby providing a stable numbering scheme for GPIO pins on MikroBUS socket.

To allow use in the Linux kernel, I created a PR to add the dt schema to the upstream repository. It has now been merged.

Dynamic alias in Linux devicetree

Currently, adding/removing/updating /aliases is not supported in the upstream Linux kernel. This means overlays cannot rely on using /aliases, which are much more powerful than existing /__symbols__. In my patch series to add support for phandles in /__symbols__, it was brought up that it might be better to switch to using /aliases instead of trying to add more to /__symbols__.

So I have created a new patch series based on the original patch series by Geert Uytterhoeven in 2015.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #8

2024-11-03T00:30:12+05:30

Hello everyone. Another light week here. Let's go over everything.

BeaglePlay PWM Patch

A while ago, I discovered that the MikroBUS PWM pin was not enabled in the upstream devicetree for BeaglePlay. So I created a patch to enable PWM and it was finally merged last week.

BeagleConnect Freedom Debugging

Continuing the work from last week, I was able to load Zephyr firmware that exhibited the stalling behavior. However, I still haven't been able to pinpoint the exact cause. You can follow the discussion in Ti E2E

I have created a minimal example to reproduce the problem.

BeagleBoard Rust Imager

There has been some interest in making the Rust flasher the official flasher. To achieve that, there has been a lot of development towards v1.0.0.

MacOS dmg support

Thanks to help from Zain, I was able to create MacOS dmg in CI. While most of the flashing functionality does not work on MacOS yet, having easy experimental CI builds should help development to at least ensure everything builds.

Make bb-imager-rs Ready for crates.io

While exploring ways to create a Debian package, I stumbled across debcargo, which is the official way to package Rust applications for Debian. Since it can potentially allow official packages in the future, I decided to prefer it over cargo-deb. However, since debcargo builds the package from crates.io, I needed to cleanup the out of tree patches for rs-drivelist and bin_file. So, I moved the unmerged/unreleased code into bb-imager itself for now.

I still need to set up CI to push to crates.io automatically, but I am a bit unsure regarding how to handle the API key securely.

Sd Card Formatting Support

I have added support for SD card formatting since it is helpful for an imaging utility. However, it does not work on Windows yet.

Performance Enhancements and Code improvements

Here is the list of minor improvements that occurred during the week:

More responsive UI
Make the default window size smaller
Better handling of big os image lists.
Code improvements to make contribution easier.

File I/O Support for Rust std for UEFI

As eluded to last week, File I/O PR is now ready for prime time. It supports the following kinds of paths:

Relative Paths
Absolute UEFI Shell Mapping
Absolute UEFI Device Path

For now, I have only added support for files (so no directory APIs) to make review easier. However, once the file support is merged, directory API implementations will be a simple matter.

Currently, there is a lack of reviewers for UEFI Rust std PRs. So, if you have the experience, feel free to check out and/or review the PR.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #7

2024-10-27T00:30:12+05:30

Hello everyone. This week mostly involved a lot of chasing stuff around (sometimes in vain), so while there was not much headline work, this post might end up a bit longer than usual. Let's get started without delay.

BeagleConnect Freedom Adventures

I started the week by trying to add IEEE802154 subg socket support in MicroPython for BeagleConnect Freedom. However, I quickly learned that it would not be simple. For some reason, BeagleConnect Freedom would completely lock up after starting.

Initially, I thought it might be a MicroPython issue, so I tried tracking down where the freeze happened. This, however, led to a dead end since, for some reason, the program would not be able to read from the UART console. While doing this, I also remembered a similar issue I encountered while working on BeagleConnect Freedom rc car demo. At the time, I fixed it by just removing unused config items like ADC and PWM from config, but forgot about it after the OOSC conference.

After some experimenting with PWM, ADC, and IEEE802154 subg radio, I figured out that the problem is reproducible in other Zephyr samples like echo_cliet, etc. For some reason, if both PWM pins (MB1 PWM and MB2 PWM) are enabled alongside the subg radio, everything freezes. If one or both of the PWM are disabled, everything works fine. This seems to be an issue with timers but it needs further investigation.

I have created a Zephyr issue and a Ti E2E question for the same.

Code Composer Studio Theia Adventures

With the MicroPython issue and the bricked BeagleConnect Freedom, I thought it is a good time to setup and learn Ti's Code Composer Studio.

I use Fedora Sway Atomic as my daily driver, and thus mostly rely on flatpaks or podman containers. However, running Code Composer Studio inside a podman container (created using toolbox) was not a great experience for me. It would randomly stutter (maybe a hardware acceleration problem?) and freeze. Additionally, while udev can make it almost painless to handle device permissions, it can occasionally cause hiccups with flashing. In fact, one of the primary reasons I switched to neovim was that my emacs GUI kept having weird performance problems inside the container.

So, I finally went ahead and installed CCS Theia on my base system. The install procedure is a bit weird since there is no rpm or deb package. Instead, there is an installer which installs everything in $HOME/ti folder. It also creates an uninstall, which seems to work. All in all, while I prefer a flatpack or app image, it wasn't too bad.

I hit a snag quite early on when I was unable to flash the cc1352p1 on my launchpad. I tried various things and opened a Ti E2E question for the same. However, the solution turned out to be quite weird. I was not saving my workspace since, well, nothing was working anyway, and CCS Theia would open the unsaved workspace. But everything magically worked once I saved my workspace because I was tired of the dialog on exit. Not really sure why.

Once I could flash the launchpad, I tried using the xds110 in launchpad with my BeagleConnect Freedom. I was able to flash a simple blinky on it and even set up breakpoints.

Now, I need to figure out how to use openocd and add instructions in Beagle docs and Zephyr docs for the same.

KUnit Adventures

I have been working on kernel patches that require writing some unit tests. So I was trying to get KUnit to work. However, kunit run kept on failing for some reason, even with the default config. The output was not very clear either. However, after following some debugging instructions, I found out that I could not execute the user mode kernel from inside the podman container. I have created an issue in Fedora toolbox regarding the same.

MicroPython

I have added MicroPython support for BeaglePlay cc1352p7 in my draft PR. It supports IEEE802154 subg sockets and also helped me ensure that MicroPython networking should work fine on BeagleConnect Freedom as well once the timer issue is resolved.

Since BeaglePlay cc1352p7 Zephyr support was merged after the 3.7.0 release, the MicroPython support will continue to live in the draft PR until MicroPython supports a newer Zephyr version.

Zephyr

Zephyr support for BeagleBoard boards continues to improve. We will continue to work to make Beagle one of the best-supported platforms for Zephyr development.

BeagleBone AI-64

Thanks to the work by Andrew Davis, Zephyr support for R5 cores in BeagleBone AI64 was merged this week. Here is the Zephyr page for BeagleBone AI 54. This adds one more board to the growing list of BeagleBoard boards that support Zephyr.

BeagleY-AI

A PR for Zephyr support was opened by Andrew Davis after BBAI-64 support was merged. Anyone interested should feel free to try it out. Hopefully, it can get merged upstream soon.

BeagleBoard Imager Rust Updates

While working on BeagleY-AI, I found a bug in the sha256 handling of the Rust-based imager while translating the old bb-imager config. So, I have created release 0.0.2 for the imager. I probably should implement changelogs before the next release.

Rust Path Prefix

While working on File I/O support for UEFI, I was reminded again of the limitations of std::path::Prefix. To fix this, an issue has been opened in Github, and I have posted my proposal. Feel free to add suggestions to it.

I will start implementing the proposal once I deem the File I/O support good enough to mark the draft PR as ready.

Migrating to dev domain

I have migrated my blog from https://programmershideaway.xyz/ to https://programmershideaway.dev/. The reason I started out with xyz was because it was extremely cheap at the time. However, now that I am writing regularly, I have decided to switch to .dev, since that feels better than .xyz for a programming blog. I have also setup redirects from the old domain, so all the old links will continue to work for now. I will renew the old domain for at least one more year. Hopefully, by 2026, all the old links will be updated to the new one.

I used Cloudflare Registrar for the domain (since my old one is also here), but payments were really difficult to do from an Indian debit card. I hope Cloudflare can fix this by the time I have to renew this domain.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #6

2024-10-20T00:30:12+05:30

Hello everyone. Another light week here. Let's go over everything.

MicroPython

Initial BeagleConnect Freedom Support

While we have had MicroPython firmware for BeagleConnect Freedom in the past, the work was out of tree. This made maintenance and collaboration hard to do. There were a few reasons for having the support out of tree:

Zephyr support for BeagleConnect Freedom was primarily out of tree, with just basic support in mainline.
MicroPython only supported Zephyr v3.1.0

Due to my work, BeagleConnect Freedom supports almost everything in mainline Zephyr. Additionally, due to the fantastic work by Maureen Helm MicroPython now supports Zephyr v3.7.0. So, it seemed like a good time to have support for BeagleConnect Freedom in mainline MicroPython. Here is the link to the merged PR. It does not contain more advanced features like ADC and PWM right now, but those are also on the way.

PWM support for Zephyr Port

While working on adding PWM support for BeagleConnect Freedom in MicroPython, I discovered that the Zephyr port of MicroPython did not support PWM. So, I ended up working on adding PWM support. Here is the PR.

MicroBlocks v2.0

MicroBlocks is a blocks programming language for physical computing inspired by Scratch. BeagleConnect Freedom has had good support for MicroBlocks, as outlined in a prior post.

Recently, MicroBlocks v2.0 was released in pilot and thankfully, BeagleConnect Freedom works with the newest firmware perfectly, without any real change in the Zephyr port.

Arduino Module for Zephyr

Due to the recent cleanup of the defaults in the device tree of BeagleConnect Freedom, ADC and PWM are supported without any overlays. So just a simple cleanup of Arduino module overlay. Here is the PR.

BeagleBoard Rust Imager

The v0.0.1 release of the BeagleBoard Rust imager took place last week. It has the following features:

Platforms:
1. Linux
  1. GUI Appimage
  2. CLI binary
2. Windows
  1. GUI Portable exe
  2. CLI binary
3. macOS
  1. CLI binary
Boards
1. Generic Linux (BeaglePlay, Beagle AI64, BeagleY-AI, BeagleV-Fire, BeagleBone Black, etc)
2. BeagleConnect Freedom
3. BeagleConnect Freedom MSP430

It is basically at feature parity with the original BeagleBoard Imager based on Raspberry Pi and supports additional boards like BeagleConnect Freedom. Here is the release page.

Rust std for UEFI

The Rust std for UEFI endeavor has picked up steam again, with some of the old PRs getting merged. I have the following support in the pipeline:

File I/O
TCP
UDP

Let's hope that I can get enough free time to upstream everything by the end of this year. However, I will not make any promises since I can only work on this in a limited capacity.

Environment Variables

Environment variables support for UEFI was merged this week. It uses UEFI Shell protocol behind the scenes since environment variables are not applicable in most other situations. . Here is the merged PR.

There is also a plan to introduce support for full UEFI variables under std::os::uefi, but that's probably far in the future. The current goal is first to reach a point where running Rust std tests is possible.

File I/O

With most of the pieces in place, I will start working on File I/O support again. Here is the draft PR, but I have a much more advanced version locally.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #5

2024-10-13T00:30:12+05:30

Hello everyone. Another light week here. Let's go over everything.

Arduino Module for Zephyr

A few weeks ago, I created a PR in Zephyr that adds ADC and PWM support to base devicetree. So we can now clean up the overlay present in the Arduino Module. Here is the PR for it.

Additionally, while working on this, I encountered that the CI is broken for Arduino Core API module for Zephyr. So, I created a PR to fix it.

BeagleBoard Rust Imager

The BeagleBoard Imager Rust Port now supports using the original BeagleBoard Imager config file. This makes the Rust imager almost feature complete the original (only MacOS support is missing).

Zephyr

Continuing the general work to improve Zephyr support in Beagle platforms, this week saw some doc improvements along with bug fixes.

Subg Testing

BeagleConnect Freedom has now been added to build samples against for subg overlay testing. Here is the PR.

Adding tests also found a bug in the IEEE802154 shell code, which was fixed in the same PR.

BeagleV-Fire Doc

I haven't been involved in BeagleV-Fire much, but for anyone unfamiliar, BeagleV-Fire supports Zephyr on its E51 and U54 cores. There were some problems with the documentation, so I ended up fixing it. Here is the PR.

BeaglePlay (CC1352P7) Twister Fix

Continuing the work to improve defaults, I created a PR to only enable IEEE802154 subg in the base devicetree of BeaglePlay CC1352P7. In the same PR, I also found out the Twister was broken for BeaglePlay CC1352P7. So, I also ended up fixing it by enabling the UART console in default Kconfig.

Rust std for UEFI

I plan to speed up Rust std for UEFI development again since it has been a work in progress for far too long. After posting on the Rust Zulip, things have started moving again. As a first step, getcwd and chdir PR was approved.

I hope more Rust reviewers interested in UEFI can start getting involved so that I can get everything merged by the end of this year.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #4

2024-10-06T00:30:12+05:30

Hello everyone. Another light week here. Let's go over everything.

BeagleConnect Freedom

Zephyr

While BeagleConnect Freedom has had good Zephyr support for a while, the base devicetree had some missing features that would require overlays. This would sometimes cause confusion among beginners. So, I created a PR to provide better defaults.

I also created another PR regarding some other cleanup.

MicroPython

MicroPython support for Zephyr v3.7.0 was finally merged last week. I would like to thank Maureen Helm for all the amazing work.

I have created a PR to add BeagleConnect Freedom support to upstream MicroPython. It only supports SPI, I2C, and FLASH for now, but once the base support is accepted, I will expand to include support for everything possible with v3.7.0.

BeaglePlay Zephyr

BeaglePlay cc1352p7 support was finally merged last week. While it was initially scheduled for Zephyr v3.7.0, it ended up being delayed. However, I hope that having upstream Zephyr support helps people create some amazing projects.

Similar to BeagleConnect Freedom, I also cleaned up the BealgePlay devicetree. Here is the PR

BeagleBoard Imager Rust Utility

Continuing from last week, there was a lot more development on the Rust-based imager utility.

Support for more firmware file types

BeagleBoard Rust Imager now supports flashing Ti-TXT, Intel Hex to BeagleConnect Freedom. This should help with using BeagleConnect Freedom using CCStudio.

I also ended up flashing a firmware that disabled BSL, so I need to figure out how to flash a firmware that enables BSL again.

Better Cross compile

I want the imager utility to work on aarch64, specifically on BeaglePlay, BeagleY-AI, etc. However, the dependence on OpenSSL and libudev made cross-compiling a bit difficult.

I was able to simplify local development using cross. However, using cross on Gitlab CI was much more difficult than I initially expected. Additionally, BeagleBoard Gitlab only had one Docker-in-Docker runner, so I opted for a more manual approach. My CI config should serve as a good starting point for anyone in a similar situation.

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #3

2024-09-29T00:30:12+05:30

Hello everyone. This was one of the lighter weeks since I couldn't get much results. But after some thinking, it is also vital to write about failed endeavors in case I pick something back.

Bluetooth support for BeagleConnect Freedom

I will outline everything I encountered while trying to get Bluetooth support for BeagleConnect Freedom on Zephyr. While I could not do it in the end, I hope this can be helpful in any future work on this.

Support for most other BeagleConnect Freedom capabilities is already present in upstream Zephyr, so Bluetooth is the last remaining major feature we are missing.

After exploring the Zephyr Bluetooth source code, I have come to 2 possible approaches. I will be outlining the benefits, effort required, etc.

Binary Blob

It is possible to use binary blobs for HCI support on cc1352p7. As is evident from Ti docs, there is already an implementation of HCI for cc13xx devices. The following steps need to be taken to integrate it with Zephyr:

Ensure that the internal structure of HCI does not conflict with Zephyr (I assume it might use Ti-RTOS).
Add the blob to hal_ti. West supports fetching binary blobs.
Write an HCI driver (see hci_esp32).

This approach requires minimal changes to the current Ti approach and should be reasonably straightforward for anyone with access to the cc13xx HCI source. Additionally, minimal maintenance is required from the Ti side since they already maintain the HCI source for Ti-RTOS.

This approach is already in use in ESP32 boards. Thus, it should be accepted with minimal resistance.

Zephyr Software Link Layer

Zephyr also supports software-based link layers, which are supported by Nordic hardware. While it should be possible to directly interface with cc13xx radio APIs in ROM and use the software link layer, the current ble stack was created around Nordic hardware. This means that supporting the Ti APIs would require significant time and effort to adapt things for Ti driverlib APIs.

I feel this approach only makes sense if Ti intends to officially support Zephyr since it will also require a permanent maintainer.

BeagleY-AI Zephyr Support

During the Beagle-Y-AI Hacking Sessions, we went over how to get started with Zephyr on R5 core of BeagleY-AI. Here is the current Zephyr repo.

Check out the video for more details.

BeagleConnect Freedom MicroPython

I have added basic BeagleConnect Freedom support to draft PR. It currently contains support for the following:

GPIO
I2C
SPI
FLASH

I will move the support for this to the main branch once support for Zephyr 0.37.0 is merged.

I am waiting on upstream Zephyr PR before adding support for ADC, PWM and IEEE802154g.

BeagleBoard Imager Rust Utility

More updates for Rust port of BeagleBoard imager utility. I am thinking of creating a release soon.

Support for more firmware file types

We are trying to make it possible to do development for BeagleConnect Freedom using Ti Code Composer Studio. However, the current flasher (both GUI and CLI) only supports flashing .bin. So to make things more ergonomic, I am planning to add support for Ti-TXT, Intel Hex, and other common formats.

I am using bin_file to handle and parse the file formats. However, it was missing some functionality I needed. Here is the PR.

I have already enabled support for new formats for flashing MSP430. Similar support for BeagleConnect Freedom is coming soon.

Updated Look

The GUI look lines up with the current BeagleBoard imager utility, complete with the background and font.

I use a window manager (sway), so the screenshots have no window decorations.

Screenshots

Here are some screenshots from the application.

Home Page

Extra Configuration Page

Flashing Page

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #2

2024-09-22T00:30:12+05:30

Hello everyone. This is the second post in my weekly series. There was some work on bb-imager-rs, mostly my pet project, along with some developments with upstream Zephyr and MicroPython. In short, there were no major developments, but it was still a good week.

BeagleBoard Rust Imager

A while ago, I started work on rewriting BeagleBoard Imaging Utility with the goal of adding support for flashing things other than SD cards. I chose Rust and Iced for this work.

Fast forward to the present, and now the Rust port can flash CC1352P7 and MSP430 in BeagleConnect Freedom. Due to some problems with the original MSP430 USB to UART bridge in BeagleConnect Freedom, it was not working on Windows. I ended up rewriting it to work on Windows.

However, this still left the problem of providing good instructions for flashing the new firmware. Originally, flashing MSP430 required using python-msp430-tools, which is a Python 2 script and can be difficult to use, especially on Windows. Thus, I added the functionality to the imager to allow GUI-based flashing. Additionally, since it is a standalone binary, chasing dependencies is unnecessary.

I also updated to Iced v0.13.1 in the process, which introduced rich text. So anyone interested in porting to new Iced can also use this as a reference.

The Rust-based imager is still missing one critical platform, MacOS, since I do not have a Mac. So, anyone interested is free to take a crack at it.

Screenshots

Here are some screenshots from the application.

Home Page

Extra Configuration Page

Flashing Page

Update BeagleConnect Freedom Zephyr devicetree

Currently, PWM and ADC support is absent in the based devicetree for BeagleConnect Freedom. This is due to the fact that I added PWM and ADC support quite recently. So, after some deliberation, I think it would be best to enable ADC and PWM in the base devicetree to make for an easier new user experience. It also allows running PWM and ADC-related tests in Twister. Here is the PR.

BeaglePlay CC1352 Zephyr Support Updates

Zephyr support for BeaglePlay CC1352P7 has been a work in progress for a long time at this point. It was initially planned for v3.7.0, but sadly, it missed that deadline. Forward to the present, and it finally seems to be ready. The name for the target has changed to beagleplay/cc1352p7 to allow for future support for Zephyr on M4/A53.

It already has the required approvals, so I hope it can be merged soon. Here is the PR

MicroPython Zephyr Mainline Port

Most BeagleBoard boards have some level of MicroPython support. However, since MicroPython usually tracks some stable versions of Zephyr, it can take a long time to add support for the board to upstream MicroPython. This often means by the time things get ready to be merged upstream, the fork with MicroPython is often unmaintained.

After a discussion on MicroPython Discord, I decided to maintain a branch of MicroPython that tracks mainline Zephyr. This can serve as a jumping point for boards still in development or ones merged after the Zephyr version currently supported by MicroPython. Currently, the plan is to keep this branch as a draft PR. I will also keep the MicroPython support for new BeagleBoard boards in this fork until they are ready to be merged into the main branch.

Here is the link to draft PR

Ending Thoughts

That is all for the week. Hopefully, this series helps keep people updated about my work and attracts potential contributors.

Consider supporting me if you like my work.

Helpful links

My Week in Code #1

2024-09-15T00:30:12+05:30

Hello everyone. I am starting a new series of weekly posts to go over stuff I worked on/found interesting over the week. I will try to post one every Sunday, but I might skip uneventful weeks.

Since I work as an embedded systems engineer at BeagleBoard.org, many updates will be about BeagleBoard stuff. Still, I might throw some Rust std and other things in occasionally. Let's see how this goes.

MikroBUS Patches

I finally sent v1 of MikroBUS patches using the approach described by Andrew Davis. I got the approach to work for GPIO, UART, and I2C but not for SPI.

I wrote the driver in Rust to see how it would go, and it was a pretty good experience. Danilo Krummrich will post patches for platform device and driver abstractions for Rust, so any future patches will probably not need to carry those either.

There is also a talk in LPC this week: Runtime hotplug on non-discoverable busses with device tree overlays, so I will be looking forward to it.

Beagle-Y-AI Hacking Sessions

We at BeagleBoard have started weekly hacking sessions for Beagle-Y-AI. Currently, we are working on adding Zephyr support for the R5 core, so feel free to join in. Here is the event invite.

GPIO Nexus Node dtschema

In the MikroBUS patches, I was asked to put the GPIO nexus node dtschema in the upstream dtschema. So just a basic PR to add dtschema for GPIO nexus nodes.

PWM in BeaglePlay

While working on MikroBUS patches, I realized that PWM support was not enabled in the upstream device tree for BeaglePlay. So, I decided to send a patch to enable it.

Once the patch is added to the kernel tree, it will be possible to use the PWM pin in the MikroBUS connector as described in Linux kernel docs.

Fix MicroBlocks for BeagleConnect Freedom

Around two weeks ago, the CI MicroBlocks for BeagleConnect Freedom broke. After checking the CI logs, it seems MicroBlocks started using digitalPinToInterrupt, which was missing in Arduino Module for Zephyr. I created a PR for it, and now the CI is fixed again.

Ending Thoughts

That is all for the week. Hopefully, I can stick to the weekly schedule.

Consider supporting me if you like my work.

Helpful links

MicroBlocks on Beagleconnect Freedom

2024-06-15T00:30:12+05:30

Hello everyone. I have been recently working on porting MicroBlocks to Beagleconnect Freedom. This also involved work improving Arduino module for Zephyr since MicroBlocks uses Arduino APIs. I will go over using MicroBlocks on beagleconnect freedom.

What is BeagleConnect Technology

2024-01-19T00:30:12+05:30

Hello everyone. I have been a bit busy these past few months working to improve BeagleConnect™ Technology. While this work initially started as a Google Summer of Code 2023 project, I am now working part-time on this. While not everything is completed, I felt this was a good point to go through an overview of it before I start creating demos (which are actually reproducable without having to approach me). So here it goes.

UEFI Rust Std is now in Nightly

2023-09-25T11:45:12+05:30

Hello everyone. I started working on Rust Std for UEFI last year as a part of my Google Summer of Code 2022 project under Tianocore. My mentors for this project were Michael Kinney and Michael Kubacki. After a year of work, initial support for UEFI Rust std has been merged into upstream. In this post, I will review what is currently possible and my plans.

GSoC23: Summary Post

2023-08-26T18:15:12+05:30

Hello everyone. This is the final blog post I will write before Google Summer of Code 2023 ends (hopefully not the final greybus one). In this post, I will summarize my GSoC23 work to make it more accessible to everyone.

GSoC23: BeaglePlay Greybus Demo

2023-07-26T23:40:12+05:30

Hello everyone. My project is now at a point where almost everything is working to a respectable level. Thus I wanted to do a demo. Check out my GSoC 2023 Introduction post for more information about my project.

GSoC23: Project Status update

2023-07-08T00:30:12+05:30

Hello everyone. It will soon be time for the Mid-term evaluation of Google Summer of Code 2023. Thus, I decided to write a post to summarise everything I have been working on. I will also go over how it can be replicated by anyone interested.

GSoC23: Concurrency in ZephyrRTOS

2023-07-03T00:30:12+05:30

Hello everyone. I am working on a CC1352 firmware for Zephyr. This will be responsible for SVC and AP Bridge role in the Greybus topology that Gbridge currently handles. Zephyr provides a lot of abstractions to write efficient concurrent code. I am going to discuss some of them in this post.

GSoC23: Linux Serial Device Bus

2023-06-15T16:05:12+05:30

Hello everyone. The Linux driver I am working on will be a Serial Device Bus Driver. So in this post, I will review the critical components of writing a functional Linux Serial Device Bus driver.

GSoC23: Getting started with Zephyr for BeaglePlay CC1352

2023-06-07T20:05:12+05:30

Hello everyone. In this post, I will go over setting up BeaglePlay and my Linux host for BeaglePlay CC1352 firmware development. Check out my GSoC 2023 Introduction post for more information about my project.

GSoC23: Writing a Hello World Driver for BeaglePlay

2023-06-01T22:07:12+05:30

Hello everyone. I will go over setting up BeaglePlay for Driver Development in this post. I will write a simple "Hello World" driver once BeaglePlay is set up to demonstrate this. Check out my previous post for more information about my project.

GSoC 2023 Introduction

2023-05-22T19:07:12+05:30

Hello everyone. I am Ayush Singh, a third-year student at the Indian Institute of Technology, Dhanbad, India. As a part of Google Summer of Code 2023, I will be working on Replacing GBridge under the BeagleBoard.org organization. In this post, I will describe the project I will be working on.

Handling ExitBootServices Event in Rust std

2023-04-07T16:07:12+05:30

Hello everyone. Recently, there was a discussion about the exact scope/boundary of Rust std for UEFI. In this post, I am going to go over the different stages of UEFI and define what std for UEFI aims to target. Additionally, I will go over how the current implementation handles ExitBootServices().

Compiler generate custom entry for any target

2023-03-18T16:08:12+05:30

Hello everyone. While implementing Rust std for UEFI, I came across an interesting problem. The signature of the entry function in Rust did not match the UEFI entry signature. Initially, I just used a hacky way to get things to work. However, later I made some changes to upstream Rust to make generating entry functions with custom signatures much easier. In this post, I will show how to implement generating such an entry function in upstream Rust through the example of UEFI.

Minimal Rust Std for UEFI

2023-03-15T19:01:12+05:30

It has been quite a while since I gave any updates about Rust std implementation for UEFI. While the Google Summer of Code ended quite a bit ago (it's almost time for GSoC 23), I have been continuing my efforts to merge it upstream. Check out my GSoC 22 Summary Post for a refresher on the project.

Validating Json Request in axum

2023-01-17T19:01:12+05:30

I have been playing around with axum, and it has been quite a fun web framework. While using it, I came across what is a relatively common use case of validating the request JSON. However, I could not find any extractor for this. Thus I decided to write my own and share it with everyone. While I haven't put it in a crate, feel free to use the code as you wish.

Using Rust main from custom entry point (Part 3)

2022-10-27T22:22:12+05:30

Even though GSoC 2022 has ended, I am still working on getting Rust std PR merged into the master. In the initial PR, I still used the entry function described in the prior post. However, this had many limitations, and thus I have finally transitioned to using a compiler-generated entry function.

GSoC22: Summary Post

2022-09-05T22:22:12+05:30

Hello everyone. This is probably the final blog post I write before Google Summer of Code 2022 ends (hopefully not the final uefi one). In this post, I will summarize my GSoC22 work to make it more accessible to everyone.

Writing UEFI Protocol in Rust

2022-08-27T22:22:12+05:30

Hello everyone. As a part of Porting Rust std for UEFI, I had to write a hacky implementation of pipes (using UEFI Variables) for piping output from launched programs. However, this implementation had some problems and failed to run tests using the feature panic_abort_tests. Since I had some time this week, I decided to write a Protocol to fix the pipes. Along the way, I also found many ways to shoot myself on foot. So I decided to write this post documenting all the gotchas I discovered while writing a new protocol in Rust. This post will only contain 1 of the two protocols I decided to create, internally named UEFI_COMMAND_PROTOCOL.

UEFI Rust std has a new home

2022-08-05T20:44:12+05:30

Hello everyone. All my work on UEFI Rust std has been moved to tianocore/rust. This should help with allowing more contribution from both Tianocore and Rust's sides. This post is just a sort of introduction to the new repository and how to get started.

GSoC 2022: Progress Report 2

2022-07-24T02:38:12+05:30

Hello everyone. It is finally possible to run the whole Rust testing suit for UEFI under QEMU and OVMF. So I think this is a good point to give a detailed overview of everything that has been implemented and the state of those implementations. I will also provide instructions on how to go about running the tests as well.

Implementing Stdio for UEFI

2022-07-08T00:53:12+05:30

Hello everyone. In this post, I will go through how I implemented the stdio module for UEFI. The implementation code can be found here.

GSoC 2022: Progress Report 1

2022-06-29T00:53:12+05:30

Hello everyone. In this post, I will explain the current state of std implementation for UEFI. The rust repository containing my work can be found here. In the end, we will use this fork to run a Rust binary.

Using Rust main from a custom entry point (Part 2)

2022-06-25T22:28:12+05:30

Hello everyone. I will continue where I left off in post with the Rust main in this post. Since we now have an allocator, the Thread::new statement at library/std/src/rt.rs works. So we need to fix the line where we set the main thread with guard information. This will be a short post since it turned out easier than I initially thought.

Writing an Allocator for UEFI

2022-06-23T16:45:12+05:30

Hello everyone, we will discuss how to write the Allocator for UEFI in this post. More specifically, the Allocator is for the DEX phase in UEFI. We will be using uefi-spec-rs, which is my wrapper around r-efi for use in the std.

Using Rust main from a custom entry point

2022-06-21T00:12:12+05:30

Hello everyone. In this post, we will deep dive into the crux of the main() function and look behind the scenes. By the end, we will have some understanding of Rust runtime. Primarily, I will describe my current implementation of efi_main to hook into Rust runtime.

Use Restricted std in UEFI

2022-06-16T00:00:00+00:00

Hello Everyone; in my last post, I set up the development environment for working on adding Rust support for UEFI. In this post, I will get a restricted version of std (basically a glorified core + alloc) to work for the x86_64 UEFI target. We will be starting with the no_std hello_world program from the last post.

Google Summer of Code 2022

2022-06-14T00:00:00+00:00

Hello everyone, I am Ayush Singh, a second-year student at the Indian Institute of Technology, Dhanbad, India. As a part of Google Summer of Code 2022, I will be working on Adding Rust Support for building UEFI Applications and Modules under the Tianocore organization. In this post, I will describe this project's goals and set up my development environment.

Using KConfig with Rust

2022-03-14T22:19:49+05:30

Hello everyone, I am currently working on KConfig bindings for Rust as a part of the Season of KDE 2022. The wrappers for most of the significant aspects of KConfig are complete, so I decided to rewrite the Introduction to KConfig Docs in Rust. The bindings are still not stable and will probably change before the end of the Season of KDE. Still, this post should also help me test out the bindings outside tests. The kconfig bindings can be found here.

Bitflags in Rust

2022-01-30T01:54:01+05:30

While working on Rust bindings for KConfig as a part of Season of KDE 2022, I came across a few problems while trying to represent QFlags in Rust:

Most QFlags are defined as C++ enums in which multiple members can have the same value. This is not possible in Rust enum.
It is possible to enable multiple flags using BitwiseOr. Rust enums cannot do bitwise operations.

Season of KDE 2022

2022-01-26T20:00:33+05:30

I am Ayush Singh, a second-year student of the Indian Institute of Technology, Dhanbad, India. My application has been accepted in the Season of KDE 2022. I will be working on writing a Rust wrapper for KConfig KDE Framework. This post describes my journey with KDE and why I submitted this Project for the Season of KDE.

Creating Rust/QML Project

2022-01-22T12:00:33+05:30

For the last few months, I have been pushing Rust/Qt development along. I am the author of ki18n crate and am currently in the middle of creating kconfig crate as a part of Season of KDE 2022.

In this post, I will walk you through creating a new Rust/QML project using cargo-generate templates. I made these templates to encourage more people to test out Qt development with Rust.