Re: Make nxboot img_header public?

[Tim Hardisty]

Thanks for the input everyone. Discussion was very useful and here 
 is the PR that 
followed, and did not result in the exposure of the nxboot struct to the 
kernel


On 05/05/2025 18:53, Alin Jerpelea wrote:

On Tue, Apr 29, 2025 at 7:49 PM Tim Hardisty
wrote:


I am adding enhancements to my custom image booting software (that
copies the image from flash to internal SDRAM).

As part of that I would like, via PR, to expose /struct
nxboot_img_header/ and it's associated /struct nxboot_hdr_version/ and
/struct nxboot_img_version/ via a public header file
(apps/include/nxboot/nxboot.h).

It will allow me to get the actual image size for copying rather than
the entire "slot" size, as well as to be able to extract the image
version information for use by my app.

Can anyone see any problems with this?

Re: sched lock/unlock issue on rp2350

[Alan C. Assis]

WOW! Nice catch!

Question to some people with more experience in the scheduler:

Why wasn't this issue detected before? It was added more than 9 months ago.

Is there some way to test and enforce that nxsched_process_delivered() and
other schedule functions are working as expected?

BR,

Alan

On Tue, May 6, 2025 at 11:14 AM Serg Podtynnyi 
wrote:

> Hi, I am still researching the sched problem on my config
>
> Found this macro code  from last September,  looks like pre vs prev
> typo, right?
>
> #definedq_insert_mid(pre,mid,next)\
> do\
> {\
> mid->flink =next;\
> mid->blink =prev;\
> pre->flink =mid;\
> next->blink =mid;\
> }\
> while(0)
>
>
>
> On 4/24/25 15:06, hujun260 wrote:
> > The lockcount can be understood as a local variable, so no race
> conditions will occur.
> > 编辑
> > 分享
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > At 2025-04-24 15:54:48, "Serg Podtynnyi"
> wrote:
> >> Hi, I tried my best to understand the logic behind unlock and
> >> merge_pending routines and come up with this fix that works for me.
> >> I split the lockcount handling in 2 parts when lockcount is > 1 just
> >> decrement fast as always,
> >> but when it's 1 we enter critical section and make it 0 inside
> >> it(pre-emption is enabled).
> >> I think there is a small time after decrement in the if statement and
> >>   enter_critical_section_wo_note() in original code where can race
> happen.
> >> Does this make sense? Sorry if it's a dumb question - scheduler stuff
> >> with SMP is rocket-science level for me yet.
> >>
> >> diff --git a/sched/sched/sched_unlock.c b/sched/sched/sched_unlock.c
> >>
> >> index 4c7d681454..15fc39b546 100644
> >> --- a/sched/sched/sched_unlock.c
> >> +++ b/sched/sched/sched_unlock.c
> >> @@ -65,13 +65,14 @@ void sched_unlock(void)
> >>
> >> DEBUGASSERT(rtcb == NULL || rtcb->lockcount > 0);
> >>
> >> -  /* Check if the lock counter has decremented to zero. If so,
> >> -   * then pre-emption has been re-enabled.
> >> -   */
> >> -
> >> -  if (rtcb != NULL && --rtcb->lockcount == 0)
> >> +  if (rtcb != NULL && rtcb->lockcount > 1)
> >> +{
> >> +  rtcb->lockcount--;
> >> +}
> >> +  else if (rtcb != NULL && rtcb->lockcount == 1)
> >>   {
> >> irqstate_t flags = enter_critical_section_wo_note();
> >> +  rtcb->lockcount  = 0;
> >>
> >> /* Note that we no longer have pre-emption disabled. */
> >>
> >> --
> >> 2.49.0
> >> On 4/22/25 14:32, hujun260 wrote:
> >>
> >> It seems to have nothing to do with the race condition, and since the
> rtcb is this_task, it will only be modified by one CPU.As for why
> your modification can solve the problem, I haven't figured it out yet. Can
> you further analyze the reasons for the failure to boot?
> >> At 2025-04-22 13:25:13, "Serg Podtynnyi"
> wrote:
> >>
> >>> Hi All, Gregory, Sebastien,
> >>>
> >>> I'm porting NuttX on rp2350(pico2 board inside ClockWork PicoCalc) and
> >>> having trouble getting SMP (2-core) config running
> >>>
> >>> without patching the sched lock/unlock routines.
> >>>
> >>> I am looking at the commit
> >>>
> https://github.com/apache/nuttx/commit/914ae532e68bf4ca75c758d6f541a1d2fcdce8c3
> >>> and reverting it helps to boot the system.
> >>>
> >>> This the the patch to make it work for me, I updated the current
> >>> lock/unlock by moving the enter_critical_section above the access to
> >>> rtcb->lockcount
> >>>
> >>> Do you think it could be the case of a race condition with
> rtcb->lockcount ?
> >>>
> >>> PS
> >>>
> >>> It's almost 11 years since I last touched NuttX - it's a please to work
> >>> with it again.
> >>>
> >>>
> >>>   From 86fa0a65fdd37804154faf3db52e2826281cdfbd Mon Sep 17 00:00:00
> 2001
> >>> From: Serg Podtynnyi
> >>> Date: Tue, 22 Apr 2025 11:37:48 +0700
> >>> Subject: sched: update lock/unlock critical section entry
> >>>
> >>> Level up enter_critical_section in sched lock/unlock to cover
> >>> rtcb->lockcount access
> >>>
> >>> Signed-off-by: Serg Podtynnyi
> >>> ---
> >>>sched/sched/sched_lock.c   | 4 ++--
> >>>sched/sched/sched_unlock.c | 4 ++--
> >>>2 files changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/sched/sched/sched_lock.c b/sched/sched/sched_lock.c
> >>> index d8f75e7c90..9cc8da3df4 100644
> >>> --- a/sched/sched/sched_lock.c
> >>> +++ b/sched/sched/sched_lock.c
> >>> @@ -82,18 +82,18 @@ void sched_lock(void)
> >>>   * operations on this thread (on any CPU)
> >>>   */
> >>>
> >>> +  irqstate_t flags = enter_critical_section_wo_note();
> >>>  if (rtcb != NULL && rtcb->lockcount++ == 0)
> >>>{
> >>>#if (CONFIG_SCHED_CRITMONITOR_MAXTIME_PREEMPTION >= 0) || \
> >>>defined(CONFIG_SCHED_INSTRUMENTATION_PREEMPTION)
> >>> -  irqstate_t flags = enter_critical_section_wo_note();
> >>>
> >>>  /* Note that we have pre-emption locked */
> >>>
> >>>  nxsched_critmon_preemption(rtcb, true, return

Re: sched lock/unlock issue on rp2350

[Alan C. Assis]

Hi Serg,

I did an analysis here and this macro was introduced in Jan 10 2024, so it
was more than 1 year ago:

https://github.com/apache/nuttx/commit/9de9f8168d6de8eab8d3a97aac21aacc4e84dd84

BR,

Alan

On Tue, May 6, 2025 at 1:12 PM Alan C. Assis  wrote:

> WOW! Nice catch!
>
> Question to some people with more experience in the scheduler:
>
> Why wasn't this issue detected before? It was added more than 9 months ago.
>
> Is there some way to test and enforce that nxsched_process_delivered() and
> other schedule functions are working as expected?
>
> BR,
>
> Alan
>
> On Tue, May 6, 2025 at 11:14 AM Serg Podtynnyi 
> wrote:
>
>> Hi, I am still researching the sched problem on my config
>>
>> Found this macro code  from last September,  looks like pre vs prev
>> typo, right?
>>
>> #definedq_insert_mid(pre,mid,next)\
>> do\
>> {\
>> mid->flink =next;\
>> mid->blink =prev;\
>> pre->flink =mid;\
>> next->blink =mid;\
>> }\
>> while(0)
>>
>>
>>
>> On 4/24/25 15:06, hujun260 wrote:
>> > The lockcount can be understood as a local variable, so no race
>> conditions will occur.
>> > 编辑
>> > 分享
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > At 2025-04-24 15:54:48, "Serg Podtynnyi"
>> wrote:
>> >> Hi, I tried my best to understand the logic behind unlock and
>> >> merge_pending routines and come up with this fix that works for me.
>> >> I split the lockcount handling in 2 parts when lockcount is > 1 just
>> >> decrement fast as always,
>> >> but when it's 1 we enter critical section and make it 0 inside
>> >> it(pre-emption is enabled).
>> >> I think there is a small time after decrement in the if statement and
>> >>   enter_critical_section_wo_note() in original code where can race
>> happen.
>> >> Does this make sense? Sorry if it's a dumb question - scheduler stuff
>> >> with SMP is rocket-science level for me yet.
>> >>
>> >> diff --git a/sched/sched/sched_unlock.c b/sched/sched/sched_unlock.c
>> >>
>> >> index 4c7d681454..15fc39b546 100644
>> >> --- a/sched/sched/sched_unlock.c
>> >> +++ b/sched/sched/sched_unlock.c
>> >> @@ -65,13 +65,14 @@ void sched_unlock(void)
>> >>
>> >> DEBUGASSERT(rtcb == NULL || rtcb->lockcount > 0);
>> >>
>> >> -  /* Check if the lock counter has decremented to zero. If so,
>> >> -   * then pre-emption has been re-enabled.
>> >> -   */
>> >> -
>> >> -  if (rtcb != NULL && --rtcb->lockcount == 0)
>> >> +  if (rtcb != NULL && rtcb->lockcount > 1)
>> >> +{
>> >> +  rtcb->lockcount--;
>> >> +}
>> >> +  else if (rtcb != NULL && rtcb->lockcount == 1)
>> >>   {
>> >> irqstate_t flags = enter_critical_section_wo_note();
>> >> +  rtcb->lockcount  = 0;
>> >>
>> >> /* Note that we no longer have pre-emption disabled. */
>> >>
>> >> --
>> >> 2.49.0
>> >> On 4/22/25 14:32, hujun260 wrote:
>> >>
>> >> It seems to have nothing to do with the race condition, and since the
>> rtcb is this_task, it will only be modified by one CPU.As for why
>> your modification can solve the problem, I haven't figured it out yet. Can
>> you further analyze the reasons for the failure to boot?
>> >> At 2025-04-22 13:25:13, "Serg Podtynnyi"
>> wrote:
>> >>
>> >>> Hi All, Gregory, Sebastien,
>> >>>
>> >>> I'm porting NuttX on rp2350(pico2 board inside ClockWork PicoCalc) and
>> >>> having trouble getting SMP (2-core) config running
>> >>>
>> >>> without patching the sched lock/unlock routines.
>> >>>
>> >>> I am looking at the commit
>> >>>
>> https://github.com/apache/nuttx/commit/914ae532e68bf4ca75c758d6f541a1d2fcdce8c3
>> >>> and reverting it helps to boot the system.
>> >>>
>> >>> This the the patch to make it work for me, I updated the current
>> >>> lock/unlock by moving the enter_critical_section above the access to
>> >>> rtcb->lockcount
>> >>>
>> >>> Do you think it could be the case of a race condition with
>> rtcb->lockcount ?
>> >>>
>> >>> PS
>> >>>
>> >>> It's almost 11 years since I last touched NuttX - it's a please to
>> work
>> >>> with it again.
>> >>>
>> >>>
>> >>>   From 86fa0a65fdd37804154faf3db52e2826281cdfbd Mon Sep 17 00:00:00
>> 2001
>> >>> From: Serg Podtynnyi
>> >>> Date: Tue, 22 Apr 2025 11:37:48 +0700
>> >>> Subject: sched: update lock/unlock critical section entry
>> >>>
>> >>> Level up enter_critical_section in sched lock/unlock to cover
>> >>> rtcb->lockcount access
>> >>>
>> >>> Signed-off-by: Serg Podtynnyi
>> >>> ---
>> >>>sched/sched/sched_lock.c   | 4 ++--
>> >>>sched/sched/sched_unlock.c | 4 ++--
>> >>>2 files changed, 4 insertions(+), 4 deletions(-)
>> >>>
>> >>> diff --git a/sched/sched/sched_lock.c b/sched/sched/sched_lock.c
>> >>> index d8f75e7c90..9cc8da3df4 100644
>> >>> --- a/sched/sched/sched_lock.c
>> >>> +++ b/sched/sched/sched_lock.c
>> >>> @@ -82,18 +82,18 @@ void sched_lock(void)
>> >>>   * operations on this thread (on any CPU)
>> >>>   */
>> >>>
>> >>> +  irqstate_t flags = enter_critical_section_wo_n

Re: sched lock/unlock issue on rp2350

[Alan C. Assis]

This file:
https://github.com/apache/nuttx/commit/9de9f8168d6de8eab8d3a97aac21aacc4e84dd84#diff-ac1d3cade3d9ab380d40fe31f8c006b3035c7b53d04c28e23d9f1ce9a176572c

On Tue, May 6, 2025 at 1:18 PM Alan C. Assis  wrote:

> Hi Serg,
>
> I did an analysis here and this macro was introduced in Jan 10 2024, so it
> was more than 1 year ago:
>
>
> https://github.com/apache/nuttx/commit/9de9f8168d6de8eab8d3a97aac21aacc4e84dd84
>
> BR,
>
> Alan
>
> On Tue, May 6, 2025 at 1:12 PM Alan C. Assis  wrote:
>
>> WOW! Nice catch!
>>
>> Question to some people with more experience in the scheduler:
>>
>> Why wasn't this issue detected before? It was added more than 9 months
>> ago.
>>
>> Is there some way to test and enforce that nxsched_process_delivered()
>> and other schedule functions are working as expected?
>>
>> BR,
>>
>> Alan
>>
>> On Tue, May 6, 2025 at 11:14 AM Serg Podtynnyi 
>> wrote:
>>
>>> Hi, I am still researching the sched problem on my config
>>>
>>> Found this macro code  from last September,  looks like pre vs prev
>>> typo, right?
>>>
>>> #definedq_insert_mid(pre,mid,next)\
>>> do\
>>> {\
>>> mid->flink =next;\
>>> mid->blink =prev;\
>>> pre->flink =mid;\
>>> next->blink =mid;\
>>> }\
>>> while(0)
>>>
>>>
>>>
>>> On 4/24/25 15:06, hujun260 wrote:
>>> > The lockcount can be understood as a local variable, so no race
>>> conditions will occur.
>>> > 编辑
>>> > 分享
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > At 2025-04-24 15:54:48, "Serg Podtynnyi"
>>> wrote:
>>> >> Hi, I tried my best to understand the logic behind unlock and
>>> >> merge_pending routines and come up with this fix that works for me.
>>> >> I split the lockcount handling in 2 parts when lockcount is > 1 just
>>> >> decrement fast as always,
>>> >> but when it's 1 we enter critical section and make it 0 inside
>>> >> it(pre-emption is enabled).
>>> >> I think there is a small time after decrement in the if statement and
>>> >>   enter_critical_section_wo_note() in original code where can race
>>> happen.
>>> >> Does this make sense? Sorry if it's a dumb question - scheduler stuff
>>> >> with SMP is rocket-science level for me yet.
>>> >>
>>> >> diff --git a/sched/sched/sched_unlock.c b/sched/sched/sched_unlock.c
>>> >>
>>> >> index 4c7d681454..15fc39b546 100644
>>> >> --- a/sched/sched/sched_unlock.c
>>> >> +++ b/sched/sched/sched_unlock.c
>>> >> @@ -65,13 +65,14 @@ void sched_unlock(void)
>>> >>
>>> >> DEBUGASSERT(rtcb == NULL || rtcb->lockcount > 0);
>>> >>
>>> >> -  /* Check if the lock counter has decremented to zero. If so,
>>> >> -   * then pre-emption has been re-enabled.
>>> >> -   */
>>> >> -
>>> >> -  if (rtcb != NULL && --rtcb->lockcount == 0)
>>> >> +  if (rtcb != NULL && rtcb->lockcount > 1)
>>> >> +{
>>> >> +  rtcb->lockcount--;
>>> >> +}
>>> >> +  else if (rtcb != NULL && rtcb->lockcount == 1)
>>> >>   {
>>> >> irqstate_t flags = enter_critical_section_wo_note();
>>> >> +  rtcb->lockcount  = 0;
>>> >>
>>> >> /* Note that we no longer have pre-emption disabled. */
>>> >>
>>> >> --
>>> >> 2.49.0
>>> >> On 4/22/25 14:32, hujun260 wrote:
>>> >>
>>> >> It seems to have nothing to do with the race condition, and since the
>>> rtcb is this_task, it will only be modified by one CPU.As for why
>>> your modification can solve the problem, I haven't figured it out yet. Can
>>> you further analyze the reasons for the failure to boot?
>>> >> At 2025-04-22 13:25:13, "Serg Podtynnyi"
>>> wrote:
>>> >>
>>> >>> Hi All, Gregory, Sebastien,
>>> >>>
>>> >>> I'm porting NuttX on rp2350(pico2 board inside ClockWork PicoCalc)
>>> and
>>> >>> having trouble getting SMP (2-core) config running
>>> >>>
>>> >>> without patching the sched lock/unlock routines.
>>> >>>
>>> >>> I am looking at the commit
>>> >>>
>>> https://github.com/apache/nuttx/commit/914ae532e68bf4ca75c758d6f541a1d2fcdce8c3
>>> >>> and reverting it helps to boot the system.
>>> >>>
>>> >>> This the the patch to make it work for me, I updated the current
>>> >>> lock/unlock by moving the enter_critical_section above the access to
>>> >>> rtcb->lockcount
>>> >>>
>>> >>> Do you think it could be the case of a race condition with
>>> rtcb->lockcount ?
>>> >>>
>>> >>> PS
>>> >>>
>>> >>> It's almost 11 years since I last touched NuttX - it's a please to
>>> work
>>> >>> with it again.
>>> >>>
>>> >>>
>>> >>>   From 86fa0a65fdd37804154faf3db52e2826281cdfbd Mon Sep 17 00:00:00
>>> 2001
>>> >>> From: Serg Podtynnyi
>>> >>> Date: Tue, 22 Apr 2025 11:37:48 +0700
>>> >>> Subject: sched: update lock/unlock critical section entry
>>> >>>
>>> >>> Level up enter_critical_section in sched lock/unlock to cover
>>> >>> rtcb->lockcount access
>>> >>>
>>> >>> Signed-off-by: Serg Podtynnyi
>>> >>> ---
>>> >>>sched/sched/sched_lock.c   | 4 ++--
>>> >>>sched/sched/sched_unlock.c | 4 ++--
>>> >>>2 files changed, 4 insertions(+), 4 deletions(-)
>>

Re: sched lock/unlock issue on rp2350

[Serg Podtynnyi]

Hi, I am still researching the sched problem on my config

Found this macro code  from last September,  looks like pre vs prev  
typo, right?


#definedq_insert_mid(pre,mid,next)\
do\
{\
mid->flink =next;\
mid->blink =prev;\
pre->flink =mid;\
next->blink =mid;\
}\
while(0)



On 4/24/25 15:06, hujun260 wrote:

The lockcount can be understood as a local variable, so no race conditions will 
occur.
编辑
分享

















At 2025-04-24 15:54:48, "Serg Podtynnyi" wrote:

Hi, I tried my best to understand the logic behind unlock and
merge_pending routines and come up with this fix that works for me.
I split the lockcount handling in 2 parts when lockcount is > 1 just
decrement fast as always,
but when it's 1 we enter critical section and make it 0 inside
it(pre-emption is enabled).
I think there is a small time after decrement in the if statement and
  enter_critical_section_wo_note() in original code where can race happen.
Does this make sense? Sorry if it's a dumb question - scheduler stuff
with SMP is rocket-science level for me yet.

diff --git a/sched/sched/sched_unlock.c b/sched/sched/sched_unlock.c

index 4c7d681454..15fc39b546 100644
--- a/sched/sched/sched_unlock.c
+++ b/sched/sched/sched_unlock.c
@@ -65,13 +65,14 @@ void sched_unlock(void)

DEBUGASSERT(rtcb == NULL || rtcb->lockcount > 0);

-  /* Check if the lock counter has decremented to zero. If so,
-   * then pre-emption has been re-enabled.
-   */
-
-  if (rtcb != NULL && --rtcb->lockcount == 0)
+  if (rtcb != NULL && rtcb->lockcount > 1)
+{
+  rtcb->lockcount--;
+}
+  else if (rtcb != NULL && rtcb->lockcount == 1)
  {
irqstate_t flags = enter_critical_section_wo_note();
+  rtcb->lockcount  = 0;

/* Note that we no longer have pre-emption disabled. */

--
2.49.0
On 4/22/25 14:32, hujun260 wrote:

It seems to have nothing to do with the race condition, and since the rtcb is this_task, it 
will only be modified by one CPU.As for why your modification can 
solve the problem, I haven't figured it out yet. Can you further analyze the reasons for 
the failure to boot?
At 2025-04-22 13:25:13, "Serg Podtynnyi" wrote:


Hi All, Gregory, Sebastien,

I'm porting NuttX on rp2350(pico2 board inside ClockWork PicoCalc) and
having trouble getting SMP (2-core) config running

without patching the sched lock/unlock routines.

I am looking at the commit
https://github.com/apache/nuttx/commit/914ae532e68bf4ca75c758d6f541a1d2fcdce8c3
and reverting it helps to boot the system.

This the the patch to make it work for me, I updated the current
lock/unlock by moving the enter_critical_section above the access to
rtcb->lockcount

Do you think it could be the case of a race condition with rtcb->lockcount ?

PS

It's almost 11 years since I last touched NuttX - it's a please to work
with it again.


  From 86fa0a65fdd37804154faf3db52e2826281cdfbd Mon Sep 17 00:00:00 2001
From: Serg Podtynnyi
Date: Tue, 22 Apr 2025 11:37:48 +0700
Subject: sched: update lock/unlock critical section entry

Level up enter_critical_section in sched lock/unlock to cover
rtcb->lockcount access

Signed-off-by: Serg Podtynnyi
---
   sched/sched/sched_lock.c   | 4 ++--
   sched/sched/sched_unlock.c | 4 ++--
   2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sched/sched/sched_lock.c b/sched/sched/sched_lock.c
index d8f75e7c90..9cc8da3df4 100644
--- a/sched/sched/sched_lock.c
+++ b/sched/sched/sched_lock.c
@@ -82,18 +82,18 @@ void sched_lock(void)
  * operations on this thread (on any CPU)
  */

+  irqstate_t flags = enter_critical_section_wo_note();
 if (rtcb != NULL && rtcb->lockcount++ == 0)
   {
   #if (CONFIG_SCHED_CRITMONITOR_MAXTIME_PREEMPTION >= 0) || \
   defined(CONFIG_SCHED_INSTRUMENTATION_PREEMPTION)
-  irqstate_t flags = enter_critical_section_wo_note();

 /* Note that we have pre-emption locked */

 nxsched_critmon_preemption(rtcb, true, return_address(0));
 sched_note_preemption(rtcb, true);
-  leave_critical_section_wo_note(flags);
   #endif
   }
+  leave_critical_section_wo_note(flags);
   }
   }
diff --git a/sched/sched/sched_unlock.c b/sched/sched/sched_unlock.c
index 4c7d681454..d21e007587 100644
--- a/sched/sched/sched_unlock.c
+++ b/sched/sched/sched_unlock.c
@@ -69,9 +69,9 @@ void sched_unlock(void)
  * then pre-emption has been re-enabled.
  */

+  irqstate_t flags = enter_critical_section_wo_note();
 if (rtcb != NULL && --rtcb->lockcount == 0)
   {
-  irqstate_t flags = enter_critical_section_wo_note();

 /* Note that we no longer have pre-emption disabled. */

@@ -162,7 +162,7 @@ void sched_unlock(void)
   }
   #endif

-  leave_critical_section_wo_note(flags);
   }
+  leave_critical_section_wo_note(flags);
   }
   }
--
2.49.0


--
Serg Podtynnyi


-- Serg Podtynnyi


-

GitHub NuttX master branch protections

[Tomek CEDRO]

Hello world :-)

I found a free moment to setup github master branch protections as
discussed before, for now PR is in Draft mode for careful review. Who
can we contact from Apache Admins to ask to verification?

https://github.com/apache/nuttx/pull/16324

* We do not have "Settings" tab in the Apache's owned repository, thus
we need to update .asf.yaml file with repository settings.
* No direct push to master branch is possible.
* Require status checks to pass before merge.
* Setup reviews parameters.
* Require signatures.
* Require conversation resolution.
* Not sure if we want to enforce "linear history"?
* If all is fine here I will do the same update for nuttx-apps repo :-)
* I am not really familiar with all these settings, please review if
this is what we want/need.
* Particularly the "checks" needs verification if these are valid
names (@lupyuen?).

Reference: https://github.com/apache/infrastructure-asfyaml.

Thank you :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: GitHub NuttX master branch protections

[Nathan Hartman]

Hello Tomek :-)

Thanks for doing that!

I have found that the easiest/quickest way to talk to the Infra folks is by
Slack [1].

If you don't want to use Slack, you can write to Infra's users list (also
see [1]).

I recommend to try slack, but either way, give them the link to the PR and
ask nicely if they could verify it...

[1] To contact Infra by Slack, see the section "Chat" at
https://infra.apache.org/contact.html

Hope that helps,
Nathan

On Tue, May 6, 2025 at 9:21 AM Tomek CEDRO  wrote:

> Hello world :-)
>
> I found a free moment to setup github master branch protections as
> discussed before, for now PR is in Draft mode for careful review. Who
> can we contact from Apache Admins to ask to verification?
>
> https://github.com/apache/nuttx/pull/16324
>
> * We do not have "Settings" tab in the Apache's owned repository, thus
> we need to update .asf.yaml file with repository settings.
> * No direct push to master branch is possible.
> * Require status checks to pass before merge.
> * Setup reviews parameters.
> * Require signatures.
> * Require conversation resolution.
> * Not sure if we want to enforce "linear history"?
> * If all is fine here I will do the same update for nuttx-apps repo :-)
> * I am not really familiar with all these settings, please review if
> this is what we want/need.
> * Particularly the "checks" needs verification if these are valid
> names (@lupyuen?).
>
> Reference: https://github.com/apache/infrastructure-asfyaml.
>
> Thank you :-)
> Tomek
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: RFC - AVR fixes and support for AVR DA/DB family

[Tomek CEDRO]

Alan just posted the PR with your AVR updates :-)

https://github.com/apache/nuttx/pull/16323

Thank you! :-)
Tomek


On Tue, May 6, 2025 at 2:37 AM Tomek CEDRO  wrote:
>
> Okay, git clone works from that location, I pushed the PR but Alan is
> working on this one too so he takes over, thanks for your
> contributions KR!
>
> Two remarks:
> 1. Please remember to git commit -s.
> 2. Please remember to mark what hardware was the code tested on.
>
> https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md
>
> Thank you! :-)
> Tomek
>
> On Mon, May 5, 2025 at 7:47 PM  wrote:
> >
> > Hi, it's just /nuttx.git without the /apache part.
> >
> > On 2025-05-05 17:46, Tomek CEDRO wrote:
> > > Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git
> > > and anything else in kerogit.eu domain :-(
> > > Tomek
> > >
> > > On Sun, May 4, 2025 at 4:44 PM  wrote:
> > >>
> > >> Hello,
> > >>
> > >> new version of the patch series is posted in the git repository, the
> > >> branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up
> > >> to and including avr_fixes_rfc2 is already merged.)
> > >>
> > >> Here are the changes from previous version:
> > >>
> > >> 1. some formatting and typo fixes in various documents
> > >>
> > >> 2. as discussed above, some mixed-case constants were preserved (_bm
> > >> and
> > >> _bp suffix) and some removed. Patch for the nxstyle tool that
> > >> facilitates this exception is added to the series. Non-permitted
> > >> constants with mixed-case letters are no longer used in their form
> > >> from
> > >> library io.h file, instead there are new files within NuttX source
> > >> tree
> > >> that provide all-uppercase constant names.
> > >>
> > >> 3. nxstyle cannot deal with the exceptions properly and come constants
> > >> with _bm suffix in their name were still flagged as incorrect. That is
> > >> worked around by various code shuffling, assigning into temporary
> > >> variables etc. Most places where this was needed to be done are marked
> > >> with comment along the lines of "this will make nxstyle happpy." The
> > >> code seems less readable this way but after trying to make heads or
> > >> tails of the nxstyle source code, this is the only solution I can
> > >> provide on my own.
> > >>
> > >> 4. after dealing with this, I found that there were some mixed-case
> > >> warnings still left - I missed them because of the quantity of others.
> > >> Specifically, it was the type USART_t, a data type which facilitates
> > >> access to a peripheral I/O registers for USART. (Other peripherals
> > >> have
> > >> their types named in the same way.) I changed this one into
> > >> avrdx_usart_t and redefined it in the NuttX source as well.
> > >>
> > >> There should be no checkpatch errors left.
> > >>
> > >>  From what I tested, the code compiles to a binary identical to
> > >> previous
> > >> version of the patch series.
> > >>
> > >> Any comments and reviews are appreciated.
>
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: GitHub NuttX master branch protections

[Tomek CEDRO]

Thank you Nathan :-)

I have talked with @Humbedooh on Slack, he said the config looks okay :-)

I am not really sure about this "contexts" part, particularly the
exact naming convention in GitHub, so I am leaving this for now and
hope it wont break anything :-)

contexts:
  - Check
  - Lint
  - Build

This means if Check, Lint, or Build fails then PR cannot be merged.

Thank you :-)
Tomek

On Tue, May 6, 2025 at 6:42 PM Nathan Hartman  wrote:
>
> Hello Tomek :-)
>
> Thanks for doing that!
>
> I have found that the easiest/quickest way to talk to the Infra folks is by
> Slack [1].
>
> If you don't want to use Slack, you can write to Infra's users list (also
> see [1]).
>
> I recommend to try slack, but either way, give them the link to the PR and
> ask nicely if they could verify it...
>
> [1] To contact Infra by Slack, see the section "Chat" at
> https://infra.apache.org/contact.html
>
> Hope that helps,
> Nathan
>
> On Tue, May 6, 2025 at 9:21 AM Tomek CEDRO  wrote:
>
> > Hello world :-)
> >
> > I found a free moment to setup github master branch protections as
> > discussed before, for now PR is in Draft mode for careful review. Who
> > can we contact from Apache Admins to ask to verification?
> >
> > https://github.com/apache/nuttx/pull/16324
> >
> > * We do not have "Settings" tab in the Apache's owned repository, thus
> > we need to update .asf.yaml file with repository settings.
> > * No direct push to master branch is possible.
> > * Require status checks to pass before merge.
> > * Setup reviews parameters.
> > * Require signatures.
> > * Require conversation resolution.
> > * Not sure if we want to enforce "linear history"?
> > * If all is fine here I will do the same update for nuttx-apps repo :-)
> > * I am not really familiar with all these settings, please review if
> > this is what we want/need.
> > * Particularly the "checks" needs verification if these are valid
> > names (@lupyuen?).
> >
> > Reference: https://github.com/apache/infrastructure-asfyaml.
> >
> > Thank you :-)
> > Tomek
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> >



-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: sched lock/unlock issue on rp2350

[Serg Podtynnyi]

Yeah, but this macro is working because of coincidental match with 
variable prev already defined in the scope.


On 5/6/25 23:19, Alan C. Assis wrote:

This file:
https://github.com/apache/nuttx/commit/9de9f8168d6de8eab8d3a97aac21aacc4e84dd84#diff-ac1d3cade3d9ab380d40fe31f8c006b3035c7b53d04c28e23d9f1ce9a176572c

On Tue, May 6, 2025 at 1:18 PM Alan C. Assis  wrote:


Hi Serg,

I did an analysis here and this macro was introduced in Jan 10 2024, so it
was more than 1 year ago:


https://github.com/apache/nuttx/commit/9de9f8168d6de8eab8d3a97aac21aacc4e84dd84

BR,

Alan

On Tue, May 6, 2025 at 1:12 PM Alan C. Assis  wrote:


WOW! Nice catch!

Question to some people with more experience in the scheduler:

Why wasn't this issue detected before? It was added more than 9 months
ago.

Is there some way to test and enforce that nxsched_process_delivered()
and other schedule functions are working as expected?

BR,

Alan

On Tue, May 6, 2025 at 11:14 AM Serg Podtynnyi 
wrote:


Hi, I am still researching the sched problem on my config

Found this macro code  from last September,  looks like pre vs prev
typo, right?

#definedq_insert_mid(pre,mid,next)\
do\
{\
mid->flink =next;\
mid->blink =prev;\
pre->flink =mid;\
next->blink =mid;\
}\
while(0)



On 4/24/25 15:06, hujun260 wrote:

The lockcount can be understood as a local variable, so no race

conditions will occur.

编辑
分享

















At 2025-04-24 15:54:48, "Serg Podtynnyi"

wrote:

Hi, I tried my best to understand the logic behind unlock and
merge_pending routines and come up with this fix that works for me.
I split the lockcount handling in 2 parts when lockcount is > 1 just
decrement fast as always,
but when it's 1 we enter critical section and make it 0 inside
it(pre-emption is enabled).
I think there is a small time after decrement in the if statement and
   enter_critical_section_wo_note() in original code where can race

happen.

Does this make sense? Sorry if it's a dumb question - scheduler stuff
with SMP is rocket-science level for me yet.

diff --git a/sched/sched/sched_unlock.c b/sched/sched/sched_unlock.c

index 4c7d681454..15fc39b546 100644
--- a/sched/sched/sched_unlock.c
+++ b/sched/sched/sched_unlock.c
@@ -65,13 +65,14 @@ void sched_unlock(void)

 DEBUGASSERT(rtcb == NULL || rtcb->lockcount > 0);

-  /* Check if the lock counter has decremented to zero. If so,
-   * then pre-emption has been re-enabled.
-   */
-
-  if (rtcb != NULL && --rtcb->lockcount == 0)
+  if (rtcb != NULL && rtcb->lockcount > 1)
+{
+  rtcb->lockcount--;
+}
+  else if (rtcb != NULL && rtcb->lockcount == 1)
   {
 irqstate_t flags = enter_critical_section_wo_note();
+  rtcb->lockcount  = 0;

 /* Note that we no longer have pre-emption disabled. */

--
2.49.0
On 4/22/25 14:32, hujun260 wrote:

It seems to have nothing to do with the race condition, and since the

rtcb is this_task, it will only be modified by one CPU.As for why
your modification can solve the problem, I haven't figured it out yet. Can
you further analyze the reasons for the failure to boot?

At 2025-04-22 13:25:13, "Serg Podtynnyi"

wrote:

Hi All, Gregory, Sebastien,

I'm porting NuttX on rp2350(pico2 board inside ClockWork PicoCalc)

and

having trouble getting SMP (2-core) config running

without patching the sched lock/unlock routines.

I am looking at the commit


https://github.com/apache/nuttx/commit/914ae532e68bf4ca75c758d6f541a1d2fcdce8c3

and reverting it helps to boot the system.

This the the patch to make it work for me, I updated the current
lock/unlock by moving the enter_critical_section above the access to
rtcb->lockcount

Do you think it could be the case of a race condition with

rtcb->lockcount ?

PS

It's almost 11 years since I last touched NuttX - it's a please to

work

with it again.


   From 86fa0a65fdd37804154faf3db52e2826281cdfbd Mon Sep 17 00:00:00

2001

From: Serg Podtynnyi
Date: Tue, 22 Apr 2025 11:37:48 +0700
Subject: sched: update lock/unlock critical section entry

Level up enter_critical_section in sched lock/unlock to cover
rtcb->lockcount access

Signed-off-by: Serg Podtynnyi
---
sched/sched/sched_lock.c   | 4 ++--
sched/sched/sched_unlock.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sched/sched/sched_lock.c b/sched/sched/sched_lock.c
index d8f75e7c90..9cc8da3df4 100644
--- a/sched/sched/sched_lock.c
+++ b/sched/sched/sched_lock.c
@@ -82,18 +82,18 @@ void sched_lock(void)
   * operations on this thread (on any CPU)
   */

+  irqstate_t flags = enter_critical_section_wo_note();
  if (rtcb != NULL && rtcb->lockcount++ == 0)
{
#if (CONFIG_SCHED_CRITMONITOR_MAXTIME_PREEMPTION >= 0) || \
defined(CONFIG_SCHED_INSTRUMENTATION_PREEMPTION)
-  irqstate_t flags = enter_critical_section_wo_note();

  /* Note that we have pre-emption locked */

  nxsched_critmon_p

Re: GitHub NuttX master branch protections

[Nathan Hartman]

Looks good and looks like it has been merged! Thank you Tomek for tackling
this!!!

Cheers,
Nathan

On Tue, May 6, 2025 at 4:46 PM Tomek CEDRO  wrote:

> Thank you Nathan :-)
>
> I have talked with @Humbedooh on Slack, he said the config looks okay :-)
>
> I am not really sure about this "contexts" part, particularly the
> exact naming convention in GitHub, so I am leaving this for now and
> hope it wont break anything :-)
>
> contexts:
>   - Check
>   - Lint
>   - Build
>
> This means if Check, Lint, or Build fails then PR cannot be merged.
>
> Thank you :-)
> Tomek
>
> On Tue, May 6, 2025 at 6:42 PM Nathan Hartman 
> wrote:
> >
> > Hello Tomek :-)
> >
> > Thanks for doing that!
> >
> > I have found that the easiest/quickest way to talk to the Infra folks is
> by
> > Slack [1].
> >
> > If you don't want to use Slack, you can write to Infra's users list (also
> > see [1]).
> >
> > I recommend to try slack, but either way, give them the link to the PR
> and
> > ask nicely if they could verify it...
> >
> > [1] To contact Infra by Slack, see the section "Chat" at
> > https://infra.apache.org/contact.html
> >
> > Hope that helps,
> > Nathan
> >
> > On Tue, May 6, 2025 at 9:21 AM Tomek CEDRO  wrote:
> >
> > > Hello world :-)
> > >
> > > I found a free moment to setup github master branch protections as
> > > discussed before, for now PR is in Draft mode for careful review. Who
> > > can we contact from Apache Admins to ask to verification?
> > >
> > > https://github.com/apache/nuttx/pull/16324
> > >
> > > * We do not have "Settings" tab in the Apache's owned repository, thus
> > > we need to update .asf.yaml file with repository settings.
> > > * No direct push to master branch is possible.
> > > * Require status checks to pass before merge.
> > > * Setup reviews parameters.
> > > * Require signatures.
> > > * Require conversation resolution.
> > > * Not sure if we want to enforce "linear history"?
> > > * If all is fine here I will do the same update for nuttx-apps repo :-)
> > > * I am not really familiar with all these settings, please review if
> > > this is what we want/need.
> > > * Particularly the "checks" needs verification if these are valid
> > > names (@lupyuen?).
> > >
> > > Reference: https://github.com/apache/infrastructure-asfyaml.
> > >
> > > Thank you :-)
> > > Tomek
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
>
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Enhancing documentation

[Matteo Golin]

Hello everyone,

I just opened a PR here for migrating some of the README.txt files to RST files 
(for board documentation,
https://github.com/apache/nuttx/pull/16328). This is part of the long list of 
old README files that need to be migrated,
all laid out in issue #11077 (https://github.com/apache/nuttx/issues/11077). If 
you could help review the PR (it's quite
long and it only tackles 6 of the READMEs), that would be great. I plan to 
continue migrating the remainder of these
READMEs over the next few weeks.

In case you haven't seen it, I've also added a tagging system to the Nuttx 
documentation in this PR #16275
(https://github.com/apache/nuttx/pull/16275) and I've started adding tags for 
chips in PR #16321
(https://github.com/apache/nuttx/pull/16321). This is part of an effort to make 
the NuttX docs easier to search through
(i.e. filter for supported boards that have some feature like `ethernet` and 
also some chip `rp2040`, etc.).

This is also part of the wider issue 
(https://github.com/apache/nuttx/issues/16278) to improve NuttX's quality and
reliability, specifically step #3.

I have been working with an undergraduate engineering design team for the past 
year on using NuttX for high powered
rocketry. Most of the struggle I have seen students (myself included) encounter 
are difficulties finding information
about what NuttX supports or how to use some of the features, programs or 
extend existing code to purpose-built
applications. I really think NuttX could increase its user base (and maintainer 
base) if some of this information was
better documented and easier to find. To me, this is a bigger priority than 
adding new features or even (in some cases)
improving the stability of a few boards. If the documentation is clear on what 
exactly is supported by NuttX, it would
cause fewer headaches to people who select a board from the docs and find out 
that the feature they expected does not
work. As long as it's marked as unstable, we're being honest with the user base 
and can work towards fixing it later.

If I may, I have a suggestion that I think might help to improve the quality of 
the documentation without requiring
specifically assigned tasks:

I've noticed that many of the maintainers on this mailing list have a set of 
boards that are supported by NuttX, which
as a whole covers a very large subset of the maintained NuttX boards. I 
personally have mostly RP2040 based boards, but
quite a few people I've noticed have STM32 boards. At this point, I would 
assume that most of these board owners are
very familiar with the process of tinkering with and uploading NuttX to them (I 
know I've gotten *very* familiar with
having to push BOOTSEL every time :) ).

If everyone could take a little time to look at the documentation page for the 
boards that they own, I think it would be
very easy to identify improvements or missing information quickly. Then we 
could all open a corresponding PR to make the
updates. Since everyone has different boards, I think this would spread the 
task fairly evenly, and the boards that are
most common among all of us will get the most updates (probably a good thing, 
they would maybe be the most common
amongst users too).

This goes for not just boards, but even examples you use often (I used the 
`gpio` example recently and noticed that its
documentation page is completely empty 
[https://nuttx.apache.org/docs/latest/applications/examples/gpio/index.html]).
Same goes for drivers that are used often. There wasn't very much documentation 
about the uORB framework until a few
months ago when it started gaining some heavy use, and now that's a tool I 
refer back to quite often.

In summary, if there's something you use often and have become an expert at, 
write down some of your expertise with it
in the docs wherever it's missing and add a few of the relevant new 'tags'. I 
think if we did that, the docs would
improve massively in a relatively short period of time.

If there's interest, I could also compile a list of empty documentation pages 
(such as for the GPIO example) and make a
checklist issue similar to #11077 just for tracking. Might be an easy task for 
new contributors to tackle as well.

-- 
Matteo Golin


signature.asc
Description: PGP signature

Re: RFC - AVR fixes and support for AVR DA/DB family

[kr . git]

I noticed, thanks. To reply to the comments and feedback in the PR:

1. The discussion about AVR_LINUXGCC_TOOLCHAIN_IS_GCC - my overall goal 
was to minimize changes for boards and AVR families I am not using (and 
have no experience with them and, most importantly, cannot test.)


Setting DEBUG_OPT_UNUSED_SECTIONS to No in all defconfigs is something 
that did not occur to me. Using the indirection with 
AVR_LINUXGCC_TOOLCHAIN_IS_GCC still looks safer - even with 
DEBUG_OPT_UNUSED_SECTIONS being disabled, setting ARCH_TOOLCHAIN_GCC and 
ARCH_TOOLCHAIN_GNU in turn may still have some side effects. But if the 
consensus is to drop AVR_LINUXGCC_TOOLCHAIN_IS_GCC, select 
ARCH_TOOLCHAIN_GCC directly and alter existing defconfigs, I can prepare 
new version of the series which will do that instead.


2. Build instructions etc. - I noticed Alan C. Assis already said he 
will create some documentation but I can prepare something as well (so 
other people are not burdened with it.) If you want me to, I'll just 
need to know where to put that - to the board Documentation directory? 
(Documentation/platforms/avr/avrdx/boards/breadxavr/index.rst)


Also - is it appropriate to prepare more default configurations? I 
didn't want to pollute the configuration list with a bunch of 
breadxavr:nsh, breadxavr:buttons etc. But if that is not seen as a 
problem, I can try to make a few to pair with patches that add some 
hardware support


On 2025-05-06 19:16, Tomek CEDRO wrote:

Alan just posted the PR with your AVR updates :-)

https://github.com/apache/nuttx/pull/16323

Thank you! :-)
Tomek


On Tue, May 6, 2025 at 2:37 AM Tomek CEDRO  wrote:


Okay, git clone works from that location, I pushed the PR but Alan is
working on this one too so he takes over, thanks for your
contributions KR!

Two remarks:
1. Please remember to git commit -s.
2. Please remember to mark what hardware was the code tested on.

https://github.com/apache/nuttx/blob/master/CONTRIBUTING.md

Thank you! :-)
Tomek

On Mon, May 5, 2025 at 7:47 PM  wrote:
>
> Hi, it's just /nuttx.git without the /apache part.
>
> On 2025-05-05 17:46, Tomek CEDRO wrote:
> > Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git
> > and anything else in kerogit.eu domain :-(
> > Tomek
> >
> > On Sun, May 4, 2025 at 4:44 PM  wrote:
> >>
> >> Hello,
> >>
> >> new version of the patch series is posted in the git repository, the
> >> branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up
> >> to and including avr_fixes_rfc2 is already merged.)
> >>
> >> Here are the changes from previous version:
> >>
> >> 1. some formatting and typo fixes in various documents
> >>
> >> 2. as discussed above, some mixed-case constants were preserved (_bm
> >> and
> >> _bp suffix) and some removed. Patch for the nxstyle tool that
> >> facilitates this exception is added to the series. Non-permitted
> >> constants with mixed-case letters are no longer used in their form
> >> from
> >> library io.h file, instead there are new files within NuttX source
> >> tree
> >> that provide all-uppercase constant names.
> >>
> >> 3. nxstyle cannot deal with the exceptions properly and come constants
> >> with _bm suffix in their name were still flagged as incorrect. That is
> >> worked around by various code shuffling, assigning into temporary
> >> variables etc. Most places where this was needed to be done are marked
> >> with comment along the lines of "this will make nxstyle happpy." The
> >> code seems less readable this way but after trying to make heads or
> >> tails of the nxstyle source code, this is the only solution I can
> >> provide on my own.
> >>
> >> 4. after dealing with this, I found that there were some mixed-case
> >> warnings still left - I missed them because of the quantity of others.
> >> Specifically, it was the type USART_t, a data type which facilitates
> >> access to a peripheral I/O registers for USART. (Other peripherals
> >> have
> >> their types named in the same way.) I changed this one into
> >> avrdx_usart_t and redefined it in the NuttX source as well.
> >>
> >> There should be no checkpatch errors left.
> >>
> >>  From what I tested, the code compiles to a binary identical to
> >> previous
> >> version of the patch series.
> >>
> >> Any comments and reviews are appreciated.



--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info