CnuasBMC, Datasheet¶
| Item | Value |
|---|---|
| Part | cnuas-rackmond, cnuas-rackmon, ORV3 shelf firmware, meta-cnuas |
| Type | Management controller stack |
| Version | fd0f896-dirty |
| Repo | PacketFive/cnuas |
1. Overview¶
The Cnuas management stack emulates the parts of a rack that sit below the operating system: the Open Rack V3 power shelf and its satellite microcontrollers, the rack management controller that polls them, and the sled management controller that powers blades on and off.
Microcontrollers run in Renode rather than QEMU, because the shelf is wired
with a multi-drop RS-485 segment and Renode can model that segment directly.
Real OpenBMC images run on the resulting machines, and standard tooling reaches
them: ipmitool over the network, Redfish over HTTPS, and serial over local
area network for console access.
Key features¶
- Open Rack V3 power shelf emulated at the firmware level, not stubbed.
- Multi-drop RS-485 segment shared by the shelf and its satellites, bridged to a TCP endpoint.
- Modbus remote terminal unit polling by the rack management controller.
- Sensor publication onto D-Bus for OpenBMC consumers.
- Yocto layer with machine configurations for the rack, sled and switch controllers.
- Sled controller drives an emulated blade through general purpose input and output over the emulator monitor.
2. Components¶
| Component | Role | State |
|---|---|---|
| ORV3 shelf firmware | Power shelf and battery backup behaviour | Builds, host tests run |
cnuas-rackmond |
Rack management daemon, polls the shelf | Builds for host and for the controller |
cnuas-rackmon |
Operator client for the daemon | Builds |
meta-cnuas |
Yocto layer, machine configurations and recipes | Layer content present |
| Renode platforms | Shelf and satellite machine definitions | Shelf and battery machines run, several satellites are skeletons |
| Sled bridge | Management controller to blade power path | Ships inside cnuas-tools |
3. Renode machine definitions¶
| Machine | Core | Peripherals |
|---|---|---|
| ORV3 satellite | Cortex-M3 | RS-485 through a 16550 compatible port at 0x40000000, strap block at 0x30000000 |
| Battery management | Cortex-M4 | RS-485 through a serial port at 0x40004400 |
| Power supply | Cortex-M0 | Power management bus over an inter-integrated circuit slave |
| Fan controller | Cortex-M0 | Inter-integrated circuit slave |
| Sequencer | Cortex-M0 | Inter-integrated circuit slave with a fault line |
| Front panel | Cortex-M0 | Serial port and inter-integrated circuit slave |
| Optics | Cortex-M0 | Inter-integrated circuit slave, superseded |
The RS-485 segment itself is a Renode plugin that joins the machines onto one multi-drop bus and exposes it on a TCP endpoint so that host software can attach.
Not every satellite carries firmware
The fan, sequencer, front panel and optics machines are defined but their firmware loads are placeholders. Only the shelf and battery management machines run real firmware today. Treat the remaining satellites as scaffolding.
4. Rack management controller¶
| Item | Value |
|---|---|
| Daemon | cnuas-rackmond |
| Client | cnuas-rackmon |
| Shelf protocol | Modbus remote terminal unit |
| Shelf transport | Serial device, or a TCP endpoint on port 3485 |
| Operator protocol | JSON over a UNIX domain socket |
| Operator commands | status, sweep, ping |
| Publication | D-Bus sensor objects for OpenBMC |
| Sensor objects | 56, plus chassis inventory |
| Builds | Host binaries, and static binaries for the controller |
The same shelf readings drive the facility twin live animation.
5. Sled management controller¶
| Item | Value |
|---|---|
| Bridge | cnuas-tools sledbmc bridge |
| Blade control lines | Power output, reset output, power good, power on self test |
| Transport to the blade | Emulator monitor protocol |
| Redfish | HTTPS, port 2444 |
| Intelligent platform management interface | UDP port 623, reachable with ipmitool -I lanplus |
| Serial over local area network | Blade console through the emulator serial socket |
6. Yocto layer¶
meta-cnuas carries the layer configuration, machine configurations for the
rack, sled and switch controllers, template samples, and recipes covering
branding, the rack monitor, kernel device trees, entity manager configuration,
console configuration, a package group, and host power control.
7. Validation¶
| Area | How it is exercised |
|---|---|
| Shelf firmware | Host test target in the firmware makefile |
| Rack management controller | Host test target in the controller makefile |
| Renode machines | Scripted machine start under bmc/renode/tests/ |
| Sled bridge and emulator monitor protocol | 33 cases in tools/tests/sledbmc/, all passing |
Only the sled bridge is covered by the continuously run pytest suites. The firmware and controller test targets are makefile driven and are not yet wired into the same reporting. That gap is recorded in the Validation Matrix.
8. Operating notes¶
- The run scripts expect externally supplied QEMU and OpenBMC images and check for them before starting.
- Renode is a separate dependency from QEMU and is needed only for the management stack.
9. Integration information¶
| Item | Value |
|---|---|
| Repo | PacketFive/cnuas |
| Source | bmc/firmware/orv3/, bmc/rmc/, bmc/renode/, bmc/meta-cnuas/ |
| Bridge source | tools/src/cnuas_tools/sledbmc/ |
| Emulators | Renode for the controllers, QEMU for the blade |
| Language | C for firmware and the controller, Python for the bridge |
| Related | Roadmap Epic 7 |
10. Revision history¶
| Revision | Notes |
|---|---|
| A | First publication. Machine definitions, protocols and build targets read from the platform files, makefiles and sources. |