Our contributions to Zephyr v3.5

Zephyr is an open source RTOS (real-time operating system) project that is being widely adopted for resource-constrained systems, from environmental sensors to smart watches and IoT wireless gateways. BayLibre is a member of the Zephyr Project and has been a core contributor since the project began.  We have ported Zephyr to the 64-bit ARM and 64-bit RISC-V architectures. Our engineers also maintain core parts of Zephyr.

Zephyr v3.5 was released last month:

Zephyr 3.5 introduces numerous enhancements to its various connectivity options to keep them aligned with latest developments in the various standards (Wi-Fi, Bluetooth, etc.), secure, and easier to maintain going forward. This will greatly simplify the lives of connected product developers.

What’s more, whether you’re looking at building IoT devices or not, several significant improvements were made to help build applications that are small, modular, and well tested (and if this sounds like a pretty generic statement to you, it’s because I want you to read further to see what I mean by that!).

• Created a timepoint API for events (typically expiration deadlines) tied to absolute time. This replaces open coded implementations that were prone to mistakes and sometimes lacked coherency and efficiency.
• Added 64-bits cycle reporting to the systick timer driver.
• Improved the ability to configure the whole timer subsystem out when unneeded in order to reduce the final binary size.

• Added support for the CLIC vectored mode on RISC-V
• Added support for the stack unwinding on ARM64 at run-time
• IPC service with the OpenAMP backend now takes into account the cache line size and alignment. This is done to align and pad structs in the cacheable shared memory so that invalidation operations can be performed safely.
• There is a pretty complex work ongoing about adding a new `zephyr,memory-attr` property to the memory nodes in the DT. This new property is used to describe properties and capabilities of the associated memory region. A library helper can use this information to do several different things. Currently the library is only used to configure the MPU region associated to the memory region but the idea is to extend that to be able to allocate memory heaps with different capabilities (cacheable, non-cacheable memory, etc…)

• Fixed an issue in the IPC service which occured when it could not find enough memory.