Hi,

The first release candidate for Zephyr 2.5.0 has been tagged (v2.5.0-rc1).

The merge window for features and enhancements is now closed for this release, and it will remain closed until 2.5.0 is released; the stabilization period is now open. During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. Additional features or enhancements for the 2.5.0 release require approval by the TSC.

As we need to reduce bug counts for the release, you are all encouraged to submit PRs that close existing bug reports, and to help reviewing such PRs submitted by other contributors or maintainers. You can follow the bug numbers with the thresholds for each bug category here:

                https://testing.zephyrproject.org/issues/zephyrproject-rtos/zephyr/index.html

Testing Zephyr master branch during the stabilization period is also requested; please test the code base and file bug reports so they can be addressed before the release deadline. Everyone is encouraged, especially hardware vendors, to test on hardware available to them. Use twister to run tests from the Zephyr tree on the boards you have using the device testing features.

The full release log can be found here:

https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.5.0-rc1

We plan to release weekly candidates (2.5.0-rcx) leading to the final release (2.5.0) which is tentatively scheduled for 15 February.

You may continue to submit pull requests for new features in order to gather feedback early or collaborate with others, but the release team would like to encourage everyone to focus on bugfixes and documentation improvements to the largest extent possible, so that we can release 2.5.0 on time and in the best shape possible.

A big Thank You to everyone that contributed to this release so far, be it with code, reviews, documentation or any other type of contribution!

Anas

Hi Michael,

You can use the clone-depth attribute in projects, but there’s an ongoing effort for shallow cloning that we plan to revisit very soon:

https://github.com/zephyrproject-rtos/west/issues/319

Carles

Hi all,

I would like to extend the zero latency interrupt feature to processors with an ARMv6-M architecture such as ARM Cortex M0, M0+ and M1. Is somebody already working on such a feature extension or has some ideas concerning this?

In the following I present a rough concept, how I would implement it. I am open to suggestions.

Initial position

The concerning processors have two possibilities to disable exceptions with configurable priorities. First, the Priority Mask core register (PRIMASK), which prevents the activation of all exceptions with configurable priority. Secondly, the Interrupt Clear-Enable register (CLRENA) of the Nested Vector Interrupt Controller that can disable each of the 32 interrupts individually. The PRIMASK is currently used for the IRQ lock of these processors.

Suggested solution

To implement a zero latency interrupt on ARMv6-M architecture the locking function has to be complemented by an additional compiler directive (#ifdef). The locking of the interrupts first saves the value of the NVIC_ICER into a shadow register and then clears all interrupts except of the interrupts registered as zero latency interrupt. For the functions that access the NVIC_ICER and NVIC_ISER register, a guard has to be implemented. This guard shall update the shadow register instead of writing to the NVIC_ICER and NVIC_ISER register. To unlock the interrupts, this shadow register will be written to NVIC_ISER and enable the interrupts again.

Additional notes

The feature that the IRQ lock is thread specific should not be restricted, since the changes mainly happen in the arch_irq_lock function.

There have to be some rules to prevent an inconsistency with the IRQ priority. The zero latency IRQ has to be registered with the highest interrupt priority available. If multiple zero latency interrupts are registered, they have to be on the same priority. With multiple zero latency IRQ, the zero latency can only be guaranteed, if they are strictly sequential.

Regards,

Fabio Egg

Hi,

This is a reminder that the v2.5.0 merge window for new features closes this Friday, 22nd January. After that, only bug fixes and documentation will be merged until the final release is tagged, which is targeted for Friday, February 12th. Exceptions require TSC approval. New feature PRs may still be submitted while the merge window is closed, but please keep in mind that maintainers will have less time to review them during the release stabilization period.

Please add the v2.5.0 milestone to PRs that need to be included in the release, and do not wait until Friday, January 22nd to submit them.

https://github.com/zephyrproject-rtos/zephyr/wiki/Program-Management

https://github.com/zephyrproject-rtos/zephyr/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+milestone%3Av2.5.0

Please try to help fix bugs, test release candidates, and write release notes to minimize the time the merge window is closed so we can all quickly get back to adding fun new things to Zephyr! 

Thank you for your contributions!

Regards,

Anas Nashif

Hi,

Based on various discussions and decisions made last year we introduced the MAINTAINERS file which serves as main place for documenting areas of the Zephyr code base and the respective maintainers and collaborators of those areas.

The goal has been to identify all key areas and the maintainers of those areas and use robots (CI) to add reviewers and labels and add assignees for each pull request submitted to the Zephyr project to accelerate reviews and bring pull requests to a mergable state. Assignees in the context will be responsible for driving a pull request to a mergeable state. (for example, getting the required 2 approvals, helping contributors with the code changes, deal with stale reviews, etc.)

For more information, see https://docs.zephyrproject.org/latest/contribute/project_roles.html?highlight=maintainers#teams-and-supporting-activities

Some of you have noticed over the last week pull-requests being assigned to you by *zephyr-bot*. This was a first attempt to deal with all open pull-requests and set the right assignee and add reviewers based on the data in the MAINTAINERS file. This activity was done manually using a script.

The plan is to integrate this as a Github action and set assignee and add reviewers for new pull requests, something that will happen by the end of this week.

Please help us improve this process and the data in the MAINTAINERS file:

• Review the PRs that were assigned to you and let us know if you think something was incorrectly assigned to you.
• Review the MAINTAINERS file and examine the areas you are responsible for and add any missing paths
• Review PRs where you were added as reviewers and report any issues

We are already aware of some issues with adding reviewers where already existing reviewer were added or removed by mistake. This was fixed already in the script.

The baseline for the assignments was this PR https://github.com/zephyrproject-rtos/zephyr/pull/31101. This PR already has some significant changes, and it should be merged soon.

Use slack or reply to this email if you have any questions or concerns.

Regards,

Anas Nashif