This Week in Beagle #24

By

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:

  1. 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.
  2. The cape devicetree changes should be concentrated on the connector node. This should help with isolation, and curb the concerns regarding security.
  3. 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:

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

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.

Helpful links