I recently completed the HIL on two different platforms for my Rust attempt at asymmetric multiprocessing, and now I'm here to share it with the community.

The crate embassy-stm32 doesn't officially support the STM32MP series, and embassy-imxrt doesn't involve the NXP i.MX series, let alone idiomatic inter-processor communication with a typed, asynchronous, and symmetric API design.

By wrapping the IPC into Transport, Doorbell, and Channel, I abstracted the IPC into two things: sending the data and receiving the data. It handles all serialization and deserialization, memory allocation, and cross-core signalling through a standard interface, successfully landed it on both the bare-metal side on Cortex-M, as well as the rich OS side on Cortex-A through UIO and mmap.

I successfully completed the initial hardware-in-the-loop test today on ST's STM32MP257F-DK and NXP's FRDM-IMX93, which carry STM32MP257FAK3 and MIMX9352CVVX SoCs inside, on Embassy-based hardware bring-up on remote cores (including basic PAC and HAL, Embassy time driver, defmt debug port over shared memory, etc.) and IPC pattern on both of the platforms. Half a year ago, someone said it must explode when I was calling for help, but today, it worked.

If you want to try it out, you can explore the GitHub page GitHub - consortium-rs/consortium: Rust-based framework for asymmetric multiprocessor like STM32MP or i.MX series. · GitHub.

Please note that the test OS is tailored to run UIO. I'll pack the Yocto-built, UIO-enabled system and the DTS file later, or you can also build it on your own according to my engineering logs in the Book. I'll also upload the HIL test video later on YouTube and the HIL log if required. Just add those fields in built-in assets like Linux cfg, let U-Boot redirect the UIO genirq, add some nodes to the DTS, and it may work.

If you have any technical review of this attempt, I'm here to listen and try to improve it.

1 post - 1 participant

Read full topic