Hello Richard,
Thanks for your interest and instant replies. Please note I have just pushed the MQTT-Agent demo today. I’ll give a bit more context/details on our work.
We have extended FreeRTOS/RISC-V port to work with our CHERI architecture [1]. This gives us complete spatial memory safety with negligible performance overheads. There’s WIP on providing SW compartmentalization based on that.
For this specific topic, I thought I’d contribute back the vanilla RISC-V libraries (i.e., no CHERI, unless there will be an interest for it in the future).
For the vanilla RISC-V port offered by FreeRTOS, there are almost no changes in the kernel itself. There are, however, a few added libraries (that I placed in FreeRTOS-Labs) to include a portable VirtIO library among others. This library provides networking and block devices support. I added drivers to both FreeRTOS-Plus-TCP and FreeRTOS-Plus-FAT to make use of this library. Such libraries/drivers are independent of a specific demo and can be shared.
The other part is a new RISC-V Demo directory. That directory [2] holds BSPs and a few drivers (interrupt controller, HTIF, UART, syscalls, etc) plus the apps it can run. The design of this Demo aims to be generic enough to build for different variants of RISC-V platforms (QEMU, Spike, FPGAs, etc), different apps (blinky, CLI, FTP, OTA, etc), different toolchains (GCC, LLVM), w/o CHERI support, w/o compartmentalization support, among other command-line options. It uses a build system called waf.
That makes the project structure a bit different from the one you use in the Lab-Project-coreMQTT-Agent [3]; I re-use the existing released libraries in the classical FreeRTOS/ distribution (being the top directory) and I don’t create separate repos/submodules under coreMQTT-Agent.
Back to where things should go. The libraries should be generic enough not to be part of a specific demo. For example, the VirtIO library may go under FreeRTOS-Labs (like FAT), or FreeRTOS-Plus/ThirdParty for instance. The NetworkInterface.c for that needs to be merged with FreeRTOS-Plus-TCP and similarly the ff_virtioblk_disk.c in FreeRTOS-Plus-FAT.
Regarding the changes I made to the coreMQTT Agent demo itself, I basically just added a new ota-pal [4] that uses FreeRTOS-FAT instead of Windows. That’s the relevant part that can be upstreamed (as new files).
[1] https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
[2] https://github.com/CTSRD-CHERI/FreeRTOS-Demos-CHERI-RISC-V
[3] https://github.com/FreeRTOS/Lab-Project-coreMQTT-Agent
[4] https://github.com/CTSRD-CHERI/Lab-Project-coreMQTT-Agent/commit/b2d705d4cdfbbdcbdfba8a29198b14d3f5629320