Date   

Cancelled Event: Zephyr: Power Management Sync - Thursday, November 11, 2021 #cal-cancelled

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

Cancelled: Zephyr: Power Management Sync

This event has been cancelled.

When:
Thursday, November 11, 2021
11:00am to 12:00pm
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams

Organizer: devel@...

Description:


________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,677440320# United States, Orlando
Phone Conference ID: 677 440 320#
 
________________________________________________________________________________


Event: Zephyr Project: Dev Meeting - 11/11/2021 #cal-reminder

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

Reminder: Zephyr Project: Dev Meeting

When:
11/11/2021
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:

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


Re: Dev-Review Meeting Agenda Nov 11th

Kumar Gala
 

(Correcting Subject to Nov 11th)

On Nov 10, 2021, at 12:18 PM, Kumar Gala via lists.zephyrproject.org <kumar.gala=linaro.org@...> wrote:

All,

Originally we planned on discussing sensors this week, but that will get pushed to next week (Nov 18th). I’ll be out this week and Carles will run the meeting.

Agenda for the week:

doc: replace breathe with Sphinx-Doxygen bridge
- https://github.com/zephyrproject-rtos/zephyr/pull/39702

soc: esp32: Support booting from MCUboot
- https://github.com/zephyrproject-rtos/zephyr/pull/37872

Plus anything anyone else has.

- k




Dev-Review Meeting Agenda Oct 14th

Kumar Gala
 

All,

Originally we planned on discussing sensors this week, but that will get pushed to next week (Nov 18th). I’ll be out this week and Carles will run the meeting.

Agenda for the week:

doc: replace breathe with Sphinx-Doxygen bridge
- https://github.com/zephyrproject-rtos/zephyr/pull/39702

soc: esp32: Support booting from MCUboot
- https://github.com/zephyrproject-rtos/zephyr/pull/37872

Plus anything anyone else has.

- k


Event: Zephyr Project: APIs - 11/09/2021 #cal-reminder

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

Reminder: Zephyr Project: APIs

When:
11/09/2021
9:00am to 10:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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
 
 
________________________________________________________________________________


Re: API meeting: agenda

Burdick, Thomas
 

Hi Carles,

I'd like to discuss the stats work I've done for i2c if possible, its on the API project in TODO

Thanks!

Tom

-----Original Message-----
From: devel@... <devel@...> On Behalf Of Carles Cufi via lists.zephyrproject.org
Sent: Tuesday, November 9, 2021 5:48 AM
To: devel@...
Cc: Bursztyka, Tomasz <tomasz.bursztyka@...>
Subject: [Zephyr-devel] API meeting: agenda

Hi all,

Agenda for today:

- SPI API updates
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39992

- PM structure optimization: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39286
- PR (option 4): https://github.com/zephyrproject-rtos/zephyr/pull/39397

- Road to pinctrl: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39740

If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40thread.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-5e334e88f6d8%22%7d

https://lists.zephyrproject.org/g/devel/calendar
https://github.com/zephyrproject-rtos/zephyr/projects/18

Minutes:
https://docs.google.com/document/d/1lv-8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


Re: API meeting: agenda

Carles Cufi
 

Hi all,

Another item for today:

- I2C stats
- PR: https://github.com/zephyrproject-rtos/zephyr/pull/39788

Thanks,

Carles

-----Original Message-----
From: Cufi, Carles
Sent: 09 November 2021 12:48
To: devel@...
Cc: Bursztyka, Tomasz <tomasz.bursztyka@...>
Subject: API meeting: agenda

Hi all,

Agenda for today:

- SPI API updates
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39992

- PM structure optimization: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39286
- PR (option 4): https://github.com/zephyrproject-rtos/zephyr/pull/39397

- Road to pinctrl: Update
- Issue: https://github.com/zephyrproject-rtos/zephyr/issues/39740

If you have additional items please let me know.

Teams link: https://teams.microsoft.com/l/meetup-
join/19%3ameeting_NWU2MjZlYWEtZDcwMi00MWQzLTgwMjEtNDdkYjQwMjBjMmFj%40threa
d.v2/0?context=%7b%22Tid%22%3a%22af0096d9-700c-411a-b795-
b3dd7122bad2%22%2c%22Oid%22%3a%22841a7c92-7816-4faf-9887-
5e334e88f6d8%22%7d

https://lists.zephyrproject.org/g/devel/calendar
https://github.com/zephyrproject-rtos/zephyr/projects/18

Minutes:
https://docs.google.com/document/d/1lv-
8B5QE2m4FjBcvfqAXFIgQfW5oz6306zJ7GIZIWCk/edit

Regards,

Carles


API meeting: agenda

Carles Cufi
 


Re: Issue with k_poll

Venkatesh Sukumaran
 


On Mon, Nov 8, 2021 at 11:27 PM Andy Ross <andrew.j.ross@...> wrote:
Can you submit that as a github bug?  I don't know that I see it, but if you're sure that it can happen it's something we need to fix.

Andy

From: Venkatesh Sukumaran <venkatesh.sukumaran@...>
Sent: Monday, November 8, 2021 9:39 AM
To: Ross, Andrew J <andrew.j.ross@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@... <devel@...>; Leung, Daniel <daniel.leung@...>
Subject: Re: [Zephyr-devel] Issue with k_poll
 
I understand that the number of wakeups is not equal to the number of events signalled but the problem here is that the pending thread can *miss* a signal. The "signalled" field is being reset to zero by the pending thread after servicing the signal handler and at that time, the same signal could be set again.

Thanks,
- Venkatesh.


On Mon, Nov 8, 2021 at 6:54 PM Andy Ross <andrew.j.ross@...> wrote:
That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


RISC-V: mtvec: Vectored Mode

William <wpatty24@...>
 


Hi all,

I would like to add support for "vectored mode" of the Machine Trap-Vector Base-Address Register (mtvec) to the RISC-V architecture — at the SOC level. Some SOCs have already implemented this directly. It makes sense to centralize this feature since it could be reused for all RISC-V SOCs. Additionally, centralizing the feature would allow RISC-V to support Zephyr’s ‘direct’ IRQ feature when vectored mode is used. Im interested to hear if others agree that this feature would be useful.

For background purposes, I’m working on a project that uses the lowRISC Ibex processor. This processor implements the RISC-V Privileged Architecture specification; however, it doesn’t support mtvec direct mode, only vectored mode.

Given that the vectored mode is in the RISC-V Privileged Architecture specification, it should be supported within the RISCV_PRIVILEGE SOC family. 

Here’s what I’m proposing:

  • Add ‘config RISCV_MTVEC_VECTORED_MODE to “soc/riscv/riscv-privilege/Kconfig’; default will be DIRECT_MODE which is how it is implemented currently
  • Add preprocessor conditions to handle both cases within “soc/riscv/riscv-privilege/common/vector.S”
  • Take advantage of CONFIG_GEN_IRQ_VECTOR_TABLE to generate the vector table to use for mtvec
  • For vectored mode, mtvec will be set to the address of the Zephyr generated IRQ Table (_irq_vector_table symbol)
  • Add a default implementation for _isr_wrapper that’s simply a jump to __irq_wrapper; RISC-V uses CONFIG_GEN_SW_ISR_TABLE.
  • [Future] Enable Zephyr’s ‘direct’ IRQ feature when VECTORED_MODE configuration is set. There are more specifics to discuss here but that can wait until if / when this feature is added. 

However, there is one aspect that’s more complicated:

  • Per the RISC-V Privileged Architecture specification, setting vectored mode may impose additional alignment constraints on the address stored in mtvec. This implies that each processor can have it’s own alignment constraints. If we want to take advantage of Zephyr’s CONFIG_GEN_IRQ_VECTOR_TABLE option, we would need to force correct alignment on _irq_vector_table symbol. We should decide on a “good default” but have a mechanism where alignment could be changed for a specific SOC series. It probably makes sense to enforce the alignment in the default RISC-V linker script. However, linker scripts are not my strong suit and I’m not confident on the approach for this aspect of the change. Any ideas would be welcomed.

I appreciate you taking the time to read this. I look forward to any discussion this proposal might create.

Thanks,
William


Re: Issue with k_poll

Andy Ross
 

Can you submit that as a github bug?  I don't know that I see it, but if you're sure that it can happen it's something we need to fix.

Andy


From: Venkatesh Sukumaran <venkatesh.sukumaran@...>
Sent: Monday, November 8, 2021 9:39 AM
To: Ross, Andrew J <andrew.j.ross@...>
Cc: Cufi, Carles <Carles.Cufi@...>; devel@... <devel@...>; Leung, Daniel <daniel.leung@...>
Subject: Re: [Zephyr-devel] Issue with k_poll
 
I understand that the number of wakeups is not equal to the number of events signalled but the problem here is that the pending thread can *miss* a signal. The "signalled" field is being reset to zero by the pending thread after servicing the signal handler and at that time, the same signal could be set again.

Thanks,
- Venkatesh.


On Mon, Nov 8, 2021 at 6:54 PM Andy Ross <andrew.j.ross@...> wrote:
That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Re: Issue with k_poll

Venkatesh Sukumaran
 

I understand that the number of wakeups is not equal to the number of events signalled but the problem here is that the pending thread can *miss* a signal. The "signalled" field is being reset to zero by the pending thread after servicing the signal handler and at that time, the same signal could be set again.

Thanks,
- Venkatesh.


On Mon, Nov 8, 2021 at 6:54 PM Andy Ross <andrew.j.ross@...> wrote:
That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy

From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Event: Zephyr Memory Footprint - biweekly discussion - 11/08/2021 #cal-reminder

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

Reminder: Zephyr Memory Footprint - biweekly discussion

When:
11/08/2021
8:00am to 9:00am
(UTC-08:00) America/Los Angeles

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:
Working doc: https://docs.google.com/document/d/1bnQLJKVhgI3zkk3MsSXun8onEsA8z1Rf5ohdbCHASmU/edit#heading=h.x36xe8bnwr9r

________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,546018126# United States, Orlando
Phone Conference ID: 546 018 126#
 
 
________________________________________________________________________________


Re: Issue with k_poll

Andy Ross
 

That's right:  k_poll() is level triggered, it's not a queue.  The number of wakeups is not guaranteed to be equal to the number of events signalled.  The idea is that you go to sleep waiting on any of a number of events/things to occur and are woken up when at least one of them does.  But then you need to do the accounting yourself to figure out who was signaled (and how many times) and what should happen.

In this particular use case it sounds like you should be polling on a semaphore and not a signal.  Semaphores do provide proper counting of how many give/take calls are made.

Andy


From: Cufi, Carles <Carles.Cufi@...>
Sent: Monday, November 8, 2021 1:12 AM
To: venkatesh.sukumaran@... <venkatesh.sukumaran@...>; devel@... <devel@...>; Ross, Andrew J <andrew.j.ross@...>; Leung, Daniel <daniel.leung@...>
Subject: RE: [Zephyr-devel] Issue with k_poll
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Re: Issue with k_poll

Carles Cufi
 

+ Andy, Daniel

 

From: devel@... <devel@...> On Behalf Of Venkatesh Sukumaran via lists.zephyrproject.org
Sent: 08 November 2021 08:08
To: devel@...
Subject: Re: [Zephyr-devel] Issue with k_poll

 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.


Thanks,

- Venkatesh.

 

 

On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:

Hi Zephyr developers,

 

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

 

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.

2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.

3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.

4) Destination thread goes back to k_poll to pend on events.

 

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

 

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?


Thanks,

- Venkatesh.


Re: Issue with k_poll

Venkatesh Sukumaran
 

Anyone familiar with k_poll architecture here? Let me know if you need any other info.

Thanks,
- Venkatesh.


On Wed, Oct 27, 2021 at 12:47 PM Venkatesh Sukumaran <venkatesh.sukumaran@...> wrote:
Hi Zephyr developers,

I was looking at the k_poll mechanism in Zephyr and found that it can potentially miss events from the producer in SMP when the following happens:

1) Set up a bunch of events with K_POLL_TYPE_SIGNAL and K_POLL_MODE_NOTIFY_ONLY.
2) A producer thread calls k_poll_signal_raise() to set the "signalled" field to 1 for event X in the list above.
3) The destination/consumer thread is already in the middle of processing of events and finds the same event X "raised" (from a previous signal_raise() call maybe), runs the handler for the event to completion and sets the "signalled" field to zero.
4) Destination thread goes back to k_poll to pend on events.

Now depending how 2) and 3) are ordered - step 3) could set "signalled" back to zero and lose the update from the producer thread in step 2).

Am I missing something here? Shouldn't we take a snapshot of the events/signals when exiting k_poll in the critical section and pass that to the destination thread? Once, a thread calls k_poll again then "OR" the pending events with events that the thread has not handled so far (if any)?

Thanks,
- Venkatesh.


Updated Event: Zephyr: Power Management Sync #cal-invite

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

Zephyr: Power Management Sync

When:
Thursday, November 11, 2021
11:00am to 12:00pm
(UTC-08:00) America/Los Angeles
Repeats: Weekly on Thursday

Where:
Microsoft Teams

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:


________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,677440320# United States, Orlando
Phone Conference ID: 677 440 320#
 
________________________________________________________________________________


Fix for mcumgr/smp over serial not adding CRC16 to packet length

Ermel, Dominik
 

Hello,

 

For a long time the Zephyr implementation of mcumgr/smp protocol over serial has not been adding length of CRC16 to the length of the packet,

although mcumgr-cli always did so. This bug has been present due to the information not being included into documentation, which has been

corrected here https://github.com/apache/mynewt-mcumgr/commit/9bd9d55d00bb70f93d85e52d7b016bbbb8c79942.

 

I have created Zephyr issue https://github.com/zephyrproject-rtos/zephyr/issues/39546 that describes the bug, and provided the fix here

https://github.com/zephyrproject-rtos/zephyr/pull/40127; because this fix may break something in software that is already there,

I am sending this e-mail to let you all know about that fix, so that you may voice your concerns under the issue or in the PR for the fix.

 

Best regards,

Dominik

Dominik ERMEL | Senior Software Engineer
Kraków, Poland
nordicsemi.com | devzone.nordicsemi.com

Nordic_logo_signature

 


Event: Zephyr: Power Management Sync - 11/04/2021 #cal-reminder

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

Reminder: Zephyr: Power Management Sync

When:
11/04/2021
6:00pm to 7:00pm
(UTC+00:00) UTC

Where:
Microsoft Teams

Organizer: devel@...

An RSVP is requested. Click here to RSVP

Description:


________________________________________________________________________________
Microsoft Teams meeting
Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 321-558-6518,,677440320# United States, Orlando
Phone Conference ID: 677 440 320#
 
________________________________________________________________________________


Updated Event: Zephyr Project: APIs #cal-invite

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

Zephyr Project: APIs

When:
Tuesday, November 9, 2021
9:00am to 10:00am
(UTC-08:00) America/Los Angeles
Repeats: Weekly on Tuesday

Where:
Microsoft Teams Meeting

Organizer: devel@...

An RSVP is requested. Click here to RSVP

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 8634