Zephyr 4.4 released - wonder how soon until we migrate to it

Official Hardware UNO Family UNO Q
1

Zephyr RTOS 4.4 Now Available: WireGuard, Wi‑Fi Direct, OpenRISC, and More – Zephyr Project

Looks like there has been some playing with the 4.4 RC candidates

Branches · arduino/zephyr

2

Is Zephyr RTOS a free software or Arduino needs to buy it from Linux Foundation? Will it be automatically updated in the flash of MCU when there is an update offer at power session of the UNO Q?

3

Sorry in advance for the long answer...

All of the ArduinoCore-zephyr Arduino installs including the Uno-Q are built using Zephyr
as you can see in the Readme file:

ArduinoCore-zephyr/README.md at main · arduino/ArduinoCore-zephyr

Arduino has their own Fork of Zephyr:
arduino/zephyr: Fork of the Git Repository for the Zephyr Project

Which currently they are using a modified version of the Zephyr 4.2 release, which has some Arduino specific changes and are many commits behind, like:
This branch is

46 commits ahead of and 18369 commits behind zephyrproject-rtos/zephyr:main.

If you are curious, for each release they have a have a document file that shows all of the things that changed and what might impact current apps or boards)

So I understand it will take Arduino a bit of time to verify the 4.4 release and see which of their current mods to 4.2 need to be migrated into the 4.4 and what other things they may have to change.

I am also setup to build using the zephyr build system directly, including with some of my own test sketches that build for some of the Arduino boards, like the Q or Giga or Portenta H7. I need this in order to implement and test possible extensions or fixes to the underlying zephyr code base. And each time I sync up, something else has changes, that requires some time to modify my own sketches. For example a couple of days ago, I rebased some of my changes for a Pull Request to the latest stuff (4.4-rc3)and found I had to change things like:

  1. New release of Zephyr SDK - build requires minimum of version 1.0. 1.0.1 has been released.
  2. Some configuration options changed, like the name of the property to define how big the video buffer is (not video in this context think camera)
  3. DMA index - is now 1 biased instead of 0 biased...
    ...

Now sinking again about 400 changes since then, to play again with my PR to maybe allow the Video driver for the STM32 DCMI to run in snapshot mode (1 image) instead of always running in video mode.

Was testing it yesterday on Portenta H7 on GC2145 camera on Mid Carrier to ST7796 display, and other app that converts the image to BMP format and outputs over USB...

But that is sort of off topic for currently I don't have a setup for Q to hook up a camera...

4

Thank you for the post.

I know that Linux OS is an open source software; so, it is freely available. I am not sure about Zephyr RTOS if it is also an open source software and freely available.

5

AFAIK Zephyr is completely open source:

zephyrproject-rtos/zephyr: Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.

It is Apache 2
zephyr/LICENSE at main · zephyrproject-rtos/zephyr

Edit: I should mention, that I believe there are mechanisms for different boards or the like to be able to include things that are not Apache licensed and sort of download as blobs...
Binary Blobs — Zephyr Project Documentation

For example Arduino may not want everything as Apache 2.

6

Something to note is that "not Apache licensed" doesn't necessarily mean "not open source". The Apache License is only one of many open source licenses. The excellent documentation @KurtE linked focuses on the use case of components that have proprietary code. That is indeed a significant use case, but it is also possible to use binary blobs even for components that are open source. For example, here we see a proposal to use the feature for the ArduinoCore-API component of the Arduino core, even though that component is licensed under the open source GNU Lesser General Public License 2.1:

We do indeed have specific preferences for which open source licenses to use for a given project type. However, license type may also be determined by the existing licensing of the project content. Open source projects are often build on top of an existing project, and in this case the established license type is inherited from the parent project. I would guess that the LGPL license was inherited from Processing programming language, which was the model for the Wiring API, which was in turn the origin of the Arduino core API.

It is possible to change the licensing of a established project, but this can only be done with the permission of every copyright holder. For older projects, it may be a herculean task to determine the list of copyright holders, contact each of them, resolve any disagreements, and replace any IP for which permission can not be obtained.

7

Thanks @ptillisch,
Sorry I should have filled in a few more of those details. - I was trying to remember where that Issue/PR was created.