Date   

Zephyr Project: APIs - Tue, 02/16/2021 5:00pm-6:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 16 February 2021, 5:00pm to 6:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Zephyr 2.5.0 released, merge window is now open.

Nashif, Anas
 

Hi,

We are pleased to announce the release of Zephyr RTOS version 2.5.0!

 

Major enhancements with this release include:

  • Introduced support for the SPARC processor architecture and the LEON

processor implementation.

  • Added Thread Local Storage (TLS) support
  • Added support for per thread runtime statistics
  • Added support for building with LLVM on X86
  • Added new synchronization mechanisms using Condition Variables
  • Add support for demand paging on systems with MMU

 

 

The detailed release notes can be found here:

 

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

 

The next release, v2.6.0, is scheduled for May 28th, 2021. The merge window is now open.

 

Thank you to everyone that contributed features, documentation, testing, infrastructure, and bug fixes!

 

Regards,

Anas


Zephyr 2.5.0-rc4 tagged / Last Call for release notes

Nashif, Anas
 

Hi,

The fourth release candidate for Zephyr v2.5.0 has been tagged (v2.5.0-rc4). This is planned to be the last release candidate. Only blocker issues will be considered.

 

The merge window for features and enhancements remains closed until v2.5.0 is released.

 

This is the last call for release notes, in case you notice something missing, please let us know or submit a change to:

 

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/releases/release-notes-2.5.rst

  

More information about bugs counts and real-time tracking of bug counts can be found 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.

 

All changes since 2.5.0-rc3 can be found here:

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

 

More details about Zephyr releases can found on the pages below:

https://docs.zephyrproject.org/latest/development_process/release_process.html  

 

You may continue to send 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 v2.5.0 on time and in the best shape possible. If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

 

Thanks,

Anas

 

 


Re: Dev-Review Meeting Agenda Feb 11

Bolivar, Marti
 

Hi,

For anyone interested, minutes from today's meeting are here:

https://docs.google.com/document/d/15KUINNj7Re0GQiWYpqKvO5jgDw8oiQv3SGJfNHGaPOU/edit#heading=h.xuqvp7a5nn9s

Minutes for the dev-review meetings are available, but up until now,
that hasn't been widely advertised on the lists.

Unless I hear otherwise, I'll continue posting a note here when minutes
are up each week.

Thanks,
Martí


Zephyr Project: Dev Meeting - Thu, 02/11/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 11 February 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda Feb 11

Kumar Gala
 

Here’s the agenda topics for this week:

Remove usage of DT_INST in samples (Marti)
- https://github.com/zephyrproject-rtos/zephyr/issues/32139

devicetree-based device definitions and dependency representations reboot (Peter)
- https://github.com/zephyrproject-rtos/zephyr/pull/32127

device: refactor to aggregate common dynamic state for devices (Peter)
- https://github.com/zephyrproject-rtos/zephyr/pull/31880


https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


Zephyr Project: APIs - Tue, 02/09/2021 5:00pm-6:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: APIs

When: Tuesday, 9 February 2021, 5:00pm to 6:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


API meeting: agenda

Carles Cufi
 


Zephyr: Toolchain Working Group - Mon, 02/08/2021 #cal-notice

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Zephyr: Toolchain Working Group

When:
Monday, 8 February 2021
4:00pm to 5:00pm
(GMT+00:00) UTC

Where:
Microsoft Teams Meeting

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Zephyr: Toolchain Working Group - Mon, 02/08/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr: Toolchain Working Group

When: Monday, 8 February 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: Torsten Rasmussen

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 682 738 030#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 


Zephyr 2.5.0 RC3 tagged

Nashif, Anas
 

Hi,

The third release candidate for Zephyr v2.5.0 has been tagged (v2.5.0-rc3).

 

The merge window for features and enhancements remains closed until v2.5.0 is released. The next release milestone is code freeze. The final release remains scheduled for 12 Feb.

 

The focus now should be shifted to testing and documentation of the release. If you are a maintainer, please provide release notes for the areas you are responsible for and any other contributions you might have submitted since the last release. Everyone is encouraged to contribute to the release notes. The draft release notes file can be found here:

 

https://github.com/zephyrproject-rtos/zephyr/blob/master/doc/releases/release-notes-2.5.rst

 

During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master. 

Additional features or enhancements for the v2.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. Current bug counts are:

 

    High: 3 (Target: 0)

    Medium: 21 (Target: 20)

    Low: 94 (Target: 100)

 

More information about bugs counts and real-time tracking of bug counts can be found 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.

 

All changes since 2.5.0-rc2 can be found here:

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

 

More details about Zephyr releases can found on the pages below:

https://docs.zephyrproject.org/latest/development_process/release_process.html  

 

You may continue to send 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 v2.5.0 on time and in the best shape possible. If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

 

Thanks,

Anas

 


Zephyr Project: Dev Meeting - Thu, 02/04/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr Project: Dev Meeting

When: Thursday, 4 February 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: devel@...

Description:

________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 483 314 739#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Dev-Review Meeting Agenda Feb 4

Kumar Gala
 

Here’s the agenda topics for this week:

usb: mass storage: use inquiry parameters from Kconfig
- https://github.com/zephyrproject-rtos/zephyr/pull/31834

* Any PR/issues w/dev-review tag

https://github.com/zephyrproject-rtos/zephyr/labels/dev-review

* Any topics anyone else has.

- k


Re: Zero latency interrupt extension for ARMv6-M

Glaropoulos, Ioannis
 

Hi Fabio,

Thanks for your email. To the best of my knowledge, none is working on ZLI on Baseline Cortex-M. If you would like to move with this forward, the best way is to an RFC issue in the Zephyr main tree Github, to get feedback from the architecture maintainers/collaborators. Remember to copy the content in this email thread.

Some comments to your suggestion:

ZLI works OK on Mainline Cortex-M, essentially because we can guarantee the following priority level order:
       ZLI > Kernel > HW IRQs (+misc) > PendSV (Faults are always given highest configurable priority)
So ZLIs can preempt all HW IRQs, and can also preempt the Kernel (i.e. SVCs).

Now on Baseline (If I understand the proposal):
- PRIMASK won't be used at all for IRQ locking, if the ZLI feature is enabled.
- For ZLIs to preempt the kernel (thus, for ZLI to have the same functionality as in Mainline), SVCs need to be given a priority level lower than the ZLIs. That means, 1 out of 4 priority levels need to be reserved, which is something we were trying to avoid for some time.

There's also the performance of irq_lock and _unlock functions: the beauty of the current solution is that no memory-mapped register access is performed. This speeds up the execution, and requires only an ISB barrier. With NVIC, read-modify-write and ram-variable-storing we will need memory-mapped accesses in addition to data synchronization barriers, which might increase the overhead of locking and unlocking the IRQs. The problem will be harder on Armv8-m Baseline, which has support for much more than 32 IRQ lines.

Guess these are reasons why the software emulation of irq locking "up-to-a-priority-level" has not attracted much attention so far, but I'd be happy to see an actual discussion going on here, ideally in an RFC Github issue.

Best,
Ioannis


Zephyr 2.5.0-rc2 tagged

Nashif, Anas
 

Hi,

The second release candidate for Zephyr v2.5.0 has been tagged (v2.5.0-rc2).

 

The merge window for features and enhancements remains closed until v2.5.0 is released. The next release milestone is code freeze. The final release remains scheduled for 12 Feb.

 

During the stabilization period only bug-fix, documentation, and stabilization-related patches may be merged to master.

Additional features or enhancements for the v2.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. Current bug counts are:

 

    High: 1 (Target: 0)

    Medium: 25 (Target: 20)

    Low: 112 (Target: 100)

 

More information about bugs counts and real-time tracking of bug counts can be found 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.

 

All changes since 2.5.0-rc1 can be found here:

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

 

More details about Zephyr releases can found on the pages below:

https://docs.zephyrproject.org/latest/development_process/release_process.html  

 

You may continue to send 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 v2.5.0 on time and in the best shape possible. If you have a feature or enhancement you would like to submit to the TSC, please tag the Pull Request with the "TSC" label, make sure it is approved and passing CI, and attend the next TSC meeting.

 

Thanks,

Anas

 


Zephyr: Networking Forum - Tue, 02/02/2021 4:00pm-5:00pm, Please RSVP #cal-reminder

devel@lists.zephyrproject.org Calendar <devel@...>
 

Reminder: Zephyr: Networking Forum

When: Tuesday, 2 February 2021, 4:00pm to 5:00pm, (GMT+00:00) UTC

Where:Microsoft Teams Meeting

An RSVP is requested. Click here to RSVP

Organizer: tsc@...

Description:


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 458 216 365#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________


Re: Dual core configuration of peripheral from other core/DTS file (e.g. nRF5340)

lairdjm
 

Hi,
Does anyone have suggestions for how to configure a peripheral on a dual core chip from the main core so it can be used by the secondary core but in a way that the devices are synchronised in DTS files? The example I have is with the nRF5340, the main core has to configure which pins can be used by the second core, but in order to do that it needs to be made aware of what pins the secondary core is going to use. The secondary core might have pins for a peripheral defined in it’s DTS file but the main core doesn’t have runtime access to that DTS file so is not aware of it. The first idea that comes to mind but I’m not overly happy with the idea would be to have a fake peripheral for the main core and both cores would include a single DTS which defines the pins, the main core would at start-up be able to read the DTS details and configure the pins but wouldn’t enable any driver for it whilst the secondary core would be able to start and use it as required. Or maybe using the real peripheral for both but forcing the driver for the second to be disabled in the Kconfig might be another way.
I do not want to use an overlay file at all for this. This is something that should be enabled by default and remain synchronised by changes only being made to one file.
Maybe a simple example would help.

But why have the main core involved in the pin config at all? Seems like having the driver on the secondary core manage the pins that are needed would be easier. (Especially since on the nordic devices it seems like most of the pin config is done in the peripherals register).
The main core has to set which pins can be accessed/controlled by the secondary core, for example with the nRF5340 there is code which is included and runs on the main core to enable the UART pins to be used by the secondary core - DTS of the main board has no knowledge of it so in the reset .c file it is not getting the details from DTS, it's just using defines: https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/nrf5340dk_nrf5340/nrf5340_cpunet_reset.c
The main core does not get involved with what the secondary core does with them, it's only to setup which are routed to the primary core or the secondary core, all peripheral configuration for the secondary core is performed by that core.


Re: Dual core configuration of peripheral from other core/DTS file (e.g. nRF5340)

Kumar Gala
 

On Feb 2, 2021, at 4:17 AM, lairdjm <jamie.mccrae@lairdconnect.com> wrote:

Hi,
Does anyone have suggestions for how to configure a peripheral on a dual core chip from the main core so it can be used by the secondary core but in a way that the devices are synchronised in DTS files? The example I have is with the nRF5340, the main core has to configure which pins can be used by the second core, but in order to do that it needs to be made aware of what pins the secondary core is going to use. The secondary core might have pins for a peripheral defined in it’s DTS file but the main core doesn’t have runtime access to that DTS file so is not aware of it. The first idea that comes to mind but I’m not overly happy with the idea would be to have a fake peripheral for the main core and both cores would include a single DTS which defines the pins, the main core would at start-up be able to read the DTS details and configure the pins but wouldn’t enable any driver for it whilst the secondary core would be able to start and use it as required. Or maybe using the real peripheral for both but forcing the driver for the second to be disabled in the Kconfig might be another way.
I do not want to use an overlay file at all for this. This is something that should be enabled by default and remain synchronised by changes only being made to one file.
Maybe a simple example would help.

But why have the main core involved in the pin config at all? Seems like having the driver on the secondary core manage the pins that are needed would be easier. (Especially since on the nordic devices it seems like most of the pin config is done in the peripherals register).

- k


Cancelled Event: Zephyr Project: APIs - Tuesday, 2 February 2021 #cal-cancelled

devel@lists.zephyrproject.org Calendar <noreply@...>
 

Cancelled: Zephyr Project: APIs

This event has been cancelled.

When:
Tuesday, 2 February 2021
5:00pm to 6:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams Meeting

Organizer: devel@...

Description:

Meeting decisions/discussions in their respective PRs, tracked here: https://github.com/zephyrproject-rtos/zephyr/projects/18


________________________________________________________________________________
+1 321-558-6518 United States, Orlando (Toll)
Conference ID: 317 990 129#
Local numbers | Reset PIN | Learn more about Teams | Meeting options
 
 
________________________________________________________________________________

481 - 500 of 8050