My Week in Code #16
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.