[ANNOUNCE] Apache NuttX 10.1.0-incubating released

[Alin Jerpelea]

The Apache NuttX (incubating) project team is proud to announce that
Apache NuttX 10.1.0-incubating has been released.

The release artifacts and Release Notes can be found at:
https://nuttx.apache.org/download/
https://nuttx.apache.org/releases/10.1.0/

Thanks,
Alin Jerpelea
on behalf of Apache NuttX PPMC

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Nathan Hartman]

On Fri, May 28, 2021 at 5:24 PM Alan Carvalho de Assis 
wrote:

> Hi Nathan,
>
> On 5/28/21, Nathan Hartman  wrote:
> > On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
> >  wrote:
> >>
> >> Hi Erik,
> >>
> >> Thank you very much for your help.
> >>
> >> I noticed the final binary is too big (more than 300KB), is it also
> >> happening to you?
> >>
> >> BR,
> >>
> >> Alan
> >
> >
> > Do some sections in the linker script need (NOLOAD)?
> >
> > See PR-3198 [1], where the binary was also huge, until davids5 taught
> > me about that:
> >
> > [1] https://github.com/apache/incubator-nuttx/pull/3198
> >
>
> Good question!
>
> When using external libraries with NuttX I need to use "--gc-sections"
> to reduce the final size:
>
>
> https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/
>
> BR,
>
> Alan



Ah, yes, I use that too, together with -ffunction-sections and
-fdata-sections, because the linker gc works at the granularity of a
section.

Did it work in this case?

Nathan

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Alan Carvalho de Assis]

Hi Nathan,

On 5/28/21, Nathan Hartman  wrote:
> On Fri, May 28, 2021 at 4:43 PM Alan Carvalho de Assis
>  wrote:
>>
>> Hi Erik,
>>
>> Thank you very much for your help.
>>
>> I noticed the final binary is too big (more than 300KB), is it also
>> happening to you?
>>
>> BR,
>>
>> Alan
>
>
> Do some sections in the linker script need (NOLOAD)?
>
> See PR-3198 [1], where the binary was also huge, until davids5 taught
> me about that:
>
> [1] https://github.com/apache/incubator-nuttx/pull/3198
>

Good question!

When using external libraries with NuttX I need to use "--gc-sections"
to reduce the final size:

https://acassis.wordpress.com/2020/10/06/linking-external-libraries-on-nuttx/

BR,

Alan

Re: Nimble on U-blox Nina B112 (Nrf52832)

[Alan Carvalho de Assis]

Hi Erik,

Thank you very much for your help.

I noticed the final binary is too big (more than 300KB), is it also
happening to you?

BR,

Alan

On 5/27/21, Erik Englund  wrote:
> Yes, I think seamless Nordic BLE support is important for NuttX.
>
> I will try to release some time for this, I´ve got nrf52832, nrf52833 and
> nrf52840 boards/products at my disposal.
>
> Med vänlig hälsning
> Erik Englund
>
> Innoware Development AB
> Hyttvägen 13
> 73338 SALA
>
> Org.nr. 556790-2977
> www.innoware.se
>
>
> Den ons 26 maj 2021 kl 11:42 skrev Alan Carvalho de Assis
> >:
>
>> Thank you Erik and Greg,
>>
>> I think we need to modify the default "sdc" board config to get nimBLE
>> running correctly.
>>
>> Thank you for these suggestions.
>>
>> BR,
>>
>> Alan
>>
>> On Wednesday, May 26, 2021, Erik Englund 
>> wrote:
>>
>> > I was encountering the same error while trying to run NuttX 10.x /
>> > nimble
>> > on NRF52832, tracked it down to insufficient ram available.
>> > The nimble nsh-app were present in the builtin-apps internal lists, but
>> > when trying to allocate application stack NuttX will return an error
>> code,
>> > and it seems all allocation error codes when trying to start an nsh-app
>> > will result in that "command not found" error message.
>> > I think enabling some memory debugging flags in nuttx will show you the
>> > correct error.
>> >
>> > So this isn't a nimble problem.
>> >
>> >
>> > Med vänlig hälsning
>> > Erik Englund
>> >
>> > Innoware Development AB
>> > Hyttvägen 13
>> > 73338 SALA
>> >
>> >
>> > Org.nr. 556790-2977
>> > www.innoware.se
>> >
>> >
>> > Den ons 26 maj 2021 kl 01:42 skrev Gregory Nutt :
>> >
>> > > The failure doesn't seem to have anything to do with nimBLE.  The
>> nimble
>> > > app is not running at all!
>> > >
>> > > Put a breakpoint on nimble_main().  I doubt that you ever get there.
>> > > But I don't know why.
>> > >
>> > > The error report is probably misleading too...  I seem to recall that
>> > > that there is an issue that the NSH error reported is always "command
>> > > not found" even if some other error occurs.  It does mean that NSH
>> could
>> > > not run the built-in command, but it does not necessarily mean that
>> > > the
>> > > built-in command was not found.
>> > >
>> > > On 5/25/2021 4:51 PM, Alan Carvalho de Assis wrote:
>> > > > Hi Matias and Miguel,
>> > > >
>> > > > I just tried nimble on nrf52832-mdk board without success:
>> > > >
>> > > > $ ./tools/configure.sh nrf52832-mdk:sdc
>> > > > $ make
>> > > >
>> > > > It downloaded and compiled nimble for NuttX correctly, the
>> > > > nuttx.bin
>> > > > was about 314944 bytes.
>> > > >
>> > > > When I drop this file inside DAPLINK disk it tries to flash and
>> create
>> > > > the file FAIL.TXT with this content:
>> > > >
>> > > > "The hex file cannot be decoded. Checksum calculation failure
>> > occurred."
>> > > >
>> > > > Then I ran "make menuconfig" and enabled the "Intel HEX binary
>> format"
>> > > > and after copying the nuttx.hex to DAPLINK disk the error
>> disappeared.
>> > > >
>> > > > Accessing the nsh terminal I can see the nimble binary, but it is
>> > > > not
>> > > running:
>> > > >
>> > > > NuttShell (NSH) NuttX-10.1.0-RC1
>> > > > nsh> ?
>> > > > help usage:  help [-v] []
>> > > >
>> > > >. cdecho  hexdump   mkdir ps
>> > > > source
>> > > >   unset
>> > > >[ cpexec  ifconfig  mkfatfs   pwd   test
>> > > >   usleep
>> > > >? cmp   exit  ifdownmkrd  rmtime
>> > > >   xd
>> > > >basename  dirname   false ifup  mount rmdir true
>> > > >break ddfree  kill  mvset
>> > > > uname
>> > > >cat   dfhelp  lsnslookup  sleep
>> > > > umount
>> > > >
>> > > > Builtin Apps:
>> > > >nimble  sh  nsh
>> > > > nsh> nimble
>> > > > nsh: nimble: command not found
>> > > > nsh> ifconfig
>> > > > bnep0   Link encap:UNSPEC at UP
>> > > >
>> > > > nsh> nimble -h
>> > > > nsh: nimble: command not found
>> > > > nsh> nimble
>> > > > nsh: nimble: command not found
>> > > > nsh>
>> > > >
>> > > > Initially I thought it was caused by recent update of the nimble
>> stack
>> > > > on NuttX, but I moved to a commit previous to that update and still
>> > > > facing same error.
>> > > >
>> > > > Matias, do you think it could be some issue with my crosscompiler?
>> > > >
>> > > > I'm using the default ARM gcc from Ubuntu 20.04 gcc-arm-none-eabi
>> > > package:
>> > > >
>> > > > gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision
>> > > > 277599] (15:9-2019-q4-0ubuntu1)
>> > > >
>> > > > Thank you very much!
>> > > >
>> > > > BR,
>> > > >
>> > > > Alan
>> > > >
>> > > > On 5/25/21, Miguel Wisintainer  wrote:
>> > > >> Matias
>> > > >>
>> > > >> Me and Alan will investigate!
>> > > >>
>> > > >> Thank you so much!
>> > > >>
>> > > >> Enviado do Email
>> para
>> > > >> Windows 10
>> > > 

Cygwin build broken again

[Gregory Nutt]

The Cygwin build is broken again.  It is broken in the current master, 
in 10.0.0, and 10.0.1.  See 
https://github.com/apache/incubator-nuttx/issues/3799 for more details.


This is the commit that broke the build:

d5b6ec450fde069a4e64569b0eb7e4fcb3b96e83 is the first bad commit
commit d5b6ec450fde069a4e64569b0eb7e4fcb3b96e83
Author: Matias N 
Date:   Wed Nov 18 13:44:58 2020 -0300

    Parallelize depend file generation

 arch/arm/src/Makefile   |  7 +--
 arch/avr/src/Makefile   |  7 +--
 arch/hc/src/Makefile    |  7 +--
 arch/mips/src/Makefile  |  7 +--
 arch/misoc/src/Makefile |  7 +--
 arch/or1k/src/Makefile  |  7 +--
 arch/renesas/src/Makefile   |  6 +-
 arch/risc-v/src/Makefile    |  7 +--
 arch/sim/src/Makefile   |  7 +--
 arch/x86/src/Makefile   |  7 +--
 arch/x86_64/src/Makefile    |  7 +--
 arch/xtensa/src/Makefile    |  7 +--
 audio/Makefile  |  6 +-
 binfmt/Makefile |  6 +-
 boards/Makefile | 11 +--
 crypto/Makefile |  6 +-
 drivers/Makefile    |  6 +-
 fs/Makefile |  6 +-
 graphics/Makefile   |  6 +-
 libs/libc/Makefile  | 12 ++--
 libs/libc/bin/Makefile  |  2 +-
 libs/libc/zoneinfo/Makefile |  6 +-
 libs/libdsp/Makefile    |  6 +-
 libs/libnx/Makefile | 12 ++--
 libs/libnx/kbin/Makefile    |  2 +-
 libs/libxx/Makefile |  6 +-
 mm/Makefile | 12 ++--
 net/Makefile    |  6 +-
 openamp/Makefile    |  6 +-
 pass1/Makefile  |  6 +-
 sched/Makefile  |  6 +-
 syscall/Makefile    |  7 +--
 tools/Config.mk | 17 +
 video/Makefile  |  6 +-
 wireless/Makefile   |  6 +-

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Fri, May 28, 2021 at 12:16 PM Sebastien Lorquet  wrote:
> The documentation about NuttX is exploded all around. This is an issue
> that is often noticed by all of my colleagues that attempted to have a
> look at this project.

Documentation has moved from place to place over the years, but we are
gradually consolidating it in the Documentation directory, which is
included in release artifacts and also appears on the website. AFAIK
the CWIKI is basically deprecated since having docs in the git repo
make it easier for anyone to contribute PRs, as opposed to needing an
account for the CWIKI. Also, that keeps the docs together with the
code so we don't have to worry about things like a future migration to
a different wiki or something like that. (Not saying that's gonna
happen; just saying we don't have to worry about the possibility of
it.) But there might still be things on the CWIKI or other older
locations that aren't in Documentation yet. If you find something like
that, please do let us know, or just send a PR.

I will say that much documentation exists in the form of people's
personal blogs, which are not part of this project. That is a
testament to this project's success. Compare Linux, which has
documentation on millions of websites.

I do think it would be helpful for ReleaseNotes (in the form of
separate files per releases) to be in Documentation/ReleaseNotes and
be made accessible from the Documentation page of the website
(http://nuttx.apache.org/docs/latest/) in case someone is looking for
them there; the same files should be accessible from the Releases page
where they are now, as Brennan enlightened me earlier.

Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Abdelatif Guettouche]

> Even if I dont get to vote in your committees I will
tell you if I find some problem.

You do get to vote, everyone can vote.  It's actually helpful to have
more people voting and participating in the whole release process.
Voting for releases is done in the public dev list.  PPMC members have
binding votes but any issue raised by any member of the community
needs to be addressed before we can move forward with a release.

> I still have doubts about *why* EXTRADEFINES *had to* become EXTRAFLAGS
:) but whatever.

Because at that point we started using that variable to pass flags in
general and not only defines. EXTRADEFINES was not a valid name
anymore. (it's used in the testing script to pass -Wno-cpp -Werror for
example)


On Fri, May 28, 2021 at 5:16 PM Sebastien Lorquet  wrote:
>
> I will try to continue testing my custom board with upcoming releases to
> detect such breaks. Even if I dont get to vote in your committees I will
> tell you if I find some problem.
>
> Yes I skipped two years of nuttx development, starting christmas holiday
> 2019, followed by covid lockdowns and a busy 2020 year.
>
> Honestly this was discussed maybe, but at some point during that
> timeframe there was so many nuttx messages coming in the list (more than
> 100 per day) that it was not possible to follow everything. it was
> overwhelming. I stopped reading.
>
> A porting guide or troubleshooting page would be helpful. These breaking
> changes are durable, they are not "release" events. They are permanent,
> so it makes change to maintain an history of these.
>
> I still have doubts about *why* EXTRADEFINES *had to* become EXTRAFLAGS
> :) but whatever.
>
>
> Abdelatif replied something while I was writing:
>
> Yes, the only place I had the idea to read release notes was the
> ReleaseNote files in the repository.
>
> I had no idea there was specific release notes on your new wiki. Same
> reasons as before.
>
>
> The documentation about NuttX is exploded all around. This is an issue
> that is often noticed by all of my colleagues that attempted to have a
> look at this project.
>
>
> Sebastien
>
> Le 28/05/2021 à 17:56, Nathan Hartman a écrit :
> > On Fri, May 28, 2021 at 11:49 AM Nathan Hartman
> >  wrote:
> >> On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
> >>  wrote:
> >>> On Fri, May 28, 2021, 7:54 AM Nathan Hartman 
>  3. Make a ReleaseNotes section of the website that will render those
>  ReleaseNotes files and offer an easy to use index, so it's easier to find
>  this information. The newer ones are Markdown but not rendered as such 
>  when
>  opened in any text editor or browser because of all the preexisting
>  non-markdown content.
> 
> >>> Already done
> >>> http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns
> >> I completely missed that! Thanks!
> > I see why I missed it. It wasn't obvious (to me, anyway) that the
> > version numbers in the left column were links to the release notes for
> > that version.
> >
> > Perhaps there should be a column called Release Notes with the links.
> > I'll try to experiment with it later and if I can come up with
> > something more clear, I'll send a PR for review.
> >
> > Thanks,
> > Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

I will try to continue testing my custom board with upcoming releases to 
detect such breaks. Even if I dont get to vote in your committees I will 
tell you if I find some problem.


Yes I skipped two years of nuttx development, starting christmas holiday 
2019, followed by covid lockdowns and a busy 2020 year.


Honestly this was discussed maybe, but at some point during that 
timeframe there was so many nuttx messages coming in the list (more than 
100 per day) that it was not possible to follow everything. it was 
overwhelming. I stopped reading.


A porting guide or troubleshooting page would be helpful. These breaking 
changes are durable, they are not "release" events. They are permanent, 
so it makes change to maintain an history of these.


I still have doubts about *why* EXTRADEFINES *had to* become EXTRAFLAGS 
:) but whatever.



Abdelatif replied something while I was writing:

Yes, the only place I had the idea to read release notes was the 
ReleaseNote files in the repository.


I had no idea there was specific release notes on your new wiki. Same 
reasons as before.



The documentation about NuttX is exploded all around. This is an issue 
that is often noticed by all of my colleagues that attempted to have a 
look at this project.



Sebastien

Le 28/05/2021 à 17:56, Nathan Hartman a écrit :

On Fri, May 28, 2021 at 11:49 AM Nathan Hartman
 wrote:

On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
 wrote:

On Fri, May 28, 2021, 7:54 AM Nathan Hartman 

3. Make a ReleaseNotes section of the website that will render those
ReleaseNotes files and offer an easy to use index, so it's easier to find
this information. The newer ones are Markdown but not rendered as such when
opened in any text editor or browser because of all the preexisting
non-markdown content.


Already done
http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns

I completely missed that! Thanks!

I see why I missed it. It wasn't obvious (to me, anyway) that the
version numbers in the left column were links to the release notes for
that version.

Perhaps there should be a column called Release Notes with the links.
I'll try to experiment with it later and if I can come up with
something more clear, I'll send a PR for review.

Thanks,
Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Abdelatif Guettouche]

> > 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a
> > ChangeLog rather than ReleaseNotes. In the past we talked about a
> > Documentation/ReleaseNotes directory that could hold a separate
> > ReleaseNotes for each major version?
> >
> They are broken out per release and linked on the download page.

It would still be a good idea if we can do this to the main
ReleaseNote file as well.  It's 29344 lines long (and counting).  We
talked before about keeping the latest notes in the top level
ReleaseNote and kind of archive the rest somewhere else.


On Fri, May 28, 2021 at 4:56 PM Nathan Hartman  wrote:
>
> On Fri, May 28, 2021 at 11:49 AM Nathan Hartman
>  wrote:
> >
> > On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
> >  wrote:
> > >
> > > On Fri, May 28, 2021, 7:54 AM Nathan Hartman 
> > > > 3. Make a ReleaseNotes section of the website that will render those
> > > > ReleaseNotes files and offer an easy to use index, so it's easier to 
> > > > find
> > > > this information. The newer ones are Markdown but not rendered as such 
> > > > when
> > > > opened in any text editor or browser because of all the preexisting
> > > > non-markdown content.
> > > >
> > >
> > > Already done
> > > http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns
> >
> > I completely missed that! Thanks!
>
> I see why I missed it. It wasn't obvious (to me, anyway) that the
> version numbers in the left column were links to the release notes for
> that version.
>
> Perhaps there should be a column called Release Notes with the links.
> I'll try to experiment with it later and if I can come up with
> something more clear, I'll send a PR for review.
>
> Thanks,
> Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Fri, May 28, 2021 at 11:49 AM Nathan Hartman
 wrote:
>
> On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
>  wrote:
> >
> > On Fri, May 28, 2021, 7:54 AM Nathan Hartman 
> > > 3. Make a ReleaseNotes section of the website that will render those
> > > ReleaseNotes files and offer an easy to use index, so it's easier to find
> > > this information. The newer ones are Markdown but not rendered as such 
> > > when
> > > opened in any text editor or browser because of all the preexisting
> > > non-markdown content.
> > >
> >
> > Already done
> > http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns
>
> I completely missed that! Thanks!

I see why I missed it. It wasn't obvious (to me, anyway) that the
version numbers in the left column were links to the release notes for
that version.

Perhaps there should be a column called Release Notes with the links.
I'll try to experiment with it later and if I can come up with
something more clear, I'll send a PR for review.

Thanks,
Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Fri, May 28, 2021 at 11:43 AM Brennan Ashton
 wrote:
>
> On Fri, May 28, 2021, 7:54 AM Nathan Hartman 
> > 3. Make a ReleaseNotes section of the website that will render those
> > ReleaseNotes files and offer an easy to use index, so it's easier to find
> > this information. The newer ones are Markdown but not rendered as such when
> > opened in any text editor or browser because of all the preexisting
> > non-markdown content.
> >
>
> Already done
> http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns

I completely missed that! Thanks!

Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Brennan Ashton]

On Fri, May 28, 2021, 7:54 AM Nathan Hartman 
wrote:

> On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet 
> wrote:
>
> > I'm not talking of renaming code symbols like up_anything to
> > arm_anything, which makes sense and can be noticed quite easily at link
> > stage.
> >
> > I'm talking about renaming a shell/make variable from EXTRADEFINES to
> > EXTRAFLAGS. This is hidden, and the build system has no way to complain
> > about anything missing.
> >
> > Of course, this has no impact on any built-in board, because the change
> > was made locally. so CI cannot detect this.
> >
> > But this breaks ALL the custom boards people actually use for real
> > projects.
> >
> > And the relevant documentation is hidden at the bottom of some obsolete
> > (nuttx 9) release notes, in a "concerns" section.
> >
> > This doc is critical from anyone porting a custom board from pre-9 nuttx
> > to current one.
> >
> > I cant believe I'm the only one in this case...
> >
> > Sebastien
>
>
>
> Yes, it's documented way near the bottom of the very long ReleaseNotes file
> and is hard to find.
>
> Several things we could do to improve:
>
> 1. When we make a change like this, detect the obsolete define in the build
> system and give some kind of warning?



> 2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a
> ChangeLog rather than ReleaseNotes. In the past we talked about a
> Documentation/ReleaseNotes directory that could hold a separate
> ReleaseNotes for each major version?
>

They are broken out per release and linked on the download page.


> 3. Make a ReleaseNotes section of the website that will render those
> ReleaseNotes files and offer an easy to use index, so it's easier to find
> this information. The newer ones are Markdown but not rendered as such when
> opened in any text editor or browser because of all the preexisting
> non-markdown content.
>

Already done
http://nuttx.apache.org/releases/10.0.0/#compatibility-concerns


> 4. Add a troubleshooting (or FAQ) section to the website and add this
> EXTRAFLAGS case to it, i.e., list the symptom and give this as a potential
> cause to check for.
>
> 5. We use semantic versioning, but it would be worthwhile to check if the
> major version number was bumped in the first release that contained this
> change. If not, that might have been a mistake.
>

This was part of the reason for making the major version number jump for
this release.

We already do so much to try and not break things. If you are going to jump
3 major release versions that span __6 years__ you have to expect to run
into something and should read at least the compatibility comments for the
major releases.

I'm all for changing the release notes to be easier to use and they take a
huge amount of time to compile. But it is disingenuous to say that nothing
was done.

--Brennan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Nathan Hartman]

On Fri, May 28, 2021 at 9:12 AM Sebastien Lorquet 
wrote:

> I'm not talking of renaming code symbols like up_anything to
> arm_anything, which makes sense and can be noticed quite easily at link
> stage.
>
> I'm talking about renaming a shell/make variable from EXTRADEFINES to
> EXTRAFLAGS. This is hidden, and the build system has no way to complain
> about anything missing.
>
> Of course, this has no impact on any built-in board, because the change
> was made locally. so CI cannot detect this.
>
> But this breaks ALL the custom boards people actually use for real
> projects.
>
> And the relevant documentation is hidden at the bottom of some obsolete
> (nuttx 9) release notes, in a "concerns" section.
>
> This doc is critical from anyone porting a custom board from pre-9 nuttx
> to current one.
>
> I cant believe I'm the only one in this case...
>
> Sebastien



Yes, it's documented way near the bottom of the very long ReleaseNotes file
and is hard to find.

Several things we could do to improve:

1. When we make a change like this, detect the obsolete define in the build
system and give some kind of warning?

2. Split up the ReleaseNotes file? As it is now, it reads a bit more like a
ChangeLog rather than ReleaseNotes. In the past we talked about a
Documentation/ReleaseNotes directory that could hold a separate
ReleaseNotes for each major version?

3. Make a ReleaseNotes section of the website that will render those
ReleaseNotes files and offer an easy to use index, so it's easier to find
this information. The newer ones are Markdown but not rendered as such when
opened in any text editor or browser because of all the preexisting
non-markdown content.

4. Add a troubleshooting (or FAQ) section to the website and add this
EXTRAFLAGS case to it, i.e., list the symptom and give this as a potential
cause to check for.

5. We use semantic versioning, but it would be worthwhile to check if the
major version number was bumped in the first release that contained this
change. If not, that might have been a mistake.

Any other thoughts?

Nathan

Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

I'm not talking of renaming code symbols like up_anything to 
arm_anything, which makes sense and can be noticed quite easily at link 
stage.


I'm talking about renaming a shell/make variable from EXTRADEFINES to 
EXTRAFLAGS. This is hidden, and the build system has no way to complain 
about anything missing.


Of course, this has no impact on any built-in board, because the change 
was made locally. so CI cannot detect this.


But this breaks ALL the custom boards people actually use for real projects.

And the relevant documentation is hidden at the bottom of some obsolete 
(nuttx 9) release notes, in a "concerns" section.


This doc is critical from anyone porting a custom board from pre-9 nuttx 
to current one.


I cant believe I'm the only one in this case...

Sebastien

Le 27/05/2021 à 16:51, Alan Carvalho de Assis a écrit :

I think a benefit from renaming many of those "up_something" to
"stm32_something", "esp32_something", etc is now it is easy for
software find the right function.

I think many IDEs cannot handle functions search correctly for NuttX
because they don't have heuristics to know that IF I'm searching a
function inside a board or inside an arch, it shouldn't return a
function with same name from other board or from other arch.

So, at end-of-day, these modifications you are complain about, will
make the life of all users better.

BR,

Alan

On 5/27/21, Sebastien Lorquet  wrote:

I sill wonder what is the purpose of this variable rename. Sorry to say,
but it just looks cosmetic while critically breaking everything that was
made before, and this kind of thing is a nightmare for migration when
you cant follow the project day to day. Boards can be external to the
project, and are a supported feature, so they should continue to work
reliably even if you change the internal sauce!

At one point there was too many trafic on the mailing list and I just
stopped reading it, I marked several hundreds of messages as read
without having the time to go through then. It seems that this change
was made during this time.

Sebastien

Le 27/05/2021 à 09:38, Sebastien Lorquet a écrit :

Boom, that was the extrastuff. The board now boots. We're going to run
a lot of functional tests to make sure everything is okay, but I dont
have this strange hardfault at boot.

Thank you.

I did not find this page despite searching through a lot of
documentation, mainly the "official" ReadTheDocs-like documentation.

I suggest you link to this doc in the getting started manuals.

Sebastien


Le 26/05/2021 à 18:42, Abdelatif Guettouche a écrit :

Maybe this one could help:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+9.1#NuttX9.1-CompatibilityConcerns




I am using the flat (monolithic build) and I see no place that define
this flag, at all.
I dont even see a place in the codebase that defines this flag.

__KERNEL__ is defined in tools/Config.mk (line:100)


The fact that mm_initialize only shows one region is weird... where is

the heap for the main RAM at 0x2000?

CONFIG_MM_REGIONS needs to be set up correctly if you have multiple
heap regions.

On Wed, May 26, 2021 at 5:22 PM Sebastien Lorquet
 wrote:

Hello,

Thanks for the remarks.

I am using the flat (monolithic build) and I see no place that define
this flag, at all.

I dont even see a place in the codebase that defines this flag.

I see nothing related to mm, nor anything outdated in my Make.defs,
which is from my old setup, yes, but still similar to a recent one.

Sebastien

Le 26/05/2021 à 18:08, raiden00pl a écrit :

If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is
set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85


I remember that at some point I had a similar hardfault in mm which
doesn't
make sense and it was due to outdated board Make.defs.

śr., 26 maj 2021 o 17:21 Sebastien Lorquet 
napisał(a):


Update: stack dump and register analysis are in fact pointing to a
crash
in mm_alloc

I have enabled memory management debug:

mm_initialize: Heap: start=0x1000 size=65536
mm_addregion: Region 1: base=0x1154 size=65184
stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
mm_free: Freeing 0x70fb460b
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0: 0001 2000737c c0f2 08000101 
  200073c8
up_registerdump: R8:     
200073c8 080126ad 080126f8
up_registerdump: xPSR: 2100 PRIMASK:  CONTROL: 
up_registerdump: EXC_RETURN: fff9
up_dumpstate: sp: 200072c8
up_dumpstate: stack base: 20007078
up_dumpstate: stack size: 0400

The fact that mm_initialize only shows one region is weird...
where is
the heap for the main RAM at 0x2000?

the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but 

Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release

[Abdelatif Guettouche]

It's gonna be there: https://github.com/apache/incubator-nuttx-website/pull/52

On Fri, May 28, 2021 at 1:37 PM Maciej Wójcik  wrote:
>
> Hmm, it looks like it is still missing here https://nuttx.apache.org/download 
> (or is it intended for some reason?)
>
> On Wed, 26 May 2021, 10:28 ,  wrote:
>>
>> Hello all,
>>
>> I sent the results email and created the release
>>
>> Best regards
>> Alin
>>
>>
>> -Original Message-
>> From: 张铎(Duo Zhang) 
>> Sent: den 26 maj 2021 04:10
>> To: dev@nuttx.apache.org
>> Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release
>>
>> We have enough binding votes from IPMC now, so let's close the vote and 
>> finish the release?
>>
>> Thanks.
>>
>> 张铎(Duo Zhang)  于2021年5月20日周四 下午4:17写道：
>>
>> > As Nathan Hartman is an ASF member now, you could ask to join the
>> > IPMC, then we could have 2 binding votes when releasing...
>> >
>> > And let me contact our champion, he has been really busy recently...
>> >
>> > Thanks.
>> >
>> > Byron Ellacott  于2021年5月8日周六 下午1:28写道：
>> >
>> >> +1 with caveat that I need to backport the compiler patch.
>> >>
>> >> Toolchain:
>> >> clang version 13.0.0 (g...@github.com:jacobly0/llvm-project.git
>> >> ff3f5b865edbac826fdd251f810da833dda775de)
>> >> Target: ez80-none-unknown-elf
>> >> Thread model: posix
>> >>
>> >>  - LICENSE, NOTICE, README.md, DISCLAIMER-WIP present in both
>> >> repositories.
>> >>  - Build for eZ80 using commit ID 9d4742af00 backported from master,
>> >> plus patch for Z80 ELF support (PR to happen when tested adequately)
>> >>  - Build size is 253,610 text (down from 257,713 bytes for RC0), 197
>> >> bytes in data (unchanged from RC0)
>> >>
>> >> NuttShell (NSH) NuttX-10.1.0
>> >> nsh> free
>> >>  total   used   freelargest
>> >> Umem:   253856  66272 187584 184736
>> >>
>> >> --
>> >> bje
>> >>
>> >> On Tue, May 4, 2021 at 1:25 AM Alan Carvalho de Assis
>> >> 
>> >> wrote:
>> >>
>> >> > Hi Everyone, please submit some information when you test it:
>> >> >
>> >> > - Used toolchain: i.e. last line of "gcc -v" is enough
>> >> > - ELF nuttx size: i.e. "arm-none-eabi-size nuttx"
>> >> > - Result of internal nsh free command.
>> >> >
>> >> > It will help us to track the size increase from a release to another.
>> >> >
>> >> > BR,
>> >> >
>> >> > Alan
>> >> >
>> >> > On 5/3/21, alin.jerpe...@sony.com  wrote:
>> >> > > Hello all,
>> >> > >
>> >> > > This is the latest tarball
>> >> > >
>> >> > > I am sorry for the confusion
>> >> > >
>> >> > > Thanks
>> >> > > Alin
>> >> > >
>> >> > >
>> >> > > -Original Message-
>> >> > > From: Nathan Hartman 
>> >> > > Sent: den 3 maj 2021 17:14
>> >> > > To: dev@nuttx.apache.org
>> >> > > Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release
>> >> > >
>> >> > > On Mon, May 3, 2021 at 1:22 AM Alin Jerpelea 
>> >> wrote:
>> >> > >>
>> >> > >> Hello all,
>> >> > >> Apache NuttX (Incubating) 10.1.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.1.0-RC1
>> >> > >>   Hash for the release incubating-nuttx tag:
>> >> > >> 3130ff691e386934eb276587a24d1efacf3bb30b
>> >> > >>   Hash for the release incubating-nuttx-apps tag:
>> >> > >> 4348d91d1356335483089c3865282d80f13bedcd
>> >> > >>
>> >> > >> [1]
>> >> > >>
>> >> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/in
>> >> c
>> >> > >>
>> >> ubator/nuttx/10.1.0-RC1/__;!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz
>> >> 4
>> >> > >> HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBF0cM9oFQ$
>> >> > >> [2]
>> >> https://urldefense.com/v3/__https://raw.githubusercontent.com/apach
>> >> > >>
>> >> e/incubator-nuttx/nuttx-10.1.0-RC1/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!
>> >> u
>> >> > >> 7bO_5TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBELDkRTX
>> >> > >> A$
>> >> > >> [3]
>> >> > >>
>> >> 

Support for disk full detection using LittleFS

[Flavio Castro Alves Filho]

Hello,

I am using LittleFS to store information on an external dataflash.

I need to know if the memory is full. I saw that the nsh provides the
df command, which as far as I understood is a cat for /proc/fs/usage
file.

In my code, I could see the LFS message indicating LFS_ERR_NOSPC,
which is an error message indicating no more space when writing files.
But the return from the fwrite call is OK (indicating the number of
written bytes) :-|

Is /proc/fs/usage available for LittleFS? Is there any way to get the
disk space programmatically?

Best regards,

Flavio

-- 
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: [issue] Killing a parent pid and all its children pid all together

[Alan Carvalho de Assis]

Hi Rodrigo,

Based on your direct message on LinkedIn I think you already found it, right?

RTOS Features->
Tasks & Scheduling->
[*] Support parent/child task relationship

I think the current behavior is expected for a POSIX / Unix SO, please
take a look:

http://morningcoffee.io/killing-a-process-and-all-of-its-descendants.html

BR,

Alan

On 5/28/21, Rodrigo Garcia  wrote:
> Hello all,
>
> My issue is related to testing the SIGKILL in Nuttx and not making it work
> correctly.
>
> Description:
> =
> I am using a ESP32 DevKitC Board using default NSH configuration.
>
> 1) Enabled CONFIG_SIG_DEFAULT=y and CONFIG_SCHED_HAVE_PARENT=y
> 2) After starting the board, type "sh" +  3 times. Run "ps":
>
> nsh> sh
> nsh> sh
> nsh> sh
> nsh> ps
>   PID  PPID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK
> COMMAND
> 0 0   0 FIFO Kthread N-- Ready   003072
> Idle Task
> 1 0 100 RR   Task--- Waiting  Signal 002096
> init
> 4 1 100 RR   Task--- Waiting  Signal 002096 sh
> 5 4 100 RR   Task--- Waiting  Signal 002096 sh
> 6 5 100 RR   Task--- Running 002096 sh
>
> 3) kill the parent "sh" and try to run "ps"
> Result is a situation where it is very hard to type any command, as seen
> below:
>
> nsh> kill -9 4
> nsh> nsh>
> nsh>
> nsh> ps
> nsh: p: command not found
> nsh> sp
> nsh: ss: command not found
> nsh> ps
> nsh: pp: command not found
> nsh> ss
> nsh: ss: command not found
> nsh> pps
> nsh: p: command not found
> nsh> ps
> nsh: spsp: command not found
> nsh> sp
> nsh: ss: command not found
> nsh> sp
>   PID  PPID PRI POLICY   TYPENPX STATEEVENT SIGMASK   STACK
> COMMAND
> 0 0   0 FIFO Kthread N-- Ready   003072
> Idle Task
> 1 0 100 RR   Task--- Ready   002096
> init
> 5 4 100 RR   Task--- Waiting  Signal 002096 sh
> 6 5 100 RR   Task--- Running 002096 sh
>
> 4) As above, none of the children were killed... and I think that init (pid
> 1) and sh (pid 6) are both reading the console input, generating all those
> "sort of typing errors" above. I had to type "sp" to run "ps".
>
> Question:
> Do I need to set up some other option on menuconfig in order to kill the
> pid of the parent and all its children all together?
>
> Best Regards,
> Rodrigo Garcia.
>