RE: [DISCUSS]: Self merge and Single company/organization merge gating

[alin.jerpe...@sony.com]

Hi all

In my opinion we should not use the auto merge functionality since most of the 
time there is at least 1 of us active at any time and the amount of patches is 
not comparable to EX: Google. 

I think that the merge policy is fine as it is now since almost all patches 
follow the rule and seldom someone self-merges a patch. 

Also we should note that in case some patches land accidentally in the master 
branch we can always revert them if it is necessary

Best regards
Alin

-Original Message-
From: David Sidrane  
Sent: den 17 februari 2022 22:31
To: dev@nuttx.apache.org
Subject: RE: [DISCUSS]: Self merge and Single company/organization merge gating

On Self merge:

As Nathan pointed out, it is more about time zones then merge velocity.
However, using a backport only methodology requires an upstream merge before 
the work can be backported with least effort and adds a serial delay. It would 
be ideal to reduces the CI quantum delay this as much as we can.

GH has a setting to merge on successful CI after approval. It is lit by the 
approver. This removes the polling for completion of CI.
If this can be configured it reduces the polling for both approver and author. 
If it can not be configured in our repos, then self merge is the next best 
thing.

I am not trying to circumvent the review process at all - just remove the idle 
time imposed by the process that is sampling related.

> an approval from outside of the company/organization then the author 
> can do the merge. For complex changes the person outside the 
> organization should perform the merge even if there are more than 1 
> approval from inside the company/organization.

I agree.

David

-Original Message-
From: Petro Karashchenko 
Sent: Thursday, February 17, 2022 1:01 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS]: Self merge and Single company/organization merge gating

Hello,

Regarding PRs megre by the author: I think that if the changes are relatively 
simple (again that is very subjective, but I hope that people with merge rights 
have more or less the same common sense of
it) and there is an approval from outside of the company/organization then the 
author can do the merge. For complex changes the person outside the 
organization should perform the merge even if there are more than 1 approval 
from inside the company/organization.

In this way reviewers can perform reviews with better quality and if someone 
"forget" to press the "rebase & merge" button because for example CI is still 
running and that is the end of working day, then the author can press that 
button and not do extra tagging in PRs. I vote to make that process usable for 
people and sacrifice bureaucracy in the places where it is possible.

Best regards,
Petro

вт, 15 лют. 2022 р. о 18:26 Nathan Hartman  пише:
>
> On Mon, Feb 14, 2022 at 2:01 PM Brennan Ashton 
>  wrote:
> > > Background:
> > I am generally opposed to both of these. It is quite rare that we 
> > need a crazy fast merge turn around on a PR. And if something is 
> > approved and straight up broken in master that needs to get in then 
> > I think forgiveness can be used to self merge.
> >
> >
> > I also generally do not have a big issue about people from the same 
> > company reviewing and merging. I could see the arguments for shared 
> > code but then I
> > think we are nitpicking.   I prefer the velocity with a few oops that
> > can
> > be reverted along the way if needed.  There is also parts of the 
> > code base where the best people to review are on the same company.
> >
> >
> > I think most of the concerns here are best addressed not by process 
> > but increasing the number of contributors who can participate. (more 
> > committers and PPMC)
>
> Feel free to correct me if I'm mistaken, but I think David is bringing 
> this up because of time zones.
>
> Indeed, most of the PR merging activity seems to occur during what I 
> would call nighttime or early morning, and I think that might be more 
> pronounced in David's time zone.
>
> Still, I think things have been working well, more or less, and I 
> don't think we need to make up any new rules right now.
>
> Instead, I would only urge committers to give complex PRs 12-24 hours 
> to percolate, even if there's an approving review, so other time zones 
> have a chance to look at them.
>
> Obviously that doesn't apply if it's urgent. For example, if the build 
> is broken and people can't get work done, or a serious error was 
> merged and needs to be reverted ASAP, don't wait, do it!
>
> Also, it's not necessary to delay for trivial PRs.
>
> What are the definitions of "complex," "trivial," "urgent," etc? I 
> say, committers should just use their best judgment and try to find a 
> good balance. Don't rush too much, don't delay too much. :-)
>
> David brings up a good point about time zones and we do have to 
> remember that NuttX is a global project, and I think that's the main 
> point to keep in mind.
>
> To Brennan's l

RE: Graduation?

[alin.jerpe...@sony.com]

Hi all,

I am happy to announce that the licenses are migrated to Apache and the 
remaining ones are documented in the LICENSE file 

It would be good If someone can run a FOSSID scan to double check the licenses 
(in case I missed something)  then I think that we can remove the 
DISCLAIMER-WIP from NuttX and start the NuttX 10.3 release process

Best regards
Alin

-Original Message-
From: Nathan Hartman  
Sent: den 9 februari 2022 19:14
To: dev@nuttx.apache.org
Subject: Re: Graduation?

On Wed, Feb 9, 2022 at 12:30 PM Brennan Ashton  
wrote:
> There is also some code still in the repo with restrictions on use to 
> a single microcontroller. That have come up in votes before.

Can we wrap code like that with a Kconfig, e.g., ALLOW_NONFREE_CODE, like we 
already have for GPL and BSD components?

Cheers,
Nathan

NuttX 10.3 release plan

[alin.jerpe...@sony.com]

Hi all,



Our latest release (NuttX 10.2) was on 2021-11-28.



I think that we can remove the DISCLAIMER and start the release process for 
10.3 on the following schedule



W10 -- Master Stability Window (keep the merging of risky PRs to a minimum this 
week)

W11.2 -- Create the 10.2 release branch

W11.2-13.1 -- Stabilize / test / release notes

W13.1 -- Tag RC0 and call for PPMC / Community Vote

W14(or when we have the votes) Call for IPMC Vote

W14.6 -- Update site and announce (we have to wait for download mirrors to 
sync).





Best regards

Alin

RE: NuttX 10.3 release plan

[alin.jerpe...@sony.com]

Hi all,

I crested the release 10.3 branch and started working on the release notes

Please PR backports to the branch 

Best regards
Alin




-Original Message-
From: alin.jerpe...@sony.com  
Sent: den 7 mars 2022 10:13
To: dev@nuttx.apache.org
Subject: NuttX 10.3 release plan

Hi all,



Our latest release (NuttX 10.2) was on 2021-11-28.



I think that we can remove the DISCLAIMER and start the release process for 
10.3 on the following schedule



W10 -- Master Stability Window (keep the merging of risky PRs to a minimum this 
week)

W11.2 -- Create the 10.2 release branch

W11.2-13.1 -- Stabilize / test / release notes

W13.1 -- Tag RC0 and call for PPMC / Community Vote

W14(or when we have the votes) Call for IPMC Vote

W14.6 -- Update site and announce (we have to wait for download mirrors to 
sync).





Best regards

Alin

RE: NuttX 10.3 release plan

[alin.jerpe...@sony.com]

@Nathan Hartman thanks for the update

If you are ok with the current state for the Licensed please submit the PR for 
DISCLAIMER removal on both master and 10.3 branches

Best regards
Alin

-Original Message-
From: Nathan Hartman  
Sent: den 16 mars 2022 15:52
To: dev@nuttx.apache.org
Subject: Re: NuttX 10.3 release plan

On Wed, Mar 16, 2022 at 7:04 AM alin.jerpe...@sony.com  
wrote:
>
> Hi all,
>
> I created the release 10.3 branch and started working on the release 
> notes
>
> Please PR backports to the branch

Thank you, Alin. Please note there is a draft Release Notes here:
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/NuttX*10.3__;Kw!!JmoZiZGBv3RvKRSx!os5eAPMXxcGPh3uu7kQuP3PAcPT5aESa_ARDPGyeOisZF7kXK_dUiDQA8VF4MrcmDA$
 

There I have documented "breaking changes" but not much else so far.

I am looking forward to our first non-DISCLAIMER release and hopefully 
graduating soon afterwards!

Cheers,
Nathan

RE: NuttX 10.3 release plan

[alin.jerpe...@sony.com]

Hi all,

I am happy to announce the confluence release notes are ready and we can 
proceed with the NuttX 10.3-RC0 release

@Nathan Hartman please check if you can fix the format 
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.3

Does anyone oppose to the removal of the DISCLAIMER for 10.3-RC0 release ?

Best regards
Alin


-Original Message-
From: alin.jerpe...@sony.com  
Sent: den 17 mars 2022 09:33
To: dev@nuttx.apache.org; Nathan Hartman 
Subject: RE: NuttX 10.3 release plan

@Nathan Hartman thanks for the update

If you are ok with the current state for the Licensed please submit the PR for 
DISCLAIMER removal on both master and 10.3 branches

Best regards
Alin

-Original Message-
From: Nathan Hartman 
Sent: den 16 mars 2022 15:52
To: dev@nuttx.apache.org
Subject: Re: NuttX 10.3 release plan

On Wed, Mar 16, 2022 at 7:04 AM alin.jerpe...@sony.com  
wrote:
>
> Hi all,
>
> I created the release 10.3 branch and started working on the release 
> notes
>
> Please PR backports to the branch

Thank you, Alin. Please note there is a draft Release Notes here:
https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/NuttX*10.3__;Kw!!JmoZiZGBv3RvKRSx!os5eAPMXxcGPh3uu7kQuP3PAcPT5aESa_ARDPGyeOisZF7kXK_dUiDQA8VF4MrcmDA$
 

There I have documented "breaking changes" but not much else so far.

I am looking forward to our first non-DISCLAIMER release and hopefully 
graduating soon afterwards!

Cheers,
Nathan

RE: [VOTE] Apache NuttX 10.3.0 (incubating) RC1 release

[alin.jerpe...@sony.com]

Hi Masayuki -san 

Are you able to cherry-pick and test the patches on the real HW ?

Thanks 
Alin


-Original Message-
From: Masayuki Ishikawa  
Sent: den 3 maj 2022 16:17
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 10.3.0 (incubating) RC1 release

-1

sabre-6quad:smp (real hardware) does not boot.
I think some armv7-a-related PRs need to be merged.

On Wed, Apr 27, 2022 at 5:01 PM Alin Jerpelea  wrote:

> Hello all,
>
>
> Apache NuttX (Incubating) 10.3.0 RC1 has been staged under [1] and 
> it's time to vote on accepting it for release. If approved we will 
> seek final release approval from the IPMC. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 
> are required to pass.
>
> The Apache requirements for approving a release can be found here [3] 
> "Before voting +1 [P]PMC members are required to download the signed 
> source code package, compile it as provided, and test the resulting 
> executable on their own platform, along with also verifying that the 
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on 
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM 
> items in [4]) [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
>   Release tag: nuttx-10.3.0-RC1
>   Hash for the release incubating-nuttx tag:
> 2e3c217d103f9c98dc3e4c6f02ba87e6e8b719f0
>   Hash for the release incubating-nuttx-apps tag:
> ecd8a9722f9da777829ed6f28998311f1664b278
>
> [1] 
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/inc
> ubator/nuttx/10.3.0-RC1/__;!!JmoZiZGBv3RvKRSx!4aququvO7zQseiusM3fVPWZq
> Hup5x8YDb2G67QRh0r-6yhO42lpQspOum_H5U2ckeBXP6zVNIpmNrW6cKYZ482YHbNff$
> [2]
>
> https://urldefense.com/v3/__https://raw.githubusercontent.com/apache/i
> ncubator-nuttx/nuttx-10.3.0-RC1/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!4aqu
> quvO7zQseiusM3fVPWZqHup5x8YDb2G67QRh0r-6yhO42lpQspOum_H5U2ckeBXP6zVNIp
> mNrW6cKYZ48-I3p9r2$ [3] 
> https://urldefense.com/v3/__https://www.apache.org/dev/release.html*ap
> proving-a-release__;Iw!!JmoZiZGBv3RvKRSx!4aququvO7zQseiusM3fVPWZqHup5x
> 8YDb2G67QRh0r-6yhO42lpQspOum_H5U2ckeBXP6zVNIpmNrW6cKYZ484QkBmjj$
> [4]
>
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/displa
> y/NUTTX/Validating*a*staged*Release__;Kysr!!JmoZiZGBv3RvKRSx!4aququvO7
> zQseiusM3fVPWZqHup5x8YDb2G67QRh0r-6yhO42lpQspOum_H5U2ckeBXP6zVNIpmNrW6
> cKYZ48y7wfpdl$
>

[RESULT] [VOTE] Release Apache NuttX (Incubating) 10.3.0 [RC2]

[alin.jerpe...@sony.com]

Hi,



The vote closes now as over 72hr have passed. The vote PASSES with 4

3 (+1 non-binding) votes from the PPMC,

1 (+1 binding) vote from the IPMC,

0 (+1 non-binding) votes from the developer community, No further +1, 0 or -1 
votes.



The vote thread:

[1]

https://lists.apache.org/thread/r4dgncvozmog3vnz6ybm9dxvs008m9z8



I will now bring the vote to 
gene...@incubator.apache.org>
 to get approval by the IPMC.

If this vote passes also, the release is accepted and will be published.



Thanks,

Alin Jerpelea

RE: Add license Kconfig for 3rd party binary blobs?

[alin.jerpe...@sony.com]

Hi all,

Thanks for finding and reporting the issue 
I will add a license guard and scout for all other binary files ASAP

Best regards
Alin


-Original Message-
From: Tomek CEDRO  
Sent: den 15 maj 2022 23:40
To: dev@nuttx.apache.org
Subject: Re: Add license Kconfig for 3rd party binary blobs?

On Sun, May 15, 2022 at 10:35 PM Nathan Hartman  wrote:
> On Sun, May 15, 2022 at 10:51 AM Tomek CEDRO wrote:
> > On Sun, May 15, 2022 at 4:23 PM Nathan Hartman wrote:
> > > I noticed that we are downloading a 3rd party precompiled library, 
> > > libphy62xxble.a from 
> > > https://urldefense.com/v3/__http://www.phyplusinc.com__;!!JmoZiZGB
> > > v3RvKRSx!9JL17Pkv7OE6IRnA6D1BnJPZ0cHcT3NCnrDoIr5N3A2Goa59Tm0jb4SbR
> > > x7PIutQJqv22asvg2yg4SY2iw$ . (One of the Linux build tests on 
> > > PR-6266 failed because curl failed to download it.)
> > >
> > > This download is done in arch/arm/src/phy62xx/Make.defs:
> > >
> > > if [ ! -f libphy62xxble.a ]; then \ echo "download lib 
> > > form server"; \ curl -L -o libphy62xxble.a 
> > > https://urldefense.com/v3/__http://www.phyplusinc.com/phyplus/libp
> > > hy62xxble.a__;!!JmoZiZGBv3RvKRSx!9JL17Pkv7OE6IRnA6D1BnJPZ0cHcT3NCn
> > > rDoIr5N3A2Goa59Tm0jb4SbRx7PIutQJqv22asvg2wMFha_gw$ ; \ cp -a 
> > > libphy62xxble.a ../../../staging; \ else \ echo "file 
> > > exist"; \ fi \
> > >
> > > Should we add a new item to Kconfig -> License Setup?
> > > For example:
> > > [ ] Use components that include 3rd party binary objects
> >
> > This is a good catch! No Open-Source project should silently include 
> > external closed-source binary blobs from internet.
>
>
> Yes, this is what I'm getting at.
>
> If we allow this at all, it should definitely be gated behind a 
> "Licensing" Kconfig that is OFF by default.
>
> More below:
>
> > Not to mention insecure HTTP and no signature / certificate / 
> > checksum residing in the project for download verification. This is 
> > a serious security issue.
>
> If we allow this at all, there should be at least a basic mitigation:
> (1) The SHA-512 of the known-legitimate file should be written in 
> arch/arm/src/phy62xx/Make.defs. (2) When the file is downloaded, it is 
> initially saved to an alternate name, e.g., 
> libphy62xxble.a.downloaded. (3) The downloaded file's SHA-512 is 
> computed and compared to the known-legitimate SHA-512. If there is a 
> discrepancy then the build is aborted and the user is left to check 
> what happened. If the file SHA-512 is verified then the file is 
> renamed to its correct name.
>
> Nathan

Exactly :-)

`sha512 -c sum filename` works on BSD like a charm and status can be checked 
with `echo $?` :-)

Also `curl --hostpubsha256` can be used here to verify the server public 
certificate :-)

   --hostpubsha256 
  (SFTP SCP) Pass a string containing a Base64-encoded SHA256 hash
  of the remote host's public key. Curl will refuse the connection
  with the host unless the hashes match.

  Example:
   curl --hostpubsha256
NDVkMTQxMGQ1ODdmMjQ3MjczYjAyOTY5MmRkMjVmNDQ= 
https://urldefense.com/v3/__sftp://example.com/__;!!JmoZiZGBv3RvKRSx!9JL17Pkv7OE6IRnA6D1BnJPZ0cHcT3NCnrDoIr5N3A2Goa59Tm0jb4SbRx7PIutQJqv22asvg2zfJiCpKA$
 

  See also --hostpubmd5. Added in 7.80.0.


--
CeDeROM, SQ7MHZ, 
https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!JmoZiZGBv3RvKRSx!9JL17Pkv7OE6IRnA6D1BnJPZ0cHcT3NCnrDoIr5N3A2Goa59Tm0jb4SbRx7PIutQJqv22asvg2zszpH-cg$
 

[DISCUSS] NuttX Online Workshop 2022 - call for the event crew -

[alin.jerpe...@sony.com]

Hi all,

Each year we organized the NuttX International/Online Workshop during the 
summer and I think that we should continue this year with an Online event since 
travel is still difficult.

This thread is intended to

  *   gather the event crew needed to prepare the event

- decide the event date at the end of August/Beginning of September

- start the event planning

If someone is interested to join the organizer crew please reply this thread.

Best regards
Alin

RE: [DISCUSS] Graduate NuttX as TLP

[alin.jerpe...@sony.com]

I think that we should modify the paths so that we use 
nuttx and nuttx_apps folders. 
In my opinion this will be less confusing for the users

Best regards
Alin

-Original Message-
From: Tomek CEDRO  
Sent: den 28 juni 2022 02:55
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Graduate NuttX as TLP

Congratulations on NuttX Graduation and all of the achievements! :-)


On Mon, Jun 27, 2022 at 6:18 PM Alan Carvalho de Assis wrote:
> I don't know you guys but I hate this incubator-nuttx and 
> incubator-nuttx-apps repositories names.
>
> I hope we get github.com/apache/nuttx and github.com/apache/apps soon 
> (hope they accept we use this /apps name, will make our users life 
> easier!)

+1 :-)

How about something like nuttx_rtos and nuttx_apps ?

It was not clear for me what apps are and if they are mandatory..
keeping apache/apps could be even more confusing.. also I usually keep `.git` 
suffix for directories that keep git repos and that was not working here :-)

Maybe just nuttx + nuttx/nuttx_apps where apps are git submodule kept as it is 
right now in a sperate repo for easier maintenance? :-)

--
CeDeROM, SQ7MHZ, 
https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!JmoZiZGBv3RvKRSx!6HrO-4qVO1mY_faiW-6kxCv6sQxyeUdYuL9_HLWZCaxV9eclVaPiUFuThqR-7C8RXGs6X-G2MtYdfE46lg$
 

RE: [ANNOUNCE] Apache NuttX 10.3.0-incubating released

[alin.jerpe...@sony.com]

My plan is to start the release process every 3 moths 

Best regards
Alin


-Original Message-
From: Abdelatif Guettouche  
Sent: den 24 juni 2022 13:16
To: dev@nuttx.apache.org
Subject: Re: [ANNOUNCE] Apache NuttX 10.3.0-incubating released

> What are next steps?

Release wise, nothing -- we just need to keep making releases.

For graduation that's a different story that we need to discuss.
There is a checklist here:
https://urldefense.com/v3/__https://incubator.apache.org/guides/graduation.html*before_you_graduate__;Iw!!JmoZiZGBv3RvKRSx!8tn0GIg4ZXCYp5d7w2Ddmz46Ru5vu3M9l7ITUE-sm8dUxgKagg6sUU42BoQpzvacM_TrGnk7QuEv-cb3y2U-9fSPwKfp$
I believe we already checked most of the boxes.

On Fri, Jun 24, 2022 at 12:43 PM Alan Carvalho de Assis  
wrote:
>
> Very nice! Kudo guys!
>
> What are next steps?
>
> BR,
>
> Alan
>
> On Friday, June 24, 2022, Abdelatif Guettouche < 
> abdelatif.guettou...@gmail.com> wrote:
>
> > First non-WIP release!  One step closer to graduation!
> >
> > On Fri, Jun 24, 2022 at 7:47 AM Tomek CEDRO  wrote:
> > >
> > > CONGRATZ! :-)
> > >
> > > --
> > > CeDeROM, SQ7MHZ, 
> > > https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!JmoZiZ
> > > GBv3RvKRSx!8tn0GIg4ZXCYp5d7w2Ddmz46Ru5vu3M9l7ITUE-sm8dUxgKagg6sUU4
> > > 2BoQpzvacM_TrGnk7QuEv-cb3y2U-9VE5857q$
> >

RE: Wikipedia: "Proposal deletion of NuttX"

[alin.jerpe...@sony.com]

I can't spot promotional materials and I think that we should try to contact 
MrsSnoozyTurtle and understand what is his concern 

Best regards
Alin
 


-Original Message-
From: Alan Carvalho de Assis  
Sent: den 21 juli 2022 13:10
To: dev 
Subject: Wikipedia: "Proposal deletion of NuttX"

Hi team,

I received this email and I don't know what we need to do to avoid it:

‪MrsSnoozyTurtle‬ left a message on *your talk page* in "*‪Proposed deletion of 
NuttX‬*".
The article NuttX has been proposed for deletion because of the following
concern: Promotional article While all constructive contributions to Wiki

RE: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release

[alin.jerpe...@sony.com]

Hi Alan,
Thanks for investigating the issue. Did you fix the hash ? Do you retract your 
-1 ?

@Petro Thanks for providing a explanation for the issue 

Best regards
Alin

-Original Message-
From: Alan Carvalho de Assis  
Sent: den 12 augusti 2022 02:38
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release

The most important I forgot to say:

Alin: reverting Petro's commit solves the issue, but is not the solution.

He fixed the issue, it is just incompatible with old hash. The solution is to 
fix the hash.

BR,

Alan

On 8/11/22, Alan Carvalho de Assis  wrote:
> Hi Petro,
>
> I think we don't want to be compatible with it if it was in fact faulty.
>
> The TEA algorithm by itself has some weakness as people can see here:
>
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Tiny_Encrypt
> ion_Algorithm__;!!JmoZiZGBv3RvKRSx!-xb49ukgyjFVAohl5rByBw6U6G89QqC7-aO
> 7eJyN4-0ToLVA9ga3FbLyC0QLlERRU2FCiH6_su8CI-UD$
>
> "TEA has a few weaknesses. Most notably, it suffers from equivalent 
> keys—each key is equivalent to three others, which means that the 
> effective key size is only 126 bits.[5] As a result, TEA is especially 
> bad as a cryptographic hash function. This weakness led to a method 
> for hacking Microsoft's Xbox game console, where the cipher was used 
> as a hash function."
>
> We could keep TEA support as an option (maybe for devices that don't 
> need strong security) but the default algo could be XTEA or some other 
> without known weakness.
>
> Just my 2 cents.
>
> BR,
>
> Alan
>
> On 8/11/22, Petro Karashchenko  wrote:
>> The code had an obvious bug when memory was accessed out of bounds.
>>
>> In some of the cases it was accessing zeroes and producing some 
>> output, but after my changes it started to work "as designed" and use 
>> "space" (not
>> zero) as padding.
>>
>> I'm not sure what is the best way to fix this. Changing padding 
>> symbol from "space" to zero should also make decryption working. I 
>> really do not know what is the best solution and what is better "to 
>> be right" or "to be backward compatible".
>>
>> Best regards,
>> Petro
>>
>> On Thu, Aug 11, 2022, 10:10 PM Alan Carvalho de Assis 
>> 
>> wrote:
>>
>>> ACK
>>>
>>> Strange, the previous email went only to you!
>>>
>>> On 8/11/22, Alin Jerpelea  wrote:
>>> > @Alan Carvalho de Assis   please confirm that 
>>> > works after revert
>>> >
>>> > On Thu, 11 Aug 2022, 20:22 Petro Karashchenko, 
>>> > 
>>> > wrote:
>>> >
>>> >> Hello Alan,
>>> >>
>>> >> Seems that the root cause is my change 
>>> >> https://urldefense.com/v3/__https://github.com/apache/incubator-n
>>> >> uttx-apps/pull/1097__;!!JmoZiZGBv3RvKRSx!-xb49ukgyjFVAohl5rByBw6U
>>> >> 6G89QqC7-aO7eJyN4-0ToLVA9ga3FbLyC0QLlERRU2FCiH6_ss9mT39r$
>>> >>
>>> >> I think that all previously generated passwords need to be 
>>> >> re-generated.
>>> >>
>>> >> Best regards,
>>> >> Petro
>>> >>
>>> >> On Thu, Aug 11, 2022, 8:49 PM Alan Carvalho de Assis 
>>> >> >> >
>>> >> wrote:
>>> >>
>>> >> > Alin,
>>> >> >
>>> >> > I want to redraw my vote, I found the first regression, so my 
>>> >> > vote
>>> >> > is:
>>> >> >
>>> >> > -1
>>> >> >
>>> >> > Seems like the console login is not working, I'm using user: 
>>> >> > admin and
>>> >> > password: Administrator
>>> >> >
>>> >> > $ ./tools/configure.sh sim:nsh
>>> >> >
>>> >> > $ make -j
>>> >> >
>>> >> > $ ./nuttx
>>> >> > login: admin
>>> >> > password:
>>> >> > Invalid username or password
>>> >> > login: admin
>>> >> > password:
>>> >> > Invalid username or password
>>> >> > login: admin
>>> >> > password:
>>> >> > Invalid username or password
>>> >> > Login failed!
>>> >> >
>>> >> > I double checked the /etc/passwd file and it is correct:
>>> >> >
>>> >> > nsh> cat /etc/passwd
>>> >> > admin:8Tv+Hbmr3pLddSjtzL0kwC:0:0:/
>>> >> >
>>> >> > Please help me to find the offending commit.
>>> >> >
>>> >> > BR,
>>> >> >
>>> >> > Alan
>>> >> >
>>> >> > On 8/8/22, Alin Jerpelea  wrote:
>>> >> > > Hello all,
>>> >> > > Apache NuttX (Incubating) 10.4.0 RC0 has been staged under 
>>> >> > > [1] and it's time to vote on accepting it for release. If 
>>> >> > > approved we will seek final release approval from the IPMC. 
>>> >> > > Voting will be open for 72hr.
>>> >> > >
>>> >> > > A minimum of 3 binding +1 votes and more binding +1 than 
>>> >> > > binding
>>> >> > > -1
>>> >> > > are
>>> >> > > required to pass.
>>> >> > >
>>> >> > > The Apache requirements for approving a release can be found 
>>> >> > > here
>>> [3]
>>> >> > > "Before voting +1 [P]PMC members are required to download the 
>>> >> > > signed source code package, compile it as provided, and test 
>>> >> > > the resulting executable on their own platform, along with 
>>> >> > > also verifying that the package meets the requirements of the 
>>> >> > > ASF policy on releases."
>>> >> > >
>>> >> > > A document to walk through some of this process has been 
>>> >> > > published
>>> on
>>> >> > > our project wiki and can be found h

RE: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release

[alin.jerpe...@sony.com]

Hi all,

The voting is canceled and I restarted the vote process for 11.0.0-RC0

Thanks for testing the release and providing feedback 

Best regards
Alin Jerpelea

-Original Message-
From: alin.jerpe...@sony.com  
Sent: den 12 augusti 2022 08:49
To: dev@nuttx.apache.org
Subject: RE: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release

Hi Alan,
Thanks for investigating the issue. Did you fix the hash ? Do you retract your 
-1 ?

@Petro Thanks for providing a explanation for the issue 

Best regards
Alin

-Original Message-
From: Alan Carvalho de Assis 
Sent: den 12 augusti 2022 02:38
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 10.4.0 (incubating) RC0 release

The most important I forgot to say:

Alin: reverting Petro's commit solves the issue, but is not the solution.

He fixed the issue, it is just incompatible with old hash. The solution is to 
fix the hash.

BR,

Alan

On 8/11/22, Alan Carvalho de Assis  wrote:
> Hi Petro,
>
> I think we don't want to be compatible with it if it was in fact faulty.
>
> The TEA algorithm by itself has some weakness as people can see here:
>
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Tiny_Encrypt
> ion_Algorithm__;!!JmoZiZGBv3RvKRSx!-xb49ukgyjFVAohl5rByBw6U6G89QqC7-aO
> 7eJyN4-0ToLVA9ga3FbLyC0QLlERRU2FCiH6_su8CI-UD$
>
> "TEA has a few weaknesses. Most notably, it suffers from equivalent 
> keys—each key is equivalent to three others, which means that the 
> effective key size is only 126 bits.[5] As a result, TEA is especially 
> bad as a cryptographic hash function. This weakness led to a method 
> for hacking Microsoft's Xbox game console, where the cipher was used 
> as a hash function."
>
> We could keep TEA support as an option (maybe for devices that don't 
> need strong security) but the default algo could be XTEA or some other 
> without known weakness.
>
> Just my 2 cents.
>
> BR,
>
> Alan
>
> On 8/11/22, Petro Karashchenko  wrote:
>> The code had an obvious bug when memory was accessed out of bounds.
>>
>> In some of the cases it was accessing zeroes and producing some 
>> output, but after my changes it started to work "as designed" and use 
>> "space" (not
>> zero) as padding.
>>
>> I'm not sure what is the best way to fix this. Changing padding 
>> symbol from "space" to zero should also make decryption working. I 
>> really do not know what is the best solution and what is better "to 
>> be right" or "to be backward compatible".
>>
>> Best regards,
>> Petro
>>
>> On Thu, Aug 11, 2022, 10:10 PM Alan Carvalho de Assis 
>> 
>> wrote:
>>
>>> ACK
>>>
>>> Strange, the previous email went only to you!
>>>
>>> On 8/11/22, Alin Jerpelea  wrote:
>>> > @Alan Carvalho de Assis   please confirm that 
>>> > works after revert
>>> >
>>> > On Thu, 11 Aug 2022, 20:22 Petro Karashchenko, 
>>> > 
>>> > wrote:
>>> >
>>> >> Hello Alan,
>>> >>
>>> >> Seems that the root cause is my change 
>>> >> https://urldefense.com/v3/__https://github.com/apache/incubator-n
>>> >> uttx-apps/pull/1097__;!!JmoZiZGBv3RvKRSx!-xb49ukgyjFVAohl5rByBw6U
>>> >> 6G89QqC7-aO7eJyN4-0ToLVA9ga3FbLyC0QLlERRU2FCiH6_ss9mT39r$
>>> >>
>>> >> I think that all previously generated passwords need to be 
>>> >> re-generated.
>>> >>
>>> >> Best regards,
>>> >> Petro
>>> >>
>>> >> On Thu, Aug 11, 2022, 8:49 PM Alan Carvalho de Assis 
>>> >> >> >
>>> >> wrote:
>>> >>
>>> >> > Alin,
>>> >> >
>>> >> > I want to redraw my vote, I found the first regression, so my 
>>> >> > vote
>>> >> > is:
>>> >> >
>>> >> > -1
>>> >> >
>>> >> > Seems like the console login is not working, I'm using user: 
>>> >> > admin and
>>> >> > password: Administrator
>>> >> >
>>> >> > $ ./tools/configure.sh sim:nsh
>>> >> >
>>> >> > $ make -j
>>> >> >
>>> >> > $ ./nuttx
>>> >> > login: admin
>>> >> > password:
>>> >> > Invalid username or password
>>> >> > login: admin
>>> >> > password:
>>> >> > Invalid username or password

RE: Subject: [VOTE] Apache NuttX 11.0.0 (incubating) RC2 release

[alin.jerpe...@sony.com]

Please test this release
We need some more votes to be able to create the release 

Best regards
Alin Jerpelea


-Original Message-
From: Xiang Xiao  
Sent: den 14 september 2022 19:53
To: dev@nuttx.apache.org
Subject: Re: Subject: [VOTE] Apache NuttX 11.0.0 (incubating) RC2 release

+1 with tools/checkelease.sh:
./tools/checkrelease.sh --release 11.0.0-RC2 Downloading release files from 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/incubator/nuttx/11.0.0-RC2/__;!!JmoZiZGBv3RvKRSx!_AM2wqhyvJXbdzPcQZFOXYpkBNNnZwGoKQnKS8BvvYvbskS3DKRb8iVUnDSCivUymvfOiZxGdtm_vcSa2jG3KyhsDOg$
gpg: directory '/tmp/nuttx-checkrelease/.gnupg' created
gpg: keybox '/tmp/nuttx-checkrelease/.gnupg/pubring.kbx' created
gpg: /tmp/nuttx-checkrelease/.gnupg/trustdb.gpg: trustdb created
gpg: key E1B6E30DB05D6280: public key "Brennan Ashton "
imported
gpg: key 2B8C7F0EAB22000E: public key "Abdelatif Guettouche (CODE SIGNING
KEY) " imported
gpg: key 4137A71698C5E4DB: public key "Alin Jerpelea "
imported
gpg: key 9E711BAD3264C061: public key "Alin Jerpelea "
imported
gpg: key A57CE1279F1E7328: public key "Alin Jerpelea (CODE SIGNING KEY) < 
jerpe...@apache.org>" imported
gpg: key 6E72660F995FBC42: public key "Brennan Ashton < 
bash...@brennanashton.com>" imported
gpg: Total number processed: 6
gpg:   imported: 6
 OK: 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/incubator/nuttx/KEYS__;!!JmoZiZGBv3RvKRSx!_AM2wqhyvJXbdzPcQZFOXYpkBNNnZwGoKQnKS8BvvYvbskS3DKRb8iVUnDSCivUymvfOiZxGdtm_vcSa2jG3QOvIo50$
   is
imported.
Checking apache-nuttx-11.0.0-incubating.tar.gz sha512...
 OK: apache-nuttx-11.0.0-incubating.tar.gz sha512 hash matches.

Checking apache-nuttx-11.0.0-incubating.tar.gz GPG signature:
gpg: Signature made Fri Sep  9 19:17:06 2022 CST
gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB
gpg: Good signature from "Alin Jerpelea " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 9208 D2E4 B800 D66F 749A  D4E9 4137 A716 98C5 E4DB
 OK: apache-nuttx-11.0.0-incubating.tar.gz gpg signature matches.

Checking apache-nuttx-11.0.0-incubating.tar.gz for required files:
 OK: all required files exist in nuttx.

Checking apache-nuttx-apps-11.0.0-incubating.tar.gz sha512...
 OK: apache-nuttx-apps-11.0.0-incubating.tar.gz sha512 hash matches.

Checking apache-nuttx-apps-11.0.0-incubating.tar.gz GPG signature:
gpg: Signature made Fri Sep  9 19:17:11 2022 CST
gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB
gpg: Good signature from "Alin Jerpelea " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 9208 D2E4 B800 D66F 749A  D4E9 4137 A716 98C5 E4DB
 OK: apache-nuttx-apps-11.0.0-incubating.tar.gz gpg signature matches.

Checking apache-nuttx-apps-11.0.0-incubating.tar.gz for required files:
 OK: all required files exist in apps.

Trying to build nuttx sim:asan...
 OK: we were able to build sim:asan.

Trying to run nuttx sim:asan...
==25236==WARNING: ASan is ignoring requested __asan_handle_no_return: stack
top: 0x7ffd0b573000; bottom 0x63123000; size: 0x1ced0b55
(31804422946816)
False positive error reports may follow
For details see 
https://urldefense.com/v3/__https://github.com/google/sanitizers/issues/189__;!!JmoZiZGBv3RvKRSx!_AM2wqhyvJXbdzPcQZFOXYpkBNNnZwGoKQnKS8BvvYvbskS3DKRb8iVUnDSCivUymvfOiZxGdtm_vcSa2jG3WBSDneE$
 OK: ostest with ASAN pass.

On Fri, Sep 9, 2022 at 7:28 PM Alin Jerpelea  wrote:

> Hello all,
> Apache NuttX (Incubating) 11.0.0 RC2 has been staged under [1] and 
> it's time to vote on accepting it for release. If approved we will 
> seek final release approval from the IPMC. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 
> are required to pass.
>
> The Apache requirements for approving a release can be found here [3] 
> "Before voting +1 [P]PMC members are required to download the signed 
> source code package, compile it as provided, and test the resulting 
> executable on their own platform, along with also verifying that the 
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on 
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM 
> items in [4]) [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
> SCM Information:
>   Release tag: nuttx-11.0.0-RC2
>   Hash for the release incubating-nuttx tag:
> d32555f3e0492b8f4caeb407db55de23322724ef
>   Hash for the release incubating-nuttx-apps tag:
> 8b43f9f9ca30f44c1cccae9a9078d5d45b776d35
>
> [1] 
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/inc
> ubator/nuttx/11.0.0-RC

RE: dummy folders in nuttx tree

[alin.jerpe...@sony.com]

Hi Daniel,

There are boards (ex Spresense) that use drivers that are unique for those 
platforms 
In this case we use the symlinks to drivers folder but keep the drivers under 
the specific board that uses them 

Best regards
Alin


-Original Message-
From: Daniel Pereira Carvalho  
Sent: den 3 oktober 2022 21:02
To: dev@nuttx.apache.org
Subject: dummy folders in nuttx tree

Hi guys,

Looking at nuttx folders I saw two folders called "dummy", specifically 
nuttx/dummy and nuttx/drivers/dummy. The last one is referenced by the symbolic 
link nuttx/drivers/platform. What is the reason for this?

Thanks

Daniel Pereira de Carvalho

RE: NuttX Wikipedia entry vandalized

[alin.jerpe...@sony.com]

Hi All,

Looking at history, the claim regarding content (that we had during summer) and 
the edit history 
I think that the editor did not compare our page with other RTOS.
https://en.wikipedia.org/wiki/Zephyr_(operating_system)

Best regards
Alin

-Original Message-
From: Alan C. Assis  
Sent: den 4 oktober 2022 16:33
To: dev 
Subject: NuttX Wikipedia entry vandalized

Hi Eveyone,

I went to Wikipedia to get a link to show Victor about nice project using 
NXWidgets and NXWM, but I noticed the page is "completely"
empty.

Just look the history and click on October 2021 to see the difference.

BR,

Alan

RE: dummy folders in nuttx tree

[alin.jerpe...@sony.com]

Hi Daniel,

I think that it is possible to replicate the changes from Spresense for your 
own board

Please check: 
tool/Unix.mk
boards/arm/cxd56xx/drivers/Kconfig
drivers/Kconfig

Best regards
Alin

-Original Message-
From: Daniel Pereira Carvalho  
Sent: den 4 oktober 2022 20:34
To: dev@nuttx.apache.org
Subject: Re: dummy folders in nuttx tree

Hi Alin,

So, I suppose that if I have a custom driver that I have no reason to share and 
I want to keep it outside the NuttX folder tree, I can point the 
nuttx/driver/platform symlink to the custom driver folder. Doing this the 
Kconfig will appear on menuconfig. Is this correct?

If this is correct I am doing something wrong because it does not work for me. 
When I configure the board the symlink I just created is overwritten to 
original configuration, and restoring the symlink does not work either.

How should I proceed to build a custom driver outside the NuttX folder tree 
using this approach?

Thanks

Daniel Pereira de Carvalho


Em ter., 4 de out. de 2022 às 04:25, alin.jerpe...@sony.com < 
alin.jerpe...@sony.com> escreveu:

> Hi Daniel,
>
> There are boards (ex Spresense) that use drivers that are unique for 
> those platforms In this case we use the symlinks to drivers folder but 
> keep the drivers under the specific board that uses them
>
> Best regards
> Alin
>
>
> -Original Message-
> From: Daniel Pereira Carvalho 
> Sent: den 3 oktober 2022 21:02
> To: dev@nuttx.apache.org
> Subject: dummy folders in nuttx tree
>
> Hi guys,
>
> Looking at nuttx folders I saw two folders called "dummy", 
> specifically nuttx/dummy and nuttx/drivers/dummy. The last one is 
> referenced by the symbolic link nuttx/drivers/platform. What is the reason 
> for this?
>
> Thanks
>
> Daniel Pereira de Carvalho
>

RE: 11.0.0 - released?

[alin.jerpe...@sony.com]

Hi Tim
We are waiting for the IPMC vote so that we can release RC2 as final 
Best regards
Alin


-Original Message-
From: TimH  
Sent: den 7 oktober 2022 15:48
To: dev@nuttx.apache.org
Subject: 11.0.0 - released?

Have been waiting for 11.0.0 to be released so I can merge into my 10.3 
efforts. I see 11.0 is on GitHub under releases, but when I start the merge, 
files appear to be tagged with nuttx-11.0.0-RC2. I also don't recall seeing an 
email here about the release.

 

Before I continue, can someone confirm that the 11.0 release on GitHub is the 
pukka release, please?

RE: Article: NuttX RTOS for PinePhone: Render Graphics in Zig

[alin.jerpe...@sony.com]

NICE!


-Original Message-
From: Tomek CEDRO  
Sent: den 15 november 2022 14:18
To: dev@nuttx.apache.org
Subject: Re: Article: NuttX RTOS for PinePhone: Render Graphics in Zig

CONGRATZ! :-)

-- 
CeDeROM, SQ7MHZ, 
https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!JmoZiZGBv3RvKRSx!7DpXb6g0WSb3fJwyPE1svv9Fqc4z9Y8fCGPJoHURahXPSK06X_Vj99tzpIhuPkZw-WaROCwlXuiRc5S8YQ$
 

RE: Will a PR be ignored if it fails checks?

[alin.jerpe...@sony.com]

Hi Tim,

Please fix the warning / error without waiting for someone to review it. 

Best regards
Alin


-Original Message-
From: Tim Hardisty  
Sent: den 15 november 2022 20:25
To: dev@nuttx.apache.org
Subject: Will a PR be ignored if it fails checks?

As subject really. My (first real) PR failed some checks due to an unused 
variable. An easy fix, but I wanted to wait for any other feedback before 
resubmittingbut not much point waiting if the fail will mean no one reviews 
it lol.

What's the process?

RE: Will a PR be ignored if it fails checks?

[alin.jerpe...@sony.com]

Hi Tim, 

I usually do the following steps: 
- compile locally the patch and test it 
- run nxstyle to ensure that there are no errors
- let the CI run and fix errors
- wait for others to review and comment 

Best regards
Alin


-Original Message-
From: Tim Hardisty  
Sent: den 16 november 2022 11:58
To: dev@nuttx.apache.org
Subject: Re: Will a PR be ignored if it fails checks?

Hi Alin,

Ok - will do.

I ran the checkpatch script as per guides - should I have done something else 
as well before submitting a PR?

Thanks,

Tim.

On 16/11/2022, 08:00, "alin.jerpe...@sony.com"  wrote:

Hi Tim,

Please fix the warning / error without waiting for someone to review it. 

Best regards
Alin


-Original Message-
From: Tim Hardisty  
Sent: den 15 november 2022 20:25
To: dev@nuttx.apache.org
Subject: Will a PR be ignored if it fails checks?

As subject really. My (first real) PR failed some checks due to an unused 
variable. An easy fix, but I wanted to wait for any other feedback before 
resubmittingbut not much point waiting if the fail will mean no one reviews 
it lol.

What's the process?

RE: New names of repositories

[alin.jerpe...@sony.com]

Ok from me 
//Alin

-Original Message-
From: Nathan Hartman  
Sent: den 22 november 2022 14:30
To: dev@nuttx.apache.org
Subject: Re: New names of repositories

After hearing back from Infra about the repository naming convention, all the 
recent feedback has been to stay with the default and just remove "incubator-" 
from our repo names, giving:

https://urldefense.com/v3/__https://github.com/apache/nuttx__;!!JmoZiZGBv3RvKRSx!7pBPRw-m9zdGEIOK5hGfMZsKBSb1mH2hvGpMYd65kA6s2hRw75LAa6YUjFbcrOg32iG3vvO9_ow53v-3ATYj4qL1SA$
https://urldefense.com/v3/__https://github.com/apache/nuttx-apps__;!!JmoZiZGBv3RvKRSx!7pBPRw-m9zdGEIOK5hGfMZsKBSb1mH2hvGpMYd65kA6s2hRw75LAa6YUjFbcrOg32iG3vvO9_ow53v-3ATbTbs2f3A$
 

Shall I go ahead and open the Jira ticket to do that?

Cheers,
Nathan

RE: Code donation

[alin.jerpe...@sony.com]

Thanks Fotis 
I will take a look at them in the following weeks 
Best regards
Alin

-Original Message-
From: Fotis Panagiotopoulos  
Sent: den 5 december 2022 12:23
To: dev@nuttx.apache.org
Subject: Re: Code donation

Hello!

Thank you for your interest in this!

As requested, I created a temporal repository and uploaded all the code there.

https://urldefense.com/v3/__https://github.com/fjpanag/code_for_nuttx__;!!JmoZiZGBv3RvKRSx!4hM5s0Gw9fjGJlW4x9uHvWIH4_FDFUyuYvimXNh6Lcu6c2CAQgyay7oq3JogNz8P3LyQoTxBfNy32UmQ-uU$
 

I have added a NOTICE file in each subdir, with some basic information.
Please contact me before starting any work, to provide you with help and 
coordinate the effort.
Better yet, you may open a Github issue for the piece of software that you 
would like to help porting.


Alan,
I would love to cooperate with you in this effort.
Pick your target!


Alin,
I would really like to see my MQTT broker become part of NuttX.

Alternatively, you can have a look at the XML or JSON parsers, which are of 
general usefulness, and the porting effort would be very very minimal.


Tim,
Thank you for your interest in the settings storage.
It is a very useful and versatile piece of software. In fact, I have used it in 
all my projects over the last 5-6 years.

I also thought about YAML before, but never got to actually implementing this.

I suggest you first add a YAML parser to NuttX (maybe similarly to JSON and 
XML, if they get accepted), and then use it in the settings storage. It would 
be best not to couple these two softwares so someone may use one without the 
other. But, nevertheless, it is your call...

If you provide me with a YAML parser, I believe that I can develop for you a 
new settings storage that uses this parser.

Fotis

On Mon, Dec 5, 2022 at 12:12 AM Tim Hardisty 
wrote:

> I have interest in your settings storage, with the probability of 
> adding yaml output since I was going to do something similar for my 
> current project (once I get over the pain of getting NuttX fixed for 
> the arch I'm using).
>
> As have been suggested, maybe push it to github and I/we can clone 
> what's of interest, see if it makes sense, then get it working right 
> for NuttX and do a PR...in the fullness of time (i.e. I'm a slow 
> worker!)
>
> On 04/12/2022, 16:55, "Fotis Panagiotopoulos" 
> wrote:
>
> Hello everyone!
>
> Christmas arrived a bit earlier for NuttX as I would like to 
> donate some of
> my personal code to the community!
>
> A bit of context.
> Over the years that I am working on embedded systems, I have 
> developed lots
> of software that I use in my projects.
> Some of it is quite general-purpose, or useful for other 
> applications, and
> I have found my self reusing it
> quite often. In fact, there are some things that I use in 
> practically all
> firmwares that I have developed over
> the last years.
>
> I always wanted to open-source this software so other people can 
> benefit
> from it.
> But I never managed to do so. Open-sourcing needs some effort, the 
> software
> needs maintenance, documentation
> and support, and most importantly in most cases a "porting layer"
> needs to
> be developed.
> Last but not least, every project needs a bit of "marketing" and
> "advertising" so others can learn about
> your work and use it.
>
> For the last couple of years I have been using NuttX a lot, and I have
> ported most of the aforementioned software
> to NuttX. I believe that NuttX and its community are perfect for me to
> publish my code, instead of creating
> a ton of small repos, of questionable usefulness and increasing my 
> workload
> considerably.
>
> It is very important that I can get immediate feedback from the 
> community,
> learn what people are actually
> interested in (instead of investing on software that no one needs), and
> provide actual and *working*
> samples of the code (as NuttX already supports a ton of different 
> boards
> and arches).
>
> Using POSIX as the porting layer is also awesome.
>
> That being said, my free time is still exceptionally limited and I 
> cannot
> do this myself.
> I still need the help of the community, and most importantly I 
> need to see
> interest in a piece of
> software before putting any work on it.
>
> So, what I offer:
> * I offer various codes, fully featured, production ready and tested.
> * All code will be offered for free (of course) and under Apache 
> licensing.
> * I will provide support to those working on these codes, to my best
> ability.
> * I will contribute to testing everything integrated to NuttX, as 
> hardware
> availability allows me.
> * I will do some licensing check, to ensure code is 100% original 
> and mine,
> or state the licenses of the projects I borrowed code from.
>
> What I ask for:
> I need people th

RE: DISCUSS: migrate licenses to SPDX

[alin.jerpe...@sony.com]

Hi,
From my understanding our project would only replace the current license with 

"SPDX-License-Identifier: Apache-2.0" which is suggested in the same page

Best regards
Alin

-Original Message-
From: Abdelatif Guettouche  
Sent: den 15 december 2022 12:46
To: dev@nuttx.apache.org
Subject: Re: DISCUSS: migrate licenses to SPDX

We need to consider this:
https://urldefense.com/v3/__https://www.apache.org/foundation/license-faq.html*Apply-My-Software__;Iw!!JmoZiZGBv3RvKRSx!8eeI5bFJkw51EhNao_c2z-Qw1fXSI9Qk76b-9ssVKGA6HlNYchFxjnbm8lPShd7X7jkHErUAnzBzg7oKDq3gH_aCciXg$
 

> Note that the Apache Software Foundation uses a different source header that 
> is related to our use of a CLA. Our instructions for our project's source 
> headers are here.

On Thu, Dec 15, 2022 at 8:02 AM Alin Jerpelea  wrote:
>
>  Hi,
>
> It looks like the SPDX standard is used by many businesses and it may 
> have a major deciding factor when an RTOS is picked for a product
>
> More info regarding SPDX
> https://urldefense.com/v3/__https://spdx.dev/__;!!JmoZiZGBv3RvKRSx!8ee
> I5bFJkw51EhNao_c2z-Qw1fXSI9Qk76b-9ssVKGA6HlNYchFxjnbm8lPShd7X7jkHErUAn
> zBzg7oKDq3gHxWdDS9D$
>
> Do you think that we should follow the trend and migrate our licenses 
> to the SPDX format?
>
> Best regards
> Alin

RE: [VOTE] Apache NuttX 12.0.0 RC1 release

[alin.jerpe...@sony.com]

+1, test with sim and spresense

./nuttx/tools/checkrelease.sh --release 12.0.0-RC1
Downloading release files from 
https://dist.apache.org/repos/dist/dev/nuttx/12.0.0-RC1/
gpg: directory '/tmp/nuttx-checkrelease/.gnupg' created
gpg: keybox '/tmp/nuttx-checkrelease/.gnupg/pubring.kbx' created
gpg: /tmp/nuttx-checkrelease/.gnupg/trustdb.gpg: trustdb created
gpg: key E1B6E30DB05D6280: public key "Brennan Ashton " 
imported
gpg: key 2B8C7F0EAB22000E: public key "Abdelatif Guettouche (CODE SIGNING KEY) 
" imported
gpg: key 4137A71698C5E4DB: public key "Alin Jerpelea " 
imported
gpg: key 9E711BAD3264C061: public key "Alin Jerpelea " 
imported
gpg: key A57CE1279F1E7328: public key "Alin Jerpelea (CODE SIGNING KEY) 
" imported
gpg: key 6E72660F995FBC42: public key "Brennan Ashton 
" imported
gpg: Total number processed: 6
gpg:   imported: 6
 OK: https://dist.apache.org/repos/dist/dev/nuttx/KEYS is imported.
Checking apache-nuttx-12.0.0.tar.gz sha512...
 OK: apache-nuttx-12.0.0.tar.gz sha512 hash matches.

Checking apache-nuttx-12.0.0.tar.gz GPG signature:
gpg: Signature made ons 11 jan 2023 10:24:17 CET
gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB
gpg: Good signature from "Alin Jerpelea " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9208 D2E4 B800 D66F 749A  D4E9 4137 A716 98C5 E4DB
 OK: apache-nuttx-12.0.0.tar.gz gpg signature matches.

Checking apache-nuttx-12.0.0.tar.gz for required files:
 OK: all required files exist in nuttx.

Checking apache-nuttx-apps-12.0.0.tar.gz sha512...
 OK: apache-nuttx-apps-12.0.0.tar.gz sha512 hash matches.

Checking apache-nuttx-apps-12.0.0.tar.gz GPG signature:
gpg: Signature made ons 11 jan 2023 10:24:18 CET
gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB
gpg: Good signature from "Alin Jerpelea " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9208 D2E4 B800 D66F 749A  D4E9 4137 A716 98C5 E4DB
 OK: apache-nuttx-apps-12.0.0.tar.gz gpg signature matches.

Checking apache-nuttx-apps-12.0.0.tar.gz for required files:
 OK: all required files exist in apps.

Trying to build nuttx sim:asan...
 OK: we were able to build sim:asan.

Trying to run nuttx sim:asan...
==3969392==WARNING: ASan is ignoring requested __asan_handle_no_return: stack 
top: 0x7ffed7e91000; bottom 0x63123000; size: 0x1ceed7e6e000 
(31812150026240)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189
 OK: ostest with ASAN pass.

-Original Message-
From: Xiang Xiao  
Sent: den 16 januari 2023 04:33
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 12.0.0 RC1 release

+1, test with sim:
./tools/checkrelease.sh --release 12.0.0-RC1 Downloading release files from 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/nuttx/12.0.0-RC1/__;!!JmoZiZGBv3RvKRSx!9-O6uEYHyEPDWJpjGUx7F_xcrKae51fdr41Ym86MLvcXH1l-7e3RDgl5NP8dnOp2eNirlRywA_r2VPYkNNSAUBjcat4$
gpg: directory '/tmp/nuttx-checkrelease/.gnupg' created
gpg: keybox '/tmp/nuttx-checkrelease/.gnupg/pubring.kbx' created
gpg: /tmp/nuttx-checkrelease/.gnupg/trustdb.gpg: trustdb created
gpg: key E1B6E30DB05D6280: public key "Brennan Ashton "
imported
gpg: key 2B8C7F0EAB22000E: public key "Abdelatif Guettouche (CODE SIGNING
KEY) " imported
gpg: key 4137A71698C5E4DB: public key "Alin Jerpelea "
imported
gpg: key 9E711BAD3264C061: public key "Alin Jerpelea "
imported
gpg: key A57CE1279F1E7328: public key "Alin Jerpelea (CODE SIGNING KEY) < 
jerpe...@apache.org>" imported
gpg: key 6E72660F995FBC42: public key "Brennan Ashton < 
bash...@brennanashton.com>" imported
gpg: Total number processed: 6
gpg:   imported: 6
 OK: 
https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/nuttx/KEYS__;!!JmoZiZGBv3RvKRSx!9-O6uEYHyEPDWJpjGUx7F_xcrKae51fdr41Ym86MLvcXH1l-7e3RDgl5NP8dnOp2eNirlRywA_r2VPYkNNSA6RX7Nis$
  is imported.
Checking apache-nuttx-12.0.0.tar.gz sha512...
 OK: apache-nuttx-12.0.0.tar.gz sha512 hash matches.

Checking apache-nuttx-12.0.0.tar.gz GPG signature:
gpg: Signature made Wed Jan 11 17:24:17 2023 CST
gpg:using RSA key 9208D2E4B800D66F749AD4E94137A71698C5E4DB
gpg: Good signature from "Alin Jerpelea " [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: 9208 D2E4 B800 D66F 749A  D4E9 4137 A716 98C5 E4DB
 OK: apache-nuttx-12.0.0.tar.gz gpg signature matches.

Checking apache-nuttx-12.0.0.tar.gz for required files:
 OK: all required files exist in nuttx.

Checking apache-nuttx-apps-12.0.0.tar.gz sha512...
 OK: apache-nuttx-apps-12.0.0.tar.gz sha512 hash matches.

Checking apache-nuttx-apps-12.0.0.tar.gz GPG 

RE: [OT] Coral board a nice board to run TFLite Micro (and awaiting for NuttX on it)

[alin.jerpe...@sony.com]

Thanks


-Original Message-
From: Alan C. Assis  
Sent: den 4 februari 2023 22:52
To: dev 
Subject: [OT] Coral board a nice board to run TFLite Micro (and awaiting for 
NuttX on it)

FYI:

https://urldefense.com/v3/__https://www.hackster.io/news/google-opens-pre-orders-for-the-coral-dev-board-micro-its-first-microcontroller-development-board-73664dd48266__;!!JmoZiZGBv3RvKRSx!-tNeqVxN9TNfrZPbkOHGfnnu1B8G1VDqoPuDGNqc4J2ejXrmM7RKpsjzfHFN4WQoo8S-6HzKcDB5tDBl$
 

RE: NuttX is broken

[alin.jerpe...@sony.com]

Hi Sebastien,

I checked the logs and the lib_strsignal.c is untouched for a long time 
I would start debugging with make -j1

Best regards
Alin


-Original Message-
From: Sebastien Lorquet  
Sent: den 7 mars 2023 09:26
To: dev@nuttx.apache.org
Subject: NuttX is broken

What is this?

NuttX is broken.

I ran make distclean, used the same defconfig, and I get this:


CC:  string/lib_strsignal.c string/lib_strsignal.c: In function 'strsignal':
string/lib_strsignal.c:169:7: error: duplicate case value
   169 |   case SIGWORK:
   |   ^~~~
string/lib_strsignal.c:117:7: note: previously used here
   117 |   case SIGCHLD:
   |   ^~~~
make[1]: *** [Makefile:134: bin//lib_strsignal.o] Error 1
make: *** [tools/LibTargets.mk:180: libs/libc/libc.a] Error 2

Please stop the commit race and stop breaking nuttx


While having a look at this file I just found this:

/* We don't know what signals names will be assigned to which signals in
  * advance and we do not want to return a volatile value.  One solution is
  * this silly array of useless names:
  */

static FAR const char *g_default_sigstr[32] = {
   "Signal 0",
   "Signal 1",
   "Signal 2",
   "Signal 3",
   "Signal 4",
   "Signal 5",
   "Signal 6",
   "Signal 7",
   "Signal 8",
   "Signal 9",
   "Signal 10",
   "Signal 11",
   "Signal 12",
   "Signal 13",
   "Signal 14",
   "Signal 15",
   "Signal 16",
   "Signal 17",
   "Signal 18",
   "Signal 19",
   "Signal 20",
   "Signal 21",
   "Signal 22",
   "Signal 23",
   "Signal 24",
   "Signal 25",
   "Signal 26",
   "Signal 27",
   "Signal 28",
   "Signal 29",
   "Signal 30",
   "Signal 31",
};

What the actual FUCK, and I mean it, is THIS?

What does this comment mean? Who is WE?

Who has gigabytes of flash to waste to such garbage?

Who has accepted that commit?

Is anyone aware of the sprintf function?

Sebastien

RE: Build system is broken

[alin.jerpe...@sony.com]

Hi Sebastien, 

The commit 03b164f59ce40a3f5677b0588af2aee8d9697bf6  tools/makefile: silent all 
compile output

It has been reviewed and approved by several members 
https://github.com/apache/nuttx/pull/8378

Best regards
Alin


-Original Message-
From: Sebastien Lorquet  
Sent: den 7 mars 2023 14:12
To: dev@nuttx.apache.org
Subject: Re: Build system is broken

Hi,

Do your realize how counter-intuitive this is?

I would have NEVER imagined that V=0 is not the exact contrary of V=1!

Can this silent mode be made optional in a config setting please? It is really 
a non-feature. it's just a fantasy to please some committer, and should have 
never been accepted imho.


When I want to contribute a one liner to submit a new flash chip I get forced 
to wait 48 hours for useless automatic tests that will not even compile my new 
code, and such profound changes gets integrated immediately with almost no 
review other than an automatic build. I know it because some commits do not 
have corresponding pull requests.

This gives a feeling of double standard that does not seem in line with the 
inviolables of this project.


Tomek: Thanks, but I am not interested in workarounds that look like 
"here is a way to avoid asking why a change was made".


Sebastien

On 3/7/23 13:45, Nathan Hartman wrote:
> On Tue, Mar 7, 2023 at 7:23 AM Tomek CEDRO  wrote:
>
>> On Tue, Mar 7, 2023 at 9:24 AM Sebastien Lorquet wrote:
>>> No
>>> V=1 is an entirely different thing.
>>> I dont want to see the output mangled with tons of arm-none-eabi-gcc
>>> command lines.
>>> This stuff is another breakage
>>> Sebastien
>
>
> There is V=0 which gives the same output as before.
>
> It needs to be documented somehow, and in a way that people will see it, or
> we will get a lot of complaints and questions about it after the next
> release.
>
> Nathan
>

RE: DISCUSSION - Usage of mailing lists for apache projects

[alin.jerpe...@sony.com]

Hi all, 

I  feel that this thread is getting too long without a real outcome 

Some observations from my daily interactions with the project:
- I like doing reviews on github and I think that many people in this thread 
would agree that this flow is good.
- I like to be able to see all bugs in one place and get statistics  for the 
ASF reports

What I don’t feel right 
- even if I spend time daily on reviewing patches there are still changes that 
I miss and it is hard to get the flow on release date 
- some breaking changes are not discussed enough with the community since there 
are some people that do not have time to review code on gihub.

As a way going forward I propose that we improve in 2 aspects 
- All breaking commits should be discusses on dev so that people get enough 
time to digest the change and even better get involved int the flow
- all breaking changes should be documented on the release confluence page 
before merging so that we don’t miss mentioning them on release date.
- there should be at least 1 independent reviewer (not from the same company) 
so that a patch is merged except board changes (ex an employee from the same 
company merges a patch submitted by another employee from the same company, for 
a board provided by the same company)

Thanks 
Alin

-Original Message-
From: Alan C. Assis  
Sent: den 8 mars 2023 19:15
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects

Hi Lwazi,

It is not sarcarm, I'm talking about facts.

Also I didn't say Sebastien points aren't valid, but is diverting from the real 
issue.

The issue is not if the discussion is happening here or there, the Problem is 
that we don't have enough reviewers.

So, first step is that NuttX needs to increase the user base, but have few 
users really engaged with the project, reviewing patches every single day. 
Currently today he have few: Petro and Xiang are exceptional on this point. 
They are my inspiration to try do more!

Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you 
again! You have a great knowledge of BLE can we need! I was expecting you to 
share that working example of BLE application using our BLE stack).

BR,

Alan

On 3/8/23, Lwazi Dube  wrote:
> On Wed, 8 Mar 2023 at 09:55, Alan C. Assis  wrote:
>>
>> Sebastien,
>>
>> If all the discussions that happens on github start to happen here, 
>> this mailing list will be just like the nuttx-commits mailing list.
>
> I'll take this as sarcasm. Sebastien is making a lot of valid points, 
> in good faith, and being dismissive does not help the community.
>

RE: DISCUSSION - Usage of mailing lists for apache projects

[alin.jerpe...@sony.com]

Hi all,

I agree with David but in my opinion this information should go in the commit 
message and no commit without message should be merged.
Not all people will check the PR message but you will always see the reasons 
simply by typing "git log" if they are in the commit message

What do you think ?

Thanks 
Alin


-Original Message-
From: David Sidrane  
Sent: den 9 mars 2023 10:00
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: RE: DISCUSSION - Usage of mailing lists for apache projects

I would add that all pull request must have a statement explaining the reason 
or motivation for the change(s).

Just stating the "What" was done is not enough. There must be a "Why" the 
change is needed.

David

-----Original Message-
From: alin.jerpe...@sony.com 
Sent: Thursday, March 9, 2023 3:39 AM
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: RE: DISCUSSION - Usage of mailing lists for apache projects

Hi all,

I  feel that this thread is getting too long without a real outcome

Some observations from my daily interactions with the project:
- I like doing reviews on github and I think that many people in this thread 
would agree that this flow is good.
- I like to be able to see all bugs in one place and get statistics  for the 
ASF reports

What I don’t feel right
- even if I spend time daily on reviewing patches there are still changes that 
I miss and it is hard to get the flow on release date
- some breaking changes are not discussed enough with the community since there 
are some people that do not have time to review code on gihub.

As a way going forward I propose that we improve in 2 aspects
- All breaking commits should be discusses on dev so that people get enough 
time to digest the change and even better get involved int the flow
- all breaking changes should be documented on the release confluence page 
before merging so that we don’t miss mentioning them on release date.
- there should be at least 1 independent reviewer (not from the same
company) so that a patch is merged except board changes (ex an employee from 
the same company merges a patch submitted by another employee from the same 
company, for a board provided by the same company)

Thanks
Alin

-Original Message-
From: Alan C. Assis 
Sent: den 8 mars 2023 19:15
To: dev@nuttx.apache.org
Cc: Sebastien Lorquet 
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects

Hi Lwazi,

It is not sarcarm, I'm talking about facts.

Also I didn't say Sebastien points aren't valid, but is diverting from the real 
issue.

The issue is not if the discussion is happening here or there, the Problem is 
that we don't have enough reviewers.

So, first step is that NuttX needs to increase the user base, but have few 
users really engaged with the project, reviewing patches every single day.
Currently today he have few: Petro and Xiang are exceptional on this point.
They are my inspiration to try do more!

Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear from you 
again! You have a great knowledge of BLE can we need! I was expecting you to 
share that working example of BLE application using our BLE stack).

BR,

Alan

On 3/8/23, Lwazi Dube  wrote:
> On Wed, 8 Mar 2023 at 09:55, Alan C. Assis  wrote:
>>
>> Sebastien,
>>
>> If all the discussions that happens on github start to happen here, 
>> this mailing list will be just like the nuttx-commits mailing list.
>
> I'll take this as sarcasm. Sebastien is making a lot of valid points, 
> in good faith, and being dismissive does not help the community.
>

RE: DISCUSSION - Usage of mailing lists for apache projects

[alin.jerpe...@sony.com]

Hi Xiang,

Simply add some reviewers on the right side and they will be notified that 
someone asks them to step up

Best regards
Alin


-Original Message-
From: Xiang Xiao  
Sent: den 9 mars 2023 10:12
To: dev@nuttx.apache.org
Subject: Re: DISCUSSION - Usage of mailing lists for apache projects

If some PR waits for a long time without any review, how to make progress?
For example, this PR sent two weaks ago:
https://github.com/apache/nuttx/pull/8610 

On Thu, Mar 9, 2023 at 4:40 PM alin.jerpe...@sony.com < alin.jerpe...@sony.com> 
wrote:

> Hi all,
>
> I  feel that this thread is getting too long without a real outcome
>
> Some observations from my daily interactions with the project:
> - I like doing reviews on github and I think that many people in this 
> thread would agree that this flow is good.
> - I like to be able to see all bugs in one place and get statistics  
> for the ASF reports
>
> What I don’t feel right
> - even if I spend time daily on reviewing patches there are still 
> changes that I miss and it is hard to get the flow on release date
> - some breaking changes are not discussed enough with the community 
> since there are some people that do not have time to review code on gihub.
>
> As a way going forward I propose that we improve in 2 aspects
> - All breaking commits should be discusses on dev so that people get 
> enough time to digest the change and even better get involved int the 
> flow
> - all breaking changes should be documented on the release confluence 
> page before merging so that we don’t miss mentioning them on release date.
> - there should be at least 1 independent reviewer (not from the same
> company) so that a patch is merged except board changes (ex an 
> employee from the same company merges a patch submitted by another 
> employee from the same company, for a board provided by the same 
> company)
>
> Thanks
> Alin
>
> -Original Message-
> From: Alan C. Assis 
> Sent: den 8 mars 2023 19:15
> To: dev@nuttx.apache.org
> Cc: Sebastien Lorquet 
> Subject: Re: DISCUSSION - Usage of mailing lists for apache projects
>
> Hi Lwazi,
>
> It is not sarcarm, I'm talking about facts.
>
> Also I didn't say Sebastien points aren't valid, but is diverting from 
> the real issue.
>
> The issue is not if the discussion is happening here or there, the 
> Problem is that we don't have enough reviewers.
>
> So, first step is that NuttX needs to increase the user base, but have 
> few users really engaged with the project, reviewing patches every single day.
> Currently today he have few: Petro and Xiang are exceptional on this point.
> They are my inspiration to try do more!
>
> Welcome back go NuttX Lwazi (I'm not been sarcastic, I'm happy to hear 
> from you again! You have a great knowledge of BLE can we need! I was 
> expecting you to share that working example of BLE application using 
> our BLE stack).
>
> BR,
>
> Alan
>
> On 3/8/23, Lwazi Dube  wrote:
> > On Wed, 8 Mar 2023 at 09:55, Alan C. Assis  wrote:
> >>
> >> Sebastien,
> >>
> >> If all the discussions that happens on github start to happen here, 
> >> this mailing list will be just like the nuttx-commits mailing list.
> >
> > I'll take this as sarcasm. Sebastien is making a lot of valid 
> > points, in good faith, and being dismissive does not help the community.
> >
>

RE: [VOTE] Apache NuttX 12.1.0 RC0 release

[alin.jerpe...@sony.com]

@Tomek 

We need +1 or -1

Does the "ERROR undefined symbol: backtrace " error appear on master?

Thanks 
Alin


-Original Message-
From: Tomek CEDRO  
Sent: den 12 april 2023 05:45
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 12.1.0 RC0 release

Quick test on FreeBSD AMD64 13.2-RELEASE-p0 (upgraded today from 
13.1-RELEASE-p6).

FreeBSD octagon 13.2-RELEASE FreeBSD 13.2-RELEASE
releng/13.2-n254617-525ecfdad597 GENERIC amd64

ESP32 builds work fine, but sim:nsh build fails at linking backtrace o_O



1. ESP32-DEVKITC (OK, log truncated)

1.1. CoreMark (OK)

gmake distclean
./tools/configure.sh -B esp32-devkitc:coremark gmake gmake flash 
ESPTOOL_PORT=/dev/cuaU0 ESPTOOL_BAUD=115200

cu -l /dev/cuaU0 -s 115200

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:5656
load:0x40078000,len:12696
load:0x40080400,len:4292
entry 0x400806b0
Running CoreMark...
2K performance run parameters for coremark.
CoreMark Size: 666
Total ticks  : 12180
Total time (secs): 12.18
Iterations/Sec   : 985.221675
Iterations   : 12000
Compiler version : GCC8.4.0
Compiler flags   : -O3 -fno-strict-aliasing -fomit-frame-pointer
-ffunction-sections -fdata-sections
Parallel PThreads : 2
Memory location  : Stack
seedcrc  : 0xe9f5
[0]crclist   : 0xe714
[1]crclist   : 0xe714
[0]crcmatrix : 0x1fd7
[1]crcmatrix : 0x1fd7
[0]crcstate  : 0x8e3a
[1]crcstate  : 0x8e3a
[0]crcfinal  : 0xa14c
[1]crcfinal  : 0xa14c
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 985.221675 / GCC8.4.0 -O3 -fno-strict-aliasing 
-fomit-frame-pointer -ffunction-sections -fdata-sections / Stack / 2:PThreads


1.2. NSH (OK)

gmake distclean
./tools/configure.sh -B esp32-devkitc:nsh gmake gmake flash 
ESPTOOL_PORT=/dev/cuaU0 ESPTOOL_BAUD=115200

cu -l /dev/cuaU0 -s 115200

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:5656
load:0x40078000,len:12696
load:0x40080400,len:4292
entry 0x400806b0

NuttShell (NSH) NuttX-12.1.0
nsh> uname -a
NuttX 12.1.0 d40f4032fc-dirty Apr 12 2023 04:26:43 xtensa esp32-devkitc
nsh> exit
~
[EOT]


2. SIM (build error in nsh)

2.1. ostest (OK)

gmake distclean
./tools/configure.sh -B sim:ostest
gmake

./nuttx
stdio_test: write fd=1
stdio_test: Standard I/O Check: printf
stdio_test: write fd=2
stdio_test: Standard I/O Check: fprintf to stderr
ostest_main: putenv(Variable1=BadValue3)
ostest_main: setenv(Variable1, GoodValue1, TRUE)
ostest_main: setenv(Variable2, BadValue1, FALSE)
ostest_main: setenv(Variable2, GoodValue2, TRUE)
ostest_main: setenv(Variable3, GoodValue3, FALSE)
ostest_main: setenv(Variable3, BadValue2, FALSE)
show_variable: Variable=Variable1 has value=GoodValue1
show_variable: Variable=Variable2 has value=GoodValue2
show_variable: Variable=Variable3 has value=GoodValue3
ostest_main: Started user_main at PID=4

user_main: Begin argument test
user_main: Started with argc=5
user_main: argv[0]="ostest"
user_main: argv[1]="Arg1"
user_main: argv[2]="Arg2"
user_main: argv[3]="Arg3"
user_main: argv[4]="Arg4"

End of test memory usage:
VARIABLE  BEFORE   AFTER
  
arena 3fffd80  3fffd80
ordblks 22
mxordblk  3fb9a40  3fb9a40
uordblks4631046310
fordblks  3fb9a70  3fb9a70

user_main: getopt() test
getopt():  Simple test
getopt():  Invalid argument
getopt():  Missing optional argument
getopt_long():  Simple test
getopt_long():  No short options
getopt_long():  Argument for --option=argument
getopt_long():  Invalid long option
getopt_long():  Mixed long and short options
getopt_long():  Invalid short option
getopt_long():  Missing optional arguments
getopt_long_only():  Mixed long and short options
getopt_long_only():  Single hyphen long options


2.2. nsh (ERROR undefined symbol: backtrace)

 gmake clean distclean
./tools/configure.sh -B sim:nsh
  Copy files
  Select CONFIG_HOST_BSD=y
  Refreshing...
CP: arch/dummy/Kconfig to
/zraid/data/XXX/nuttxworkspace.git/nuttx/arch/dummy/dummy_kconfig
CP: boards/dummy/Kconfig to
/XXX/nuttxworkspace.git/nuttx/boards/dummy/dummy_kconfig
LN: platform/board to /XXX/nuttxworkspace.git/apps/platform/dummy
LN: include/arch to arch/sim/include
LN: include/arch/board to
/XXX/nuttxworkspace.git/nuttx/boards/sim/sim/sim/include
LN: drivers/platform to /XXX/nuttxworkspace.git/nuttx/drivers/dummy
LN: include/arch/chip to /XXX/nuttxworkspace.git/nuttx/arch/sim/include/sim
LN: arch/sim/src/chip to /XXX/nuttxworkspace.git/nuttx/arch/sim/src/sim
LN: arch/sim/src/board to /XXX/nuttxworkspace.git/nuttx/boards/sim/sim/sim/src
mkkconfig in /XXX/nuttxworkspace.git/apps/audioutils
mkkconfig in /XXX/nuttxworkspace.git/apps/benchmarks
mkkconfig in /XXX/nuttxworkspace.git/apps/boot m

RE: [VOTE] Apache NuttX 12.1.0 RC0 release

[alin.jerpe...@sony.com]

With my +1 I am closing the vote 

Thanks for supporting this release

Best regards
Alin


-Original Message-
From: Tomek CEDRO  
Sent: den 13 april 2023 13:38
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 12.1.0 RC0 release

On Wed, Apr 12, 2023 at 8:49 AM alin.jerpe...@sony.com wrote:
> @Tomek
> We need +1 or -1
> Does the "ERROR undefined symbol: backtrace " error appear on master?

Sorry for the delay Alin, this also happens for me in 12.0 and master, so 
probably local setup problem :-)

+1 :-)

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

RE: Article: NuttX for PinePhone: Phone Calls and Text Messages

[alin.jerpe...@sony.com]

This is great progress !

With an UI will be easier to handle 

Best regards
Alin


-Original Message-
From: Tomek CEDRO  
Sent: den 4 maj 2023 03:38
To: dev@nuttx.apache.org
Subject: Re: Article: NuttX for PinePhone: Phone Calls and Text Messages

Excellent job Lup! Congratz! :-)

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

RE: Requesting a Hackster.io channel

[alin.jerpe...@sony.com]

Hi Alan,

I think that all NuttX PMC's should be admins on the channel so that they can 
help promote NuttX RTOS 

Best regards
Alin


-Original Message-
From: Alan C. Assis  
Sent: den 9 maj 2023 16:20
To: Tomek CEDRO 
Cc: dev@nuttx.apache.org
Subject: Re: Requesting a Hackster.io channel

Hi Tomek,

Done! Thank you very much! Now you are an Admin too!

I think everyone can access the channel: https://www.hackster.io/nuttx
and start to following.

I'm not sure if the page is already visible, I added a simple Call For Action 
pointing to our Apache Community page.

BR,

Alan

On 5/9/23, Tomek CEDRO  wrote:
> Alan/DevList: I have account "cederom" at hackster and can help with 
> maintenance :-) Have a good day :-) Tomek
>
> On Tue, May 9, 2023 at 3:03 PM Alan C. Assis  wrote:
>>
>> Dear Hackster.io Platform Team,
>>
>> I'm officially requesting the creation of NuttX Channel at 
>> Hackster.io platform.
>>
>> As NuttX is part of Apache Software Foundation I'm CC our team 
>> members (PMC and Committers) asking for their agreement.
>>
>> Please respond to ALL with +1 or ACK.
>>
>> BR,
>>
>> Alan
>
>
>
> --
> CeDeROM, SQ7MHZ, 
> http://www.tomek.cedro.info
> RvKRSx!7EcJ487zI8p7Z5vo3fWnQJwF_3cghpMrppn8Tx7wMF5QI-QJTs14ZSfzEh87aF9
> QR2R-nMzvqOGDHfcc$
>

RE: Requesting a Hackster.io channel

[alin.jerpe...@sony.com]

Thanks for the explanation 
Please add me as admin 
Thanks 
Alin


-Original Message-
From: Alan C. Assis  
Sent: den 10 maj 2023 15:13
To: dev@nuttx.apache.org
Subject: Re: Requesting a Hackster.io channel

Hi Alin,

Yes, until now me, Tomek and Masayuki were the only admins, I didn't add others 
because there weren't members yet.

Currently we have 7 PMC members and all are promoted to admin.

Some users with usernames that I don't recognize (zipper, amerei, etc) I'll not 
promote, case someone else want please ping me or some other Admin and ask for 
it.

Unfortunately in the Hackster.io there is only two categories of
users: Member or Admin.
It should be nice if we could have Editor, etc.

BR,

Alan

On 5/10/23, alin.jerpe...@sony.com  wrote:
> Hi Alan,
>
> I think that all NuttX PMC's should be admins on the channel so that 
> they can help promote NuttX RTOS
>
> Best regards
> Alin
>
>
> -Original Message-
> From: Alan C. Assis 
> Sent: den 9 maj 2023 16:20
> To: Tomek CEDRO 
> Cc: dev@nuttx.apache.org
> Subject: Re: Requesting a Hackster.io channel
>
> Hi Tomek,
>
> Done! Thank you very much! Now you are an Admin too!
>
> I think everyone can access the channel: 
> https://www.hackster.io/nuttx
> v3RvKRSx!76A-U2WM-CezgUQ-Ow_0He4hDaTkb1VQ3IJOvUfBT5Rb98ElQZytU09W6EfqS
> qcxc-LMJbHyXyPuktn0$
> and start to following.
>
> I'm not sure if the page is already visible, I added a simple Call For 
> Action pointing to our Apache Community page.
>
> BR,
>
> Alan
>
> On 5/9/23, Tomek CEDRO  wrote:
>> Alan/DevList: I have account "cederom" at hackster and can help with 
>> maintenance :-) Have a good day :-) Tomek
>>
>> On Tue, May 9, 2023 at 3:03 PM Alan C. Assis  wrote:
>>>
>>> Dear Hackster.io Platform Team,
>>>
>>> I'm officially requesting the creation of NuttX Channel at 
>>> Hackster.io platform.
>>>
>>> As NuttX is part of Apache Software Foundation I'm CC our team 
>>> members (PMC and Committers) asking for their agreement.
>>>
>>> Please respond to ALL with +1 or ACK.
>>>
>>> BR,
>>>
>>> Alan
>>
>>
>>
>> --
>> CeDeROM, SQ7MHZ,
>> http://www.tomek.cedro.info
>> 3RvKRSx!76A-U2WM-CezgUQ-Ow_0He4hDaTkb1VQ3IJOvUfBT5Rb98ElQZytU09W6EfqS
>> qcxc-LMJbHyXwG8yg-C$
>> RvKRSx!7EcJ487zI8p7Z5vo3fWnQJwF_3cghpMrppn8Tx7wMF5QI-QJTs14ZSfzEh87aF
>> 9
>> QR2R-nMzvqOGDHfcc$
>>
>

RE: The NuttX Handbook

[alin.jerpe...@sony.com]

The book looks nice and I am looking forward to see it out

Best regards
Alin


-Original Message-
From: Gregory Nutt  
Sent: den 15 maj 2023 01:44
To: dev@nuttx.apache.org
Subject: Re: The NuttX Handbook


> On 5/14/23, Brennan Ashton  wrote:
>> Before I do more work to wire this up, please let me know if this pdf 
>> I have attached here seems like a reasonable start for people 
>> INVALID URI REMOVED
>> 95*issuecomment-1547008998__;Iw!!JmoZiZGBv3RvKRSx!_8H1y8G8TuCrR4DY6uA
>> maV965-W8JHnb2nTKY1tu8PCj_NyKKH2bFKTdSrqyE6m-VRzmW0qZfgRYnflqkSc$
>>
>> It is basically the same content on the website, so missing 
>> information is out of scope of this change, but I don't want to fix 
>> some compatibility issues here unless people actually think this is 
>> of value.
>>
Over the years, there have been several people with the dream of writing a 
commercial, NuttX book in the spirit of the famous uC/OS book.  There were even 
a few starts but all gave up when the magnitude of the effort sunk in.

But this looks like a good begubbubg.  It looks like a book.

How much additional effort would it take to develop a book (like an O'Reilly 
book) or a free eBook on Amazon or Google Books?

To bad we don't have a technical writer on the team.

RE: [OT] Learning Makefiles

[alin.jerpe...@sony.com]

Hi all,

I understand both arguments and I agree with both bunt unfortunately we can't 
maintain both environments so we will have to pick one.

I think that there is not much that we can do as PMC to pick 1 or the other 
option. An open vote to the community is probably the best but still limited in 
outreach and will still make some involved parts unhappy

There are many companies and projects that use NuttX with local code, sometimes 
extensively patches NuttX build environment to suit their needs. We should 
think about all the implications that tooling can have over their work since 
they are in the end the user.

Best regards
Alin

-Original Message-
From: Gregory Nutt  
Sent: den 23 maj 2023 16:29
To: dev@nuttx.apache.org
Subject: Re: [OT] Learning Makefiles

On 5/23/2023 7:32 AM, Nathan Hartman wrote:
> On Tue, May 23, 2023 at 8:07 AM Tomek CEDRO  wrote:
>> On Tue, May 23, 2023 at 9:31 AM Sebastien Lorquet wrote:
>>> Hello Tomek,
>>> Whatever is decided, the mere fact of wanting to make a decision on 
>>> this point will lead to more split.
>>> either from people that want cmake
>>> or from people who dont.
>>> this is an intrinsically bad decision Sebastien
>> I am afraid of that, trying to help to avoid that! :-(
>>
>> I know each group has its points.
>>
>> Maybe we should just see how it works out in practice?
>
> I very much *don't* want to cause a split in the community!!!
>
> We're only having a *discussion* and comparing/contrasting. We're not
> moving ahead and making any huge changes yet. I think it is a good
> thing for everyone to say their thoughts and explain pros/cons.
>
> If we try it in practice, we will definitely find out if it makes life
> better, or worse. Unfortunately that would require doing all the work
> (some is already done in PRs 3704 and 6718 but will need attention)
> and maintaining two parallel build systems for a while. Will people
> want to volunteer to do that if all the work might be thrown away?
> Maybe, maybe not. I suppose it depends on how strongly people feel
> about CMake.
>
> So I think, first, we should make a nice coherent list of pros/cons.
>
> I'm okay with tracking pros/cons in a GitHub issue instead of CWIKI.
>
> Cheers,
> Nathan

I see one of primary responsibility of the PMC is to support the needs a 
desires of the NuttX community.  For things like tools, the pros and 
cons are not nearly as important.  The easiest way to find out the will 
of the community is simply to ask, perhaps with a non-binding community 
vote.

On a different note, we have not talked about what level of testing a 
new build system should be held to.  I think that level should be quite 
high.  I don't think we should break any builds, even on an initial 
merge.  Satisfactory testing should address:

  * All build modes: FLAT, PROTECTED, KERNEL (including the kernel mode
file system)
  * All supported build platforms:  Linux, BSD, MacOS, Windows: Cygwin,
MYSYS, native. etc.  None of those should be broken.

RE: Thank you!

[alin.jerpe...@sony.com]

Good Luck !

Best regards
Alin

-Original Message-
From: Tomek CEDRO  
Sent: den 26 maj 2023 01:08
To: dev@nuttx.apache.org
Subject: Re: Thank you!

Good luck with Your project Tim! :-)

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

RE: Article: NuttX for PinePhone: The First Year

[alin.jerpe...@sony.com]

Kudos Lup, 

Nice to see the PinePhone having such good progress. 
I hope that you will present the journey at the NuttX International Workshop 
2023 

Best regards
Alin


-Original Message-
From: Lee, Lup Yuen  
Sent: den 21 juni 2023 04:04
To: dev@nuttx.apache.org
Subject: Re: Article: NuttX for PinePhone: The First Year

Thanks Alan and Tomek! I had lots of fun proving that NuttX runs really well on 
an Arm64 consumer gadget, now I'll do the same for NuttX on 64-bit RISC-V :-)

Lup

On Tue, Jun 20, 2023 at 8:41 PM Alan C. Assis  wrote:

> Congratulations Lup!
>
> I think your work on PinePhone is an evolution of what people did with 
> OsmocomBB and Fernvale many year ago:
>
> INVALID URI REMOVED
> /Fernvale__;!!JmoZiZGBv3RvKRSx!7rF_pRO0E6e8LgIwKhR2C9e_fxTUVTUzF9Tc1ra
> f4MK69shmzJgstPu2Su05_4FgqVljq36b7KNxhwI$
>
> I think this time we are near to get a usable feature phone running NuttX.
>
> BR,
>
> Alan
>
> On 6/19/23, Lee, Lup Yuen  wrote:
> > One year ago we started porting NuttX to PinePhone. Let’s look back 
> > and talk about…
> >
> > 1. The Features that we’ve implemented 2. Our Plans for the future 
> > 3. Why we might move to a RISC-V Tablet!
> >
> > Check out the article here...
> >
> > INVALID URI REMOVED
> > inephone2.html__;!!JmoZiZGBv3RvKRSx!7rF_pRO0E6e8LgIwKhR2C9e_fxTUVTUz
> > F9Tc1raf4MK69shmzJgstPu2Su05_4FgqVljq36bVus8lLU$
> >
> > Lup
> >
>

RE: [VOTE] Apache NuttX 12.2.1 RC0 release

[alin.jerpe...@sony.com]

+1

Tested on Sony Spresense



BR

Alin


From: Alan C. Assis 
Sent: den 16 juli 2023 16:06
To: dev@nuttx.apache.org
Cc: mark.stev...@wildernesslabs.co
Subject: Re: [VOTE] Apache NuttX 12.2.1 RC0 release

Thank you Nathan, Maybe we should create some script to automatically generate 
this log release report and save it in some place, like a attachment log in the 
release page. I'm happy to see renewed interested in a small NuttX footprint to 
use
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

Thank you Nathan,



Maybe we should create some script to automatically generate this log

release report and save it in some place, like a attachment log in the

release page.



I'm happy to see renewed interested in a small NuttX footprint to use

as bootloader.



I think it is possible to get a minimal version running on CH32V003

(16KB Flash and 2KB RAM), but it couldn't be so useful because apps

will not have enough RAM stack to use.



BR,



Alan



On 7/16/23, Nathan Hartman 
mailto:hartman.nat...@gmail.com>> wrote:

> Hi all,

>

> Pleased to submit my vote:

>

> Summary:

> +1 to release (binding)

>

> Per Alan's request for size information [1]:

>

> * NuttX-12.2.1-RC0, b-g474e-dpow1:nsh configuration:

>

> $ arm-none-eabi-size nuttx

>textdata bss dec hex filename

>  109963 8202908  113691   1bc1b nuttx

>

> This config has grown somewhat since NuttX-11.0.0-RC0, same config:

>

> $ arm-none-eabi-size nuttx

>textdata bss dec hex filename

>  107623 6722012  110307   1aee3 nuttx

>

> Text is increased by 2340. Data increases slightly by 148, bss

> increases by 896.

>

> Also built the b-g474e-dpow1:ostest configuration:

>

> Compared to b-g474e-dpow1:nsh, it adds the following configs:

>

> +CONFIG_BUILTIN=y

> +CONFIG_NSH_BUILTIN_APPS=y

> +CONFIG_TESTING_OSTEST=y

>

> During the NuttX-11.x.x release cycle, ostest was failing when built

> with priority inheritance, so currently the following configs are not

> present; eventually I intend to re-test with these and possibly open a

> PR to enable them:

>

> -CONFIG_PRIORITY_INHERITANCE=y

> -CONFIG_PTHREAD_MUTEX_DEFAULT_PRIO_INHERIT=y

>

> Here is the size information for that build:

>

> * NuttX-12.2.1-RC0, b-g474e-dpow1:ostest configuration:

>

> $ arm-none-eabi-size nuttx

>text   databssdechex filename

>  184991852   5272 191115  2ea8b nuttx

>

> Development system: Debian "Bullseye" 5.10.179-1 x86_64 GNU/Linux

>

> Verified:

> * Signatures

> * SHA-512 sums

> * LICENSE, NOTICE, and README.md present in both tarballs

> * Build, FLASH program, and boot b-g474e-dpow1:nsh to the NSH prompt

>   successfully.

> * Build, FLASH, boot b-g474e-dpow1:ostest and ran 'ostest'

>   successfully.

>

> Dependencies:

> * GCC as installed via 'sudo apt install gcc-arm-none-eabi':

>   arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release)

>   [gcc-8-branch revision 273027]

> * kconfig-conf as installed via 'sudo apt install kconfig-frontends':

>   kconfig-frontends/oldstable,now 4.11.0.1+dfsg-5 amd64 [installed]

>

> Other dependencies from Debian packages:

> * binutils-dev 2.35.2

> * bison 3.7.5

> * flex 2.6.4

> * gperf 3.1

> * libelf-dev 0.183-1.1

> * libgmp-dev 2:6.2.1+dfsg-1+deb11u1

> * libisl-dev 0.23-1

> * libmpc-dev 1.2.0-1

> * libmpfr-dev 4.1.0-3

> * libncurses5-dev 6.2+20201114-2+deb11u1

> * libusb-1.0-0-dev 2:1.0.24-3

> * libusb-dev 2:0.1.12-32

> * openocd 0.11.0~rc2-1

> * texinfo 6.7.0.dfsg.2-6

>

> A very big **THANK YOU** to our RM and to everyone in the Apache NuttX

> community for making this release (candidate) possible!

>

> References:

>

> [1] Alan Carvalho de Assis's message to the 
> dev@nuttx.a.o thread "Re:

> [VOTE] Apache NuttX 10.0.0 (incubating) RC0 release" on 26 Nov 2020,

> archived:

> https://lists.apache.org/thread/nxvwxol948psr2z7fc6cwtdv9ofoz9yj

>

> Cheers,

> Nathan

>

> On Fri, Jul 14, 2023 at 6:39 PM Tomek CEDRO 
> mailto:to...@cedro.info>> wrote:

>>

>> On Mon, Jul 10, 2023 at 4:47 PM Alin Jerpelea wrote:

>> > Apache NuttX 12.2.1 RC0 has been staged under [1] and it's time to vote

>> > on

>> > accepting it for release. Voting will be open for 72hr.

>> > (..)

>> > [1] 
>> > https://dist.apache.org/repos/dist/dev/nuttx/12.2.1-RC0/

>>

>> +1 :-)

>>

>> BUILD HOST:

>> FreeBSD octagon 13.2-RELEASE-p1 FreeBSD 13.2-RELEASE-p1 GENERIC amd64

>>

>> TARGETS:

>> 1. ESP32.

>> 2. ESP32-C3.

>> 2. ESP32-S2.

>> 3. ESP32-S3.

>>

>> === ESP32 ===

>>

>> % /usr/bin/time -h ./tools/configure.sh -B esp32-devkitc:coremark

>> 2,94s real  1,51s

[RESULTS] Apache NuttX 12.2.1 RC0 release

[alin.jerpe...@sony.com]

Hi all,

The vote to release Apache NuttX 12.2.1-rc0 is now closed.
Thanks to those that took the time to review and vote.

The release has passed with 6 +1 (binding) votes and no 0 or -1 votes.

Binding:

+1 Roberto Butcher
+1 Lup Yuen Lee
+1 Alan C.Assis
+1 Tomek CEDRO
+1 Nathan Hartman
+1 Alin Jerpelea


Vote thread https://lists.apache.org/thread/v6pg991cyjln8bbzsxfz1kk9svlxl2g7

RE: [DISCUSS] Out-of-tree builds should be standard?

[alin.jerpe...@sony.com]

Hi,

I think that we should prioritize the compatibility and standardization 
otherwise the NuttX developer experience may varry (depend on “luck”) for some 
platforms

Best regards
Alin

From: raiden00pl 
Sent: den 25 augusti 2023 11:49
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Out-of-tree builds should be standard?

I think this is reinventing the wheel. This seems to not be a trivial change, 
and the ready solution in the form of cmake is already there. If an individual 
or a company wants to devote their time to it, I don't see a problem, but this 
must
ZjQcmQRYFpfptBannerStart
This message is from an unknown sender
You have not previously corresponded with this sender and they are external to 
Sony
ZjQcmQRYFpfptBannerEnd

I think this is reinventing the wheel. This seems to not be a trivial

change,

and the ready solution in the form of cmake is already there. If an

individual

or a company wants to devote their time to it, I don't see a problem, but

this

must be backward compatible.

The main voice against cmake was that it destroys external projects and

people's workflows. If this change is supposed to do the same thing then

I don't see the point in it.



> In the GitHub comments, it was mentioned that we should not make cmake

> mandatory for certain boards



Forcing people using cmake to support make is the worst thing that can

happen.

Open source is voluntary, any contribution is voluntary, any form of

forcing

others to do anything is unacceptable.

Modifying both systems will be good practice (and an act of kindness), but

only

if the contributor wants it. In other cases, a community interested in a

particular

build system should take care of it.



czw., 24 sie 2023 o 21:55 Tomek CEDRO 
mailto:to...@cedro.info>> napisał(a):



> Out-of-tree build is the default for me in various projects. I like to

> have git submodules / dependencies untouched.

>

> FreeBSD uses (BSD) make and allows out of tree builds and it is

> possible to specify WRKDIRPREFIX for instance in tmpfs located in RAM.

> Kernel build also allows passing another variable with specific

> configuration. So various kernels can be built into different

> locations. This should be possible also with make in NuttX..? :-)

>

> I use custom board and custom application (that requires linking to

> nuttx-apps) to build NuttX anyways by default. Then my build script

> copies resulting binary to out of tree bin dir appending timestamp

> suffix to the firmware image ready to flash. NuttX sources and app

> sources are git submodules that can be easily updated / changed to a

> specific version / branch / commit / release. This enables various

> automation scenarios.

>

> This is the layout:

>

> project.git/

>   nuttx.git

>   nuttx-apps.git

>   cederom/boards/myboard

>   cederom/apps/myapp

>   bin

>   scripts

>   doc

>

> Above could be extended with "build/board_cfg" location with all

> configuration and build files specific for a given board..? This

> location could be provided and set custom in WRKDIRPREFIX env variable

> so the sources remain untouched..?

>

> Alternatively, at this point, user can simply have two nuttx.git

> subdirectories (i.e. project/nuttx-cm4 and project/nuttx-cm7) with

> build configuration and binaries for each CPU right? I do not know the

> details of linking in that situation though.

>

> This is interesting problem, as I also have some prototype Maxim MCU

> with ARM Cortex M as main CPU and modified RISC-V as Hardware Neural

> Network Accelerator. This is something new. I wonder how the story

> follows :-)

>

> --

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

>

RE: [Article] NuttX on Star64 JH7110: Power Up the Display Controller with U-Boot Bootloader

[alin.jerpe...@sony.com]

Nice article 😊

Best regards
Alin

From: Tomek CEDRO 
Sent: den 2 september 2023 18:44
To: dev@nuttx.apache.org
Subject: Re: [Article] NuttX on Star64 JH7110: Power Up the Display Controller 
with U-Boot Bootloader

wow :-) -- CeDeROM, SQ7MHZ, https: //urldefense. com/v3/__http: //www. tomek. 
cedro. 
info__;!!JmoZiZGBv3RvKRSx!4lnUdbygN2dI2DgYnSUygt7iGWgF7yxc2ITcufM4-YJtnXg57U7aaS97hmPVbdGcLvx22GyBHdrIvIsN1g$
 ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ 
‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

wow :-)



--

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

RE: CTU CAN FD driver multi-licence for Nuttx

[alin.jerpe...@sony.com]

Hi Shane,

Thanks for the clarification

There are known CAN sources that have GPL code and have been documented in the 
LICENSE File

All this code is protected under the include GPL code config option and 
disabled by default

Is this approach approved or we should completely remove the GPL code from 
NuttX?

Thanks
Alin


From: Shane Curcuru 
Sent: den 6 september 2023 13:07
To: dev@nuttx.apache.org
Subject: RE: CTU CAN FD driver multi-licence for Nuttx

On 2023/08/09 00: 20: 42 Andrew Dennison wrote: > Hi Nuttx Dev, > > We are 
negotiating with the authors of the linux device driver for the CTU > CAN FD IP 
core to it re-licenced from GPL to so the driver can then be > ported to
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

On 2023/08/09 00:20:42 Andrew Dennison wrote:

> Hi Nuttx Dev,

>

> We are negotiating with the authors of the linux device driver for the CTU

> CAN FD IP core to it re-licenced from GPL to so the driver can then be

> ported to Nuttx.



Just a reminder: Apache policy prohibits GPL code, or GPL-derived code,

from being included in any ASF project:



   
https://apache.org/legal/resolved#category-x



If there is *any* question about the license of incoming code, then you

should ask the Legal Affairs Committee for advice, after reviewing the

ASF policy on source headers:



   
https://apache.org/legal/src-headers.html



Specific questions (i.e. about a specific body of code under license X

that the project wants to incorporate) should be asked on Jira:



   
https://issues.apache.org/jira/projects/LEGAL/issues



--

- Shane

   ASF Member

   The Apache Software Foundation



> I've seen various licencing examples in the nuttx code base: but no high

> level description that gives a definitive answer. For example there are

> some cases where Authors are preserved and the code is BSD-2-Clause or

> BSD-3-Clause (not Apache-2.0).

>

> We would appreciate some feedback on whether the proposal from Pavel below

> is acceptable or if any minor adjustments would help.

>

> Kind regards,

>

> Andrew Dennison

> Chief Architect and Hardware Team Lead

> MoTeC (A Bosch Company)

>

> On Tue, 8 Aug 2023 at 19:48, Pavel Pisa 
> mailto:p...@fel.cvut.cz>> wrote:

>

> >

> > OK, consider driver code license and NuttX compatible.

> > We need to discuss what will be actual variant and file

> > headers text. I suggest

> >

> > // SPDX-License-Identifier: GPL-2.0+ OR BSD-2-Clause OR Apache-2.0

> >

> > /***

> >  *

> >  * CTU CAN FD IP Core

> >  *

> >  * Copyright (C) 2015-2018 Ondrej Ille 
> > mailto:ondrej.i...@gmail.com>> FEE CTU

> >  * Copyright (C) 2018-2020 Ondrej Ille 
> > mailto:ondrej.i...@gmail.com>> self-funded

> >  * Copyright (C) 2018-2019 Martin Jerabek 
> > mailto:martin.jerabe...@gmail.com>>

> > FEE CTU

> >  * Copyright (C) 2018-2020 Pavel Pisa 
> > mailto:p...@cmp.felk.cvut.cz>> FEE

> > CTU/self-funded

> >  *

> >  * Project advisors:

> >  * Jiri Novak mailto:jno...@fel.cvut.cz>>

> >  * Pavel Pisa mailto:p...@cmp.felk.cvut.cz>>

> >  *

> >  * Department of Measurement 
> > (http://meas.fel.cvut.cz/)

> >  * Faculty of Electrical Engineering 
> > (http://www.fel.cvut.cz)

> >  * Czech Technical University
> > (http://www.cvut.cz/)

> >  */

> >

> > I am not sure if that is acceptable for NuttX mainline, but I do not like

> > process which stripped all information about real code authors when

> > NuttX has been absorbed by Apache. The Copyright (C) statementscan be

> > replaced

> > by text "Authors list"  if copyright of NuttX copy should be transferred

> > to Apache. But I would tend to keep list of authors who invested time,

> > lot of it even from own spare one...

> >

> >

> >

>

> --

> *MoTeC Pty Ltd*

>

> 121 Merrindale Drive

> Croydon South 3136

> Victoria Australia

> *T: *61 3 9761 5050

> *W: *http://www.motec.com.au 
> >

>

>

> --

>  >

> >

> >

> >

> >

>

>

> --

>  >

>

> --

>

>

> Disclaimer Not

RE: [VOTE] Apache NuttX 12.3.0 RC0 release

[alin.jerpe...@sony.com]

Hi Daniel

Any updates on the patches?
I would like to continue with RC1

Best regards
Alin

From: Daniel Appiagyei 
Sent: den 9 oktober 2023 14:48
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 12.3.0 RC0 release

Thanks, Alin I will branch off the 12. 3. 0 RC0 branch and have a fix up within 
the week On Mon, Oct 9, 2023 at 5: 40 AM Alin Jerpelea  
wrote: > Hi, > my aim is to do a release every 3 months > if you have the
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

Thanks, Alin

I will branch off the 12.3.0 RC0 branch and have a fix up within the week



On Mon, Oct 9, 2023 at 5:40 AM Alin Jerpelea 
mailto:jerpe...@gmail.com>> wrote:



> Hi,

> my aim is to do a release every 3 months

> if you have the patches ready this week I would gladly do a MR1

> Best regards

> Alin

>

> On Mon, 9 Oct 2023, 14:37 Daniel Appiagyei,

> mailto:daniel.appiag...@braincorp.com.invalid>>
>  wrote:

>

> > Hi all,

> > Is there a publicly available schedule of future releases?

> >

> > Additionally, there are some bugs in master for my chip’s (IMXRT) DMA

> > serial driver I had planned to address later this week. Would it be

> > possible for that to make an RC1 release?

> >

> > On Mon, Oct 9, 2023 at 2:24 AM Lee, Lup Yuen 
> > mailto:lu...@appkaki.com>> wrote:

> >

> > > +1 for PinePhone and Star64

> > >

> > > Minor Issue: Building on macOS shows "sed: illegal option -- r",

> probably

> > > because macOS sed works differently from Linux. I'll track down the PR

> > that

> > > caused this.

> > >

> > > Here are the sed messages:

> > >

> > >

> >

> https://gist.github.com/lupyuen/1c3f1f1d71993609bed3b31767595beb#file-pinephone-release-log-L282-L512

> > >

> > > = PinePhone Compiler

> > > + aarch64-none-elf-gcc -v

> > > Using built-in specs.

> > > COLLECT_GCC=aarch64-none-elf-gcc

> > >

> > >

> >

> COLLECT_LTO_WRAPPER=/Applications/ArmGNUToolchain/11.3.rel1/aarch64-none-elf/bin/../libexec/gcc/aarch64-none-elf/11.3.1/lto-wrapper

> > > Target: aarch64-none-elf

> > > Configured with:

> > > /Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/configure

> > > --target=aarch64-none-elf

> > >

> > >

> >

> --prefix=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/install

> > >

> > >

> >

> --with-gmp=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

> > >

> > >

> >

> --with-mpfr=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

> > >

> > >

> >

> --with-mpc=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

> > >

> > >

> >

> --with-isl=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

> > > --disable-shared --disable-nls --disable-threads --disable-tls

> > > --enable-checking=release --enable-languages=c,c++,fortran

> --with-newlib

> > > --with-gnu-as --with-gnu-ld

> > >

> > >

> >

> --with-sysroot=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/install/aarch64-none-elf

> > > --with-pkgversion='Arm GNU Toolchain 11.3.Rel1' --with-bugurl=

> > > https://bugs.linaro.org/

> > > Thread model: single

> > > Supported LTO compression algorithms: zlib

> > > gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)

> > >

> > > = PinePhone Configuration

> > > + ./tools/configure.sh pinephone:nsh

> > >

> > > = PinePhone Size

> > > + aarch64-none-elf-size nuttx

> > >text   databssdechex filename

> > >  223895  12913  41612 278420  43f94 nuttx

> > >

> > > = PinePhone NSH Info and Free

> > > NuttShell (NSH) NuttX-12.3.0

> > > nsh> uname -a

> > > NuttX 12.3.0 1d349a2a32 Oct  9 2023 16:15:01 arm64 pinephone

> > > nsh> free

> > >total   used   freelargest  nused  nfree

> > > Umem:  133406712 551512  132855200  132855104 58  2

> > >

> > > = Star64 Compiler

> > > + riscv64-unknown-elf-gcc -v

> > > Using built-in specs.

> > > COLLECT_GCC=riscv64-unknown-elf-gcc

> > >

> > >

> >

> COLLECT_LTO_WRAPPER=/Users/Luppy/riscv64-unknown-elf-toolchain-10.2.0-2020.12.8-x86_64-apple-darwin/bin/../libexec/gcc/riscv64-unknown-elf/10.2.0/lto-wrapper

> > > Target: riscv64-unknown-elf

> > > Configured with:

> > >

> > >

> >

> /scratch/jenkins/workspace/tpp-freedom-tools/tpp01--build-binary-packages--parameterized/obj/x86_64-apple-darwin/build/riscv64-unknown-elf-gcc/riscv-gcc/configure

> > > --target=riscv64-unknown-elf

> > >

> > >

> >

> --prefix=/scratch/jenkins/workspace/tpp-freedom-tools/tpp01--build-binary-packages--parameterized/obj/x86_64-apple-darwi

RE: [VOTE] Apache NuttX 12.3.0 RC1 release

[alin.jerpe...@sony.com]

Thanks Lup!

I missed this patch MAC patch
If it is not critical we can continue with the RC1 vote

Best regards
Alin


From: Lee, Lup Yuen 
Sent: den 18 oktober 2023 10:30
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 12.3.0 RC1 release

+1 for PinePhone and Star64 Minor Issue: Building PinePhone on macOS shows the 
message "sed: illegal option -- r" and still builds OK. The patch has been 
merged, we can add this to the next release: https: //urldefense. 
com/v3/__https: //github. 
com/apache/nuttx/pull/10881__;!!JmoZiZGBv3RvKRSx!-vpt3SGmTcDKPjtok3pSFMzn7CrmoEY3juo1UPERlUK8to9iu4QMiZ1IGFB9q-sdHUKjqsxrhxTqdmM$
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

+1 for PinePhone and Star64



Minor Issue: Building PinePhone on macOS shows the message "sed: illegal

option -- r" and still builds OK. The patch has been merged, we can add

this to the next release: 
https://github.com/apache/nuttx/pull/10881



= PinePhone Compiler

+ aarch64-none-elf-gcc -v

Using built-in specs.

COLLECT_GCC=aarch64-none-elf-gcc

COLLECT_LTO_WRAPPER=/Applications/ArmGNUToolchain/11.3.rel1/aarch64-none-elf/bin/../libexec/gcc/aarch64-none-elf/11.3.1/lto-wrapper

Target: aarch64-none-elf

Configured with:

/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/configure

--target=aarch64-none-elf

--prefix=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/install

--with-gmp=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

--with-mpfr=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

--with-mpc=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

--with-isl=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools

--disable-shared --disable-nls --disable-threads --disable-tls

--enable-checking=release --enable-languages=c,c++,fortran --with-newlib

--with-gnu-as --with-gnu-ld

--with-sysroot=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/install/aarch64-none-elf

--with-pkgversion='Arm GNU Toolchain 11.3.Rel1' --with-bugurl=

https://bugs.linaro.org/

Thread model: single

Supported LTO compression algorithms: zlib

gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)



= PinePhone Configuration

+ ./tools/configure.sh pinephone:nsh



= PinePhone Size

+ aarch64-none-elf-size nuttx

   text   databssdechex filename

 223903  12913  41612 278428  43f9c nuttx



= PinePhone NSH Info and Free

NuttShell (NSH) NuttX-12.3.0

nsh> uname -a

NuttX 12.3.0 8fdb56b5f2 Oct 18 2023 16:04:29 arm64 pinephone

nsh> free

   total   used   freelargest  nused  nfree

Umem:  133406712 551512  132855200  132855104 58  2



= Star64 Compiler

+ riscv64-unknown-elf-gcc -v

Using built-in specs.

COLLECT_GCC=riscv64-unknown-elf-gcc

COLLECT_LTO_WRAPPER=/Users/Luppy/riscv64-unknown-elf-toolchain-10.2.0-2020.12.8-x86_64-apple-darwin/bin/../libexec/gcc/riscv64-unknown-elf/10.2.0/lto-wrapper

Target: riscv64-unknown-elf

Configured with:

/scratch/jenkins/workspace/tpp-freedom-tools/tpp01--build-binary-packages--parameterized/obj/x86_64-apple-darwin/build/riscv64-unknown-elf-gcc/riscv-gcc/configure

--target=riscv64-unknown-elf

--prefix=/scratch/jenkins/workspace/tpp-freedom-tools/tpp01--build-binary-packages--parameterized/obj/x86_64-apple-darwin/install/riscv64-unknown-elf-gcc-10.2.0-2020.12.8-x86_64-apple-darwin

--with-pkgversion='SiFive GCC-Metal 10.2.0-2020.12.8' --with-bugurl=

https://github.com/sifive/freedom-tools/issues
 --disable-shared

--disable-threads --enable-languages=c,c++ --enable-tls --with-newlib

--with-sysroot=/scratch/jenkins/workspace/tpp-freedom-tools/tpp01--build-binary-packages--parameterized/obj/x86_64-apple-darwin/install/riscv64-unknown-elf-gcc-10.2.0-2020.12.8-x86_64-apple-darwin/riscv64-unknown-elf

--with-native-system-header-dir=/include --disable-libmudflap

--disable-libssp --disable-libquadmath --disable-libgomp --disable-nls

--disable-tm-clone-registry --src=../riscv-gcc --with-system-zlib

--enable-checking=yes --enable-multilib --with-abi=lp64d

--with-arch=rv64imafdc CFLAGS=-O2 CXXFLAGS=-O2 'CFLAGS_FOR_TARGET=-Os

-mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os -mcmodel=medany'

Thread model: single

Supported LTO compression algorithms: zlib

gcc version 10.2.0 (SiFive GCC-Metal 10.2.0-2020.12.8)



= Star64 Configuration

+ ./tools/configure.sh star64:nsh



= Star64 Size

+ riscv64-unknown-elf-size nuttx

   text   databssdechex filename

 168996641  23984 193621  2f455 nuttx



= St

RE: Code donation

[alin.jerpe...@sony.com]

Hi Tim,

I am sorry but it slipped by agenda.
Thanks for looking at this topic. Please take your time and submit when you are 
ready.

Best regards
Alin


From: Tim Hardisty 
Sent: den 28 oktober 2023 12:10
To: dev@nuttx.apache.org
Subject: Re: Code donation

Hi, Did anyone else make any progress with porting your settings code to NuttX 
Apps? It's taken a while but I am at long last looking to add a settings 
function to my new app and this still looks like it'll fit the bill nicely. If 
not, I will
ZjQcmQRYFpfptBannerStart
This message is from an unknown sender
You have not previously corresponded with this sender and they are external to 
Sony
ZjQcmQRYFpfptBannerEnd

Hi,



Did anyone else make any progress with porting your settings code to

NuttX Apps? It's taken a while but I am at long last looking to add a

settings function to my new app and this still looks like it'll fit the

bill nicely.



If not, I will set it up as an app, make sure it works, and submit it

for review hopefully in the next few weeks. I won't add YAML as yet,

just binary - my current think is to use a YAML parser between the user

and this function rather than storing YAML directly, but not 100%

decided yet.



On 05/12/2022 11:22, Fotis Panagiotopoulos wrote:

> Hello!

>

> Thank you for your interest in this!

>

> As requested, I created a temporal repository and uploaded all the code

> there.

>

> https://github.com/fjpanag/code_for_nuttx

>

> I have added a NOTICE file in each subdir, with some basic information.

> Please contact me before starting any work, to provide you with help and

> coordinate the effort.

> Better yet, you may open a Github issue for the piece of software that you

> would like to help porting.

>

>

> Alan,

> I would love to cooperate with you in this effort.

> Pick your target!

>

>

> Alin,

> I would really like to see my MQTT broker become part of NuttX.

>

> Alternatively, you can have a look at the XML or JSON parsers, which are of

> general usefulness,

> and the porting effort would be very very minimal.

>

>

> Tim,

> Thank you for your interest in the settings storage.

> It is a very useful and versatile piece of software. In fact, I have used

> it in all my projects over the last 5-6 years.

>

> I also thought about YAML before, but never got to actually implementing

> this.

>

> I suggest you first add a YAML parser to NuttX (maybe similarly to JSON and

> XML, if they get accepted),

> and then use it in the settings storage. It would be best not to couple

> these two softwares so someone

> may use one without the other. But, nevertheless, it is your call...

>

> If you provide me with a YAML parser, I believe that I can develop for you

> a new settings storage that uses this parser.

>

> Fotis

>

> On Mon, Dec 5, 2022 at 12:12 AM Tim 
> Hardistymailto:t...@jti.uk.com.invalid>>

> wrote:

>

>> I have interest in your settings storage, with the probability of adding

>> yaml output since I was going to do something similar for my current

>> project (once I get over the pain of getting NuttX fixed for the arch I'm

>> using).

>>

>> As have been suggested, maybe push it to github and I/we can clone what's

>> of interest, see if it makes sense, then get it working right for NuttX

>> and

>> do a PR...in the fullness of time (i.e. I'm a slow worker!)

>>

>> On 04/12/2022, 16:55, "Fotis 
>> Panagiotopoulos"mailto:f.j.pa...@gmail.com>>

>> wrote:

>>

>>  Hello everyone!

>>

>>  Christmas arrived a bit earlier for NuttX as I would like to donate

>> some of

>>  my personal code to the community!

>>

>>  A bit of context.

>>  Over the years that I am working on embedded systems, I have developed

>> lots

>>  of software that I use in my projects.

>>  Some of it is quite general-purpose, or useful for other applications,

>> and

>>  I have found my self reusing it

>>  quite often. In fact, there are some things that I use in practically

>> all

>>  firmwares that I have developed over

>>  the last years.

>>

>>  I always wanted to open-source this software so other people can

>> benefit

>>  from it.

>>  But I never managed to do so. Open-sourcing needs some effort, the

>> software

>>  needs maintenance, documentation

>>  and support, and most importantly in most cases a "porting layer"

>> needs to

>>  be developed.

>>  Last but not least, every project needs a bit of "marketing" and

>>  "advertising" so others can learn about

>>  your work and use it.

>>

>>  For the last couple of years I have been using NuttX a lot, and I have

>>  ported most of the aforementioned software

>>  to NuttX. I believe that NuttX and its community are perfect for me to

>>  publish my code, instead of creating

>>  a ton of small repos, of questionable usefulness and increasing my

>> workload

>>  considerabl

RE: Interest in an Apache IoT Track at EclipseCon EU in Mainz (Germany) later this year?

[alin.jerpe...@sony.com]

HI all,
If needed I can also present the NuttX project and our activity
Best regards
Alin

From: Alan C. Assis 
Sent: den 5 januari 2024 12:13
To: Christofer Dutz 
Cc: dev@nuttx.apache.org; Christofer Dutz 
Subject: Re: Interest in an Apache IoT Track at EclipseCon EU in Mainz 
(Germany) later this year?

Hi Christofer, Cool, I think that date is fine! Is there some TsFile 
implementation in C? I think the issue of it been in Java is because we don't 
have a small JVM able to run on microcontrollers. I think in the past there was 
Waba and SuperWaba
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

Hi Christofer,



Cool, I think that date is fine!



Is there some TsFile implementation in C? I think the issue of it been in

Java is because we don't have a small JVM able to run on microcontrollers.

I think in the past there was Waba and SuperWaba for Palm, but even that

was too big to run on STM32. Maybe it can run on ESP32.



BR,



Alan



On Friday, January 5, 2024, Christofer Dutz 
mailto:christofer.d...@c-ware.de>>

wrote:



> Hi Alan,

>

>

>

> Well in that case, that’s unfortunate. I just found the information on the

> proposed dates and it’s gonna be the 22.10.-24.10.2024 which is actually 12

> days after Community over Code NA … so possibly it could work for you guys,

> right?

>

> And I fully agree with running IoTDB on embedded … that’s totally out of

> scope, but TsFile is going to be super small … it’s just the part that

> writes timeseries data into so-called TsFiles (these can be of any size) …

> so the idea is to collect data on the device in TsFiles and then send them

> off in a chunck to an IoTDB instance to work with the data.

>

>

>

> Chris

>

>

>

>

>

> *Von: *Alan C. Assis mailto:acas...@gmail.com>>

> *Datum: *Donnerstag, 4. Januar 2024 um 23:23

> *An: *Christofer Dutz 
> mailto:christofer.d...@c-ware.de>>

> *Cc: *dev@nuttx.apache.org 
> mailto:dev@nuttx.apache.org>>, Christofer Dutz <

> cd...@apache.org>

> *Betreff: *Re: Interest in an Apache IoT Track at EclipseCon EU in Mainz

> (Germany) later this year?

>

> Hi Christofer,

>

> I think many people could be interested in participating, but I'm afraid

> about the dates because you think it could be 4 weeks before Apache

> Community Over Code NA that is supposed to happen October 7-10, 2024 in

> Denver, CO.

>

>

>

> It will be very close to our VI NuttX International Workshop (that

> normally happens at the end of September see: 
> https://events.nuttx.apache.

> org ).

>

>

>

> Although this year the workshop will return to the North Hemisphere (Japan

> or China), so maybe it could happen in June/July during the summer.

>

>

>

> Do you think it is okay to present the same/similar talk on both events?

>

>

>

> I saw about Apache TsFile and IoTDB a few days ago, when I was looking

> for Apache IoT projects.

>

>

>

> Actually what they call "light weight" is too big to run on small

> microcontrollers (few KBs vs dozens MBs).

>

>

>

> I listed some good DB alternatives to use on NuttX here:

> https://acassis.wordpress.com/2022/03/15/list-of-small-dbs/

>

>

>

> Note that SQLite and QDBM are already used by companies running NuttX on

> their products.

>

>

>

> Best Regards,

>

>

>

> Alan

>

>

>

> On Thu, Jan 4, 2024 at 1:53 PM Christofer Dutz 
> mailto:christofer.d...@c-ware.de>>

> wrote:

>

> Hi Alan,

>

>

>

> no, I didn’t forget to send the link, because there actually shouldn’t be

> a link just yet.

>

> We’re still in the phase of discussing, if we should do this. It only

> makes sense to continue planning, if there is enough interest from the

> Apache side. And that’s what I’m currently reaching out for: Would there be

> enough interest to attend or to even submit talks to this sort of event.

>

>

>

> And yeah … I’m the PLC4X guy with the plush civet ;-)

>

>

>

> And yeah … I already stated digging on what NuttX is, as I think it might

> be interesting running PLC4X (PLC4Rust or PLC4C) on it … and possibly the

> brand new Apache TsFile.

>

>

>

> Chris

>

>

>

>

>

> *Von: *Alan C. Assis mailto:acas...@gmail.com>>

> *Datum: *Donnerstag, 4. Januar 2024 um 15:32

> *An: *dev@nuttx.apache.org 
> mailto:dev@nuttx.apache.org>>, Christofer Dutz <

> cd...@apache.org>

> *Betreff: *Re: Interest in an Apache IoT Track at EclipseCon EU in Mainz

> (Germany) later this year?

>

> Hi Christofer,

>

> Thank you for bringing this to our attention!

>

> I think you forgot to send the submission link, because there is no

> reference to that conference at 
> https://www

NuttX Workshop 2024 - event planning

[alin.jerpe...@sony.com]

Hi all,

A new year started and we should start planning for the yearly workshop

This year Sony offered to host the workshop in Tokyo, Japan as it as planned on 
2020 (the in person event was canceled due to Covid)

Sony proposed the following periods for the event and will come back with 
practical information for attending the event
20 May - 16 June (better weather/beautiful nature)
1-15 September (may be rainy)

I would like to ask for volunteers to help organizing the event and opinions 
regarding the dates

Best regards
Alin

RE: Ox64 crash Was: Re: [VOTE] Apache NuttX 12.4.0 RC0 release

[alin.jerpe...@sony.com]

+1 from me
The release was tested on Sony Spresense board


In this case I will close the vote and document the issue regarding Ox64.


Thanks for testing and voting the release

//Alin

From: Lee, Lup Yuen 
Sent: den 15 januari 2024 06:05
To: dev@nuttx.apache.org
Subject: Re: Ox64 crash Was: Re: [VOTE] Apache NuttX 12.4.0 RC0 release

Hi Juha: Thanks for testing, I really appreciate it :-) You're right, there is 
a problem with the sequence of getprime then hello on Ox64. I suggest we 
proceed with the rollout of 12. 4. 0 RC0 while we fix this. BL808 Timer is also 
missing from
ZjQcmQRYFpfptBannerStart
This message is from an unknown sender
You have not previously corresponded with this sender and they are external to 
Sony
ZjQcmQRYFpfptBannerEnd

Hi Juha: Thanks for testing, I really appreciate it :-) You're right, there

is a problem with the sequence of getprime then hello on Ox64.



I suggest we proceed with the rollout of 12.4.0 RC0 while we fix this.

BL808 Timer is also missing from the release (it was merged last week), so

hopefully we'll have BL808 Timer + "getprime then hello" working OK in the

next release.



Here are my findings, I'll keep you updated. Thanks :-)



https://gist.github.com/lupyuen/def8fb96245643c046e5f3ad6c4e3ed0



Lup



On Mon, Jan 15, 2024 at 12:20 AM Juha Niskanen (Haltian)

mailto:juha.niska...@haltian.com.invalid>> 
wrote:



> There is something wrong with this release on Ox64 board. Just running

> this sequence of commands in ox64:nsh defconfig machine:

>

> cd /system/bin

> getprime

> hello

>

> produces a crash:

>

> riscv_exception: EXCEPTION: Store/AMO page fault. MCAUSE:

> 000f, EPC: 50209134, MTVAL: 8020

> riscv_exception: PANIC!!! Exception = 000f

> _assert: Current Version: NuttX  12.4.0-RC0 4761af7069 Jan 11 2024

> 00:11:48 risc-v

> _assert: Assertion failed panic: at file: common/riscv_exception.c:85

> task: /system/bin/init process: /system/bin/init 0x804a

> up_dump_register: EPC: 50209134

> up_dump_register: A0: 8020 A1:  A2:

> 02a8 A3: 02a8

> up_dump_register: A4:  A5: 8020 A6:

>  A7: 

> up_dump_register: T0: 0003 T1: 0007 T2:

> 0020 T3: 802002a8

> up_dump_register: T4: 8020 T5: 00ff T6:

> 000f

> up_dump_register: S0: 8020 S1: 00080d58 S2:

>  S3: 80202988

> up_dump_register: S4: 0001 S5: 802008c8 S6:

> 50409980 S7: 

> up_dump_register: S8: 0001 S9:  S10:

>  S11: 

> up_dump_register: SP: 5040b220 FP: 8020 TP:

>  RA: 502098d6

>

> Full log:

> https://gist.github.com/juniskane/6695c16da910c040773911069d10812c<

> https://gist.github.com/juniskane/6695c16da910c040773911069d10812c>

> [https://github.githubassets.com/assets/gist-og-image-54fd7dc0713e.png]<

> https://gist.github.com/juniskane/6695c16da910c040773911069d10812c>

> nuttx-ox64-2024-01-11_getprimes_hello_crash.log<

> https://gist.github.com/juniskane/6695c16da910c040773911069d10812c>

> nuttx-ox64-2024-01-11_getprimes_hello_crash.log. GitHub Gist: instantly

> share code, notes, and snippets.

> gist.github.com

> Also slightly different combo:

>

> cd /system/bin

> getprime

> sh

>

> produces:

>

> _assert: Current Version: NuttX  12.4.0-RC0 4761af7069 Jan 11 2024

> 00:11:48 risc-v

> _assert: Assertion failed offset && val: at file:

> machine/risc-v/arch_elf.c:565 task: /system/bin/init process:

> /system/bin/init 0x804a

> up_dump_register: EPC: 50201ffe

> up_dump_register: A0: 504013d0 A1: 0235 A2:

> 502275e8 A3: 007e

> up_dump_register: A4: 5040b8d0 A5: 0001 A6:

>  A7: fff8

> up_dump_register: T0: 0003 T1: 0007 T2:

> 0020 T3: 5040b06c

> up_dump_register: T4: 5040b060 T5: 00ff T6:

> 000f

> up_dump_register: S0:  S1: 5040b8d0 S2:

> 5040d200 S3: 5040b8d0

> up_dump_register: S4: 502275e8 S5: 502275b0 S6:

> 000200042022 S7: 50401b30

> up_dump_register: S8: 0235 S9: 0766 S10:

> 2a2d S11: 0100

> up_dump_register: SP: 00

RE: NuttX Workshop 2024 - event planning

[alin.jerpe...@sony.com]

Hi Tomek,

For every event we had weekly meetings to plan the event. For all past events 
those meetings were hosted Friday 19:00-20:00.

I will send the invitation ASAP for the meeting to all people that expressed 
interest to help with the event.

I propose that we start the meetings this Friday if this works for everybody

Best regards
Alin


From: Tomek CEDRO 
Sent: den 22 januari 2024 22:10
To: dev@nuttx.apache.org
Subject: Re: NuttX Workshop 2024 - event planning

On Mon, Jan 22, 2024 at 8: 10 AM Alin Jerpelea wrote: > time is flying and we 
are almost at the end of January > I think that we should have a live meeting 
to plan the website and open the > CFP to give people time plan the trip. I
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.
ZjQcmQRYFpfptBannerEnd

On Mon, Jan 22, 2024 at 8:10 AM Alin Jerpelea wrote:

> time is flying and we are almost at the end of January

> I think that we should have a live meeting to plan the website and open the

> CFP to give people time plan the trip. I would recommend to host the event

> Thursday-Friday to avoid the jet-lag and encourage local participation .



On the other international conferences that I help to organize and

execute we have an online all-hand-on-deck meeting every two weeks for

several months in advance.. while closer to the event there may be

more meetings as required.



We can use google calendar + meet + docs.. or we could use existing

Discord server for meetings?



How about initial meeting this week? What would be preferred day and UTC time?



Wednesday around 20:00 UTC would be best for me but I can adapt :-) I

am CET (UTC+1) and in summer time CEST (UTC+2) timezone (Warsaw Time).



I can also help in updating the even website :-)



Tomek



ps/2: Twitch.TV platform gets popular and I think we should create

NuttX profile there and also use for live stream in addition to

YouTube?



--

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

RE: NuttX Workshop 2024 - event planning

[alin.jerpe...@sony.com]

Hi Alan,

>From my knowledge there are no conferences in that period in JP. AFAIK the 
>conferences are at the beginning of December and everybody is busy to attend 
>or organize them.
Considering vacation plans in Europe and I still think that 10-17 Jun would be 
a really good period. I will send the invitations for this Friday then we can 
talk live and decide if this date suits us all.

We already have the new logos for 2024 and I will run the website through a 
colleague (professional editor) to update it for 2024. The aim should be that 
latest on Monday we have a date for the event, dates for CFP and basic travel 
information for attendees.

Best regards
Alin

From: Alan C. Assis 
Sent: den 23 januari 2024 20:52
To: dev@nuttx.apache.org
Subject: Re: NuttX Workshop 2024 - event planning

Hi Alin, I used Google Flights to comparece prices and the values are basically 
the same from May to August. If we have some bigger embedded/computer 
conference happening in Japan around that time, we could put NuttX Workshop 
just after that,


Hi Alin,



I used Google Flights to comparece prices and the values are basically the

same from May to August.



If we have some bigger embedded/computer conference happening in Japan

around that time, we could put NuttX Workshop just after that, this way

people could participate in both events.



Let us define the date soon to give people enough time to submit proposals

and organize the flight.



For the Internet, while visiting my company in Canada I discovered

something very useful: install Airalo app and buy an eSIM with a low cost

Internet plan.

For Japan they have the lowest plan of 1GB data valid for 7 days for just

U$ 4.50 or 10GB valid for 30 days for U$ 9.00.



Best Regards,



Alan

Sv: NuttX correct version

[alin.jerpe...@sony.com]

Hi Roberto,

the tag has been created.
Thanks for reporting the issue

Best regards
Alin


Från: Alin Jerpelea 
Skickat: den 8 februari 2024 16:47
Till: dev@nuttx.apache.org 
Ämne: Re: NuttX correct version

ill fix it asap thanks for pointing it out Best regards Alin On Thu, 8 Feb 
2024, 16: 42 Alan C. Assis,  wrote: > Hi Roberto, > > I 
think it is happening because we released the version 12. 4. 0 and forgot >


ill fix it asap
thanks for pointing it out

Best regards
Alin

On Thu, 8 Feb 2024, 16:42 Alan C. Assis,  wrote:

> Hi Roberto,
>
> I think it is happening because we released the version 12.4.0 and forgot
> to great the tag, see the git tag result:
> ...
> nuttx-12.2.1
> nuttx-12.2.1-RC0
> nuttx-12.3.0
> nuttx-12.3.0-RC0
> nuttx-12.3.0-RC1
> nuttx-12.4.0-RC0
>
> It needs to be fixed.
>
> BR,
>
> Alan
>
> On Thu, Feb 8, 2024 at 4:57 AM Roberto Bucher <
> roberto.bucher.2...@gmail.com>
> wrote:
>
> > Hi
> >
> > When I create a library export of the NuttX project I receive a library
> > *nuttx-export-12.4.0-RC0.tar.gz*. Is this correct or I have to get a
> > *12.4.0* version?
> >
> > Thanks in advance
> >
> > Roberto
> >
> >
> >
>

Sv: [Article] Drag-n-Drop a NuttX App

[alin.jerpe...@sony.com]

Congrats LUP!!!

Best Regards
Alin

Från: Tomek CEDRO 
Skickat: den 25 februari 2024 01:33
Till: dev@nuttx.apache.org 
Ämne: Re: [Article] Drag-n-Drop a NuttX App

CONGRATZ LUP!! :-) -- CeDeROM, SQ7MHZ, https: //urldefense. com/v3/__http: 
//www. tomek. cedro. 
info__;!!JmoZiZGBv3RvKRSx!-A9ZICfumrvgh6F-6I8ZM23pIb6NICcElGFV4vO-3R8xzyUCeoOkq0v6cz4u4TTQcs2Uj4VXuGfYGSABmA$
 ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍
ZjQcmQRYFpfptBannerStart
Caution : This email originated from outside of Sony.
Do not click links or open any attachments unless you recognize the sender and 
know the content is safe. Please report phishing if unsure.

ZjQcmQRYFpfptBannerEnd

CONGRATZ LUP!! :-)

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

Sv: [VOTE] Apache NuttX 12.7.0 RC0 release

[alin.jerpe...@sony.com]

Hi all ,

sim: fix sim smp boot regression
https://github.com/apache/nuttx/pull/13933

Best regards
Alin

Från: Tim Hardisty 
Skickat: den 7 oktober 2024 16:20
Till: dev@nuttx.apache.org 
Ämne: Re: [VOTE] Apache NuttX 12.7.0 RC0 release

Hi. It was because the NuttX framebuffer driver *in LVGL* rendered directly to 
the NuttX /dev/fb0 device, causing tearing issues and artefacts. It should have 
had a second buffer that LVGL rendered to rather than direct to the device 
driver's


Hi.

It was because the NuttX framebuffer driver *in LVGL* rendered directly
to the NuttX /dev/fb0 device, causing tearing issues and artefacts. It
should have had a second buffer that LVGL rendered to rather than direct
to the device driver's framebuffer memory.

I raised a nuttx-apps issue here :
https://urldefense.com/v3/__https://github.com/apache/nuttx-apps/issues/2416__;!!JmoZiZGBv3RvKRSx!5vRrsoeEzdG1INRASOOWjC76d-TAJsUeJYAH_JJvjqPRzdmJjqxr_o-M0H00C65dkKpiK7BxG7OelzCbJRivEJAN$

and cross-referenced here: 
https://urldefense.com/v3/__https://github.com/apache/nuttx-apps/issues/2461__;!!JmoZiZGBv3RvKRSx!5vRrsoeEzdG1INRASOOWjC76d-TAJsUeJYAH_JJvjqPRzdmJjqxr_o-M0H00C65dkKpiK7BxG7OelzCbJbJ1XGKb$

The final fix, in LVGL, was here:

https://urldefense.com/v3/__https://github.com/lvgl/lvgl/pull/6580__;!!JmoZiZGBv3RvKRSx!5vRrsoeEzdG1INRASOOWjC76d-TAJsUeJYAH_JJvjqPRzdmJjqxr_o-M0H00C65dkKpiK7BxG7OelzCbJaKFAb8f$

I also had a brief discussion here about it when I was trying to
understand the issues:

https://urldefense.com/v3/__https://www.mail-archive.com/dev@nuttx.apache.org/msg11509.html__;!!JmoZiZGBv3RvKRSx!5vRrsoeEzdG1INRASOOWjC76d-TAJsUeJYAH_JJvjqPRzdmJjqxr_o-M0H00C65dkKpiK7BxG7OelzCbJbHk71ri$

I never had any issues with the framebuffer example app though.

Sneak preview that I'm happy to share only here for now - as the product
is still a few weeks away from launch - of what I'm doing; it works with
NuttX (master) and LVGL 9.2. The file linked to is an MP4 shared from my
own NAS so hopefully the link works.

https://urldefense.com/v3/__http://gofile.me/2MJqt/dBf6BZgKj__;!!JmoZiZGBv3RvKRSx!5vRrsoeEzdG1INRASOOWjC76d-TAJsUeJYAH_JJvjqPRzdmJjqxr_o-M0H00C65dkKpiK7BxG7OelzCbJejwOuVZ$


Regards,

Tim.

On 07/10/2024 14:23, Tomek CEDRO wrote:
> Thank you Tim could you please pinpoint the issue with LCD / FB? Anyone
> with that hardware help is more than welcome!! It would be great to have
> graphics working + new lvgl in upcoming release :-)
>
> I would go:
> 1. test on older release known to work. just to confirm working hardware.
> 2. try some really basic application that draws red rectangle on red
> background (something like that) just to confirm working lcd / spi / fb.
> can use nxwidgets if lvgl broken.
> 3. review / change configuration parameters to see if this is the problem.
> 4. try git bisect between master head and known working configuration to
> find what introduced the problem.
>
> Thank you!! :-)
>
> --
> CeDeROM, 
> SQ7MHZ,https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!JmoZiZGBv3RvKRSx!5vRrsoeEzdG1INRASOOWjC76d-TAJsUeJYAH_JJvjqPRzdmJjqxr_o-M0H00C65dkKpiK7BxG7OelzCbJZ1pSKU-$
>
> On Mon, Oct 7, 2024, 14:37 Tim Hardisty wrote:
>
>> FYI, I tried RC0 on my SAMA5D2 custom board with no issues. My app and
>> LVGL demos (with LVGL V9.1 - with known issues - and V9.2) run OK as
>> does the FB example app, so I would think any issues are possibly
>> arch-specific rather than 100% down to LVGL.
>>
>> I did try OSTEST but I gave up waiting for it to complete to try 
>> - I have never run it before so I have no idea how long it would be
>> expected to run for before completion!
>>
>> On 07/10/2024 08:15, Alin Jerpelea wrote:
>>> Hi all,
>>>
>>> the voting is closed
>>>
>>> We will fix the bugs and start the RC1 test and vote process
>>>
>>> Please link fixes to this thread
>>>
>>> Best regards
>>> Alin
>>>
>>> On Mon, 7 Oct 2024, 09:12 raiden00pl, wrote:
>>>
 I fully agree with Tomek. If possible, let's delay the release for a
>> while
 and fix what's broken, or at least find the broken
>> configurations/features.
 What I have tested so far:
 - [X] sim/foc - fixed
 - [X] sim/smp - **broken**
 - [X] sim/nsh - OK
 - [X] sim/crypto - OK
 - [X] sim/elf - OK
 - [X] sim/fb - OK
 - [X] sim/lvgl_fb - OK

 - [X] nrf52840-dk/adc - OK
 - [X] nrf52840-dk/pwm - OK
 - [X] nrf52840-dk/highpri - **boken**
 other highpri examples also broken
 - [X] nrf52840-dk/sdc_nimble - OK
 - [X] nrf52840-dk/sdc - OK
 - [X] nrf52840-dk/composite - OK
 - [X] nrf52840-dk/timer - fixed
 - [X] nrf52840-dk/tickelss - OK
 - [X] nrf52840-dk/qspi - OK

 - [X] stm32f4disco/nsh - OK
 - [X] stm32f4disco/elf - OK
 - [X] stm32f4disco/module - OK
 - [X] stm32f4disco/usbnsh - OK

 - [X] stm32g071b-disco/oled - fixed

 - [X] stm32f746g-disco/nsh - OK
 - [X] stm32f746g-disco/fb - *broken* (not related to 

Sv: About SW licenses

[alin.jerpe...@sony.com]

Hi all,

I am running FOSSID from time to time and now with the SPDX migration I am 
scanning again the code.
Doing checks from time to time may not be enough and the best guard would be a 
CI snipped scanner

Best regards
Alin


Från: raiden00pl 
Skickat: den 16 oktober 2024 12:04
Till: dev@nuttx.apache.org 
Ämne: Re: About SW licenses

+1 We need to pay more attention to the license of the code that is added. GPL 
can destroy this project :( śr. , 16 paź 2024 o 07: 33 Jukka Laitinen  napisał(a): > Hi, > > A kind reminder to everyone 
contributing


+1

We need to pay more attention to the license of the code that is added. GPL
can destroy this project :(

śr., 16 paź 2024 o 07:33 Jukka Laitinen  napisał(a):

> Hi,
>
> A kind reminder to everyone contributing code to NuttX;
>
> Please keep in mind that it is NOT allowed to copy code snippets from
> any GPL licensed code into Apache/NuttX.
>
> While reading through arch/arm64 code base, my eye catches a lot of
> places now, which resemble code in linux kernel. This *may* be
> co-incidence, since the code is doing the same things in practice.
>
> I don't have any proper snippet scan tool at my disposal atm. Maybe if
> someone has (e.g. blackduck hub), it would be nice to confirm that there
> isn't any creeping in of GPLv2 code snippets.
>
> Anyhow; for now I just wanted to remind everyone about this. *do not
> copy code from linux kernel or other GPL licensed code*. This would do
> great harm to users of NuttX
>
> Thanks,
>
> Jukka
>
>
>

Sv: [VOTE] Apache NuttX 12.7.0 RC1 release

[alin.jerpe...@sony.com]

I will close the vote with my
+1
tested on spresense


Från: Alan C. Assis 
Skickat: den 28 oktober 2024 16:27
Till: dev@nuttx.apache.org 
Ämne: Re: [VOTE] Apache NuttX 12.7.0 RC1 release

This is the correct link: https: //urldefense. com/v3/__https: //acassis. 
wordpress. 
com/2013/04/26/running-nuttx-on-kinetis-kl25z-freedom-board-frdm-kl25z__;!!JmoZiZGBv3RvKRSx!9fo5_mSpYK12CyxNgXW43CUPOKR01Jw-zCeQZw-t3pocq14p4R9AiqPH_RHL52qpU25XmaRoYVN3pRlw$


This is the correct link:

https://urldefense.com/v3/__https://acassis.wordpress.com/2013/04/26/running-nuttx-on-kinetis-kl25z-freedom-board-frdm-kl25z__;!!JmoZiZGBv3RvKRSx!9fo5_mSpYK12CyxNgXW43CUPOKR01Jw-zCeQZw-t3pocq14p4R9AiqPH_RHL52qpU25XmaRoYVN3pRlw$


On Mon, Oct 28, 2024 at 10:20 AM Alan C. Assis  wrote:

> Hi Tomek,
>
> Thank you for testing NuttX on the FRDM-KL25Z board, I did the port 11
> years ago and I'm surprised it is still working fine.
>
> You can find more info here:
>
> https://urldefense.com/v3/__https://acassis.wordpress.com/2013/04/26/running-nuttx-on-kinetis-kl25z-freedom-board-frdm-kl25z/FRDM-KL25Z__;!!JmoZiZGBv3RvKRSx!9fo5_mSpYK12CyxNgXW43CUPOKR01Jw-zCeQZw-t3pocq14p4R9AiqPH_RHL52qpU25XmaRoYZtpMWUd$
>
>
> https://urldefense.com/v3/__https://acassis.wordpress.com/2013/10/10/how-to-use-st-link-v2-to-program-freedom-board-frdm-kl25z/__;!!JmoZiZGBv3RvKRSx!9fo5_mSpYK12CyxNgXW43CUPOKR01Jw-zCeQZw-t3pocq14p4R9AiqPH_RHL52qpU25XmaRoYXAj_bj9$
>
> If you can, please submit a picture of the board the and instructions to
> Documentation/
>
> I don't have this board anymore.
>
> BR,
>
> Alan
>
>
> On Sun, Oct 27, 2024 at 3:35 PM Tomek CEDRO  wrote:
>
>> On Sat, Oct 26, 2024 at 7:55 AM Alin Jerpelea  wrote:
>> > Apache NuttX 12.7.0 RC1 has been staged under [1] and it's
>> > time to vote on accepting it for release. Voting will be open for 72hr.
>>
>> +1 FROM ME AND BIG THANK YOU FOR ALL CONTRIBUTORS!! :-)
>>
>> === BUILD HOST ===
>>
>> % uname -a
>> FreeBSD octagon 13.3-RELEASE-p7 FreeBSD 13.3-RELEASE-p7 GENERIC amd64
>>
>> === TARGETS ==
>>
>> 1. SIM:LVGL.
>> 2. ESP32.
>> 3. ESP32C3.
>> 4. STM32L432KC.
>> 5. STM32F769I.
>> 6. STM32F412ZG.
>> 7. STM32F411RE.
>> 8. STM32F072RB.
>> 9. MKL25Z128.
>>
>>
>> === SIM:LVGL ===
>>
>> This is the only build I did on Linux Debian12 binaries running on
>> FreeBSD as Xlib.h location needs adjustment but this is not
>> relevant right now.. we have newest version of LVGL and now we can
>> announce and share NuttX for everyone asking.. several friends asked
>> me recently about LVGL on NuttX and it is here wow :-)
>>
>> $ uname -a
>> Linux octagon 5.15.0 FreeBSD 13.3-RELEASE-p7 GENERIC x86_64 GNU/Linux
>>
>> $ ./tools/configure.sh -l sim:lvgl_fb
>> #
>> # configuration written to .config
>> #
>> $ make
>> Create version.h
>> LN: platform/board to /XXX/nuttx-apps.git/platform/dummy
>> Register: lvgldemo
>> Register: nsh
>> Register: sh
>> CP:  /XXX/nuttx.git/include/nuttx/config.h
>> CP:  /XXX/nuttx.git/include/nuttx/fs/hostfs.h
>> LD:  nuttx
>> $ ./nuttx
>> [LVGL] [User]   (0.000, +0)  check_stack_size: tid: 4, Stack size
>> : 67520 lv_nuttx_entry.c:297
>> [LVGL] [User]   (0.000, +0)  lv_nuttx_fbdev_set_file: The
>> framebuffer device was opened successfully lv_nuttx_fbdev.c:108
>> [LVGL] [User]   (0.000, +0)  lv_nuttx_fbdev_set_file: VideoInfo:
>> lv_nuttx_fbdev.c:116
>> [LVGL] [User]   (0.000, +0)  lv_nuttx_fbdev_set_file:   fmt:
>> 13 lv_nuttx_fbdev.c:117
>> [LVGL] [User]   (0.000, +0)  lv_nuttx_fbdev_set_file:  xres:
>> 640 lv_nuttx_fbdev.c:118
>> [LVGL] [User]   (0.000, +0)  lv_nuttx_fbdev_set_file:  yres:
>> 480 lv_nuttx_fbdev.c:119
>> [LVGL] [User]   (0.000, +0)  lv_nuttx_fbdev_set_file:   nplanes: 1
>> lv_nuttx_fbdev.c:120
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo: PlaneInfo (plane 0):
>> lv_nuttx_fbdev.c:319
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo: mem: 0x44e0
>> lv_nuttx_fbdev.c:320
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo: fblen: 2457600
>> lv_nuttx_fbdev.c:321
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo:stride: 2560
>> lv_nuttx_fbdev.c:322
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo:   display: 0
>> lv_nuttx_fbdev.c:323
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo:   bpp: 32
>> lv_nuttx_fbdev.c:324
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo: PlaneInfo (plane 0):
>> lv_nuttx_fbdev.c:319
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo: mem: 0x44e0
>> lv_nuttx_fbdev.c:320
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo: fblen: 2457600
>> lv_nuttx_fbdev.c:321
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo:stride: 2560
>> lv_nuttx_fbdev.c:322
>> [LVGL] [User]   (0.000, +0)  fbdev_get_pinfo:  

Sv: NuttX Code Quality Improvement 2025Q1

[alin.jerpe...@sony.com]

Hi Tomek,

another important change is that PRs should only touch one area.
In the past it was common for developers to submit PR with arch, documentation 
and board commits
If we aim to start the LTS releases, from now we should request that they send 
several PRs

Best regards
Alin


Från: alin.jerpe...@sony.com 
Skickat: den 6 februari 2025 10:20
Till: dev@nuttx.apache.org 
Ämne: Sv: NuttX Code Quality Improvement 2025Q1

Hi Tomek, thanks for taking the lead on summarizing the changes so that we can 
vote them I would propose that we refine the review requirement and demand less 
reviews for boards and areas that have limited scope while increasing the 
number for


Hi Tomek,

thanks for taking the lead on summarizing the changes so that we can vote them
I would propose that we refine the review requirement and demand less reviews 
for boards and areas that have limited scope while increasing the number for 
common areas that have a wider scope : ex arch, drivers, frameworks. In my 
opinion we should mandate HW testing and community discussion for NuttX core, 
scheduler or areas that impact everybody.

Best regards
Alin

Från: raiden00pl 
Skickat: den 6 februari 2025 09:28
Till: dev@nuttx.apache.org 
Ämne: Re: NuttX Code Quality Improvement 2025Q1

> Perhaps I would limit this to larger commits only (and all affecting Build / 
> Kernel / common arch code of course). GitHub bot tells you the size of the 
> pull request, so we can draw some line according to that. And maybe it could 
> also automatically


> Perhaps I would limit this to larger commits only (and all affecting
Build / Kernel / common arch code of course). GitHub bot tells you the
size of the pull request, so we can draw some line according to that.
And maybe it could also automatically set the mandatory number of
reviewers. This way simple changes/fixes/additions to BSPs or MCU
drivers would be handled faster.

+1. Not all PRs have the same importance and impact. For PR that
has a high impact on other users, 4 reviewers make sense.
For PR that has low impact, addressing new features or newly
developed architectures this is overkill. I could list more cases where
such an approach doesn't make sense considering the resources
we have. We'll end up being flooded with PRs without approvals,
which will discourage both contributors and reviewers.

Using github labels in this case can help, but the automation of
this is very limited by the tool. It's not really possible to create
complicated dependencies for labels, or I haven't figured out how to
do it. We can introduce a new label "4 approvals", but it's assignment
will have to be done manually by the PR creator or reviewer.

We could also add labels for individual chips and separate them from
labels for code common to the architecture (like "Arch: arm" and
"Arch: STM32"), this would greatly help with judging the importance
of PR.  Unfortunately, implementing this is a long and boring work.

> By Architecture, do you mean common architecture code or even MCU
specific code? I am not sure if describing every change to a single MCU
on a mailing list is beneficial, I am afraid it will just flood the list
and no one will read it. GitHub issues seem more suitable for this.

+1. Informing about breaking changes in the common code of the
architectures - YES. Informing about breaking changes in stable chips
that are used by users (like stm32) - YES. All other cases - probably NO.

czw., 6 lut 2025 o 08:45 Michal Lenc  napisał(a):

> Hi Tomek,
>
> I think most of the points make sense, just few notes to some of them.
>
> > * Number of required code reviews should be increased from 2 to 4.
> > This will ensure cross-checks and filter out faulty changes.
>
> Perhaps I would limit this to larger commits only (and all affecting
> Build / Kernel / common arch code of course). GitHub bot tells you the
> size of the pull request, so we can draw some line according to that.
> And maybe it could also automatically set the mandatory number of
> reviewers. This way simple changes/fixes/additions to BSPs or MCU
> drivers would be handled faster.
>
> > * If change touches Build / Kernel / Architecture it must be presented
> > and discussed on the mailing list with the community first. PR may be
> > created with clear indication it is for discussion and marked as draft
> > not to be "accidentally merged".
>
> By Architecture, do you mean common architecture code or even MCU
> specific code? I am not sure if describing every change to a single MCU
> on a mailing list is beneficial, I am afraid it will just flood the list
> and no one will read it. GitHub issues seem more suitable for this.
>
> > Also it will be nice to have monthly online meetings just to talk
> > things ov

Sv: NuttX Code Quality Improvement 2025Q1

[alin.jerpe...@sony.com]

Hi Tomek,

thanks for taking the lead on summarizing the changes so that we can vote them
I would propose that we refine the review requirement and demand less reviews 
for boards and areas that have limited scope while increasing the number for 
common areas that have a wider scope : ex arch, drivers, frameworks. In my 
opinion we should mandate HW testing and community discussion for NuttX core, 
scheduler or areas that impact everybody.

Best regards
Alin

Från: raiden00pl 
Skickat: den 6 februari 2025 09:28
Till: dev@nuttx.apache.org 
Ämne: Re: NuttX Code Quality Improvement 2025Q1

> Perhaps I would limit this to larger commits only (and all affecting Build / 
> Kernel / common arch code of course). GitHub bot tells you the size of the 
> pull request, so we can draw some line according to that. And maybe it could 
> also automatically


> Perhaps I would limit this to larger commits only (and all affecting
Build / Kernel / common arch code of course). GitHub bot tells you the
size of the pull request, so we can draw some line according to that.
And maybe it could also automatically set the mandatory number of
reviewers. This way simple changes/fixes/additions to BSPs or MCU
drivers would be handled faster.

+1. Not all PRs have the same importance and impact. For PR that
has a high impact on other users, 4 reviewers make sense.
For PR that has low impact, addressing new features or newly
developed architectures this is overkill. I could list more cases where
such an approach doesn't make sense considering the resources
we have. We'll end up being flooded with PRs without approvals,
which will discourage both contributors and reviewers.

Using github labels in this case can help, but the automation of
this is very limited by the tool. It's not really possible to create
complicated dependencies for labels, or I haven't figured out how to
do it. We can introduce a new label "4 approvals", but it's assignment
will have to be done manually by the PR creator or reviewer.

We could also add labels for individual chips and separate them from
labels for code common to the architecture (like "Arch: arm" and
"Arch: STM32"), this would greatly help with judging the importance
of PR.  Unfortunately, implementing this is a long and boring work.

> By Architecture, do you mean common architecture code or even MCU
specific code? I am not sure if describing every change to a single MCU
on a mailing list is beneficial, I am afraid it will just flood the list
and no one will read it. GitHub issues seem more suitable for this.

+1. Informing about breaking changes in the common code of the
architectures - YES. Informing about breaking changes in stable chips
that are used by users (like stm32) - YES. All other cases - probably NO.

czw., 6 lut 2025 o 08:45 Michal Lenc  napisał(a):

> Hi Tomek,
>
> I think most of the points make sense, just few notes to some of them.
>
> > * Number of required code reviews should be increased from 2 to 4.
> > This will ensure cross-checks and filter out faulty changes.
>
> Perhaps I would limit this to larger commits only (and all affecting
> Build / Kernel / common arch code of course). GitHub bot tells you the
> size of the pull request, so we can draw some line according to that.
> And maybe it could also automatically set the mandatory number of
> reviewers. This way simple changes/fixes/additions to BSPs or MCU
> drivers would be handled faster.
>
> > * If change touches Build / Kernel / Architecture it must be presented
> > and discussed on the mailing list with the community first. PR may be
> > created with clear indication it is for discussion and marked as draft
> > not to be "accidentally merged".
>
> By Architecture, do you mean common architecture code or even MCU
> specific code? I am not sure if describing every change to a single MCU
> on a mailing list is beneficial, I am afraid it will just flood the list
> and no one will read it. GitHub issues seem more suitable for this.
>
> > Also it will be nice to have monthly online meetings just to talk
> > things over and stay connected and synchronized. It should bring
> > community closer together :-)
>
> Yes! We have to find a proper channel for this though. I think there
> were efforts to have meetings on our Discord channel, but many people
> don't like the platform (for understandable reasons) so it didn't last
> for long.
>
> Best regards,
>
> Michal
>
> On 2/6/25 04:45, Tomek CEDRO wrote:
> > Hello world :-)
> >
> > We have long discussions over the last months NuttX code quality and
> > self-compatibility degradation. I think open discussion in this area
> > as for 2025Q1 can be constructive. Please join the discussion :-)
> >
> > After we have a good understanding and agreement on selected points we
> > should update Contributing Guidelines both for developers and
> > reviewers.
> >
> > * Each PR _must_ adhere to requirements presented in Contributing
> > Guidelines or be auto-rejected

Sv: [VOTE] Apache NuttX 12.9.0 RC0 release

[alin.jerpe...@sony.com]

Hi Liu,

thanks for your feedback
Can you link the missing patches?

Thanks
Alin


Från: Yanfeng Liu 
Skickat: den 9 april 2025 09:42
Till: dev@nuttx.apache.org 
Ämne: Re: [VOTE] Apache NuttX 12.9.0 RC0 release

Hi, -1 here. Checked mainly with rv-virt on Ubuntu 22. 04 with 
riscv64-unknown-elf-gcc toolchain 10. 2. 0 mainly. Passed configs: nsh, knsh, 
nsbi, flats Minor issue:   - rv-virt: python (failed to build with both 10. 2 
and 14. 2) Regards, yf On Tue,


Hi,

-1 here.

Checked mainly with rv-virt on Ubuntu 22.04 with riscv64-unknown-elf-gcc
toolchain 10.2.0 mainly.

Passed configs: nsh, knsh, nsbi, flats
Minor issue:
  - rv-virt:python (failed to build with both 10.2 and 14.2)

Regards,
yf

On Tue, 2025-04-08 at 07:21 +0200, Alin Jerpelea wrote:
> Hello all,
> Apache NuttX 12.9.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> required to pass.
>
> The Apache requirements for approving a release can be found here [3]
> "Before voting +1 PMC members are required to download the signed
> source code package, compile it as provided, and test the resulting
> executable on their own platform, along with also verifying that the
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
>   Release tag: nuttx-12.9.0-RC0
>   Hash for the release nuttx tag: 47cdb6a283974dd500f89c96e7ef8dc8abcca6c7
>   Hash for the release nuttx-apps tag:
> 036fe7668d81a02a9dc32cc18c31a8d74ee6fa4a
>
> [1] 
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/nuttx/12.9.0-RC0/__;!!O7_YSHcmd9jp3hj_4dEAcyQ!z1_lbwBG-XQibl3a_roE7vgw1ebLo0Jo77xLFIR0sXQYmLwRO5wI4lK0d9CoqcpzjmbkKG4hnCtJFuJTNqxVv_dm$
> [2]
> https://urldefense.com/v3/__https://raw.githubusercontent.com/apache/nuttx/nuttx-12.9.0-RC0/ReleaseNotes__;!!O7_YSHcmd9jp3hj_4dEAcyQ!z1_lbwBG-XQibl3a_roE7vgw1ebLo0Jo77xLFIR0sXQYmLwRO5wI4lK0d9CoqcpzjmbkKG4hnCtJFuJTNtfpuZ8m$
> [3] 
> https://urldefense.com/v3/__https://www.apache.org/dev/release.html*approving-a-release__;Iw!!O7_YSHcmd9jp3hj_4dEAcyQ!z1_lbwBG-XQibl3a_roE7vgw1ebLo0Jo77xLFIR0sXQYmLwRO5wI4lK0d9CoqcpzjmbkKG4hnCtJFuJTNjIS4LvH$
> [4]
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/Validating*a*staged*Release__;Kysr!!O7_YSHcmd9jp3hj_4dEAcyQ!z1_lbwBG-XQibl3a_roE7vgw1ebLo0Jo77xLFIR0sXQYmLwRO5wI4lK0d9CoqcpzjmbkKG4hnCtJFuJTNo9rOLqu$

Sv: Vote for using system dd instead of nsh dd, avoid duplicate code

[alin.jerpe...@sony.com]

+1

Best
Alin

Från: Lee, Lup Yuen 
Skickat: den 14 april 2025 15:53
Till: dev@nuttx.apache.org 
Ämne: Re: Vote for using system dd instead of nsh dd, avoid duplicate code

+1 Hi Donny: Please remember to close the voting in 72 hours. Thanks :-) Lup On 
Mon, Apr 14, 2025 at 9: 07 PM 董九柱  wrote: > Hello 
Community, > > I submit some PRs about using system/dd app instead of dd


+1

Hi Donny: Please remember to close the voting in 72 hours. Thanks :-)

Lup

On Mon, Apr 14, 2025 at 9:07 PM 董九柱  wrote:

> Hello Community,
>
> I submit some PRs about using system/dd app instead of dd command from
> nshlib.
>
> PR link:
> https://urldefense.com/v3/__https://github.com/apache/nuttx-apps/pull/3057__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2eBUrH98rX0tl8JvPrPE37DeNTU5GBbP8XSJonhrf_g5h2StfwhSHTlMwUEzhJvT1cxEIPNktq1ggT0$
> https://urldefense.com/v3/__https://github.com/apache/nuttx/pull/16198__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2eBUrH98rX0tl8JvPrPE37DeNTU5GBbP8XSJonhrf_g5h2StfwhSHTlMwUEzhJvT1cxEIPNkz7GKyqI$
>
> Why do?
> There are two implementations of dd in the current system, one under nshlib
> and the other under system/dd.
> we need to remove one to avoid duplication code and function lost. The
> discuss: 
> https://urldefense.com/v3/__https://github.com/apache/nuttx-apps/pull/3048__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2eBUrH98rX0tl8JvPrPE37DeNTU5GBbP8XSJonhrf_g5h2StfwhSHTlMwUEzhJvT1cxEIPNkXPgv_zE$
> From the current perspective, the system "dd" is a better choice, as it
> allows for the separate configuration of its corresponding stack and
> compilation into an independent wasm module.
>
> How do?
> 1. Align the functionality of "dd" in nshlib with that in the system "dd"
> to ensure consistent functionality.
> 2. Remove implement of dd in nshlib, include
> config(CONFIG_NSH_DISABLE_DD、NSH_CMDOPT_DD_STATS) and
> file(nshlib/nsh_ddcmd.c)
> 3. Adjust all board configurations to ensure backward and forward
> compatibility.
>
> So I need your vote here:
> If you accept the breaking PR, please reply with +1.
> If you reject the PR, please reply with -1.
>
> BRs,
>

Sv: [Article] NuttX for Avaota-A1 SBC: Creating the Unicorn Emulator

[alin.jerpe...@sony.com]

Kudos Lup!



Från: Tomek CEDRO 
Skickat: den 13 april 2025 22:26
Till: dev@nuttx.apache.org 
Ämne: Re: [Article] NuttX for Avaota-A1 SBC: Creating the Unicorn Emulator

Wow! What a journey! Thank you Lup!! :-) -- CeDeROM, SQ7MHZ, https: 
//urldefense. com/v3/__http: //www. tomek. cedro. 
info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!0uNKfXCTmON74tVOOjrd7HWRkFvJWQkHXElSLmZdCT6fJ6Wro_gkWozuMoH42LrTw123uI4mJn0JukVA_A$
 On Sun, Apr


Wow! What a journey! Thank you Lup!! :-)

--
CeDeROM, SQ7MHZ, 
https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!0uNKfXCTmON74tVOOjrd7HWRkFvJWQkHXElSLmZdCT6fJ6Wro_gkWozuMoH42LrTw123uI4mJn0JukVA_A$

On Sun, Apr 13, 2025 at 2:07 AM Lee, Lup Yuen  wrote:
>
> NuttX is officially supported on Avaota-A1 Arm64 SBC (Allwinner A527 SoC). 
> Let’s take Unicorn Emulator and create a Software Emulator for Avaota SBC...
>
> (1) We call Unicorn Library to create our Barebones Emulator
>
> (2) Emulate the 16550 UART hardware by intercepting I/O Memory
>
> (3) Recompile NuttX with 4 Tiny Tweaks and boot on Unicorn
>
> (4) NuttX makes a Context Switch and fails
>
> (5) Because Unicorn doesn’t handle Arm64 SysCalls?
>
> (6) No worries we’ll Emulate Arm64 SysCalls ourselves!
>
> (7) By jumping into the Arm64 Vector Table
>
> (8) NuttX on Unicorn boots to NSH Shell! (Almost)
>
> (9) How exactly does NuttX boot on Avaota SBC? We have a Detailed Boot Flow
>
> Why are we doing this?
>
> -- So we can create NuttX Drivers and Apps on Avaota SBC Emulator (without 
> the actual hardware)
>
> -- Avaota Emulator is helpful for NuttX Continuous Integration, making sure 
> that all Code Changes will run correctly on Avaota SBC
>
> -- The Trade Tariffs are Terribly Troubling. Some of us NuttX Folks might 
> need to hunker down and emulate Avaota SBC, for now.
>
> -- Or maybe we should provide Remote Access to a Real Avaota SBC? 🤔
>
> Check out the article: 
> https://urldefense.com/v3/__https://lupyuen.org/articles/unicorn4.html__;!!O7_YSHcmd9jp3hj_4dEAcyQ!0uNKfXCTmON74tVOOjrd7HWRkFvJWQkHXElSLmZdCT6fJ6Wro_gkWozuMoH42LrTw123uI4mJn3m3_LAtg$
>
>
>
> Lup
>

Sv: [Bug] RP2040 broken, any config&boards, ostest and apps hang

[alin.jerpe...@sony.com]

Hi Alan,

12.9 is already released
I will prepare a 12.9.1 release ASAP

Best regards
Alin



Från: Alan C. Assis 
Skickat: den 14 april 2025 13:25
Till: dev@nuttx.apache.org 
Ämne: Re: [Bug] RP2040 broken, any config&boards, ostest and apps hang

Hi Kevin and Alin, I confirmed that NuttX 12. 9-RC1 is broken on Raspberry Pi 
Pico. After copying the nuttx. uf2 to virtual disk RPI-RP2 the board restart by 
the /dev/ttyACM0 is not created. Please find the steps below: alan@ dev: /tmp$ 
cd nuttx/


Hi Kevin and Alin,

I confirmed that NuttX 12.9-RC1 is broken on Raspberry Pi Pico.

After copying the nuttx.uf2 to virtual disk RPI-RP2 the board restart by
the /dev/ttyACM0 is not created.

Please find the steps below:

alan@dev:/tmp$ cd nuttx/
alan@dev:/tmp/nuttx$ . tools/configure_completion.bash
alan@dev:/tmp/nuttx$ ./tools/configure.sh raspberrypi-pico:usbnsh

alan@dev:/tmp/nuttx$ make -j
Create version.h
LN: platform/board to /tmp/apps/platform/dummy
Register: hello
Register: nsh
Register: sh
Register: getprime
Register: ostest
CPP:
 
/tmp/nuttx/boards/arm/rp2040/raspberrypi-pico/scripts/raspberrypi-pico-flash.ld->
/tmp/nuLD: nuttx
Memory region Used Size  Region Size  %age Used
   flash:152 KB 2 MB  7.42%
sram:8872 B   264 KB  3.28%
Generating: nuttx.uf2
Done.

alan@dev:/tmp/nuttx$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/13.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/lib/include' --mandir='/usr/lib/share/man'
--infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/lib/x86_64-linux-gnu'
--libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --mandir=/usr/share/man
--enable-languages=c,c++,lto --enable-multilib --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-nls --disable-shared --disable-threads --enable-tls
--build=x86_64-linux-gnu --target=arm-none-eabi --with-system-zlib
--with-gnu-as --with-gnu-ld --with-pkgversion=15:13.2.rel1-2
--without-included-gettext --prefix=/usr/lib
--infodir=/usr/share/doc/gcc-arm-none-eabi/info
--htmldir=/usr/share/doc/gcc-arm-none-eabi/html
--pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3
--host=x86_64-linux-gnu --with-headers=no --without-newlib
--with-multilib-list=rmprofile,aprofile ASFLAGS= ASFLAGS_FOR_BUILD=
CFLAGS='-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
-flto=auto -ffat-lto-objects -fstack-protector-strong
-fstack-clash-protection -Wno-format -Wno-error=format-security
-fcf-protection
-fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
'CFLAGS_FOR_BUILD=-g -O2' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=3'
CPPFLAGS_FOR_BUILD= CXXFLAGS='-g -O2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
-flto=auto -ffat-lto-objects -fstack-protector-strong
-fstack-clash-protection -Wno-format -Wno-error=format-security
-fcf-protection
-fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
'CXXFLAGS_FOR_BUILD=-g -O2' DFLAGS=-frelease DFLAGS_FOR_BUILD=-frelease
FCFLAGS='-g -O2 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
-flto=auto -ffat-lto-objects -fstack-protector-strong
-fstack-clash-protection -fcf-protection
-fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
'FCFLAGS_FOR_BUILD=-g -O2' FFLAGS='-g -O2 -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer
-ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
-flto=auto -ffat-lto-objects -fstack-protector-strong
-fstack-clash-protection -fcf-protection
-fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2.rel1-2'
'FFLAGS_FOR_BUILD=-g -O2' LDFLAGS='-Wl,-Bsymbolic-functions -flto=auto
-ffat-lto-objects -Wl,-z,relro' LDFLAGS_FOR_BUILD= OBJCFLAGS='-g -O2
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffile-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=.
-flto=auto -ffat-lto-objects -fstack-protector-strong
-fstack-clash-protection -Wno-format -Wno-error=format-security
-fcf-protection
-fdebug-prefix-map=/build/gcc-arm-none-eabi-TuTZN0/gcc-arm-none-eabi-13.2.rel1=/usr/src/gcc-arm-none-eabi-15:13.2

Sv: Documentation tags for boards

[alin.jerpe...@sony.com]

Looks like a promising feature.

Thanks Matteo for proposing this feature!

Best regards
Alin



Från: Tomek CEDRO 
Skickat: den 27 april 2025 22:49
Till: dev@nuttx.apache.org 
Ämne: Re: Documentation tags for boards

Very cool start Matteo! Builds and works fine for me :-) Would it be possible 
to rename "Site Tags" to just "Tags"? :-) Thank you :-) Tomek On Sun, Apr 27, 
2025 at 8: 51 PM Matteo Golin  wrote: > > Hello 
everyone,


Very cool start Matteo! Builds and works fine for me :-)

Would it be possible to rename "Site Tags" to just "Tags"? :-)

Thank you :-)
Tomek

On Sun, Apr 27, 2025 at 8:51 PM Matteo Golin  wrote:
>
> Hello everyone,
>
> I opened a PR here to test out using tags in our docs:
> https://urldefense.com/v3/__https://github.com/apache/nuttx/pull/16275__;!!O7_YSHcmd9jp3hj_4dEAcyQ!00sA-EkxUCT6wXreo3756CstdLTmsW8DwB-Ub33S5y5UxSQfCeeWnR5Pz1hZmWN-tnkfO-ER5Ku9AxAOOw$
> Please leave your feedback!
>
> For now, I've included three types of tags:
> - Chip tags to indicate what chip a board uses
> - Peripheral tags to indicate supported peripherals (WiFi, Ethernet, etc)
> - 'Experimental' tag to indicate experimentally supported boards and
> drivers that are still under testing. This should hopefully alleviate some
> issues when it's adopted so users can avoid using experimental boards if
> they need a stable system.
>
> Let me know what you think or if you have any tag ideas! I'm considering
> having architecture tags like it was suggested here, and maybe also adding
> some feature tags that aren't necessarily related to peripherals like
> "multicore", "SMP", "asymmetric cores", "graphics" (for graphics capable
> systems), etc. I also think it might be a good idea to add "stable" tags to
> boards which are regularly tested, but that might have to wait until we're
> able to really commit to maintaining the stability of those boards.
>
> If this gets accepted I can work on tagging more of the documentation.
>
> Matteo
>
> On Thu, Apr 17, 2025 at 6:12 PM Matteo Golin  wrote:
>
> > Actually, I was just thinking about supported peripherals/features when I
> > thought about this, but I also think having tags for MCUs/chips would be
> > really useful! Perhaps even architectures, although I'm not sure if that's
> > necessary since all the boards are organized into directories based on
> > architecture anyways. I don't think every board needs its own tag since
> > each board is unique, it can just be searched by name.
> >
> > Happy to see that other people would benefit from this feature!
> >
> > Matteo
> >
> > On Thu, Apr 17, 2025 at 1:49 PM Tomek CEDRO  wrote:
> >
> >> Hi Matteo! Very cool idea to have tags in the docs to mark supported
> >> features! :-)
> >>
> >> I would see a list of all available predefined tags somewhere at the
> >> end of documentation (tag index) so we know what is out there and not
> >> to create new ones, so the search results and markings are coherent.
> >>
> >> Each board could have its own tag, mcu would have its own mcu, and
> >> supported peripherals (i.e. wifi), right?
> >>
> >> Thanks :-)
> >> Tomek
> >>
> >>
> >>
> >> On Thu, Apr 17, 2025 at 2:49 AM Matteo Golin 
> >> wrote:
> >> >
> >> > Hello everyone,
> >> >
> >> > I am starting a new drone project which I am hoping to use NuttX for,
> >> and as part of the project I am looking for NuttX
> >> > supported boards that include WiFi support. I was thinking, it might be
> >> useful for the NuttX documentation to make use
> >> > of a tag system to easily search for features.
> >> >
> >> > I found this Sphinx extension that allows you to use tags, maybe we
> >> could start using it in NuttX's docs:
> >> > https://urldefense.com/v3/__https://sphinx-tags.readthedocs.io/en/latest/quickstart.html*usage__;Iw!!O7_YSHcmd9jp3hj_4dEAcyQ!00sA-EkxUCT6wXreo3756CstdLTmsW8DwB-Ub33S5y5UxSQfCeeWnR5Pz1hZmWN-tnkfO-ER5KtBke7GJA$
> >> >
> >> > This way it would be possible to filter boards by different features,
> >> which would be a useful search feature. For
> >> > example, the XIAO ESP32S3 has hardware support for WiFi:
> >> >
> >> https://urldefense.com/v3/__https://nuttx.apache.org/docs/latest/platforms/xtensa/esp32s3/boards/esp32s3-xiao/index.html__;!!O7_YSHcmd9jp3hj_4dEAcyQ!00sA-EkxUCT6wXreo3756CstdLTmsW8DwB-Ub33S5y5UxSQfCeeWnR5Pz1hZmWN-tnkfO-ER5Kv8hFWKGA$
> >> >
> >> > But I don't think NuttX implements it yet. If I were able to filter by
> >> boards that support WiFi, I wouldn't have to look
> >> > up supported boards I'm not familiar with, or read all their
> >> documentation pages. I wanted to know what others think;
> >> > would this would be worthwhile to add or is it just more work to ensure
> >> that documented boards include the proper tags?
> >> >
> >> > On a side note, if there is anyone who has written WiFi support for a
> >> chip in NuttX, please let me know if you have any
> >> > tips to get started or if you've happened to write a guide. I might
> >> decide to spend some time on adding 

Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

[alin.jerpe...@sony.com]

Hi Tomek,
thanks for taking the leas on the new vote round but

I would like to express my concern because AFAIK the voting process should be 
conducted on the mailing list for transparency and archiving purposes.

I think that it is better to restart the vote on the mailing list (similar to 
round 1)

Best regards
Alin


Från: Tiago Medicci Serrano 
Skickat: den 24 februari 2025 12:51
Till: dev@nuttx.apache.org 
Ämne: Re: [VOTE] ROUND2 NuttX Contributing Guidelines update 202502.

Voted! Please vote. This is valid for the overall NuttX community (not only 
PMCs or committers). Em sex. , 21 de fev. de 2025 às 23: 45, Tomek CEDRO 
 escreveu: > Hello world :-) > > After the first voting, 
discussions,


Voted!

Please vote. This is valid for the overall NuttX community (not only PMCs
or committers).

Em sex., 21 de fev. de 2025 às 23:45, Tomek CEDRO 
escreveu:

> Hello world :-)
>
> After the first voting, discussions, and updates, here goes the Round
> 2 of the voting for NuttX Contributing Guidelines update:
>
> https://urldefense.com/v3/__https://forms.gle/m3uRDGuE3QZy2yNn6__;!!O7_YSHcmd9jp3hj_4dEAcyQ!1TZwX8z2QbAGVBThPeIqRjrVwYavi50tX53yQXRaIPr7USnPeM0lQfjVZvl1p3hGlKR4o34RJZMC5FgbulyKFDgJ$
>
> There are again all rule propositions numbered from 1 to 19 with
> optional text fields if you feel texting can be fixed, especially
> important to provide feedback when you vote 0 or -1.
>
> Vote will close on 20250228 with results presentation and hopefully
> rules update :-)
>
> Thank you for your time and votes! :-)
> Tomek
>
> --
> CeDeROM, SQ7MHZ, 
> https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!1TZwX8z2QbAGVBThPeIqRjrVwYavi50tX53yQXRaIPr7USnPeM0lQfjVZvl1p3hGlKR4o34RJZMC5FgbugXlmYWH$
>

Re: [Vote] NuttX LTS release

[alin.jerpe...@sony.com]

Hi Tim,
the release process for every release is having 4 weeks of stabilization

ex: for the proposed release

LTS release plan for 13.0.0

  *
create the 13.0.0 branch on 1 March
  *
back-port the fixes (no enhancements) for 4 weeks
  *
create the RC0 release tag on 21 March and start the release vote
  *
if RC0 passes create 13.0.0 LTS release
  *
if RC0 does not pass we fix the issues and we create RC1 tag on 28 March and 
start the release vote

LTS release maintenance

  *
13.0.0 branch will receive bugfixes and security fixes for 15 months
  *
planned LTS tags and releases
 *
13.0.1 LTS end of Jun 2025
 *
13.0.2 LTS end of September 2025
 *
13.0.3 LTS end of December 2025
 *
13.0.4 LTS end of March 2026
 *
13.0.5 LTS end of Jun 2026

Regular releases are continuing on Jun, Sept, December

  *
create 13.1.0 branch on 1 Jun
  *
back-port the fixes (no enhancements) for 4 weeks
  *
if RC0 passes create 13.1.0 release
  *
if RC0 does not pass we fix the issues and we create RC1 tag and start the 
release vote

Best regards
Alin

Från: Tim Hardisty 
Skickat: den 26 februari 2025 11:51
Till: dev@nuttx.apache.org 
Ämne: Re: [Vote] NuttX LTS release

I was only skim reading the discussions on LTS, so probably missed detailed 
descriptions/conclusion of the LTS proposal. It seems a great idea but 
@raiden00pl makes a valid point I think? This is a vote for 13. 0. 0 which is 
an LTS candidate I


I was only skim reading the discussions on LTS, so probably missed
detailed descriptions/conclusion of the LTS proposal. It seems a great
idea but @raiden00pl makes a valid point I think?

This is a vote for 13.0.0 which is an LTS candidate I would imagine.
Once out in the wild, any fixes (not enhancements, additions etc) would
be applied until it is deemed stable, then a vote on 13.0.1LTS would be
made.

So any PRs that relate to 13.0.1LTS need a procedure to mark them as
such, or a 13.0.1LTS branch created at the same time as 13.0.0 is
released perhaps and "fix" PRs based on that baseline? Or a suitable tag
to the PR allows a backport to 13.0.0 for the 13.0.1LTS release?

Other PRs that are not fixes but enhancements would become 13.0.2 perhaps?

Is that right? Does it make sense?

On 26/02/2025 09:59, raiden00pl wrote:
>> we only need separate commits not PR which is a best practice and improves
> readability
>
> Lately I've been seeing something completely different on Github...
> Separate commits are OK, separate PRs are not.
>
>> We can provide fixes and improve the LTS releases compardd with the
> regular
> releases which brings a stability benefit for users that maintain oftree
> boards
>
> I understand that, but shouldn't the first LTS release be tested and
> stable?
> Something that is marked LTS and is not tested from the very beginning
> makes
> a bad impression about the project. Quality assurance first - then we can
> think about LTS.
>
> śr., 26 lut 2025 o 10:50 Alin Jerpelea  napisał(a):
>
>> On Wed, 26 Feb 2025, 10:32 raiden00pl,  wrote:
>>
>>> -1 from me.
>>>
>>> 1. It's a waste of already limited resources in this project.
>>>
>>> 2. It makes life harder for contributors, by for example requiring
>>> separation of PRs on arch/boards/doc. Extra work for contributors to
>>> compensate for the project's limited resources is not okay.
>>>
>> we only need separate commits not PR which is a best practice and improves
>> readability
>>
>>> 3. Regarding the above point: I don't see the point in separating changes
>>> that MUST BE implemented together. In this way, error detection by
>>> CI won't be impossible in some cases.
>>>
>>> 4. LTS should have some quality assurance, which involves testing as many
>>> features as possible in the current NuttX. Otherwise it makes no sense.
>>> At this time, NuttX doesn't have the resources for this.
>>>
>> We can provide fixes and improve the LTS releases compardd with the regular
>> releases which brings a stability benefit for users that maintain oftree
>> boards
>>
>>> śr., 26 lut 2025 o 10:08 Alin Jerpelea  napisał(a):
>>>
 This vote proposes to start the LTS releases for NuttX RTOS

 The proposed LTS release plan is
 - 1st release each year is a LTS release (maintained for 1.5 years)
 - 6 minor releases for each release
 ex: 13.0.0-13.0.6 for our first LTS release

 Voting will be open for 72hr.

 A minimum of 3 binding +1 votes and more +1 binding than -1 are
>> required
>>> to
 pass.

 Best regards
 Alin

Re: [OT] PebbleOS becomes open-source

[alin.jerpe...@sony.com]

Hi Alan,

Thanks for sharing the information

Best regards
Alin

Från: Alan C. Assis 
Skickat: den 25 februari 2025 1:35
Till: dev@nuttx.apache.org 
Ämne: [OT] PebbleOS becomes open-source

Hi NuttXers, Last month Google/Fitbit released PlebbleOS source code (Apache 
License) https: //urldefense. com/v3/__https: //ericmigi. 
com/blog/why-were-bringing-pebble-back__;!!O7_YSHcmd9jp3hj_4dEAcyQ!yr_KGuyP0ul3jxoDMgmV9kaR873t3okZ0VE3ZsQ_mbZZUSFzLRpcXGqno7Om0Dk3TocJ_Bb0Ml2-CQIQ$


Hi NuttXers,

Last month Google/Fitbit released PlebbleOS source code (Apache License)

https://urldefense.com/v3/__https://ericmigi.com/blog/why-were-bringing-pebble-back__;!!O7_YSHcmd9jp3hj_4dEAcyQ!yr_KGuyP0ul3jxoDMgmV9kaR873t3okZ0VE3ZsQ_mbZZUSFzLRpcXGqno7Om0Dk3TocJ_Bb0Ml2-CQIQ$

The code is in GitHub and probably there are useful things that could be
interesting for NuttX community to explore (they used FreeRTOS but the C
code is agnostic, and no CamelCase).

BR,

Alan

Sv: mDNS - apps utility or kernel? And licensing

[alin.jerpe...@sony.com]

+1
thanks for the contribution

Best regards
Alin

Från: Tomek CEDRO 
Skickat: den 13 maj 2025 21:47
Till: dev@nuttx.apache.org 
Ämne: Re: mDNS - apps utility or kernel? And licensing

Sounds good to share solutions between NuttX and Vela, thank you folks! :-) +1 
for adding mdns to nuttx-apps :-) +1 for example apllication :-) +1 for 
documentation how this works and how to use :-) -- CeDeROM, SQ7MHZ, https: 
//urldefense. com/v3/__http: //www. tomek. cedro. 
info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2LSc0LXTOmiLZj4iSbwiMkIrrutsFGS3sNy8rjNJPedRdKluDTI6xSvA32f-Cn29wCApNmv41_FZ7r_VNg$


Sounds good to share solutions between NuttX and Vela, thank you folks! :-)

+1 for adding mdns to nuttx-apps :-)
+1 for example apllication :-)
+1 for documentation how this works and how to use :-)

--
CeDeROM, SQ7MHZ, 
https://urldefense.com/v3/__http://www.tomek.cedro.info__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2LSc0LXTOmiLZj4iSbwiMkIrrutsFGS3sNy8rjNJPedRdKluDTI6xSvA32f-Cn29wCApNmv41_FZ7r_VNg$

On Tue, May 13, 2025, 20:55 Tim Hardisty  wrote:

> I will get it working in the way I need it (basic mDNS response to
> resolve a .local address for an appliance) and then submit it. It might
> benefit from a NuttX-specific example app to make it easier to
> understand for dimwits like me, so would include that too. With
> documentation :-)
>
> On 13/05/2025 19:14, Alan C. Assis wrote:
> > Hi Tim,
> >
> > I think everything that speeds up NuttX users development and makes user
> > experience easy is welcome!
> >
> > Please also include some basic Documentation/ explaining how to test it
> on
> > NuttX.
> >
> > BR,
> >
> > Alan
> >
> > On Tue, May 13, 2025 at 3:07 PM Tim Hardisty 
> > wrote:
> >
> >> I have it working as a downloaded 3rd party utility, currently into my
> >> own personal Apps space rather than nuttx-apps. Would there be any
> >> benefit to others if I move it to apps/netutils and submit it as a PR?
> >> It works "out of the box" as a NuttX app or library, depending on
> >> Kconfig settings as per Xiang Xiao's links to open-vela.
> >>
> >> On 13/05/2025 15:20, Tim Hardisty wrote:
> >>> FANTASTIC - thanks Xiang Xiao. I love learning how to do things and
> >>> even better when I don't really have to do anything :-)
> >>>
> >>> On 13/05/2025 14:27, Xiang Xiao wrote:
>  On Tue, May 13, 2025 at 8:07 PM Tim Hardisty  >
>  wrote:
> 
> > See Greg's response below which didn't make it to the list.
> >
> > See comments inline below.
> >
> > On 13/05/2025 03:13, Gregory Nutt wrote:
> >> On 5/12/2025 11:54 AM, Tim Hardisty wrote:
> >>> I am adding mDNS/DNS-SD query responder software to my project to
> >>> allow my NuttX "appliance" to be identified as a ".local" device on
> >>> the network.
> >>>
> >>> It is using public domain software here:
> >>> https://urldefense.com/v3/__https://github.com/mjansson/mdns__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2LSc0LXTOmiLZj4iSbwiMkIrrutsFGS3sNy8rjNJPedRdKluDTI6xSvA32f-Cn29wCApNmv41_ESWRB8bg$
> >>>
> >>> Firstly: would this be best done as part of the kernel under the
> >>> CONFIG_NET umbrella; or as an app as a NETUTILS feature?
>  We have done the porting before, you can use it from here directly:
>  https://urldefense.com/v3/__https://github.com/open-vela/external/tree/dev/mdns__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2LSc0LXTOmiLZj4iSbwiMkIrrutsFGS3sNy8rjNJPedRdKluDTI6xSvA32f-Cn29wCApNmv41_GZQkFTYg$
>  https://urldefense.com/v3/__https://github.com/open-vela/external_mdns__;!!O7_YSHcmd9jp3hj_4dEAcyQ!2LSc0LXTOmiLZj4iSbwiMkIrrutsFGS3sNy8rjNJPedRdKluDTI6xSvA32f-Cn29wCApNmv41_HJQntAWA$
> 
> > If it uses *only* standard applications interfaces, to the OS then it
> >> is an application and should not be inside the OS.  This is for
> >> modularity and security reasons.  If it uses both standardized
> >> application interfaces and internal OS interfaces, then it belongs
> in
> >> libs/.  If it uses *only* OS interfaces then it might be part of
> >> the OS.
> >>
> >> NOTE that OS and applications use a different set of interfaces with
> >> difference calling rules from application space.  It is not portable
> >> between the either of the two contexts without some additional
> >> complexity and a fairly deep understanding of the OS interfaces.
> >>
> > Noted: but, all things being equal, would mDNS/DNS-SD be "better" in
> > the
> > OS or as an App (daemon)?
> >
>  it should belong to the apps folder which is a normal library calling
>  POSIX
>  API.
> 
> 
> >>> Secondly: my read of the PD license is that there would be no
> problem
> >>> plundering the necessary code and submitting it as a NuttX feature.
> >>> Does anyone disagree - for example is an Apache license of what was
> >>> public domain software not a good/nice/allowed thing? I assume it
> >>> would be good to include a link to the original work somewhere or

Sv: RFC: fix race conditions in drivers/serial/serial.c

[alin.jerpe...@sony.com]

Hi KR,

thank for submitting the patches

They have been uploaded to mainline and are under review
https://github.com/apache/nuttx/pull/16466


Best regards
Alin

Från: kr@kerogit.eu 
Skickat: den 1 juni 2025 22:42
Till: dev@nuttx.apache.org 
Ämne: RFC: fix race conditions in drivers/serial/serial.c

While going through the code in drivers/serial/serial. c, I noticed this 
comment: The head and tail pointers are 16-bit values. The only time that the 
following could be unsafe is if the CPU made two non-atomic 8-bit accesses to 
obtain the 16-bit


While going through the code in drivers/serial/serial.c, I noticed this
comment:

The head and tail pointers are 16-bit values.  The only time that
the following could be unsafe is if the CPU made two non-atomic
8-bit accesses to obtain the 16-bit head index.

This is what happens for (at least) AVR architecture. These are 8bit
microcontrollers and as such, they will fetch the 16-bit value in two
8-bit load instructions; interrupt routine may execute between those and
change the value being read. This will result in corrupted read (one
byte of the value will be from pre-interrupt state and the other from
post-interrupt state.)

This patch introduces CONFIG_ARCH_LD_16BIT_NOT_ATOMIC configuration
option, which is automatically selected for architectures known to be
unable to load 16bit values in one instruction. (It is currently only
set for AVR. I presume it might be also useful for Z80 but I do not have
any experience with that architecture so I did no changes there.) When
this configuration option is set, reads of recv.head and xmit.tail are
enclosed with enter_critical_section and leave_critical_section calls to
prevent interrupt handlers from running, if needed. Not all reads need
to be protected this way - some are already in existing critical
sections and some happen with the UART-specific interrupt disabled.

If the configuration option is not set, the code simply loads the value
into a local variable. Subsequent direct uses of the unprotected
volatile variable are replaced with the local variables for both cases.

There is also a related change that only applies when
CONFIG_SERIAL_IFLOWCONTROL_WATERMARKS is set. Aside from the protection
selected by CONFIG_ARCH_LD_16BIT_NOT_ATOMIC, this patch also fixes
calculation of the nbuffered value. This calculation is not running with
interrupts disabled and value of rxbuf->head can change between the
condition and actual computation. Even if the load itself is atomic,
this leads to TOCTOU error.

Impact: this change should not impact architectures that do not benefit
from this change at all unless CONFIG_SERIAL_IFLOWCONTROL is set. If
CONFIG_SERIAL_IFLOWCONTROL is set, the only change that remains in
effect is the fix of the TOCTOU error.

Testing: Patch was tested with rv-virt:nsh - disassembly of functions
from drivers/serial/serial.c was compared and did not change after the
patch was applied - with one exception. The exception was an address of
a global variable, I assume it was caused by change of g_version length
(which notes that the tree is dirty) and is therefore inconsequential.
CONFIG_SERIAL_IFLOWCONTROL was not set in this test.

Configuration with CONFIG_SERIAL_IFLOWCONTROL set was tested by building
it for AVR DA/DB. Configuration with CONFIG_SERIAL_IFLOWCONTROL unset
was tested by custom echo application running on AVR128DA28 for a few
hours.

I also ran CI test: 1044 passed, 10 skipped, 14 deselected, 3 warnings
in 2463.23s (0:41:03)


On a related note, it seems to me that there may be a bug in echo
handling in uart_readv. If dev->tc_lflag & ECHO is true, then
uart_putxmitchar is called. This function adds the received character to
transmit buffer and increments xmit.head value. However,
uart_putxmitchar is also called from uart_writev; this function states
"Only one user can access dev->xmit.head at a time" and takes the
dev->xmit.lock. As far as I can see, uart_readv does not take the lock
and may interfere with uart_writev. Evaluating and solving this properly
is currently above my skillset though. (If this is even considered
serious enough to warrant a fix.)


The patch series also fixes a typo in drivers/serial/serial.c


Both patches are attached to this message and also available in a git
repository nuttx.git at git.kerogit.eu accessible through HTTP/S.
(Trying to prevent bot traffic by not posting the URL in
machine-readable form.) The relevant branch is called uart_fixes_rfc1.
If the patches are acceptable, I would like to ask someone with GitHub
account to open a PR (I don't have a GH account.) Any comments or
suggestions are welcome.