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.
Ending Thoughts
This was it for this week. Hopefully, this helps bring transparency regarding where the development efforts are concentrated, and how the community can help. Look forward to next update.