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