Control plane agent for Nucleo boards - #2400
Open
lzrd wants to merge 1 commit into
Open
Conversation
The Nucleo board is a useful off-the-shelf board for prototyping and for testing "pure Hubris" code paths. Configuring the control plane agent into the image makes the board more useful. The Nucleo board can also be a convenient platform for developing I2C device drivers. While there is enforcement in xtask to ensure that the vlan feature is enabled for production boards, the feature results in compilation errors if those guards are commented out and the vlan feature is removed from the `app.toml`. That is fixed so that the Nucleo boards can opt out of the vlan feature. All of the changes in the machine code output are explained by line number changes (ringbuf, etc.), the caboose `GITC` value, a different Hubris ImageId, and one layout change due to a line number constant value being a different size: in `control_plane_agent` in `handle_mgs_request` a `cmp.w r0, #728` became `move r1,#729; cmp r0, r1` While people have prototyped a Nucleo + NXP LPC55S69 xPresso board to simulate SP + RoT, there is no intention to officially support that configuration. Configuration changes to Nucleo boards: - add `control_plane_agent` (CPA) - add "Caboose" for Hubris image identification - omitting VLAN tags on Nucleo boards - `update_server` to manage firmware updates - `sprot` is assigned the appropriate pins for connection to a non-existent RoT `control_plane_agent` references `i2c_driver` unconditionally via `task_slot!(I2C, i2c_driver)`, so add it to CPA's task-slots in `app-h743.toml` (`app-h753.toml` already had it).
lzrd
marked this pull request as ready for review
September 4, 2026 20:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Improve Nucleo support for Hubris and hardware testing
The Nucleo board is a useful off-the-shelf board for prototyping and for
testing "pure Hubris" code paths. Configuring the control plane agent
into the image makes the board more useful.
The Nucleo board can also be a convenient platform for developing I2C
device drivers.
While there is enforcement in xtask to ensure that the vlan feature is
enabled for production boards, the feature results in compilation errors
if those guards are commented out and the vlan feature is removed from
the
app.toml. That is fixed so that the Nucleo boards can opt out ofthe vlan feature.
All of the changes in the machine code output are explained by line
number changes (ringbuf, etc.), the caboose
GITCvalue, a differentHubris ImageId, and one layout change due to a line number constant value
being a different size: in
control_plane_agentinhandle_mgs_requesta
cmp.w r0, #728becamemove r1,#729; cmp r0, r1While people have prototyped a Nucleo + NXP LPC55S69 xPresso board to
simulate SP + RoT, there is no intention to officially support that
configuration.
Configuration changes to Nucleo boards:
control_plane_agent(CPA)update_serverto manage firmware updatessprotis assigned the appropriate pins for connection to a non-existent RoTcontrol_plane_agentreferencesi2c_driverunconditionally viatask_slot!(I2C, i2c_driver), so add it to CPA's task-slots inapp-h743.toml(app-h753.tomlalready had it).