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

[Abdelatif Guettouche]

Is it just me or there is an issue with the checksum of the apps tar?

On Sun, Apr 18, 2021 at 3:06 PM Alin Jerpelea  wrote:
>
> Hello all,
> Apache NuttX (Incubating) 10.1.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 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-RC0
>   Hash for the release incubating-nuttx tag:
> f380c919f04d5ee88e0a83f5632cc83af503664f
>   Hash for the release incubating-nuttx-apps tag:
> 4348d91d1356335483089c3865282d80f13bedcd
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0/
> [2]https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.1.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

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

[Abdelatif Guettouche]

Thanks Alin & Brennan.

+1 for me:
 - LICENSE, NOTICE and DISCLAIMER files exit in both repos.
 - Signatures and checksums valid.
 - Can build from source.


On Sun, Apr 18, 2021 at 6:41 PM Alin Jerpelea  wrote:
>
> Hi all,
>
> The sum is reuploaded now seems to be ok
> Thansk for reporing it
>
> Regards
> Alin
>
>
> On Sun, Apr 18, 2021 at 7:25 PM Brennan Ashton 
> wrote:
>
> > On Sun, Apr 18, 2021 at 9:38 AM Abdelatif Guettouche
> >  wrote:
> > >
> > > Is it just me or there is an issue with the checksum of the apps tar?
> > >
> >
> > Alin,
> > Can you check this an re-upload. You can verify locally as I showed here
> >
> > https://gist.github.com/btashton/ee474723013a7040186c91d41a4c7fad#check-the-release-artifacts
> >
> > After it is uploaded you can also run this script against the uploaded
> > files, which is where we see the bad checksum.
> >
> > ❯ ./tools/checkrelease.sh --url
> > https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0
> > Downloading release files from
> > https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0/
> > 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 9E711BAD3264C061: public key "Alin Jerpelea
> > " imported
> > gpg: Total number processed: 2
> > gpg:   imported: 2
> >  OK:
> > https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0/../KEYS
> > is imported.
> > Checking apache-nuttx-10.1.0-incubating.tar.gz sha512...
> >  OK: apache-nuttx-10.1.0-incubating.tar.gz sha512 hash matches.
> >
> > Checking apache-nuttx-10.1.0-incubating.tar.gz GPG signature:
> > gpg: Signature made Sun 18 Apr 2021 07:03:03 AM PDT
> > gpg:using RSA key C26CE5B1F2F08DBC0C4DE2409E711BAD3264C061
> > 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: C26C E5B1 F2F0 8DBC 0C4D  E240 9E71 1BAD 3264 C061
> >  OK: apache-nuttx-10.1.0-incubating.tar.gz gpg signature matches.
> >
> > Checking apache-nuttx-10.1.0-incubating.tar.gz for required files:
> >  OK: all required files exist in nuttx.
> >
> > Checking apache-nuttx-apps-10.1.0-incubating.tar.gz sha512...
> > sha512sum: WARNING: 1 computed checksum did NOT match
> > apache-nuttx-apps-10.1.0-incubating.tar.gz: FAILED
> >  - apache-nuttx-apps-10.1.0-incubating.tar.gz sha512 hash does not match.
> >
> > Checking apache-nuttx-apps-10.1.0-incubating.tar.gz GPG signature:
> > gpg: Signature made Sun 18 Apr 2021 07:03:03 AM PDT
> > gpg:using RSA key C26CE5B1F2F08DBC0C4DE2409E711BAD3264C061
> > 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: C26C E5B1 F2F0 8DBC 0C4D  E240 9E71 1BAD 3264 C061
> >  OK: apache-nuttx-apps-10.1.0-incubating.tar.gz gpg signature matches.
> >
> > Checking apache-nuttx-apps-10.1.0-incubating.tar.gz for required files:
> >  OK: all required files exist in apps.
> >
> > Trying to build nuttx sim:nsh...
> >

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

[Abdelatif Guettouche]

> Wasn't the stack restructure behind the 10.1 release?

Yes, but that change just exposed an old issue.

On Wed, Apr 28, 2021 at 2:45 PM Matias N.  wrote:
>
> Wasn't the stack restructure behind the 10.1 release?
>
> Best,
> Matias
>
> On Wed, Apr 28, 2021, at 09:57, Gustavo Henrique Nihei wrote:
> > Hi folks,
> >
> > I believe we should consider backporting the fix from this PR into the
> > 10.1.0 release:
> > https://github.com/apache/incubator-nuttx/pull/3614
> >
> > It fixes a side effect from the refactoring of the stack architecture
> > due to a wrong stack alignment for RISC-V chips.
> >
> > Best regards,
> > Gustavo.
> >
> > On Mon, Apr 26, 2021 at 5:58 AM  > > wrote:
> > >
> > > Hi Brenan,
> > >
> > > We still have the following commit that is not resolved and I think that 
> > > it is better to hold the release until it is ready for emerge
> > > https://github.com/apache/incubator-nuttx/pull/3601
> > >
> > > Regards
> > > Alin
> > >
> > > -Original Message-
> > > From: Alin Jerpelea mailto:jerpelea%40gmail.com>>
> > > Sent: den 22 april 2021 16:14
> > > To: dev@nuttx.apache.org 
> > > Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release
> > >
> > > It is perfect timing!
> > >
> > > I will cut RC1 with the fixes tonight
> > >
> > > Thanks
> > > Alin
> > >
> > > On Thu, Apr 22, 2021, 16:12 Nathan Hartman  > > > wrote:
> > >
> > > > On Thu, Apr 22, 2021 at 2:54 AM Alin Jerpelea  > > > > wrote:
> > > >
> > > > > Hi Brennan,
> > > > > I think that we should backport them and I will cut RC1 Thanks Alin
> > > >
> > > >
> > > >
> > > > If I'm not too late, I fixed up the ReleaseNotes a little bit in
> > > > PR-3570
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Thu, Apr 22, 2021, 08:30 Brennan Ashton
> > > > > mailto:bashton%40brennanashton.com>>
> > > > > wrote:
> > > > >
> > > > > > Alin,
> > > > > > I think we should consider if we want to backport these into the
> > > > > > 10.1.0 release.  I am still running more tests myself on all the
> > > > > > hardware I have, but these seemed important to at least consider.
> > > > > > https://urldefense.com/v3/__https://github.com/apache/incubator-nu
> > > > > > ttx/pull/3586__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY2nV6G_l
> > > > > > kT8Y8QJWo9Nv_bGYGjtgmeOc3mRLLOLl7Nw$
> > > > > > https://urldefense.com/v3/__https://github.com/apache/incubator-nu
> > > > > > ttx/pull/3580__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY2nV6G_l
> > > > > > kT8Y8QJWo9Nv_bGYGjtgmeOc3mRKshpGeRw$
> > > > > >
> > > > > > --Brennan
> > > > > >
> > > > > > On Sun, Apr 18, 2021 at 7:06 AM Alin Jerpelea  > > > > > >
> > > > > wrote:
> > > > > > >
> > > > > > > Hello all,
> > > > > > > Apache NuttX (Incubating) 10.1.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 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-RC0
> > > > > > >   Hash for the release incubating-nuttx tag:
> > > > > > > f380c919f04d5ee88e0a83f5632cc83af503664f
> > > > > > >   Hash for the release incubating-nuttx-apps tag:
> > > > > > > 4348d91d1356335483089c3865282d80f13bedcd
> > > > > > >
> > > > > > > [1]
> > > > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/inc
> > > > ubator/nuttx/10.1.0-RC0/__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY
> > > > 2nV6G_lkT8Y8QJWo9Nv_bGYGjtgmeOc3mRIUEGmDag$
> > > > > > > [2]
> > > > > >
> > > > >
> > > > https://urldefense.com/v3/__https://raw.githubusercontent.com/apache/i
> > > > ncubator-nuttx/nuttx-10.1.0-RC0/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!rb2n
> > > > GxDcx1NeBVx6ZgXhc6ZY2nV6G_lkT8Y8QJWo9Nv_bGYGjtgmeOc3mRJlgBtnkg$
> > > > > > > [3]
> > > > > > > h

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

[Abdelatif Guettouche]

> I mentioned that this should be backported, not sure if the author saw it:
https://github.com/apache/incubator-nuttx/pull/3613

I've labeled it so.  Thanks.

On Wed, Apr 28, 2021 at 2:51 PM Matias N.  wrote:
>
> Right, thanks.
>
> I mentioned that this should be backported, not sure if the author saw it:
> https://github.com/apache/incubator-nuttx/pull/3613
>
> Best,
> Matias
>
> On Wed, Apr 28, 2021, at 10:46, Abdelatif Guettouche wrote:
> > > Wasn't the stack restructure behind the 10.1 release?
> >
> > Yes, but that change just exposed an old issue.
> >
> > On Wed, Apr 28, 2021 at 2:45 PM Matias N.  > <mailto:matias%40imap.cc>> wrote:
> > >
> > > Wasn't the stack restructure behind the 10.1 release?
> > >
> > > Best,
> > > Matias
> > >
> > > On Wed, Apr 28, 2021, at 09:57, Gustavo Henrique Nihei wrote:
> > > > Hi folks,
> > > >
> > > > I believe we should consider backporting the fix from this PR into the
> > > > 10.1.0 release:
> > > > https://github.com/apache/incubator-nuttx/pull/3614
> > > >
> > > > It fixes a side effect from the refactoring of the stack architecture
> > > > due to a wrong stack alignment for RISC-V chips.
> > > >
> > > > Best regards,
> > > > Gustavo.
> > > >
> > > > On Mon, Apr 26, 2021 at 5:58 AM  > > > <mailto:Alin.Jerpelea%40sony.com> <mailto:Alin.Jerpelea%40sony.com>> 
> > > > wrote:
> > > > >
> > > > > Hi Brenan,
> > > > >
> > > > > We still have the following commit that is not resolved and I think 
> > > > > that it is better to hold the release until it is ready for emerge
> > > > > https://github.com/apache/incubator-nuttx/pull/3601
> > > > >
> > > > > Regards
> > > > > Alin
> > > > >
> > > > > -Original Message-
> > > > > From: Alin Jerpelea mailto:jerpelea%40gmail.com> 
> > > > > <mailto:jerpelea%40gmail.com>>
> > > > > Sent: den 22 april 2021 16:14
> > > > > To: dev@nuttx.apache.org <mailto:dev%40nuttx.apache.org> 
> > > > > <mailto:dev%40nuttx.apache.org>
> > > > > Subject: Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release
> > > > >
> > > > > It is perfect timing!
> > > > >
> > > > > I will cut RC1 with the fixes tonight
> > > > >
> > > > > Thanks
> > > > > Alin
> > > > >
> > > > > On Thu, Apr 22, 2021, 16:12 Nathan Hartman  > > > > <mailto:hartman.nathan%40gmail.com> 
> > > > > <mailto:hartman.nathan%40gmail.com>> wrote:
> > > > >
> > > > > > On Thu, Apr 22, 2021 at 2:54 AM Alin Jerpelea  > > > > > <mailto:jerpelea%40gmail.com> <mailto:jerpelea%40gmail.com>> wrote:
> > > > > >
> > > > > > > Hi Brennan,
> > > > > > > I think that we should backport them and I will cut RC1 Thanks 
> > > > > > > Alin
> > > > > >
> > > > > >
> > > > > >
> > > > > > If I'm not too late, I fixed up the ReleaseNotes a little bit in
> > > > > > PR-3570
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Apr 22, 2021, 08:30 Brennan Ashton
> > > > > > > mailto:bashton%40brennanashton.com> 
> > > > > > > <mailto:bashton%40brennanashton.com>>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Alin,
> > > > > > > > I think we should consider if we want to backport these into the
> > > > > > > > 10.1.0 release.  I am still running more tests myself on all the
> > > > > > > > hardware I have, but these seemed important to at least 
> > > > > > > > consider.
> > > > > > > > https://urldefense.com/v3/__https://github.com/apache/incubator-nu
> > > > > > > > ttx/pull/3586__;!!JmoZiZGBv3RvKRSx!rb2nGxDcx1NeBVx6ZgXhc6ZY2nV6G_l
> > > > > > > > kT8Y8QJWo9Nv_bGYGjtgmeOc3mRLLOLl7Nw$
> > > > 

Re: How can I use I2C?

[Abdelatif Guettouche]

If you want to use the I2C tool, you'll also have to register the i2c
driver from your board logic.

See:
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32f0l0g0/nucleo-g070rb/src/stm32_bringup.c#L89-L111
https://github.com/apache/incubator-nuttx/blob/master/boards/risc-v/esp32c3/esp32c3-devkit/src/esp32c3_i2c.c

On Fri, Apr 30, 2021 at 1:47 PM Alan Carvalho de Assis
 wrote:
>
> Hi Yuta,
>
> Yes, you forgot to select the I2C Character driver support.
>
> Please try to follow this tutorial:
>
> https://www.youtube.com/watch?v=RzrDa4Sm1rU
>
> BR,
>
> Alan
>
> On 4/30/21, yuta  wrote:
> > Hi all,
> > I'm trying to use I2C.
> > I configured below in menuconfig.
> > - System Type > STM32 Peripheral Support > [*] I2C1
> > - Device Drivers > [*] I2C Driver Support
> > then compilation was done successfully.
> > But no I2C device( like /dev/i2c1 ) showed up when I tried ls /dev
> > Do I forget something to do?
> >
> > I'm using Nucleo-F767ZI board.
> >
> > Thank you.
> > Yuta Ide
> >
> >

Re: How to share code and Kconfig between different boards

[Abdelatif Guettouche]

> I'm not sure if there's support for custom-board common-code (in the same 
> sense as for in-tree boards).

There is, it works the same way as the in-tree boards.  But I think
what's being asked here is something common between different boards
of different architectures?
I think what you suggested should work (provided that this is some
external driver and not board logic).

On Wed, May 5, 2021 at 2:15 PM Matias N.  wrote:
>
> I'm not sure if there's support for custom-board common-code (in the same 
> sense as for in-tree boards). In any case, we've introduced an external/ 
> directory for the purpose of adding external OS level code. Simply point 
> nuttx/external symlink to your common directory.
>
> Best,
> Matias
>
> On Wed, May 5, 2021, at 04:56, Frank-Christian Kruegel wrote:
> > Hi.
> >
> > I've created several board support packages, each in its own out-of-tree
> > directory. Ive configured them as custom boards with a relative path
> > like ...
> >
> > +- nuttx
> > +- apps
> > +- company-boards
> > |  +- board1
> > |  +- board2
> > |  +- board3
> > +- company-apps
> > |  +- app1
> > |  +- app2
> > ...
> >
> > Works fine.
> >
> > These boards have different microcontrollers from different
> > architectures, but they all have common hardware and configuration
> > items. It would be very helpful, it i could share code between the
> > boards like...
> >
> > +- company-boards
> > |  +- board1
> > | +-Kconfig
> > | +-src
> > |  +- board2
> > | +-Kconfig
> > | +-src
> > |  +- board3
> > | +-Kconfig
> > | +-src
> > |  +- board-common  <-- NEW SHARED DIRECTORY
> > | +-Kconfig
> > | +-src
> >
> > so I can reference the common codefrom each board. The shared code is
> > kernel code, custom drivers, driver initialisation etc, no application
> > logic, and since it is very specific to my hardware the nuttx tree is
> > not a good place for it.
> >
> > How do I do it the correct way?
> >
> > I've notices that the board Kconfig gets copied over to
> > nuttx/boards/dummy, so a mere "source ../../board-common/Kconfig"
> > doesn't work. I managed to make Kconfig work by using "source
> > $TOPDIR/../company-boards/board-common/Kconfig". Now I'm stuck with
> > makefiles.
> >
> > Best regards
> >
> > Frank-Christian
> >

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

[Abdelatif Guettouche]

Hi,
+1 :
  - LICENSE, NOTICE and DISCLAIMER files exit in both repos.
  - Signatures and checksums valid.
  - Can build from source.

On Thu, May 6, 2021 at 8:40 AM  wrote:
>
> Hi all,
>
> 72h have passed
> Can we get some votes to finish the 10.1 release?
>
> Thanks
> Alin
>
>
> -Original Message-
> From: alin.jerpe...@sony.com 
> Sent: den 3 maj 2021 17:17
> To: dev@nuttx.apache.org
> Subject: RE: [VOTE] Apache NuttX 10.1.0 (incubating) RC1 release
>
> 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/inc
> > ubator/nuttx/10.1.0-RC1/__;!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz4
> > HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBF0cM9oFQ$
> > [2]https://urldefense.com/v3/__https://raw.githubusercontent.com/apach
> > e/incubator-nuttx/nuttx-10.1.0-RC1/ReleaseNotes__;!!JmoZiZGBv3RvKRSx!u
> > 7bO_5TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBELDkRTXA$
> > [3]
> > https://urldefense.com/v3/__https://www.apache.org/dev/release.html*ap
> > proving-a-release__;Iw!!JmoZiZGBv3RvKRSx!u7bO_5TgIUsO429c5U2xXTz4HI0T2
> > TqnSm836Wse15R0SGxhUdWk3viAcBGKE_xsSw$
> > [4]https://urldefense.com/v3/__https://cwiki.apache.org/confluence/dis
> > play/NUTTX/Validating*a*staged*Release__;Kysr!!JmoZiZGBv3RvKRSx!u7bO_5
> > TgIUsO429c5U2xXTz4HI0T2TqnSm836Wse15R0SGxhUdWk3viAcBE_QwknXQ$
>
>
> Just to be sure I don't misunderstand, this is the latest release candidate 
> to be tested now?
>
> In the future, I recommend to increment the -RC numbers each time there are 
> new tarballs, to avoid any potential confusion.
>
> If this is indeed the latest RC, I'll try to test it today.
>
> Thanks for all your hard work!!
>
> Cheers,
> Nathan

Re: NuttX (Online) Workshop 2021 (call for event team members)

[Abdelatif Guettouche]

Do we have any preliminary dates for the event?

On Tue, May 18, 2021 at 3:02 PM David Sidrane  wrote:
>
> Please count me in.
>
> -Original Message-
> From: alin.jerpe...@sony.com [mailto:alin.jerpe...@sony.com]
> Sent: Tuesday, May 18, 2021 1:54 AM
> To: dev@nuttx.apache.org
> Subject: NuttX (Online) Workshop 2021 (call for event team members)
>
> Hi all,
>
> Yesterday me and Alan were talking about the plans for the NuttX 2021
> workshop and we were thinking that we should see if there are other people
> interested to be part of the event team.
> If you are interested to be part of the event team please replay to this
> mail and we will invite you to the online meeting.
> Regards
> Alin

Re: external board build failure

[Abdelatif Guettouche]

Hi,

Is it possible to share the defconfig?  I just tried with an old one
(based on STM32) and I have a clean build.
The relevant configs that need to be correctly set are:
CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_DIR="../boards/stm32/board-dir"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="Custom-STM32-Board"

On Thu, May 20, 2021 at 10:47 AM Sebastien Lorquet  wrote:
>
> Hello,
>
> I have to update the nuttx in our project from pre-apache to last version.
>
> We would like to use the external board feature.
>
> As a test I copied the nucleo-f446re folder in boards/arm to somewhere
> else (sibling to apps and nuttx), renamed it, and pointed to it in the
> configuration. make menuconfig was happy with that.
>
> However the build fails:
>
> IN: fs/libfs.a -> staging/libfs.a
> make[1]: Entering directory '/home/slo/nut/nuttx/binfmt'
> CC:  binfmt_globals.c
> CC:  binfmt_initialize.c
> CC:  binfmt_register.c
> CC:  binfmt_unregister.c
> CC:  binfmt_loadmodule.c
> CC:  binfmt_unloadmodule.c
> CC:  binfmt_execmodule.c
> CC:  binfmt_exec.c
> CC:  binfmt_copyargv.c
> CC:  binfmt_dumpmodule.c
> CC:  builtin.c
> AR (create): libbinfmt.a   binfmt_globals.o binfmt_initialize.o
> binfmt_register.o binfmt_unregister.o binfmt_loadmodule.o
> binfmt_unloadmodule.o binfmt_execmodule.o binfmt_exec.o
> binfmt_copyargv.o binfmt_dumpmodule.o builtin.o
> make[1]: Leaving directory '/home/slo/nut/nuttx/binfmt'
> IN: binfmt/libbinfmt.a -> staging/libbinfmt.a
> make[1]: Entering directory '/home/slo/nut/nuttx/arch/arm/src'
> make[2]: Entering directory '/home/slo/nut/my_own_nucleo/src'
> make[2]: *** No rule to make target 'libboard.a'.  Stop.
> make[2]: Leaving directory '/home/slo/nut/my_own_nucleo/src'
> make[1]: *** [Makefile:152: board/libboard.a] Error 2
> make[1]: Leaving directory '/home/slo/nut/nuttx/arch/arm/src'
> make: *** [tools/Makefile.unix:422: nuttx] Error 2
>
> Looks like a Makefile (or just a rule) is missing. Is it a bug in this
> board/arch or in my own method or a problem in the external board build
> system?
>
> I'm using a relative board path.
>
> I'll add a github issue when the problem is understood.
>
> Sebastien
>

Re: external board build failure

[Abdelatif Guettouche]

There is this issue that has more details, as well:
https://github.com/apache/incubator-nuttx/issues/2206

On Thu, May 20, 2021 at 12:44 PM Abdelatif Guettouche
 wrote:
>
> Hi,
>
> Is it possible to share the defconfig?  I just tried with an old one
> (based on STM32) and I have a clean build.
> The relevant configs that need to be correctly set are:
> CONFIG_ARCH_BOARD_CUSTOM=y
> CONFIG_ARCH_BOARD_CUSTOM_DIR="../boards/stm32/board-dir"
> CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> CONFIG_ARCH_BOARD_CUSTOM_NAME="Custom-STM32-Board"
>
> On Thu, May 20, 2021 at 10:47 AM Sebastien Lorquet  
> wrote:
> >
> > Hello,
> >
> > I have to update the nuttx in our project from pre-apache to last version.
> >
> > We would like to use the external board feature.
> >
> > As a test I copied the nucleo-f446re folder in boards/arm to somewhere
> > else (sibling to apps and nuttx), renamed it, and pointed to it in the
> > configuration. make menuconfig was happy with that.
> >
> > However the build fails:
> >
> > IN: fs/libfs.a -> staging/libfs.a
> > make[1]: Entering directory '/home/slo/nut/nuttx/binfmt'
> > CC:  binfmt_globals.c
> > CC:  binfmt_initialize.c
> > CC:  binfmt_register.c
> > CC:  binfmt_unregister.c
> > CC:  binfmt_loadmodule.c
> > CC:  binfmt_unloadmodule.c
> > CC:  binfmt_execmodule.c
> > CC:  binfmt_exec.c
> > CC:  binfmt_copyargv.c
> > CC:  binfmt_dumpmodule.c
> > CC:  builtin.c
> > AR (create): libbinfmt.a   binfmt_globals.o binfmt_initialize.o
> > binfmt_register.o binfmt_unregister.o binfmt_loadmodule.o
> > binfmt_unloadmodule.o binfmt_execmodule.o binfmt_exec.o
> > binfmt_copyargv.o binfmt_dumpmodule.o builtin.o
> > make[1]: Leaving directory '/home/slo/nut/nuttx/binfmt'
> > IN: binfmt/libbinfmt.a -> staging/libbinfmt.a
> > make[1]: Entering directory '/home/slo/nut/nuttx/arch/arm/src'
> > make[2]: Entering directory '/home/slo/nut/my_own_nucleo/src'
> > make[2]: *** No rule to make target 'libboard.a'.  Stop.
> > make[2]: Leaving directory '/home/slo/nut/my_own_nucleo/src'
> > make[1]: *** [Makefile:152: board/libboard.a] Error 2
> > make[1]: Leaving directory '/home/slo/nut/nuttx/arch/arm/src'
> > make: *** [tools/Makefile.unix:422: nuttx] Error 2
> >
> > Looks like a Makefile (or just a rule) is missing. Is it a bug in this
> > board/arch or in my own method or a problem in the external board build
> > system?
> >
> > I'm using a relative board path.
> >
> > I'll add a github issue when the problem is understood.
> >
> > Sebastien
> >

Re: external board build failure

[Abdelatif Guettouche]

(It looks like we dropped the list somehow, I'm bringing it back...)

> There is no way this common file is going into my custom board.

If you don't want it; just remove it.  But you'll have to adapt your
Make.defs file.  Mainly adding "include $(TOPDIR)/boards/Board.mk" at
the end.
Other small things could be required. Adapt it from a different board
that doesn't have a common directory, an STM32F7 for example, it will
be simpler.


On Thu, May 20, 2021 at 2:11 PM Sebastien Lorquet  wrote:
>
> This entirely defeat the purpose of a custom board.
>
> There is no way this common file is going into my custom board.
>
> What to do? Do I need TWO custom dirs? One for the board and one for the
> custom stuff?
>
> Sebastien
>
> Le 20/05/2021 à 15:08, Abdelatif Guettouche a écrit :
> > It should then also be the same case as #2206, you'll need the common
> > directory: 
> > https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721141748
> >
> > For STM32 (and other chips that have the "common" directory
> > structure), the stm32/board_dir/src/Make.defs file is not complete.
> > It needs the stm32/common/Makefile in order to get everything hooked
> > into the build system.
> >
> > On Thu, May 20, 2021 at 2:01 PM Sebastien Lorquet  
> > wrote:
> >> It was the defconfig from nucleo-f446re:nsh, only modified to use a
> >> custom board with relpath.
> >>
> >> The same failure happens with the stm32f427i-disco:nsh configuration.
> >>
> >>
> >> I have the same issues as described in 2206
> >>
> >> I have tried running: tools/configure.sh ../my_own_nucleo/configs/nsh
> >>
> >> And the log shows:
> >>
> >> LN: include/arch to arch/arm/include
> >> LN: include/arch/board to 
> >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/include
> >> LN: include/arch/chip to arch/arm/include/stm32
> >> LN: arch/arm/src/board to 
> >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/../common
> >> LN: arch/arm/src/board/board to 
> >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/src
> >> LN: arch/arm/src/chip to arch/arm/src/stm32
> >> LN: /home/slo/nut/nuttx/drivers/platform to 
> >> /home/slo/nut/nuttx/drivers/dummy
> >>
> >> and it builds, because it uses the original dev board
> >>
> >> So in fact using configure with a custom board path DOES NOT work. It just 
> >> configures whatever built in board is indicated in the config file.
> >>
> >> Then I tried to change the board path using make menuconfig, then make 
> >> again, and then it stops building as before: '*** No rule to make target 
> >> 'libboard.a'.'
> >>
> >> Sebastien
> >>
> >>
> >> Le 20/05/2021 à 13:44, Abdelatif Guettouche a écrit :
> >>> Hi,
> >>>
> >>> Is it possible to share the defconfig?  I just tried with an old one
> >>> (based on STM32) and I have a clean build.
> >>> The relevant configs that need to be correctly set are:
> >>> CONFIG_ARCH_BOARD_CUSTOM=y
> >>> CONFIG_ARCH_BOARD_CUSTOM_DIR="../boards/stm32/board-dir"
> >>> CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> >>> CONFIG_ARCH_BOARD_CUSTOM_NAME="Custom-STM32-Board"
> >>>
> >>> On Thu, May 20, 2021 at 10:47 AM Sebastien Lorquet  
> >>> wrote:
> >>>> Hello,
> >>>>
> >>>> I have to update the nuttx in our project from pre-apache to last 
> >>>> version.
> >>>>
> >>>> We would like to use the external board feature.
> >>>>
> >>>> As a test I copied the nucleo-f446re folder in boards/arm to somewhere
> >>>> else (sibling to apps and nuttx), renamed it, and pointed to it in the
> >>>> configuration. make menuconfig was happy with that.
> >>>>
> >>>> However the build fails:
> >>>>
> >>>> IN: fs/libfs.a -> staging/libfs.a
> >>>> make[1]: Entering directory '/home/slo/nut/nuttx/binfmt'
> >>>> CC:  binfmt_globals.c
> >>>> CC:  binfmt_initialize.c
> >>>> CC:  binfmt_register.c
> >>>> CC:  binfmt_unregister.c
> >>>> CC:  binfmt_loadmodule.c
> >>>> CC:  binfmt_unloadmodule.c
> >>>> CC:  binfmt_execmodule.c
> >>>> CC:  binfmt_exec.c
> >>>> CC:  binfmt_copyargv.c
> >

Re: external board build failure

[Abdelatif Guettouche]

I just copied the nucleo-fe446re board without the common directory.

Here are the steps I took:
Add the correct custom board CONFIGs to nsh/defconfig (and remove some
of the old ones)
Rename Make.defs to Makefile
Add include $(TOPDIR)/boards/Board.mk to the end of the file.

./tools/configure.sh ../boards/nucleo-f446re/configs/nsh
make

Builds fine.

On Thu, May 20, 2021 at 2:14 PM Abdelatif Guettouche
 wrote:
>
> (It looks like we dropped the list somehow, I'm bringing it back...)
>
> > There is no way this common file is going into my custom board.
>
> If you don't want it; just remove it.  But you'll have to adapt your
> Make.defs file.  Mainly adding "include $(TOPDIR)/boards/Board.mk" at
> the end.
> Other small things could be required. Adapt it from a different board
> that doesn't have a common directory, an STM32F7 for example, it will
> be simpler.
>
>
> On Thu, May 20, 2021 at 2:11 PM Sebastien Lorquet  
> wrote:
> >
> > This entirely defeat the purpose of a custom board.
> >
> > There is no way this common file is going into my custom board.
> >
> > What to do? Do I need TWO custom dirs? One for the board and one for the
> > custom stuff?
> >
> > Sebastien
> >
> > Le 20/05/2021 à 15:08, Abdelatif Guettouche a écrit :
> > > It should then also be the same case as #2206, you'll need the common
> > > directory: 
> > > https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721141748
> > >
> > > For STM32 (and other chips that have the "common" directory
> > > structure), the stm32/board_dir/src/Make.defs file is not complete.
> > > It needs the stm32/common/Makefile in order to get everything hooked
> > > into the build system.
> > >
> > > On Thu, May 20, 2021 at 2:01 PM Sebastien Lorquet  
> > > wrote:
> > >> It was the defconfig from nucleo-f446re:nsh, only modified to use a
> > >> custom board with relpath.
> > >>
> > >> The same failure happens with the stm32f427i-disco:nsh configuration.
> > >>
> > >>
> > >> I have the same issues as described in 2206
> > >>
> > >> I have tried running: tools/configure.sh ../my_own_nucleo/configs/nsh
> > >>
> > >> And the log shows:
> > >>
> > >> LN: include/arch to arch/arm/include
> > >> LN: include/arch/board to 
> > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/include
> > >> LN: include/arch/chip to arch/arm/include/stm32
> > >> LN: arch/arm/src/board to 
> > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/../common
> > >> LN: arch/arm/src/board/board to 
> > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/src
> > >> LN: arch/arm/src/chip to arch/arm/src/stm32
> > >> LN: /home/slo/nut/nuttx/drivers/platform to 
> > >> /home/slo/nut/nuttx/drivers/dummy
> > >>
> > >> and it builds, because it uses the original dev board
> > >>
> > >> So in fact using configure with a custom board path DOES NOT work. It 
> > >> just configures whatever built in board is indicated in the config file.
> > >>
> > >> Then I tried to change the board path using make menuconfig, then make 
> > >> again, and then it stops building as before: '*** No rule to make target 
> > >> 'libboard.a'.'
> > >>
> > >> Sebastien
> > >>
> > >>
> > >> Le 20/05/2021 à 13:44, Abdelatif Guettouche a écrit :
> > >>> Hi,
> > >>>
> > >>> Is it possible to share the defconfig?  I just tried with an old one
> > >>> (based on STM32) and I have a clean build.
> > >>> The relevant configs that need to be correctly set are:
> > >>> CONFIG_ARCH_BOARD_CUSTOM=y
> > >>> CONFIG_ARCH_BOARD_CUSTOM_DIR="../boards/stm32/board-dir"
> > >>> CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > >>> CONFIG_ARCH_BOARD_CUSTOM_NAME="Custom-STM32-Board"
> > >>>
> > >>> On Thu, May 20, 2021 at 10:47 AM Sebastien Lorquet 
> > >>>  wrote:
> > >>>> Hello,
> > >>>>
> > >>>> I have to update the nuttx in our project from pre-apache to last 
> > >>>> version.
> > >>>>
> > >>>> We would like to use the external board feature.
> > >>>>
> > >>>> As a test I copied

Re: external board build failure

[Abdelatif Guettouche]

> Rename Make.defs to Makefile

To be clear, here I'm referring to ../boards/nucleo-f446re/src/Make.defs

On Thu, May 20, 2021 at 2:27 PM Abdelatif Guettouche
 wrote:
>
> I just copied the nucleo-fe446re board without the common directory.
>
> Here are the steps I took:
> Add the correct custom board CONFIGs to nsh/defconfig (and remove some
> of the old ones)
> Rename Make.defs to Makefile
> Add include $(TOPDIR)/boards/Board.mk to the end of the file.
>
> ./tools/configure.sh ../boards/nucleo-f446re/configs/nsh
> make
>
> Builds fine.
>
> On Thu, May 20, 2021 at 2:14 PM Abdelatif Guettouche
>  wrote:
> >
> > (It looks like we dropped the list somehow, I'm bringing it back...)
> >
> > > There is no way this common file is going into my custom board.
> >
> > If you don't want it; just remove it.  But you'll have to adapt your
> > Make.defs file.  Mainly adding "include $(TOPDIR)/boards/Board.mk" at
> > the end.
> > Other small things could be required. Adapt it from a different board
> > that doesn't have a common directory, an STM32F7 for example, it will
> > be simpler.
> >
> >
> > On Thu, May 20, 2021 at 2:11 PM Sebastien Lorquet  
> > wrote:
> > >
> > > This entirely defeat the purpose of a custom board.
> > >
> > > There is no way this common file is going into my custom board.
> > >
> > > What to do? Do I need TWO custom dirs? One for the board and one for the
> > > custom stuff?
> > >
> > > Sebastien
> > >
> > > Le 20/05/2021 à 15:08, Abdelatif Guettouche a écrit :
> > > > It should then also be the same case as #2206, you'll need the common
> > > > directory: 
> > > > https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721141748
> > > >
> > > > For STM32 (and other chips that have the "common" directory
> > > > structure), the stm32/board_dir/src/Make.defs file is not complete.
> > > > It needs the stm32/common/Makefile in order to get everything hooked
> > > > into the build system.
> > > >
> > > > On Thu, May 20, 2021 at 2:01 PM Sebastien Lorquet 
> > > >  wrote:
> > > >> It was the defconfig from nucleo-f446re:nsh, only modified to use a
> > > >> custom board with relpath.
> > > >>
> > > >> The same failure happens with the stm32f427i-disco:nsh configuration.
> > > >>
> > > >>
> > > >> I have the same issues as described in 2206
> > > >>
> > > >> I have tried running: tools/configure.sh ../my_own_nucleo/configs/nsh
> > > >>
> > > >> And the log shows:
> > > >>
> > > >> LN: include/arch to arch/arm/include
> > > >> LN: include/arch/board to 
> > > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/include
> > > >> LN: include/arch/chip to arch/arm/include/stm32
> > > >> LN: arch/arm/src/board to 
> > > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/../common
> > > >> LN: arch/arm/src/board/board to 
> > > >> /home/slo/nut/nuttx/boards/arm/stm32/nucleo-f446re/src
> > > >> LN: arch/arm/src/chip to arch/arm/src/stm32
> > > >> LN: /home/slo/nut/nuttx/drivers/platform to 
> > > >> /home/slo/nut/nuttx/drivers/dummy
> > > >>
> > > >> and it builds, because it uses the original dev board
> > > >>
> > > >> So in fact using configure with a custom board path DOES NOT work. It 
> > > >> just configures whatever built in board is indicated in the config 
> > > >> file.
> > > >>
> > > >> Then I tried to change the board path using make menuconfig, then make 
> > > >> again, and then it stops building as before: '*** No rule to make 
> > > >> target 'libboard.a'.'
> > > >>
> > > >> Sebastien
> > > >>
> > > >>
> > > >> Le 20/05/2021 à 13:44, Abdelatif Guettouche a écrit :
> > > >>> Hi,
> > > >>>
> > > >>> Is it possible to share the defconfig?  I just tried with an old one
> > > >>> (based on STM32) and I have a clean build.
> > > >>> The relevant configs that need to be correctly set are:
> > > >>> CONFIG_ARCH_BOARD_CUSTOM=y
> > > >>> CONFIG_ARCH_BOARD_CUSTOM_

Re: external board build failure

[Abdelatif Guettouche]

> Also I woud advise against this common dir in boards, since it prevents
users from creating custom boards from built-in ones.

We can still create a custom board from an in-tree board that has the
common dir. We just have to either include the common dir or remove it
and adapt the makefiles as we did here.
I have something similar to this:
tree -L 2 boards/

|── board1
│   ├── configs
...
│   └── src
|── board2
│   ├── configs
...
│   └── src
└── stm32
├── common
├── drivers
└── stm32-board1
└── stm32-board2

I think the common dir just added an extra step (although, it's not too obvious)

> I've just tested the external board build following these simple steps.

These steps will work because STM32L4 family doesn't have a common
directory.  This is the "old" method that Sebastien was referring to.

In any case, I think we can write a script that can create a custom
board based on an in-tree board, regardless of the presence or not of
the common directory.

On Thu, May 20, 2021 at 2:35 PM Alan Carvalho de Assis
 wrote:
>
> I agree, it should a good idea if it could be turned into a Documentation 
> page!
>
> BR,
>
> Alan
>
> On 5/20/21, Sebastien Lorquet  wrote:
> > :o
> >
> > it worked.
> >
> > How am I supposed to guess this?
> >
> > Your email should be copied verbatim in the official documentation
> > somewhere under "how to create and build a custom board"
> >
> > Also I woud advise against this common dir in boards, since it prevents
> > users from creating custom boards from built-in ones.
> >
> > Duplication is not always bad, as we know...
> >
> > Sebastien
> >
> >
> > Le 20/05/2021 à 15:27, Abdelatif Guettouche a écrit :
> >> Rename Make.defs to Makefile
> >

Re: CONFIG_CAN_PASS_STRUCTS disappeared ?

[Abdelatif Guettouche]

That option was removed in 9.0, it only affects the SDCC compiler, I
think you can remove it in your case.

Here is a snippet from the release notes.

>   * Compatibility Concerns

- The configuration option CONFIG_CAN_PASS_STRUCT is now
removed.  Previously, it was used (at the cost of breaking standards
support) to support older versions of the SDCC compiler that couldn't
pass structs/unions as functions' parameters.  A newer version of the
compiler has resolved the issue.

On Mon, May 24, 2021 at 10:06 AM Sebastien Lorquet  wrote:
>
> Hello,
>
> Migrating our system from NuttX 7.30 to current trunk
>
> Nothing very bad, just up_arch.h changed to arm_arch.h and it's mostly
> compiling fine.
>
> One of our custom drivers use sigqueue, which requires different types
> according to CONFIG_CAN_PASS_STRUCTS
>
> This config seems to not exist anymore. Is it implied now? Can I delete
> the code that assume absence of this config?
>
> Thanks,
>
> Sebastien
>

Re: (Late) heads-up for new risc-v soc and board

[Abdelatif Guettouche]

Nice work!  Thanks for the contribution!

On Mon, May 24, 2021 at 8:34 PM Janne Rosberg 
wrote:

> Hi Alan,
>
> Yes, it has FPGA “build-in” so you can do very nice processing with that.
> Also 4+1 cores running on 600+Mhz so it’s almost a supercomputer. 😊
> Let’s see what we can squeeze out of it.
> Later on hoping to get SMP config working….
>
> Janne
>
> From: Alan Carvalho de Assis 
> Date: Monday, 24. May 2021 at 22.13
> To: dev@nuttx.apache.org 
> Subject: Re: (Late) heads-up for new risc-v soc and board
> Hi Janne,
>
> Very nice! Kudos!!!
>
> So, this SoC has FPGA integrated on it?
>
> BR,
>
> Alan
>
> On 5/24/21, Janne Rosberg  wrote:
> > Hi all devs,
> >
> > First of all, it’s nice to be back on (public) NuttX development. It’s
> been
> > a while since last time. 😊
> >
> > We are doing porting for MicroChip PolarFire Risc-V SoC and Icicle
> > evaluation board.
> > Basic things already works (uart and gpios) so we can boot to nsh.
> > First PR #3770 is already “pending”
> >
> > If there is anybody who is working on this SoC please let us know so
> that we
> > can combine our work forces…
> > But anyway, we continue with peripheral drivers; I2C already done others
> to
> > follow.
> >
> > This work is was made possible by TII. https://github.com/tiiuae so all
> PR’s
> > are coming from there.
> >
> > Br,
> > Janne
> >
> >
>

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

[Abdelatif Guettouche]

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 what the hell is is this invalid address!
> >>
> >> This is the first call to mm_free, here is the backtrace:
> >>
> >> Breakpoint 1, mm_free (heap=0x200060b4 , mem=0x70fb460b) at
> >> mm_heap/mm_free.c:85
> >> 85if (!mem)
> >> (gdb) bt
> >> #0  mm_free (heap=0x200060b4 , mem=0x70fb460b) at
> >> mm_heap/mm_free.c:85
> >> #1  0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
> >> mm_heap/mm_malloc.c:82
> >> #2  0x08012672 in mm_malloc (heap=0x200060b4 , size=24) at
> >> mm_heap/mm_malloc.c:115
> >> #3  0x08012a32 in mm_zalloc (heap=0x200060b4 , size=24) at
> >> mm_heap/mm_zalloc.c:45
> >> #4  0x080123ac in zalloc (size=24) at umm_heap/umm_zalloc.c:68
> >> #5  0x080399fa in inode_alloc (name=0x8059a78 "") at
> >> inode/fs_inodereserve.c:78
> >> #6  0x08039a5c in inode_root_reserve () at inode/fs_inodereserve.c:129
> >> #7  0x080398cc in inode_initialize () at inode/fs_inode.c:92
> >> #8  0x08039284 in fs_initialize () at fs_initialize.c:47
> >> #9  0x08007eb4 in nx_start () at init/nx_start.c:600
> >> #10 0x0800421e in __start () at chip/stm32_start.c:338
> >>
> >> As previously analyzed, this happens in fs_initialize through
> >> inode_root_reserve, so I was on the right track.
> >>
> >> Caller shows mm_free called with that weird address:
> >>
> >> (gdb) f 1
> >> #1  0x0801264a in mm_free_delaylist (heap=0x200060b4 ) at
> >> mm_heap/mm_malloc.c:82
> >> 82mm_free(heap, address);
> >> (gdb) list
> >> 77
> >> 78/* The address should always be non-NULL since that was
> >> checked in the
> >> 79 * 'while' condition above.
> >> 80 */
> >> 81
> >> 82mm_free(heap, address); <-- address == 0x70fb460b
> >> 83  }
> >> 84  #endif
> >> 85  }
> >> 86
> >>
> >> (gdb) print &g_mmheap
> >> $3 = (struct mm_heap_s *) 0x200060b4 
> >> (gdb) print g_mmheap
> >> $4 = {mm_impl = 0x0}
> >>
> >> this is not good!
> >>
> >> This is not a timing or IRQ related issue but a heap issue.
> >>
> >> R15 = 080126f8 translates to here:
> >>
> >>
> >> https://github.com/apache/incubator-nuttx/blob/master/mm/mm_heap/mm_malloc.c#L199
> >>
> >> => this free() has corrupted a badly initialized heap, and the next
> >> malloc fails, giving a hardfault because that address is invalid.
> >>
> >> Horrific mess!
> >>
> >> ==>
> >>
> >> I think that my old board code does not initialize the board proper

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]
>> >> > >>
>> >> https://urldefense.com/v3/__https://www.apache.

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

[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: ESP8266 support

[Abdelatif Guettouche]

> Looking at NuttX source code, I couldn't find any example of an
> application that implements the ESP8266 functions. Is there any place
> where I can find reference for this use?

There is a separate application in apps/netutils/esp8266.  I've never
tried it though, so I don't now about its state.


On Thu, Jun 3, 2021 at 3:28 PM Grr  wrote:
>
> There's a protocol to use SPI as network link, which obviously has much
> bigger bandwidth and potential
>
> If you're not in a hurry to implement the solution and are interested in
> developing a better one, count me in
>
> El jue., 3 de jun. de 2021 9:02 AM, Flavio Castro Alves Filho <
> flavio.al...@gmail.com> escribió:
>
> > Hello,
> >
> > I am using UART.
> >
> >
> > Em qui., 3 de jun. de 2021 às 10:44, Grr  escreveu:
> > >
> > > What physical link will you use to connect 8266 and main board?
> > >
> > > Your project is very interesting and opens a lot of potential for
> > > inexpensive distributed control
> > >
> > > El jue., 3 de jun. de 2021 8:27 AM, Flavio Castro Alves Filho <
> > > flavio.al...@gmail.com> escribió:
> > >
> > > > Hello,
> > > >
> > > > I am working on the integration between a STM32F4Discovery based board
> > > > to a ESP8266-WROOM-2 module, in order to have WiFi connectivity.
> > > >
> > > > My plan is to implement a thread using USRSOCK and the ESP8266
> > > > functions available in netutils, using as reference the work
> > > > previously done with GS2200m.
> > > >
> > > > Looking at NuttX source code, I couldn't find any example of an
> > > > application that implements the ESP8266 functions. Is there any place
> > > > where I can find reference for this use?
> > > >
> > > > Best regards,
> > > >
> > > > Flavio
> > > >
> > > > --
> > > > Flavio de Castro Alves Filho
> > > >
> > > > flavio.al...@gmail.com
> > > > Twitter: http://twitter.com/#!/fraviofii
> > > > LinkedIn profile: www.linkedin.com/in/flaviocastroalves
> > > >
> >
> >
> >
> > --
> > Flavio de Castro Alves Filho
> >
> > flavio.al...@gmail.com
> > Twitter: http://twitter.com/#!/fraviofii
> > LinkedIn profile: www.linkedin.com/in/flaviocastroalves
> >

Re: Introduction + incoming RISC-V port(s)

[Abdelatif Guettouche]

*So I've kicked that back in, but it appears I have to wait for a
(gasp)human**to push a button*.

This is actually a Github thing and is outside of our control.  It's pretty
new too, so we too have to get used to it.  As Nathan said, this only
applies to first time contributors.  Subsequent contributions should go a
bit smoother.

On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman 
wrote:

> On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe  wrote:
>
> > >
> > >
> > > > The presubmit flips out about C99 comments. Even that's too radical.
> So
> > > > much for being king. :-)
> > >
> > > You can use C99, but you cannot forgot to follow the Coding Style, //
> > > comments shouldn't be used :-)
> > >
> >
> > It's actually worse than that. You can use C99 comments at the end of a
> > line
> > but not at the beginning
> >
> > frobnicate();  // this is accepted
> > // this is an error
>
>
> That is a bug in nxstyle.c and should be fixed. Please file an issue or, if
> you're inclined, open a PR...
>
> This is perfectly legal C99. That's 20+ years ago and was widely accepted
> > before then.
>
>
> That's true; however this standard and code style are well established in
> this project; of course anyone can feel free to open a [DISCUSS] thread to
> propose changes but the onus is obviously on them to persuade the community
> why it should make those changes.
>
> I see // comments in 48 *.[ch] files. That ship has sailed.
>
>
> That, too, is a bug and should be fixed.
>
> So I've kicked that back in, but it appears I have to wait for a (gasp)
> > human
> > to push a button. I assume this is to stop script kiddies from submitting
> > bitcoin
> > harvesters in the presubmit, but it really hoses a workflow as it's like
> > submitting
> > a box of punched cards across the table into the Holy Room where
> computing
> > is done and then awaiting a stack of greenbar with the results later in
> the
> > day.
>
>
> Yes, it's to stop script kiddies with their mining businesses; however IIRC
> that only applies to your first PR with a project. I think once your PR
> gets merged the next one will go more swiftly.
>
> Hopefully, you're convinced I'm an actual human at this point (even if I
> > complain
> > too much :-)
>
>
> Nope. I'm not convinced. :-p
>
> Jokes aside your participation is greatly appreciated.
>
> Cheers,
> Nathan
>

Re: Podling Nuttx Report Reminder - August 2021

[Abdelatif Guettouche]

The biggest hardle we had was licenses.  Alin has made significant progress
and converted most of what can be converted (maybe all).  What we need to
do before graduation now is having a release without the WIP Disclaimer.

On Sun, Aug 1, 2021, 05:36 Nathan Hartman  wrote:

> Hi all,
>
> As we discussed after the previous report, it's time to start checking the
> box for "Nearing Graduation" so this is a fitting time to start talking
> about what issues remain to be solved to prepare for a formal DISCUSS/VOTE
> and incubator vote to graduate and become a Top Level Project.
>
> Meanwhile, I'll start preparing the report in the CWIKI as I've done until
> now, with the only change from before being to check that box.
>
> Here's to a successful graduation process!!
>
> Cheers,
> Nathan
>
>
> On Sun, Aug 1, 2021 at 12:24 AM  wrote:
>
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 18 August 2021.
> > The report for your podling will form a part of the Incubator PMC
> > report. The Incubator PMC requires your report to be submitted 2 weeks
> > before the board meeting, to allow sufficient time for review and
> > submission (Wed, August 04).
> >
> > Please submit your report with sufficient time to allow the Incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Candidate names should not be made public before people are actually
> > elected, so please do not include the names of potential committers or
> > PPMC members in your report.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> > *   How does the podling rate their own maturity.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > https://cwiki.apache.org/confluence/display/INCUBATOR/August2021
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Note: The format of the report has changed to use markdown.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
> >
>

Re: ./tools/configure.sh | find -L | to follow symlinks

[Abdelatif Guettouche]

What's the reason for symlinking the custom board to the in-tree
boards/ folder?  The configuration script accepts a relative path to a
custom location.

On Tue, Aug 3, 2021 at 9:56 AM Simon Filgis
 wrote:
>
> Dear all,
>
> I have my own board assembled with Atmel SAME70 and I would like to work on
> the board files "outside" the nuttix structure in a separate folder
> (custom_board). Now I symlinked my custom_board folder into nuttx:
>
> cd ../nuttx/boards/arm/samv7
> > ln -s ../../../../custom_board/ custom_board
>
>
> This only works if the find command gets a -L (follow symlinks) in
>
> function dumpcfgs
> > {
> >   configlist=`find -L ${TOPDIR}/boards -name defconfig`
> >   for defconfig in ${configlist}; do
> > config=`dirname ${defconfig} | sed -e "s,${TOPDIR}/boards/,,g"`
> > boardname=`echo ${config} | cut -d'/' -f3`
> > configname=`echo ${config} | cut -d'/' -f5`
> > echo "  ${boardname}:${configname}"
> >   done
> > }
>
>
> Has anybody any concern in adding -L to the find or in general with my
> approach?
>
> Regards,
>
> Simon
>
> Ingenieurbüro-Filgis
> USt-IdNr.: DE305343278

Re: ./tools/configure.sh | find -L | to follow symlinks

[Abdelatif Guettouche]

> Regarding my advice from a few minutes ago. Somebody in
> https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
> complains that
> the process is not working.


That's only when the board is part of a group that has the "common"
directory and the common directory isn't wanted.  So more tweaking was
needed there.
The SAMxx families don't have that, so creating a custom board from
the in-tree boards is straightforward.


On Tue, Aug 3, 2021 at 10:16 AM Maciej Wójcik  wrote:
>
> Regarding my advice from a few minutes ago. Somebody in
> https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
> complains that
> the process is not working.
>
> Just to be sure I will test it today and maybe finish that documentation.
> If I won't, still just try what is described there. I am sorry for the
> inconvenience. It looks a bit complicated, but it is quite simple in the
> end.
>
> Am Di., 3. Aug. 2021 um 10:10 Uhr schrieb Maciej Wójcik :
>
> > In general, you probably don't want to change files in the OS repository
> > just to attach your board.
> >
> > I was supposed to document how to do this correctly, more than a half year
> > ago. I didn't, but what you need is described in this issue
> > https://github.com/apache/incubator-nuttx/issues/2206#issuecomment-721138548
> >
> > The whole idea is to call `./config.sh` with a relative path. Other than
> > this you need to nest your board configuration in particular folder
> > structure. I don't remember exactly, but what is in that issue is correct
> > and supported.
> >
> > Am Di., 3. Aug. 2021 um 09:57 Uhr schrieb Simon Filgis <
> > si...@ingenieurbuero-filgis.de>:
> >
> >> Dear all,
> >>
> >> I have my own board assembled with Atmel SAME70 and I would like to work
> >> on
> >> the board files "outside" the nuttix structure in a separate folder
> >> (custom_board). Now I symlinked my custom_board folder into nuttx:
> >>
> >> cd ../nuttx/boards/arm/samv7
> >> > ln -s ../../../../custom_board/ custom_board
> >>
> >>
> >> This only works if the find command gets a -L (follow symlinks) in
> >>
> >> function dumpcfgs
> >> > {
> >> >   configlist=`find -L ${TOPDIR}/boards -name defconfig`
> >> >   for defconfig in ${configlist}; do
> >> > config=`dirname ${defconfig} | sed -e "s,${TOPDIR}/boards/,,g"`
> >> > boardname=`echo ${config} | cut -d'/' -f3`
> >> > configname=`echo ${config} | cut -d'/' -f5`
> >> > echo "  ${boardname}:${configname}"
> >> >   done
> >> > }
> >>
> >>
> >> Has anybody any concern in adding -L to the find or in general with my
> >> approach?
> >>
> >> Regards,
> >>
> >> Simon
> >>
> >> Ingenieurbüro-Filgis
> >> USt-IdNr.: DE305343278
> >>
> >

Re: not reached any more ?!

[Abdelatif Guettouche]

Please check your board/_path_/src/Makefile and check that your
CONFIG_ are all in the new format, i.e.: CONFIG_LIB_BOARDCTL to
CONFIG_BOARDCTL


On Wed, Aug 11, 2021 at 3:56 PM Simon Filgis
 wrote:
>
> Hi Nathan,
>
> You mean this option?
>
>
> Makes no difference.
>
> I checked all the points in the list of cwiki. I did not miss a single line.
>
> I have attached my board's Kconfig and defconfig file, could you please have 
> a look?
>
> Simon
>
>
>
> On Wed, Aug 11, 2021 at 3:03 PM Nathan Hartman  
> wrote:
>>
>> On Wed, Aug 11, 2021 at 8:32 AM Nathan Hartman 
>> wrote:
>>
>> > On Wed, Aug 11, 2021 at 8:28 AM Simon Filgis <
>> > si...@ingenieurbuero-filgis.de> wrote:
>> >
>> >> Dear all,
>> >>
>> >> since yesterday's upstream fetch, my custom board is not working any more.
>> >>
>> >> Basically it is a copy of same70_explained:nsh ...
>> >>
>> >> ADC, CAN, ETHERNET is not any more in /dev/
>> >> nsh is prompting fine...
>> >>
>> >> board_app_initialize() is not called any more.
>> >>
>> >> I think it has something to do with the following commit: Rename
>> >> CONFIG_LIB_BOARDCTL to CONFIG_BOARDCTL.
>> >>
>> >> Does somebody have a hint where to search?
>> >>
>> >> Simon
>> >
>> >
>> >
>> > Yes. That Kconfig was renamed so your board's Kconfig needs to be updated
>> > to the new name.
>> >
>> > You can run make menuconfig and enable BOARDCTL, then run make
>> > savedefconfig and copy the defconfig file from nuttx/ to your board's
>> > config directiry.
>> >
>> > It's documented in the release notes on CWIKI, let me find the link...
>> >
>> >
>> Since this hasn't been released yet it's in the work in progress release
>> notes:
>>
>> Under "changes to Kconfig":
>> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2
>>
>> (If you're on mobile you may need to request the desktop version.)
>>
>> Cheers,
>> Nathan

Re: nxfss on MT25Q nor flash

[Abdelatif Guettouche]

> but I can't find the way to either mount it, or "probe" it, or anything,
from nuttx.


The sequence to initialise the flash and mount NXFFS should look like the
following (to be adapted for chip and device):

spi = stm32_spibus_initialize(1);
  if (!spi)
{
  ferr("ERROR: Failed to initialize SPI port 2\n");
  return -ENODEV;
}

  mtd = w25_initialize(spi);
  if (!mtd)
{
  ferr("ERROR: Failed to bind SPI port 2 to the SST 25 FLASH driver\n");
  return -ENODEV;
}

  ret = nxffs_initialize(mtd);
  if (ret < 0)
{
  ferr("ERROR: NXFFS initialization failed: %d\n", -ret);
  return ret;
}

ret = nx_mount(NULL, "/mnt", "nxffs", 0, NULL);
 if (ret < 0)
   {
   ret = nx_mount(NULL, "/mnt", "nxffs", 0, "forceformat");
   if (ret < 0)
 {
 ferr("ERROR: Failed to mount the FS volume: %d\n", errno);
return ret;
  }
   }


On Tue, Aug 24, 2021 at 6:39 PM Tim  wrote:

> Hi Alan,
>
> >Hi Tim,
> >
> >On 8/24/21, Tim  wrote:
> >>
> >>>Then before try to setup the NXFFS you need to confirm that the Flash
> >>>NOR  was detected correctly.
> >>
> >> How, in code or from the nsh, do I do that? I know the chip works as
> >> I've used it (for example) for u-boot environment variables with no
> >> issue, but I can't find the way to either mount it, or "probe" it, or
> >> anything, from nuttx. It doesn’t appear as a /dev.
> >>
> >
> >You can enable the CONFIG_DEBUG_FS_* to see the mtd debug messages. It
> will
> >tell you want is going on.
> >
> Yes, I have done that of course, but get no messages. I am sure this is
> simply because there is no code being called to register the driver as I
> can't find an example for any other boards that looks relevant :(
>
>

Re: nxfss on MT25Q nor flash

[Abdelatif Guettouche]

BTW, do we have a driver for MT25Q? I can't see one.  Is it compatible with
the M25P series?

On Tue, Aug 24, 2021 at 5:50 PM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> > but I can't find the way to either mount it, or "probe" it, or anything,
> from nuttx.
>
>
> The sequence to initialise the flash and mount NXFFS should look like the
> following (to be adapted for chip and device):
>
> spi = stm32_spibus_initialize(1);
>   if (!spi)
> {
>   ferr("ERROR: Failed to initialize SPI port 2\n");
>   return -ENODEV;
> }
>
>   mtd = w25_initialize(spi);
>   if (!mtd)
> {
>   ferr("ERROR: Failed to bind SPI port 2 to the SST 25 FLASH
> driver\n");
>   return -ENODEV;
> }
>
>   ret = nxffs_initialize(mtd);
>   if (ret < 0)
> {
>   ferr("ERROR: NXFFS initialization failed: %d\n", -ret);
>   return ret;
> }
>
> ret = nx_mount(NULL, "/mnt", "nxffs", 0, NULL);
>  if (ret < 0)
>{
>ret = nx_mount(NULL, "/mnt", "nxffs", 0, "forceformat");
>if (ret < 0)
>  {
>  ferr("ERROR: Failed to mount the FS volume: %d\n", errno);
> return ret;
>   }
>}
>
>
> On Tue, Aug 24, 2021 at 6:39 PM Tim  wrote:
>
>> Hi Alan,
>>
>> >Hi Tim,
>> >
>> >On 8/24/21, Tim  wrote:
>> >>
>> >>>Then before try to setup the NXFFS you need to confirm that the Flash
>> >>>NOR  was detected correctly.
>> >>
>> >> How, in code or from the nsh, do I do that? I know the chip works as
>> >> I've used it (for example) for u-boot environment variables with no
>> >> issue, but I can't find the way to either mount it, or "probe" it, or
>> >> anything, from nuttx. It doesn’t appear as a /dev.
>> >>
>> >
>> >You can enable the CONFIG_DEBUG_FS_* to see the mtd debug messages. It
>> will
>> >tell you want is going on.
>> >
>> Yes, I have done that of course, but get no messages. I am sure this is
>> simply because there is no code being called to register the driver as I
>> can't find an example for any other boards that looks relevant :(
>>
>>

Re: Briki board

[Abdelatif Guettouche]

> How difficult should be the porting of the ESP32 processor to NuttX? It
is possible to use one of the Expressif configurations?

Yes it is possible.  Most of the configurations should work on any board.
For special configs, if there is an external device required, then
that has to be there of course.
One other thing to note, is the different modules, this would affect
the presence or not of a PSRAM, its size and the size of the flash.

BTW the ESP32-D0WD is somewhat old and not recommended for new
designs.  Better use the ESP32-D0WD-V3.


On Wed, Aug 25, 2021 at 10:56 AM Roberto Bucher  wrote:
>
> Sorry, but in copy and paste I've lost the figure...
>
>
>
> BR
>
> Roberto
>
> On 8/25/21 10:53 AM, Roberto Bucher wrote:
>
> Hi
>
> we have this little board (www.briki.org)
>
>
> with 2 different cores:
>
> MBC-WB01-BPN:
> SAMD211 – ESP322 – EXT 64 Mbit flash3 – PCB Antenna4 – No Crypto5
>
> SAMD211: ATSAMD21G18A ARM® Cortex®-M0+
> ESP32: ESP32-D0WD dual-core Tensilica Xtensa LX6 running @240MHz
>
> How difficult should be the porting of the ESP32 processor to NuttX? It is 
> possible to use one of the Expressif configurations? What about the 
> ATSAMD21G18A board?
>
> Thanks in advance!
>
>

Re: How SPI Chip Select Number (CSn) works?

[Abdelatif Guettouche]

>  How, multiple slave devices can be used in this situation?

You can define as many CS pins as you need in your board logic.  Then
in the corresponding spiXselect function, you enable the correct slave
based on its ID.

On Thu, Sep 30, 2021 at 8:47 AM murat tologlu  wrote:
>
> Hi,
>
> I am trying to implement a master-slave SPI configuration with multiple slave 
> devices on a single SPI bus.
>
> For this purpose I wanted to play with apps/system/spi/ SPI Tool to 
> experiment and understand how multiple slave devices can be configured on a 
> single bus in Nuttx, and a question occured:  In SPI configurations I have 
> seen in Nuttx so far, there is only a single CS pin number defined and this 
> corresponds to a single device. How, multiple slave devices can be used in 
> this situation?
>
> In SPI Tool the default value of uint32_t CSn is 0,  today I will make some 
> experiments and research to find-out my own answer but I'll also appreciate 
> having your comments about what happens if I chose CSn = 1,2,3.. , what is 
> the relation between this parameter and the actual hardware? I also wander 
> the effect of SPI devtype parameter.
>
> Thanks and best regards,
> Murat

Re: ESP32-C3 RISC-V

[Abdelatif Guettouche]

> When is next release planned with ESP32-C3 already included?

NuttX 10.1.0 already includes support for ESP32-C3 with a fair amount
of drivers including Wifi.  BLE is on master however, and will be part
of the next release.

On Fri, Oct 8, 2021 at 6:26 AM Tomasz CEDRO  wrote:
>
> On Fri, Oct 8, 2021 at 5:33 AM Takashi Yamamoto wrote:
> > > I can see some "bashisms" in the shell scripts, did you consider using
> > > raw /bin/sh or is it too much work and `bash` is the best way already?
> > > I am asking because on Linux `/bin/sh` is `/bin/bash` while on BSD
> > > `/bin/sh` is /bin/sh` while `bash` is the optional package :-)
> >
> > i consider using bash-only features in a script with /bin/sh shebang is a 
> > bug.
> > please feel free to contribute patches, either to avoid bashism or to
> > fix shebang.
>
> Hello Takashi :-)
>
> I saw in README.md this was already mentioned. Most scripts now are
> properly called with `#!/usr/bin/env bash` so no problem (there are
> still some `#!/bin/sh` left only in `boards/arm/lpc17xx_40xx`). I
> guess additional bash features are required then.
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: NuttX-10.2 release

[Abdelatif Guettouche]

Hi,

I'm trying to use https://github.com/btashton/nxutils to generate the
board. (https://github.com/apache/incubator-nuttx/projects/10).  Due
to Github's rate limiting I was not able to generate all the PRs since
the last release. I'm not sure if there is a trick to that or we have
to add what's missing manually (about a hundred).



On Mon, Oct 11, 2021 at 8:59 AM  wrote:
>
> Hello all
> According to the proposed plan I will create the 10.2 branches today
>
> @Brennan Ashton @Nathan Hartman @Abdelatif Guettouche
> Can you please generate the RAW release notes so that I can continue
>
> Thanks
> Alin
>
> -Original Message-
> From: Alin Jerpelea 
> Sent: den 4 oktober 2021 08:37
> To: dev@nuttx.apache.org
> Subject: Re: NuttX-10.2 release
>
> since none opposed to the release here my proposal for the release schedule:
>
>   w40 -- Master Stability Window (keep the merging of risky PRs to a minimum 
> this week)
>   W41.1 -- Create the 10.2 release branch
>   w41-42 -- Stabilize / test / release notes
>   w43.1 -- Tag RC0 and call for PPMC / Community Vote
>   w44(or when we have the votes) Call for IPMC Vote
>   w45 -- Update site and announce (we have to wait for download mirrors to 
> sync).
>
>
> On Thu, Sep 30, 2021 at 9:57 AM  wrote:
>
> > Hi,
> >
> > Our latest release 10.1 was on 2021-05-26.
> >
> > I think that is time to create the branches and the release notes.
> >
> > @Brennan Ashton<mailto:bash...@brennanashton.com> can you please
> > create the draft release notes
> >
> > I offer to be the release manager for this release
> >
> > Best regards
> > Alin
> >
> >

Re: NuttX-10.2 release

[Abdelatif Guettouche]

> I'm not sure if there is a trick to that or we have
to add what's missing manually (about a hundred).

The script is adding 750 now, it will take a few minutes.

On Mon, Oct 11, 2021 at 10:09 AM Abdelatif Guettouche
 wrote:
>
> Hi,
>
> I'm trying to use https://github.com/btashton/nxutils to generate the
> board. (https://github.com/apache/incubator-nuttx/projects/10).  Due
> to Github's rate limiting I was not able to generate all the PRs since
> the last release. I'm not sure if there is a trick to that or we have
> to add what's missing manually (about a hundred).
>
>
>
> On Mon, Oct 11, 2021 at 8:59 AM  wrote:
> >
> > Hello all
> > According to the proposed plan I will create the 10.2 branches today
> >
> > @Brennan Ashton @Nathan Hartman @Abdelatif Guettouche
> > Can you please generate the RAW release notes so that I can continue
> >
> > Thanks
> > Alin
> >
> > -Original Message-
> > From: Alin Jerpelea 
> > Sent: den 4 oktober 2021 08:37
> > To: dev@nuttx.apache.org
> > Subject: Re: NuttX-10.2 release
> >
> > since none opposed to the release here my proposal for the release schedule:
> >
> >   w40 -- Master Stability Window (keep the merging of risky PRs to a 
> > minimum this week)
> >   W41.1 -- Create the 10.2 release branch
> >   w41-42 -- Stabilize / test / release notes
> >   w43.1 -- Tag RC0 and call for PPMC / Community Vote
> >   w44(or when we have the votes) Call for IPMC Vote
> >   w45 -- Update site and announce (we have to wait for download mirrors to 
> > sync).
> >
> >
> > On Thu, Sep 30, 2021 at 9:57 AM  wrote:
> >
> > > Hi,
> > >
> > > Our latest release 10.1 was on 2021-05-26.
> > >
> > > I think that is time to create the branches and the release notes.
> > >
> > > @Brennan Ashton<mailto:bash...@brennanashton.com> can you please
> > > create the draft release notes
> > >
> > > I offer to be the release manager for this release
> > >
> > > Best regards
> > > Alin
> > >
> > >

Re: NuttX-10.2 release

[Abdelatif Guettouche]

Ok, everything should be there.  Once the biggest chunk was added I
ran it again on the smaller one.

On Mon, Oct 11, 2021 at 10:12 AM Abdelatif Guettouche
 wrote:
>
> > I'm not sure if there is a trick to that or we have
> to add what's missing manually (about a hundred).
>
> The script is adding 750 now, it will take a few minutes.
>
> On Mon, Oct 11, 2021 at 10:09 AM Abdelatif Guettouche
>  wrote:
> >
> > Hi,
> >
> > I'm trying to use https://github.com/btashton/nxutils to generate the
> > board. (https://github.com/apache/incubator-nuttx/projects/10).  Due
> > to Github's rate limiting I was not able to generate all the PRs since
> > the last release. I'm not sure if there is a trick to that or we have
> > to add what's missing manually (about a hundred).
> >
> >
> >
> > On Mon, Oct 11, 2021 at 8:59 AM  wrote:
> > >
> > > Hello all
> > > According to the proposed plan I will create the 10.2 branches today
> > >
> > > @Brennan Ashton @Nathan Hartman @Abdelatif Guettouche
> > > Can you please generate the RAW release notes so that I can continue
> > >
> > > Thanks
> > > Alin
> > >
> > > -Original Message-
> > > From: Alin Jerpelea 
> > > Sent: den 4 oktober 2021 08:37
> > > To: dev@nuttx.apache.org
> > > Subject: Re: NuttX-10.2 release
> > >
> > > since none opposed to the release here my proposal for the release 
> > > schedule:
> > >
> > >   w40 -- Master Stability Window (keep the merging of risky PRs to a 
> > > minimum this week)
> > >   W41.1 -- Create the 10.2 release branch
> > >   w41-42 -- Stabilize / test / release notes
> > >   w43.1 -- Tag RC0 and call for PPMC / Community Vote
> > >   w44(or when we have the votes) Call for IPMC Vote
> > >   w45 -- Update site and announce (we have to wait for download mirrors 
> > > to sync).
> > >
> > >
> > > On Thu, Sep 30, 2021 at 9:57 AM  wrote:
> > >
> > > > Hi,
> > > >
> > > > Our latest release 10.1 was on 2021-05-26.
> > > >
> > > > I think that is time to create the branches and the release notes.
> > > >
> > > > @Brennan Ashton<mailto:bash...@brennanashton.com> can you please
> > > > create the draft release notes
> > > >
> > > > I offer to be the release manager for this release
> > > >
> > > > Best regards
> > > > Alin
> > > >
> > > >

Re: NuttX-10.2 release

[Abdelatif Guettouche]

> Is there a tool to migrate the notes from github to cwiki?

Do you mean from Confluence to Github (i.e. ReleaseNotes file)?  If
so, no there isn't.  One thing we can do is to change the syntax to
Markdown so we can just copy/paste.

BTW, regarding the changes documented in  Confluence, this:
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2#changes-to-build-system
has been reverted.  Or at least part of it if I recall correctly.

On Tue, Oct 12, 2021 at 9:16 AM  wrote:
>
> Hi Nathan
>
>
>
> Is there a tool to migrate the notes from github to cwiki?
>
>
>
> Thanks
>
> Alin
>
>
>
>
>
> From: Nathan Hartman 
> Sent: den 12 oktober 2021 06:14
> To: Jerpelea, Alin 
> Cc: abdelatif.guettou...@gmail.com; bash...@brennanashton.com; 
> dev@nuttx.apache.org
> Subject: Re: NuttX-10.2 release
>
>
>
> Please note, there is already a draft Release Notes page at the following 
> link. Commits that required compatibility changes are already documented 
> there:
>
>
>
> https://cwiki.apache.org/confluence/display/NUTTX/NuttX+10.2
>
>
>
>
>
> On Mon, Oct 11, 2021 at 2:59 AM  wrote:
>
> Hello all
> According to the proposed plan I will create the 10.2 branches today
>
> @Brennan Ashton @Nathan Hartman @Abdelatif Guettouche
> Can you please generate the RAW release notes so that I can continue
>
> Thanks
> Alin
>
> -Original Message-
> From: Alin Jerpelea 
> Sent: den 4 oktober 2021 08:37
> To: dev@nuttx.apache.org
> Subject: Re: NuttX-10.2 release
>
> since none opposed to the release here my proposal for the release schedule:
>
>   w40 -- Master Stability Window (keep the merging of risky PRs to a minimum 
> this week)
>   W41.1 -- Create the 10.2 release branch
>   w41-42 -- Stabilize / test / release notes
>   w43.1 -- Tag RC0 and call for PPMC / Community Vote
>   w44(or when we have the votes) Call for IPMC Vote
>   w45 -- Update site and announce (we have to wait for download mirrors to 
> sync).
>
>
> On Thu, Sep 30, 2021 at 9:57 AM  wrote:
>
> > Hi,
> >
> > Our latest release 10.1 was on 2021-05-26.
> >
> > I think that is time to create the branches and the release notes.
> >
> > @Brennan Ashton<mailto:bash...@brennanashton.com> can you please
> > create the draft release notes
> >
> > I offer to be the release manager for this release
> >
> > Best regards
> > Alin
> >
> >

Re: NuttX-10.2 release

[Abdelatif Guettouche]

You mean we drop the ReleaseNote file?

We do need to have the notes versioned with the rest of the code.
What was suggested before is to use Markdown for both Confluence and
ReleaseNote and then it's just a matter of copy/paste.
What also can be done to make it easy, is to only keep the latest
release notes on the top level file.  One could checkout to a specific
release branch to inspect the release notes.
I think a few didn't agree with this and argued that we need all the
release notes, I guess in this case we can move the old release notes
to a releasenotes.d folder of some sort.  For me keeping all the
release notes in one file is getting hard to maintain, and we need to
do something about it.

On Tue, Oct 12, 2021 at 10:37 AM  wrote:
>
> I propose that we work on wiki to create the release notes
> What do you say?
>
> Thanks
> Alin
>
>
> -Original Message-
> From: Abdelatif Guettouche 
> Sent: den 12 oktober 2021 09:22
> To: Jerpelea, Alin 
> Cc: Nathan Hartman ; Brennan Ashton 
> ; dev@nuttx.apache.org
> Subject: Re: NuttX-10.2 release
>
> > Is there a tool to migrate the notes from github to cwiki?
>
> Do you mean from Confluence to Github (i.e. ReleaseNotes file)?  If so, no 
> there isn't.  One thing we can do is to change the syntax to Markdown so we 
> can just copy/paste.
>
> BTW, regarding the changes documented in  Confluence, this:
> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/NUTTX/NuttX*10.2*changes-to-build-system__;KyM!!JmoZiZGBv3RvKRSx!tJy3l96vFgH7-sGLU_8t8T8fRPm4IUGy5hIS8KhNRfjNiIE9NJoapeDV14m-LWStzw$
> has been reverted.  Or at least part of it if I recall correctly.
>
> On Tue, Oct 12, 2021 at 9:16 AM  wrote:
> >
> > Hi Nathan
> >
> >
> >
> > Is there a tool to migrate the notes from github to cwiki?
> >
> >
> >
> > Thanks
> >
> > Alin
> >
> >
> >
> >
> >
> > From: Nathan Hartman 
> > Sent: den 12 oktober 2021 06:14
> > To: Jerpelea, Alin 
> > Cc: abdelatif.guettou...@gmail.com; bash...@brennanashton.com;
> > dev@nuttx.apache.org
> > Subject: Re: NuttX-10.2 release
> >
> >
> >
> > Please note, there is already a draft Release Notes page at the following 
> > link. Commits that required compatibility changes are already documented 
> > there:
> >
> >
> >
> > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/displa
> > y/NUTTX/NuttX*10.2__;Kw!!JmoZiZGBv3RvKRSx!tJy3l96vFgH7-sGLU_8t8T8fRPm4
> > IUGy5hIS8KhNRfjNiIE9NJoapeDV14nZ0Kzw0w$
> >
> >
> >
> >
> >
> > On Mon, Oct 11, 2021 at 2:59 AM  wrote:
> >
> > Hello all
> > According to the proposed plan I will create the 10.2 branches today
> >
> > @Brennan Ashton @Nathan Hartman @Abdelatif Guettouche Can you please
> > generate the RAW release notes so that I can continue
> >
> > Thanks
> > Alin
> >
> > -Original Message-
> > From: Alin Jerpelea 
> > Sent: den 4 oktober 2021 08:37
> > To: dev@nuttx.apache.org
> > Subject: Re: NuttX-10.2 release
> >
> > since none opposed to the release here my proposal for the release schedule:
> >
> >   w40 -- Master Stability Window (keep the merging of risky PRs to a 
> > minimum this week)
> >   W41.1 -- Create the 10.2 release branch
> >   w41-42 -- Stabilize / test / release notes
> >   w43.1 -- Tag RC0 and call for PPMC / Community Vote
> >   w44(or when we have the votes) Call for IPMC Vote
> >   w45 -- Update site and announce (we have to wait for download mirrors to 
> > sync).
> >
> >
> > On Thu, Sep 30, 2021 at 9:57 AM  wrote:
> >
> > > Hi,
> > >
> > > Our latest release 10.1 was on 2021-05-26.
> > >
> > > I think that is time to create the branches and the release notes.
> > >
> > > @Brennan Ashton<mailto:bash...@brennanashton.com> can you please
> > > create the draft release notes
> > >
> > > I offer to be the release manager for this release
> > >
> > > Best regards
> > > Alin
> > >
> > >

Re: github nuttx/nuttx vs apache/incubator-nuttx

[Abdelatif Guettouche]

People who have admin access to that org are all committers/PPMC members.
If we want to take it down we can do that.
As Greg mentioned earlier, that was supposed to host GPL repos and the os
and apps version there are outdated.

On Sat, Oct 16, 2021, 16:53 Tomasz CEDRO  wrote:

> I have contacted GitHub support in that matter. Maybe taking ownership
> of that org / repo will be possible.
> Tomek
>
> On Sat, Oct 16, 2021 at 4:39 PM Gregory Nutt  wrote:
> >
> > The project never was at that location, https://github.com/NuttX.
> > Everything there is of uncertain lineage and uncertain and should just be
> > removed or converted to mirrors.
> >
> > Prior to moving to https://github.com/apache/incubator-nuttx*, the
> project
> > was on bitbucket at https://bitbucket.org/nuttx/.  The remaining
> > repositories there are the only ones that need to be retained.
> >
> >
> > On Sat, Oct 16, 2021 at 8:27 AM Tomasz CEDRO  wrote:
> >
> > > Maybe you could re-gain access Gregory manage users and put it in an
> > > "archived state" with a note that the project moved to Apache
> > > organization? :-)
> > >
> > > That way nothing will be deleted, while note on new upstream will
> > > redirect users to a new place decreasing confusion.
> > >
> > > There is a chance that someone still may want to use current
> > > repository, or you may want to use it in future in that case
> > > "archiving" will prevent name / ownership takeover.
> > >
> > > Regarding kconfig-frontends I am in touch with Espressif and Debian
> > > maintainers, also contacted initial author Yann MORIN. Maybe putting
> > > this package into the Apache organization would be a good idea if
> > > possible..?
> > >
> > > Thanks :-)
> > > Tomek
> > >
> > >
> > > On Sat, Oct 16, 2021 at 4:11 PM Gregory Nutt 
> wrote:
> > > >
> > > > No, https://github.com/NuttX/nuttx is just garbage and should be
> > > deleted.
> > > > It has nothing to do with Apache NuttX and I don't think anything has
> > > been
> > > > touched there in months.
> > > >
> > > > A thought was that this could be a place to keep GPL tools and
> > > applications
> > > > that are needed with NuttX but that are incompatible with the ASF
> > > project.
> > > > This is where a tool like kconfig-frontends could be supported,
> > > >
> > > > A problem now is that many people have access to the repository and
> it is
> > > > not under the control of any project.
> > > >
> > > >
> > > > On Sat, Oct 16, 2021 at 7:53 AM Tomasz CEDRO 
> wrote:
> > > >
> > > > > Hello world :-)
> > > > >
> > > > > Another thing I found confusing a bit for a newcomer is the dual
> > > > > repository model:
> > > > > 1. https://github.com/NuttX/nuttx
> > > > > 2. https://github.com/apache/incubator-nuttx
> > > > >
> > > > > There is not information or redirect on 1 that development takes
> place
> > > on
> > > > > 2.
> > > > >
> > > > > Is 2 going to become 1 back again when incubation is complete? :-)
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > >
> > >
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
>
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: github nuttx/nuttx vs apache/incubator-nuttx

[Abdelatif Guettouche]

I can access it and deleting it is a click away (provided that Github
doesn't ask for every members approval)

On Sat, Oct 16, 2021 at 5:17 PM Gregory Nutt  wrote:
>
> I just tried accessing github.com/nuttx and it appears that I can no longer
> see project information.  I don't know what is going on with those
> repositories.
>
> On Sat, Oct 16, 2021 at 9:09 AM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > People who have admin access to that org are all committers/PPMC members.
> > If we want to take it down we can do that.
> > As Greg mentioned earlier, that was supposed to host GPL repos and the os
> > and apps version there are outdated.
> >
> > On Sat, Oct 16, 2021, 16:53 Tomasz CEDRO  wrote:
> >
> > > I have contacted GitHub support in that matter. Maybe taking ownership
> > > of that org / repo will be possible.
> > > Tomek
> > >
> > > On Sat, Oct 16, 2021 at 4:39 PM Gregory Nutt 
> > wrote:
> > > >
> > > > The project never was at that location, https://github.com/NuttX.
> > > > Everything there is of uncertain lineage and uncertain and should just
> > be
> > > > removed or converted to mirrors.
> > > >
> > > > Prior to moving to https://github.com/apache/incubator-nuttx*, the
> > > project
> > > > was on bitbucket at https://bitbucket.org/nuttx/.  The remaining
> > > > repositories there are the only ones that need to be retained.
> > > >
> > > >
> > > > On Sat, Oct 16, 2021 at 8:27 AM Tomasz CEDRO  wrote:
> > > >
> > > > > Maybe you could re-gain access Gregory manage users and put it in an
> > > > > "archived state" with a note that the project moved to Apache
> > > > > organization? :-)
> > > > >
> > > > > That way nothing will be deleted, while note on new upstream will
> > > > > redirect users to a new place decreasing confusion.
> > > > >
> > > > > There is a chance that someone still may want to use current
> > > > > repository, or you may want to use it in future in that case
> > > > > "archiving" will prevent name / ownership takeover.
> > > > >
> > > > > Regarding kconfig-frontends I am in touch with Espressif and Debian
> > > > > maintainers, also contacted initial author Yann MORIN. Maybe putting
> > > > > this package into the Apache organization would be a good idea if
> > > > > possible..?
> > > > >
> > > > > Thanks :-)
> > > > > Tomek
> > > > >
> > > > >
> > > > > On Sat, Oct 16, 2021 at 4:11 PM Gregory Nutt 
> > > wrote:
> > > > > >
> > > > > > No, https://github.com/NuttX/nuttx is just garbage and should be
> > > > > deleted.
> > > > > > It has nothing to do with Apache NuttX and I don't think anything
> > has
> > > > > been
> > > > > > touched there in months.
> > > > > >
> > > > > > A thought was that this could be a place to keep GPL tools and
> > > > > applications
> > > > > > that are needed with NuttX but that are incompatible with the ASF
> > > > > project.
> > > > > > This is where a tool like kconfig-frontends could be supported,
> > > > > >
> > > > > > A problem now is that many people have access to the repository and
> > > it is
> > > > > > not under the control of any project.
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 16, 2021 at 7:53 AM Tomasz CEDRO 
> > > wrote:
> > > > > >
> > > > > > > Hello world :-)
> > > > > > >
> > > > > > > Another thing I found confusing a bit for a newcomer is the dual
> > > > > > > repository model:
> > > > > > > 1. https://github.com/NuttX/nuttx
> > > > > > > 2. https://github.com/apache/incubator-nuttx
> > > > > > >
> > > > > > > There is not information or redirect on 1 that development takes
> > > place
> > > > > on
> > > > > > > 2.
> > > > > > >
> > > > > > > Is 2 going to become 1 back again when incubation is complete?
> > :-)
> > > > > > >
> > > > > > > --
> > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > >
> > >
> > >
> > >
> > > --
> > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > >
> >

Re: github nuttx/nuttx vs apache/incubator-nuttx

[Abdelatif Guettouche]

BTW the version of the OS we have there, is _very_ old.  The description says:

> This is an old snapshot of NuttX from when arch/, configs/, and 
> Documentation/ were submodules

On Sat, Oct 16, 2021 at 5:43 PM Abdelatif Guettouche
 wrote:
>
> I can access it and deleting it is a click away (provided that Github
> doesn't ask for every members approval)
>
> On Sat, Oct 16, 2021 at 5:17 PM Gregory Nutt  wrote:
> >
> > I just tried accessing github.com/nuttx and it appears that I can no longer
> > see project information.  I don't know what is going on with those
> > repositories.
> >
> > On Sat, Oct 16, 2021 at 9:09 AM Abdelatif Guettouche <
> > abdelatif.guettou...@gmail.com> wrote:
> >
> > > People who have admin access to that org are all committers/PPMC members.
> > > If we want to take it down we can do that.
> > > As Greg mentioned earlier, that was supposed to host GPL repos and the os
> > > and apps version there are outdated.
> > >
> > > On Sat, Oct 16, 2021, 16:53 Tomasz CEDRO  wrote:
> > >
> > > > I have contacted GitHub support in that matter. Maybe taking ownership
> > > > of that org / repo will be possible.
> > > > Tomek
> > > >
> > > > On Sat, Oct 16, 2021 at 4:39 PM Gregory Nutt 
> > > wrote:
> > > > >
> > > > > The project never was at that location, https://github.com/NuttX.
> > > > > Everything there is of uncertain lineage and uncertain and should just
> > > be
> > > > > removed or converted to mirrors.
> > > > >
> > > > > Prior to moving to https://github.com/apache/incubator-nuttx*, the
> > > > project
> > > > > was on bitbucket at https://bitbucket.org/nuttx/.  The remaining
> > > > > repositories there are the only ones that need to be retained.
> > > > >
> > > > >
> > > > > On Sat, Oct 16, 2021 at 8:27 AM Tomasz CEDRO  wrote:
> > > > >
> > > > > > Maybe you could re-gain access Gregory manage users and put it in an
> > > > > > "archived state" with a note that the project moved to Apache
> > > > > > organization? :-)
> > > > > >
> > > > > > That way nothing will be deleted, while note on new upstream will
> > > > > > redirect users to a new place decreasing confusion.
> > > > > >
> > > > > > There is a chance that someone still may want to use current
> > > > > > repository, or you may want to use it in future in that case
> > > > > > "archiving" will prevent name / ownership takeover.
> > > > > >
> > > > > > Regarding kconfig-frontends I am in touch with Espressif and Debian
> > > > > > maintainers, also contacted initial author Yann MORIN. Maybe putting
> > > > > > this package into the Apache organization would be a good idea if
> > > > > > possible..?
> > > > > >
> > > > > > Thanks :-)
> > > > > > Tomek
> > > > > >
> > > > > >
> > > > > > On Sat, Oct 16, 2021 at 4:11 PM Gregory Nutt 
> > > > wrote:
> > > > > > >
> > > > > > > No, https://github.com/NuttX/nuttx is just garbage and should be
> > > > > > deleted.
> > > > > > > It has nothing to do with Apache NuttX and I don't think anything
> > > has
> > > > > > been
> > > > > > > touched there in months.
> > > > > > >
> > > > > > > A thought was that this could be a place to keep GPL tools and
> > > > > > applications
> > > > > > > that are needed with NuttX but that are incompatible with the ASF
> > > > > > project.
> > > > > > > This is where a tool like kconfig-frontends could be supported,
> > > > > > >
> > > > > > > A problem now is that many people have access to the repository 
> > > > > > > and
> > > > it is
> > > > > > > not under the control of any project.
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Oct 16, 2021 at 7:53 AM Tomasz CEDRO 
> > > > wrote:
> > > > > > >
> > > > > > > > Hello world :-)
> > > > > > > >
> > > > > > > > Another thing I found confusing a bit for a newcomer is the dual
> > > > > > > > repository model:
> > > > > > > > 1. https://github.com/NuttX/nuttx
> > > > > > > > 2. https://github.com/apache/incubator-nuttx
> > > > > > > >
> > > > > > > > There is not information or redirect on 1 that development takes
> > > > place
> > > > > > on
> > > > > > > > 2.
> > > > > > > >
> > > > > > > > Is 2 going to become 1 back again when incubation is complete?
> > > :-)
> > > > > > > >
> > > > > > > > --
> > > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> > > >
> > >

Re: ESP32-C3 RISC-V

[Abdelatif Guettouche]

> I could not find detailed information on how to setup RISC-V toolchain
except just using "generic toolchain":
https://nuttx.apache.org/docs/latest/platforms/risc-v/esp32c3/index.html

There is a link there to download the toolchain used, here:
https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14.tar.gz
You can download the file, untar it and add the location to the PATH.

On Sat, Oct 16, 2021 at 6:04 PM Tomasz CEDRO  wrote:
>
> Allright, except for the FreeBSD works, I would like to have a working
>  reference point based on Linux Debian 10.10, so I have created a VM.
>
> I could not find detailed information on how to setup RISC-V toolchain
> except just using "generic toolchain":
> https://nuttx.apache.org/docs/latest/platforms/risc-v/esp32c3/index.html
>
> So I have installed pre-built generic toolchain according to Debian Wiki:
> https://wiki.debian.org/RISC-V#Pre-built_toolchains
>
> I have configured ESP32-C3 target with:
> ./tools/configure.sh esp32c3-devkit:ble
>
> Then during `make` it seems that `esp32c3-devkit` requires different 
> toolchain?
>
> $ make
> Create .version
> Create version.h
> make[1]: Entering directory '/home/user/work/nuttx/nuttx.git/nuttx/boards'
> make[1]: Nothing to be done for 'dirlinks'.
> make[1]: Leaving directory '/home/user/work/nuttx/nuttx.git/nuttx/boards'
> make[1]: Entering directory '/home/user/work/nuttx/nuttx.git/apps'
> make[2]: Entering directory '/home/user/work/nuttx/nuttx.git/apps/platform'
> LN: platform/board to /home/user/work/nuttx/nuttx.git/apps/platform/dummy
> make[2]: Leaving directory '/home/user/work/nuttx/nuttx.git/apps/platform'
> make[1]: Leaving directory '/home/user/work/nuttx/nuttx.git/apps'
> make[1]: Entering directory '/home/user/work/nuttx/nuttx.git/nuttx/boards'
> make[2]: Entering directory
> '/home/user/work/nuttx/nuttx.git/nuttx/boards/risc-v/esp32c3/esp32c3-devkit/src'
> make[2]: riscv64-unknown-elf-gcc: Command not found
> make[2]: *** [Makefile:118:
> /home/user/work/nuttx/nuttx.git/nuttx/boards/risc-v/esp32c3/esp32c3-devkit/scripts/esp32c3_out.ld]
> Error 127
> make[2]: Leaving directory
> '/home/user/work/nuttx/nuttx.git/nuttx/boards/risc-v/esp32c3/esp32c3-devkit/src'
> make[1]: *** [Makefile:105: context] Error 2
> make[1]: Leaving directory '/home/user/work/nuttx/nuttx.git/nuttx/boards'
> make: *** [tools/Makefile.unix:341: context] Error 2
>
> OS is Debian 10.10:
> uname -a
> Linux vboxdebian 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29)
> x86_64 GNU/Linux
>
> Following tools are installed:
> $ riscv64-linux-gnu-
> riscv64-linux-gnu-addr2line riscv64-linux-gnu-gcc
> riscv64-linux-gnu-gcov-8riscv64-linux-gnu-objcopy
> riscv64-linux-gnu-arriscv64-linux-gnu-gcc-8
> riscv64-linux-gnu-gcov-dump riscv64-linux-gnu-objdump
> riscv64-linux-gnu-asriscv64-linux-gnu-gcc-ar
> riscv64-linux-gnu-gcov-dump-8   riscv64-linux-gnu-pkg-config
> riscv64-linux-gnu-c++filt   riscv64-linux-gnu-gcc-ar-8
> riscv64-linux-gnu-gcov-tool riscv64-linux-gnu-ranlib
> riscv64-linux-gnu-cpp   riscv64-linux-gnu-gcc-nm
> riscv64-linux-gnu-gcov-tool-8   riscv64-linux-gnu-readelf
> riscv64-linux-gnu-cpp-8 riscv64-linux-gnu-gcc-nm-8
> riscv64-linux-gnu-gprof riscv64-linux-gnu-size
> riscv64-linux-gnu-elfedit   riscv64-linux-gnu-gcc-ranlib
> riscv64-linux-gnu-ldriscv64-linux-gnu-strings
> riscv64-linux-gnu-g++   riscv64-linux-gnu-gcc-ranlib-8
> riscv64-linux-gnu-ld.bfdriscv64-linux-gnu-strip
> riscv64-linux-gnu-g++-8 riscv64-linux-gnu-gcov
> riscv64-linux-gnu-nm
>
>
> On FreeBSD there is just one system package for riscv32 and riscv64 so
> name / package confusion is possible.
>
> On Zephyr there is a `west` utility to manage project, it has
> `espressif` subcommand that can fetch, install, and update local
> toolchain and utilities. It uses `idf_tools.py` sctipt from ESP-IDF.
> Recently it was simplified and it just fetches all development for the
> ESP32 chips (openocd-esp32 riscv32-esp-elf xtensa-esp32-elf
> xtensa-esp32s2-elf ) into `~/.espressif/tools/zephyr`. I have also
> sent patches to the upstream that allows FreeBSD to use Linux
> binaries.
>
> https://github.com/espressif/esp-idf/blob/master/tools/idf_tools.py
>
> Maybe this tool could be  integrated with NuttX or should I use it by
> hand before using NuttX? :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: ESP32-C3 RISC-V

[Abdelatif Guettouche]

There isn't really a big difference between IDF's toolchain and the one
from Sifive, this is why we didn't add both.
Are you having issues running the one from SiFive?
The CROSSDEV variable will just have the name of the toolchain.  If we want
to add another toolchain we add another ifeq in
riscv/rv32im/Toolchains.defs.


On Sat, Oct 16, 2021, 23:28 Tomasz CEDRO  wrote:

> On Sat, Oct 16, 2021 at 6:15 PM Tomasz CEDRO wrote:
> >
> > On Sat, Oct 16, 2021 at 6:11 PM Abdelatif Guettouche
> >  wrote:
> > >
> > > > I could not find detailed information on how to setup RISC-V
> toolchain
> > > except just using "generic toolchain":
> > >
> https://nuttx.apache.org/docs/latest/platforms/risc-v/esp32c3/index.html
> > >
> > > There is a link there to download the toolchain used, here:
> > >
> https://static.dev.sifive.com/dev-tools/riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14.tar.gz
> > > You can download the file, untar it and add the location to the PATH.
> >
> > Thanks Abdelatif :-) I am at the moment trying the ESP-IDF
> > `idf_tools.py` on Linux as I am using them on FreeBSD with success.
> > That should keep my work more consistent. It provides all compilers
> > and OpenOCD to work with ESP32 chips. Will report back if that works
> > :-)
>
> ESP-IDF Toolchain also does not work.
>
> Problem comes from hardcoding `riscv64-unknown-elf-` in `CROSSDEV`.
>
> On Linux I have 2 GNU RV Toolchains available. On FreeBSD I have 3.
> None of them matches `iscv64-unknown-elf-`.
>
> Some sort of toolchain auto-detection needs to be implemented :-)
>
> https://github.com/apache/incubator-nuttx/issues/4674
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: github nuttx/nuttx vs apache/incubator-nuttx

[Abdelatif Guettouche]

> I would be happy to delete the whole thing.  Adbelatif has offered to
> delete the contents as well.  But we would need consensus.  A few people
> writing emails doesn't constitute consensus.  That is why we have formal
> votes so that everyone's voice is heard and the direction is clear.

We can then create a VOTE thread to decide whether we want to delete
it or not (can we consider this one as a DISCUSS thread?)

> And there should be some position about where and how we provide OS tool
> support.  If not github.com/nuttx, then where?

We've been told before that we can host well known projects even if
they are in an incompatible license.  We discussed moving them to
Apache.
I'm not sure if we want to revive that discussion as it always went
unnoticed, but it would be ideal to have all the necessary
repositories in one place.

Otherwise, github.com/nuttx would be a good place, maybe we can also
change the name to something similar to what Alin suggested above.


On Sun, Oct 17, 2021 at 2:45 PM Gregory Nutt  wrote:
>
>  > Either way is fine, but we need action now. I have seen the same topic
> > happen on the email list many times, but nothing happens after that
> >discussion.
>
> I would be happy to delete the whole thing.  Adbelatif has offered to
> delete the contents as well.  But we would need consensus.  A few people
> writing emails doesn't constitute consensus.  That is why we have formal
> votes so that everyone's voice is heard and the direction is clear.
>
> With regard to the trademark usage, it would be good to get PPMC feedback
> on that.  Perhaps they would have a clear position.  I don't really know if
> there is an issue here or not... certainly there is less of an issue here
> than with NuttX YouTube, LinkedIN, Discord, and various NuttX named
> websites.  The bitbucket nuttx repository would have the same trademark
> problem, if there is any.
>
> And there should be some position about where and how we provide OS tool
> support.  If not github.com/nuttx, then where? Up until now no one has ever
> made any change to kconfig-frontends other than to fix compile failures due
> to toolchain differences. The only significant change has been to add
> Windows Native support and that is not in either the github or bitbucket
> repos.

Re: esp32c3-devkit:ble boot loop

[Abdelatif Guettouche]

Is this loop from the 1st stage bootloader?
If that is the case, you only need to flash the 2nd stage bootloader.
You can get prebuilt binaries for that on
github.com/espressif/esp-nutt-bootloader and then from NuttX you can flash
with make download ESPTOOL_BINDIR=...
You can also build it yourself if you want.  Please check the
documentation, there should be direct links. (Using just a phone now sorry)

On Mon, Oct 18, 2021, 01:22 Tomasz CEDRO  wrote:

> Hello world :-)
>
> By selecting toolkit by hand (make CROSSDEV=riscv32-esp-elf-) I made
> it to build the esp32c3-devkit:ble example. Both on FreeBSD and Linux.
> I am using ESP-IDF toolchain.
>
> After flashing I can see on terminal emulator that device is locked in
> a boot loop :-(
>
> Is there any additional setup required?
>
> Can this additional setup be put into a board configuration so it
> works out of the box?
>
> The result is exactly the same both with build from FreeBSD and Linux.
>
> Any hints welcome :-)
> Tomek
>
> ps/2: I have created and send FreeBSD Port update (2.5.1 -> 3.1) to
> esptool system package that supports esp32-c3 / risc-v :-)
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259235
>
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: [VOTE] Apache NuttX 10.2.0 (incubating) RC0 release

[Abdelatif Guettouche]

Hi,

+1

I checked:

 - Incubator in name
- LICENSE, NOTICE and DISCLAIMER files exist
- Signatures and checksum valid
- Can build from source.

On Tue, Nov 2, 2021 at 3:30 PM Nathan Hartman  wrote:
>
> Summary:
> +1 to release (binding)
>
> Per Alan's request for size information:
>
> * NuttX-10.2.0-RC0, b-g474e-dpow1:nsh configuration:
>
> $ arm-none-eabi-size nuttx
>textdata bss dec hex filename
>  115331 6242500  118455   1ceb7 nuttx
>
> * For comparison, same configuration on NuttX-10.0.0:
>
> $ arm-none-eabi-size nuttx
>textdata bss dec hex filename
>  116315 6203008  119943   1d487 nuttx
>
> Text decreases 984, data increases 4, bss decreases 508.
>
> Development system: Linux
> (Debian 4.19.0-18-rt-amd64 x86_64)
>
> Verified:
> * Signatures
> * SHA-512 sums
> * Incubating in artifact names
> * LICENSE, NOTICE, README.md, DISCLAIMER-WIP present in both tarballs
> * Build and run b-g474e-dpow1:nsh configuration successfully
> * Release notes LGTM
>
> Dependencies:
> * gcc-arm-none-eabi-7-2017-q4-major
> * kconfig-conf from NuttX tools repository
>
> Other dependencies from Debian packages:
> * binutils-dev 2.31.1-16
> * bison 2:3.3.2.dfsg-1
> * flex 2.6.4-6.2
> * gperf 3.1-1
> * libelf-dev 0.176-1.1
> * libgmp-dev 2:6.1.2+dfsg-4
> * libisl-dev 0.20-2
> * libmpc-dev 1.1.0-1
> * libmpfr-dev 4.0.2-1
> * libncurses5-dev 6.1+20181013-2+deb10u2
> * libusb-1.0-0-dev 2:1.0.22-2
> * libusb-dev 2:0.1.12-32
> * openocd 0.10.0+dev-01241-gdadf46f6-dirty
> * texinfo 6.5.0.dfsg.1-4+b1
>
> Thanks to our RM and to everyone in the Apache NuttX community for making this
> release (candidate) possible!
>
> Cheers,
> Nathan
>
>
> On Mon, Nov 1, 2021 at 4:43 AM Alin Jerpelea  wrote:
> >
> > Hello all,
> > Apache NuttX (Incubating) 10.2.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 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.2.0-RC0
> >   Hash for the release incubating-nuttx tag:
> >   3fede42098e5883f336d846ac30edfe749899494
> >   Hash for the release incubating-nuttx-apps tag:
> >   562239ecb2d84dd9de2dd206da41df19602e20cb
> >
> > [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.2.0-RC0/
> > [2]https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.2.0-RC0/ReleaseNotes
> > [3] https://www.apache.org/dev/release.html#approving-a-release
> > [4]https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: [ANNOUNCE] Apache NuttX 10.2.0-incubating released

[Abdelatif Guettouche]

Thanks for your work, Alin!

On Sun, Nov 28, 2021, 14:16 Alin Jerpelea  wrote:

> The Apache NuttX (incubating) project team is proud to announce
> Apache NuttX 10.2.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.2.0/
>
> Thanks,
> Alin Jerpelea
> on behalf of Apache NuttX PPMC
>

Re: FUSB302

[Abdelatif Guettouche]

Haltian has submitted an SGA and we can convert their license.  You
must have an old tree since all their code now has the ASF header.
https://github.com/apache/incubator-nuttx/pull/4831
https://github.com/apache/incubator-nuttx/blob/master/drivers/usbmisc/fusb301.c#L1-L19

On Wed, Dec 1, 2021 at 5:08 PM Tim  wrote:
>
> There are some drivers for the OnSemo USB C FUSB301 and FUSB303 devices
> available in the NuttX tree, and they will make a good basis for me to
> create a driver for the FUSB302 device I chose to use.
>
> But there's a copyright notice in each saying:
>
> *   Copyright (C) 2019 Haltian Ltd. All rights reserved.
> *   Authors: Harri Luhtala 
> *Juha Niskanen 
>
> Also the usual requirement to include the exact same copyright notice in
> anything derived from them.
>
> Is that just out of date and it should have been replace by the usual ASF
> license boilerplate? Or OK to simply keep their notice?
>
> I don't want to plunder from these files if it is not correct to do so!
>
>

Re: Error when building custom board

[Abdelatif Guettouche]

Please check the common/Make.defs file in-tree of the board you based your
custom board on. There is a new variable introduced.
(Sorry, writing from my phone. I'll try to send a direct link later.)

On Thu, Mar 3, 2022, 07:10 Petro Karashchenko 
wrote:

> Hi,
>
> Do you want to use board common code? There where some code tree
> restructurings to eliminate code duplication. There is an option to
> enable/disable common code in menu config. Please try to use it and
> feedback if it helps you.
>
> Best regards,
> Petro
>
>
> On Thu, Mar 3, 2022, 12:06 AM Daniel Pereira Carvalho  >
> wrote:
>
> > Hi guys,
> >
> > I am having problems building custom boards outside of the Nuttx folder
> > tree. Usually I use the following folder structure.
> >
> > |-> apps
> > |-> my-folder
> >|-> my-apps
> >   |-> custom-app
> >|-> my-boards
> >   |-> custom-board
> > |-> nuttx
> >
> > To build my apps I just need to create a symbolic link called external
> > inside apps folder. To create a new custom board I start copying a
> similar
> > board (e.g nucleo-g431kb) to my-boards folder and make the following
> > changes
> >
> > *remove from defconfig:*
> > CONFIG_ARCH_BOARD="nucleo-g431kb"
> > CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
> >
> > *add on defconfig:*
> > CONFIG_ARCH_BOARD_CUSTOM=y
> > CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards/custom-board"
> > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > CONFIG_ARCH_BOARD_CUSTOM_NAME="custom-board"
> >
> > *Rename src/Make.defs to src/Makefile and append the line *
> > include $(TOPDIR)/boards/Board.mk at the end of file.
> >
> > This works well for me up to Nuttx version 10.2.0 but now when I try to
> > make I got the errors
> >
> > make[1]: Entering directory '/home/daniel/nuttx-workspace/nuttx/tools'
> > make[1]: Leaving directory '/home/daniel/nuttx-workspace/nuttx/tools'
> > make[1]: Entering directory '/home/daniel/nuttx-workspace/nuttx/tools'
> > make[1]: Leaving directory '/home/daniel/nuttx-workspace/nuttx/tools'
> > Create version.h
> > make[1]: Entering directory '/home/daniel/nuttx-workspace/nuttx/boards'
> > make[2]: Entering directory
> > '/home/daniel/nuttx-workspace/nuttx/boards/arm/stm32/common'
> > Makefile:23: board/Make.defs: No such file or directory
> > make[2]: *** No rule to make target 'board/Make.defs'.  Stop.
> > make[2]: Leaving directory
> > '/home/daniel/nuttx-workspace/nuttx/boards/arm/stm32/common'
> > make[1]: *** [Makefile:79: context] Error 2
> > make[1]: Leaving directory '/home/daniel/nuttx-workspace/nuttx/boards'
> > make: *** [tools/Unix.mk:425: boards/.context] Error 2
> >
> > Does anyone know how to fix this problem?
> >
> > Thanks
> >
> > Daniel Pereira de Carvalho
> >
>

Re: Error when building custom board

[Abdelatif Guettouche]

> It seems like Daniel is hitting the same issue

Daniel is actually not using the common folder from the STM32
directory.  This is why he had to do that renaming.
The issue is this:
https://github.com/apache/incubator-nuttx/blob/master/tools/Config.mk#L154-L156
Which is forcing a common directory when there isn't one. This should
not be done as people have requested before to be able to use boards
without a common directory even if in-tree we use the common
directory.
Daniel, you can just remove those lines to confirm that it builds fine
(I tried and it does, at least you don't have that error anymore,
there are some trivial compile errors though in the board).
For a final solution I think we can either remove them completely or
just add an else statement. I didn't have time to think about it.

On Thu, Mar 3, 2022 at 9:34 AM Jukka Laitinen  wrote:
>
> Hi,
>
> Maybe I was jumping in to conclusion and the issue is not the same as
> what I had. I was building PX4, which uses CMake build system, so I am
> not having any Makefile or Make.defs in my own board directory. Also the
> platform is not stm or arm, but risc-v.
>
> Anyhow, this is the error which I started getting in my build scripts:
>
> "
>
> ninja: error:
> '../../platforms/nuttx/NuttX/nuttx/arch/risc-v/include/board', needed by
> 'NuttX/nuttx_copy.stamp', missing and no known rule to make it
> make: *** [Makefile:225: ssrc_icicle_default] Error 1
> "
>
> My configs are:
>
> CONFIG_ARCH="risc-v"
> CONFIG_ARCH_BOARD_CUSTOM=y
> CONFIG_ARCH_BOARD_CUSTOM_DIR="../nuttx-config"
> CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> CONFIG_ARCH_BOARD_CUSTOM_NAME="px4"
>
> One version, where it fails is available publicly in
>
> https://github.com/tiiuae/px4-firmware/ (nuttx is included as a submodule)
>
> Building "make ssrc_icicle_default". The board files are in
> boards/ssrc/icicle/nuttx-config and NuttX cloned in
> platforms/nuttx/Nuttx/nuttx.
>
> I didn't yet start looking into it in detail, what goes wrong, just
> bisected the nuttx and reverted the commit which broke it for me. I need
> to look back later to see how to change the off-tree board config to get
> it back online.
>
> Just noticed that the error is somewhat similar, although coming from
> different build env. But in my case it is likely that I need to adapt
> the cmake build scripts according to the changes in nuttx.
>
> -Jukka
>
>
>
> On 3.3.2022 9.37, Petro Karashchenko wrote:
> > Hello Jukka,
> >
> > So you experience the same problem as Daniel and reverting the commit helps?
> >
> > Before f77956a227f1db6ecb44eda3814e7b02aa2187a6 there was no way to
> > reuse common code from "nuttx/board/...". I'm using a custom board
> > based on SAME70 and after
> > https://github.com/apache/incubator-nuttx/pull/4981 I found my code
> > tree broken. Now the folder structure for "boards/arm/samv7" is the
> > same as in "boards/arm/stm32". Here is what I did to get it back
> > running:
> > 1. Synced "custom-board/scripts/Make.defs" with
> > "boards/arm/samv7/same70-xplained/scripts/Make.defs"
> > 2. Renamed "custom-board/src/Makefile" to "custom-board/src/Make.defs"
> > and synced with "boards/arm/samv7/same70-xplained/src/Make.defs"
> > 3. Removed files in my code tree that have exactly the same
> > implementation as files from "boards/arm/samv7/common"
> >
> > It seems like Daniel is hitting the same issue, so I expect that
> > renaming Makefile to Make.defs plus setting "BOARD_STM32_COMMON=n"
> > should fix the issue without any additional file clean-up.
> > Please give me feedback if that helps.
> >
> > Best regards,
> > Petro
> >
> > чт, 3 бер. 2022 р. о 07:40 Jukka Laitinen  пише:
> >> HI,
> >>
> >> Not sure what is the correct way to fix this, but I reverted:
> >>
> >> "
> >>
> >> commit f77956a227f1db6ecb44eda3814e7b02aa2187a6
> >> Author: Petro Karashchenko 
> >> Date:   Wed Jan 19 11:16:11 2022 +0200
> >>
> >>   tools: add option to reuse boards common files for custom boards
> >>
> >>   Signed-off-by: Petro Karashchenko 
> >> "
> >>
> >> Petro, what is the proper way to configure this?
> >>
> >> Thanks,
> >>
> >> Jukka
> >>
> >>
> >>
> >> On 3.3.2022 0.06, Daniel Pereira Carvalho wrote:
> >>
> >>> Hi guys,
> >>>
> >>> I am having problems building custom boards outside of the Nuttx folder
> >>> tree. Usually I use the following folder structure.
> >>>
> >>> |-> apps
> >>> |-> my-folder
> >>>  |-> my-apps
> >>> |-> custom-app
> >>>  |-> my-boards
> >>> |-> custom-board
> >>> |-> nuttx
> >>>
> >>> To build my apps I just need to create a symbolic link called external
> >>> inside apps folder. To create a new custom board I start copying a similar
> >>> board (e.g nucleo-g431kb) to my-boards folder and make the following 
> >>> changes
> >>>
> >>> *remove from defconfig:*
> >>> CONFIG_ARCH_BOARD="nucleo-g431kb"
> >>> CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
> >>>
> >>> *add on defconfig:*
> >>> CONFIG_ARCH_BOARD_CUSTOM=y
> >>> CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards

Re: Error when building custom board

[Abdelatif Guettouche]

> "Which is forcing a common directory when there isn't one. " -- This
> statement is not true as we have
> https://github.com/apache/incubator-nuttx/blob/b953296de73ac75bb380a609f9f30e9fe34e7622/tools/Unix.mk#L272-L277
> that depends on if "BOARD_COMMON_DIR" exists or not.

Unix.mk includes $(TOPDIR)/Make.defs which in its turn includes
tools/Config.mk so reaching that Make rule, BOARD_COMMON_DIR will have
a value, whether there is a common directory or not.

On Thu, Mar 3, 2022 at 11:09 AM Petro Karashchenko
 wrote:
>
> Hello Abdelatif,
>
> "Which is forcing a common directory when there isn't one. " -- This
> statement is not true as we have
> https://github.com/apache/incubator-nuttx/blob/b953296de73ac75bb380a609f9f30e9fe34e7622/tools/Unix.mk#L272-L277
> that depends on if "BOARD_COMMON_DIR" exists or not.
>
> Getting back to original question:
>
> > To build my apps I just need to create a symbolic link called external
> > inside apps folder. To create a new custom board I start copying a similar
> > board (e.g nucleo-g431kb) to my-boards folder and make the following changes
> >
> > *remove from defconfig:*
> > CONFIG_ARCH_BOARD="nucleo-g431kb"
> > CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
> >
> > *add on defconfig:*
> > CONFIG_ARCH_BOARD_CUSTOM=y
> > CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards/custom-board"
> > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > CONFIG_ARCH_BOARD_CUSTOM_NAME="custom-board"
> >
> > *Rename src/Make.defs to src/Makefile and append the line *
> > include $(TOPDIR)/boards/Board.mk at the end of file.
> >
> > This works well for me up to Nuttx version 10.2.0 but now when I try to
> > make I got the errors
>
> I think with NuttX 10.2.0 you do not need to perform the next steps any more.
>
>*Rename src/Make.defs to src/Makefile and append the line *
>include $(TOPDIR)/boards/Board.mk at the end of file.
>
> I will get back to errors met by Jukka to see what caused the problem
> in his case.
>
> Best regards,
> Petro
>
> чт, 3 бер. 2022 р. о 10:12 Abdelatif Guettouche
>  пише:
> >
> > > It seems like Daniel is hitting the same issue
> >
> > Daniel is actually not using the common folder from the STM32
> > directory.  This is why he had to do that renaming.
> > The issue is this:
> > https://github.com/apache/incubator-nuttx/blob/master/tools/Config.mk#L154-L156
> > Which is forcing a common directory when there isn't one. This should
> > not be done as people have requested before to be able to use boards
> > without a common directory even if in-tree we use the common
> > directory.
> > Daniel, you can just remove those lines to confirm that it builds fine
> > (I tried and it does, at least you don't have that error anymore,
> > there are some trivial compile errors though in the board).
> > For a final solution I think we can either remove them completely or
> > just add an else statement. I didn't have time to think about it.
> >
> > On Thu, Mar 3, 2022 at 9:34 AM Jukka Laitinen  wrote:
> > >
> > > Hi,
> > >
> > > Maybe I was jumping in to conclusion and the issue is not the same as
> > > what I had. I was building PX4, which uses CMake build system, so I am
> > > not having any Makefile or Make.defs in my own board directory. Also the
> > > platform is not stm or arm, but risc-v.
> > >
> > > Anyhow, this is the error which I started getting in my build scripts:
> > >
> > > "
> > >
> > > ninja: error:
> > > '../../platforms/nuttx/NuttX/nuttx/arch/risc-v/include/board', needed by
> > > 'NuttX/nuttx_copy.stamp', missing and no known rule to make it
> > > make: *** [Makefile:225: ssrc_icicle_default] Error 1
> > > "
> > >
> > > My configs are:
> > >
> > > CONFIG_ARCH="risc-v"
> > > CONFIG_ARCH_BOARD_CUSTOM=y
> > > CONFIG_ARCH_BOARD_CUSTOM_DIR="../nuttx-config"
> > > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > > CONFIG_ARCH_BOARD_CUSTOM_NAME="px4"
> > >
> > > One version, where it fails is available publicly in
> > >
> > > https://github.com/tiiuae/px4-firmware/ (nuttx is included as a submodule)
> > >
> > > Building "make ssrc_icicle_default". The board files are in
> > > boards/ssrc/icicle/nuttx-config and NuttX cloned in
> > > platforms/nuttx/Nuttx/nuttx.
> > >
> > > I didn't yet start looki

Re: Error when building custom board

[Abdelatif Guettouche]

> I think with NuttX 10.2.0 you do not need to perform the next steps any more.

These are necessary when someone is using a custom board without a
common folder copied from a board in-tree that contains a common
folder.

On Thu, Mar 3, 2022 at 11:31 AM Abdelatif Guettouche
 wrote:
>
> > "Which is forcing a common directory when there isn't one. " -- This
> > statement is not true as we have
> > https://github.com/apache/incubator-nuttx/blob/b953296de73ac75bb380a609f9f30e9fe34e7622/tools/Unix.mk#L272-L277
> > that depends on if "BOARD_COMMON_DIR" exists or not.
>
> Unix.mk includes $(TOPDIR)/Make.defs which in its turn includes
> tools/Config.mk so reaching that Make rule, BOARD_COMMON_DIR will have
> a value, whether there is a common directory or not.
>
> On Thu, Mar 3, 2022 at 11:09 AM Petro Karashchenko
>  wrote:
> >
> > Hello Abdelatif,
> >
> > "Which is forcing a common directory when there isn't one. " -- This
> > statement is not true as we have
> > https://github.com/apache/incubator-nuttx/blob/b953296de73ac75bb380a609f9f30e9fe34e7622/tools/Unix.mk#L272-L277
> > that depends on if "BOARD_COMMON_DIR" exists or not.
> >
> > Getting back to original question:
> >
> > > To build my apps I just need to create a symbolic link called external
> > > inside apps folder. To create a new custom board I start copying a similar
> > > board (e.g nucleo-g431kb) to my-boards folder and make the following 
> > > changes
> > >
> > > *remove from defconfig:*
> > > CONFIG_ARCH_BOARD="nucleo-g431kb"
> > > CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
> > >
> > > *add on defconfig:*
> > > CONFIG_ARCH_BOARD_CUSTOM=y
> > > CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards/custom-board"
> > > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > > CONFIG_ARCH_BOARD_CUSTOM_NAME="custom-board"
> > >
> > > *Rename src/Make.defs to src/Makefile and append the line *
> > > include $(TOPDIR)/boards/Board.mk at the end of file.
> > >
> > > This works well for me up to Nuttx version 10.2.0 but now when I try to
> > > make I got the errors
> >
> > I think with NuttX 10.2.0 you do not need to perform the next steps any 
> > more.
> >
> >*Rename src/Make.defs to src/Makefile and append the line *
> >include $(TOPDIR)/boards/Board.mk at the end of file.
> >
> > I will get back to errors met by Jukka to see what caused the problem
> > in his case.
> >
> > Best regards,
> > Petro
> >
> > чт, 3 бер. 2022 р. о 10:12 Abdelatif Guettouche
> >  пише:
> > >
> > > > It seems like Daniel is hitting the same issue
> > >
> > > Daniel is actually not using the common folder from the STM32
> > > directory.  This is why he had to do that renaming.
> > > The issue is this:
> > > https://github.com/apache/incubator-nuttx/blob/master/tools/Config.mk#L154-L156
> > > Which is forcing a common directory when there isn't one. This should
> > > not be done as people have requested before to be able to use boards
> > > without a common directory even if in-tree we use the common
> > > directory.
> > > Daniel, you can just remove those lines to confirm that it builds fine
> > > (I tried and it does, at least you don't have that error anymore,
> > > there are some trivial compile errors though in the board).
> > > For a final solution I think we can either remove them completely or
> > > just add an else statement. I didn't have time to think about it.
> > >
> > > On Thu, Mar 3, 2022 at 9:34 AM Jukka Laitinen  
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > Maybe I was jumping in to conclusion and the issue is not the same as
> > > > what I had. I was building PX4, which uses CMake build system, so I am
> > > > not having any Makefile or Make.defs in my own board directory. Also the
> > > > platform is not stm or arm, but risc-v.
> > > >
> > > > Anyhow, this is the error which I started getting in my build scripts:
> > > >
> > > > "
> > > >
> > > > ninja: error:
> > > > '../../platforms/nuttx/NuttX/nuttx/arch/risc-v/include/board', needed by
> > > > 'NuttX/nuttx_copy.stamp', missing and no known rule to make it
> > > > make: *** [Makefile:225: ssrc_icicle_default] Error 1
> > > > "
> > > 

Re: Error when building custom board

[Abdelatif Guettouche]

> If what you are writing is true, then compilation for any board that
> does not have a "common" folder at board level should fail.

No because in-tree this line: BOARD_COMMON_DIR = $(wildcard
$(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)common)
will result on an empty string.

> We just need to copy source files from
> NuttX board common to custom board location and add files to
> compilation list

The thing is that some people won't want to do that.  They don't want
to use the common folder. It could be that they have an old board
where the common folder structure didn't exist at the time and they
don't want to change their structure.

> Or maybe I'm missing the exact use case.

Daniel's use case is the following: Use a custom board copied from an
in-tree board _without_ using the common directory even if one exists.

On Thu, Mar 3, 2022 at 11:43 AM Petro Karashchenko
 wrote:
>
> Hi,
>
> There is no problem with that. We just need to copy source files from
> NuttX board common to custom board location and add files to
> compilation list together with disabling of NuttX board common layer
> (set CONFIG_BOARD_STM32_COMMON=n for example with STM32 case).
>
> Or maybe I'm missing the exact use case. If yes, then please describe
> it more clearly and I will try to go through it to see if that can be
> achieved with the current code tree or not.
>
> Best regards,
> Petro
>
> чт, 3 бер. 2022 р. о 11:37 Abdelatif Guettouche
>  пише:
> >
> > > I think with NuttX 10.2.0 you do not need to perform the next steps any 
> > > more.
> >
> > These are necessary when someone is using a custom board without a
> > common folder copied from a board in-tree that contains a common
> > folder.
> >
> > On Thu, Mar 3, 2022 at 11:31 AM Abdelatif Guettouche
> >  wrote:
> > >
> > > > "Which is forcing a common directory when there isn't one. " -- This
> > > > statement is not true as we have
> > > > https://github.com/apache/incubator-nuttx/blob/b953296de73ac75bb380a609f9f30e9fe34e7622/tools/Unix.mk#L272-L277
> > > > that depends on if "BOARD_COMMON_DIR" exists or not.
> > >
> > > Unix.mk includes $(TOPDIR)/Make.defs which in its turn includes
> > > tools/Config.mk so reaching that Make rule, BOARD_COMMON_DIR will have
> > > a value, whether there is a common directory or not.
> > >
> > > On Thu, Mar 3, 2022 at 11:09 AM Petro Karashchenko
> > >  wrote:
> > > >
> > > > Hello Abdelatif,
> > > >
> > > > "Which is forcing a common directory when there isn't one. " -- This
> > > > statement is not true as we have
> > > > https://github.com/apache/incubator-nuttx/blob/b953296de73ac75bb380a609f9f30e9fe34e7622/tools/Unix.mk#L272-L277
> > > > that depends on if "BOARD_COMMON_DIR" exists or not.
> > > >
> > > > Getting back to original question:
> > > >
> > > > > To build my apps I just need to create a symbolic link called external
> > > > > inside apps folder. To create a new custom board I start copying a 
> > > > > similar
> > > > > board (e.g nucleo-g431kb) to my-boards folder and make the following 
> > > > > changes
> > > > >
> > > > > *remove from defconfig:*
> > > > > CONFIG_ARCH_BOARD="nucleo-g431kb"
> > > > > CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
> > > > >
> > > > > *add on defconfig:*
> > > > > CONFIG_ARCH_BOARD_CUSTOM=y
> > > > > CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards/custom-board"
> > > > > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > > > > CONFIG_ARCH_BOARD_CUSTOM_NAME="custom-board"
> > > > >
> > > > > *Rename src/Make.defs to src/Makefile and append the line *
> > > > > include $(TOPDIR)/boards/Board.mk at the end of file.
> > > > >
> > > > > This works well for me up to Nuttx version 10.2.0 but now when I try 
> > > > > to
> > > > > make I got the errors
> > > >
> > > > I think with NuttX 10.2.0 you do not need to perform the next steps any 
> > > > more.
> > > >
> > > >*Rename src/Make.defs to src/Makefile and append the line *
> > > >include $(TOPDIR)/boards/Board.mk at the end of file.
> > > >
> > > > I will get back to errors met by Jukka to see what caused th

Re: Error when building custom board

[Abdelatif Guettouche]

> Compilation failed, but not because of a common folder but because:

Again, the issue is to not use the common folder at all.  This was
requested before.  What you did here is that you used the one in-tree.

> I think this is a weak argument as we change config
option names sometimes as users are forced to adapt their code.

If users are requesting a feature, there isn't a stronger argument.
Besides, this is not even a feature request, this is a restriction
introduced by forcing the common folder to custom boards.
They are called "custom" for a reason, they should not be restricted
in this manner. We should leave the choice of using this folder or not
to the user. As it was before.
If we want to keep the option to share it for both in-tree and
out-of-tree boards, then there has to be an _option_.  Not
unconditionally forced.
One solution is to introduce a new CONFIG_ that defaults to false.




On Thu, Mar 3, 2022 at 1:20 PM Petro Karashchenko
 wrote:
>
> Hello Abdelatif,
>
> I just tried to recreate the same scenario. To do this I did:
> 1. Recreated folder structure as in Daniel's case
> |-> apps
> |-> my-folder
>  |-> my-boards
>|-> custom-board
> |-> nuttx
>
> 2. Copied  nucleo-g431kb to custom-board: cd my-folder/my-boards && cp
> -r ../../nuttx/boards/arm/stm32/nucleo-g431kb custom-board
>
> 3. *remove from defconfig:*
> CONFIG_ARCH_BOARD="nucleo-g431kb"
> CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
>
> 4. *add on defconfig:*
> CONFIG_ARCH_BOARD_CUSTOM=y
> CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards/custom-board"
> CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> CONFIG_ARCH_BOARD_CUSTOM_NAME="custom-board"
>
> 5. I did not performed: "*Rename src/Make.defs to src/Makefile and
> append the line include $(TOPDIR)/boards/Board.mk at the end of
> file.*"
>
> 6. tools/configure.sh ../my-folder/my-boards/custom-board/configs/nsh
>
> 7. make -j8
>
> Compilation failed, but not because of a common folder but because:
> "board/stm32_userleds.c:60:14: error: 'BOARD_LED1' undeclared (first
> use in this function); did you mean 'BOARD_LED2'?". So I had to "make
> menuconfig" and select "BOARD_CUSTOM_LEDS" to pass compilation
> successfully.
>
> "It could be that they have an old board where the common folder
> structure didn't exist at the time and they don't want to change their
> structure." -- I think this is a weak argument as we change config
> option names sometimes as users are forced to adapt their code. The
> only miss that I see here is that the
> https://github.com/apache/incubator-nuttx/pull/5274 was not marked as
> a "breaking change".
>
> Best regards,
> Petro
>
> чт, 3 бер. 2022 р. о 11:57 Abdelatif Guettouche
>  пише:
> >
> > > If what you are writing is true, then compilation for any board that
> > > does not have a "common" folder at board level should fail.
> >
> > No because in-tree this line: BOARD_COMMON_DIR = $(wildcard
> > $(TOPDIR)$(DELIM)boards$(DELIM)$(CONFIG_ARCH)$(DELIM)$(CONFIG_ARCH_CHIP)$(DELIM)common)
> > will result on an empty string.
> >
> > > We just need to copy source files from
> > > NuttX board common to custom board location and add files to
> > > compilation list
> >
> > The thing is that some people won't want to do that.  They don't want
> > to use the common folder. It could be that they have an old board
> > where the common folder structure didn't exist at the time and they
> > don't want to change their structure.
> >
> > > Or maybe I'm missing the exact use case.
> >
> > Daniel's use case is the following: Use a custom board copied from an
> > in-tree board _without_ using the common directory even if one exists.
> >
> > On Thu, Mar 3, 2022 at 11:43 AM Petro Karashchenko
> >  wrote:
> > >
> > > Hi,
> > >
> > > There is no problem with that. We just need to copy source files from
> > > NuttX board common to custom board location and add files to
> > > compilation list together with disabling of NuttX board common layer
> > > (set CONFIG_BOARD_STM32_COMMON=n for example with STM32 case).
> > >
> > > Or maybe I'm missing the exact use case. If yes, then please describe
> > > it more clearly and I will try to go through it to see if that can be
> > > achieved with the current code tree or not.
> > >
> > > Best regards,
> > > Petro
> > >
> > > чт, 3 бер. 2022 р. о 11:37 Abdelatif Guett

Re: Error when building custom board

[Abdelatif Guettouche]

> The case is only about creating a proper symlink.

I think in the current situation the symlink is created unconditionally.

> Abdelatif, I would really appreciate it if you can write and send me
some small proposal at what level the option should exist.

What I was referring to is similar to options like BOARD_STM32_COMMON.
However, I was thinking of having only one that we can use in
different places.  There are other boards, like ESP32, where there is
no similar option. I haven't given this any time, so I don't know how
well it would work.  I'd also be okay with these separate options but
used consistently across all boards and defaulting all to 'n'.
If this keeps the original behavior and as a bonus also removes those
weird steps where we have to rename makefiles, then this is the best
of both worlds.

On Thu, Mar 3, 2022 at 2:01 PM Petro Karashchenko
 wrote:
>
> The case is only about creating a proper symlink. "Again, the issue is
> to not use the common folder at all." -- agin, that is possible. Each
> "board/common" has options like "BOARD_STM32_COMMON" or
> "BOARD_SAMV7_COMMON" and that is exactly to or not to use in-tree
> "board/common". What other option do we need?
>
> "If users are requesting a feature, there isn't a stronger argument."
> -- that is absolutely true and that is why I suggest to mark
> https://github.com/apache/incubator-nuttx/pull/5274 as a "breaking
> change" so users will be aware.
> "We should leave the choice of using this folder or not to the user"
> -- again, users have a choice over "BOARD_STM32_COMMON" or
> "BOARD_SAMV7_COMMON". "BOARD_STM32_COMMON" is defaulted to "n" and I
> will make a PR to default all similar options to "n".
>
> Let's discuss new option behavior if existing options do not satisfy a
> use cases. I'm open to that, but for now I do not see a need for that
> because IMO all options are already inplace.
>
> Abdelatif, I would really appreciate it if you can write and send me
> some small proposal at what level the option should exist.
>
> Best regards,
> Petro
>
> чт, 3 бер. 2022 р. о 13:48 Abdelatif Guettouche
>  пише:
> >
> > > Compilation failed, but not because of a common folder but because:
> >
> > Again, the issue is to not use the common folder at all.  This was
> > requested before.  What you did here is that you used the one in-tree.
> >
> > > I think this is a weak argument as we change config
> > option names sometimes as users are forced to adapt their code.
> >
> > If users are requesting a feature, there isn't a stronger argument.
> > Besides, this is not even a feature request, this is a restriction
> > introduced by forcing the common folder to custom boards.
> > They are called "custom" for a reason, they should not be restricted
> > in this manner. We should leave the choice of using this folder or not
> > to the user. As it was before.
> > If we want to keep the option to share it for both in-tree and
> > out-of-tree boards, then there has to be an _option_.  Not
> > unconditionally forced.
> > One solution is to introduce a new CONFIG_ that defaults to false.
> >
> >
> >
> >
> > On Thu, Mar 3, 2022 at 1:20 PM Petro Karashchenko
> >  wrote:
> > >
> > > Hello Abdelatif,
> > >
> > > I just tried to recreate the same scenario. To do this I did:
> > > 1. Recreated folder structure as in Daniel's case
> > > |-> apps
> > > |-> my-folder
> > >  |-> my-boards
> > >|-> custom-board
> > > |-> nuttx
> > >
> > > 2. Copied  nucleo-g431kb to custom-board: cd my-folder/my-boards && cp
> > > -r ../../nuttx/boards/arm/stm32/nucleo-g431kb custom-board
> > >
> > > 3. *remove from defconfig:*
> > > CONFIG_ARCH_BOARD="nucleo-g431kb"
> > > CONFIG_ARCH_BOARD_NUCLEO_G431KB=y
> > >
> > > 4. *add on defconfig:*
> > > CONFIG_ARCH_BOARD_CUSTOM=y
> > > CONFIG_ARCH_BOARD_CUSTOM_DIR="../my-folder/my-boards/custom-board"
> > > CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
> > > CONFIG_ARCH_BOARD_CUSTOM_NAME="custom-board"
> > >
> > > 5. I did not performed: "*Rename src/Make.defs to src/Makefile and
> > > append the line include $(TOPDIR)/boards/Board.mk at the end of
> > > file.*"
> > >
> > > 6. tools/configure.sh ../my-folder/my-boards/custom-board/configs/nsh
> > >
> > > 7. make -j8
> &

Re: NuttX 10.3 release plan

[Abdelatif Guettouche]

I am OK with removing the disclaimer for 10.3.
Thank you for your work on this, Alin!

On Mon, Mar 28, 2022 at 2:32 PM alin.jerpe...@sony.com
 wrote:
>
> 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: NuttX github code review practices

[Abdelatif Guettouche]

> Have a few custom boards in the test process. we're talking build
> testing, not runtime. No need for a farm.

We actually should do this.  It should be possible to have a few
custom boards in another repository (the old testing repo for
instance) and trigger its workflow on PRs.
I believe once Greg suggested to use a special sim config with the
necessary custom options enabled, if that work that would be simpler.
However, I'm not sure if we can test all the possible configurations
like this, for example we have boards with common folder, boards with
no common folder and boards with common but the user doesn't want the
common folder.  Either way, we should do something about custom boards
to avoid any breakage.

Regarding testing in hardware, what we have right now is different
organisations doing their own tests on their own infrastructure.  In
most cases, this means that we wait until the change is already in
master.  For us (as in Espressif) we sometimes push branches
internally with the changes of some PRs that we think require more
tests.
I don't know how we can setup hardware test runners with Apache
infrastructure, the best thing we can do is to have QEMU for most
chips.

This is a bit out of topic, sorry about this Jukka, we can move this
discussion to a different thread if you want.

Regarding code review, please remember that _anyone_ in the community
can participate, it doesn't have to be a commiter or PPMC member.  If
a concern is raised by anyone, the corresponding PR will have to wait
until everything is addressed.
So if you guys have some spare time, you can check PRs of interest,
you don't have to go through all the commits of all the PRs, any help
is appreciated.


On Mon, Mar 28, 2022 at 2:51 PM Sebastien Lorquet  wrote:
>
> Sorry, I cant possibly test every commit and tell you what breaks
>
> Have a few custom boards in the test process. we're talking build
> testing, not runtime. No need for a farm.
>
> I am not actively developing in nuttx. I'm just using it.
>
>
> Your request is ONLY possible for contributors working on NuttX full
> time on the very long term.
>
> It's not my situation. Following the github feeds would result in
> massive amounts of commit "spam" to read, sort, review, delete. sorry
> not possible given the amount of commits by certains companies and
> various topics.
>
> But still I see the project evolving with fear and tbh, because at some
> point I'll have to work on a new board (it's planned).
>
>
> I am not here to rant more. These were feelings and of course it's
> biased. I was just adding my voice to Jukka's concerns.
>
>
> Sebastien
>
>
>
>
> Le 28/03/2022 à 14:03, Alan Carvalho de Assis a écrit :
> > On 3/28/22, Sebastien Lorquet  wrote:
> >> In this example it's Xiaomi and Sony.
> >>
> >> NuttX has a code review problem and it has to be identified and addressed.
> >>
> >> I have the same feeling here, last time I tried to send a pull request,
> >> it took several day to fix style issues for a ONE LINE code typo.
> >>
> > Most probably you didn't follow the process to verify for code style errors 
> > etc:
> > https://nuttx.apache.org/docs/latest/contributing/making-changes.html#git-workflow-with-an-upstream-repository
> >
> >> And a lot of board breaking changes are committed regularly. when you
> >> have a custom board it's not fun.
> >>
> > Please help us to test! We don't have CI with a board farm test to help us.
> >
> >> I believe a LOT of things including new features happens "silently" in
> >> github comments only, and very little is discussed on this mailing list.
> >>
> > This mailing list purpose it not for code reviewing, but you can
> > subscribe on github or apache repository to receive an email with each
> > PR and with each comment other people are doing.
> >
> > We need more people to review the code, not more people to complain!
> >
> > BR,
> >
> > Alan

Re: [VOTE] Apache NuttX 10.3.0 (incubating) RC0 release

[Abdelatif Guettouche]

+1

I checked:
1. NOTICE, DISCLAIMER and LICENSE files exist.
2. Incubating in name
3. Can build from source.

Thank you Alin!

On Wed, Mar 30, 2022 at 6:50 PM Alin Jerpelea  wrote:
>
> Hello all,
>
>
> Apache NuttX (Incubating) 10.3.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 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-RC0
>   Hash for the release incubating-nuttx tag:
> c18075779548fcba3f2978689888af8c3b9c959c
>   Hash for the release incubating-nuttx-apps tag:
> 4a2aa6d8cffb6eef45d445ca42a3653f700a2565
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.3.0-RC0/
> [2]
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.3.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

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

[Abdelatif Guettouche]

+1 to release.

I checked:
1. NOTICE, DISCLAIMER and LICENSE files exist.
2. Incubating in name
3. Can build from source.


On Fri, Apr 29, 2022 at 7:35 AM Xiang Xiao  wrote:
>
> +1.
> Test with checkrelease.sh.
>
> On Wed, Apr 27, 2022 at 4: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://dist.apache.org/repos/dist/dev/incubator/nuttx/10.3.0-RC1/
> > [2]
> >
> > https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.3.0-RC1/ReleaseNotes
> > [3] https://www.apache.org/dev/release.html#approving-a-release
> > [4]
> >
> > https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
> >

Re: [VOTE] Apache NuttX 10.3.0 (incubating) RC2 release

[Abdelatif Guettouche]

+1 to release.

I checked:
1. NOTICE, DISCLAIMER and LICENSE files exist.
2. Incubating in name
3. Can build from source.

Thank you Alin.

On Thu, May 5, 2022 at 12:34 PM Alin Jerpelea  wrote:
>
> Hello all,
>
>
> Apache NuttX (Incubating) 10.3.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-10.3.0-RC2
>   Hash for the release incubating-nuttx tag:
> ec8fa7d2bfd649d8848448243744e30c96467ff2
>   Hash for the release incubating-nuttx-apps tag:
> ecd8a9722f9da777829ed6f28998311f1664b278
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.3.0-RC2/
> [2]
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.3.0-RC2/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: Question about versions

[Abdelatif Guettouche]

Do you have the latest tags in your first version?
You can get them with: git pull upstream --tags

On Wed, May 25, 2022 at 4:22 PM Roberto Bucher 
wrote:

> Hi
>
> I have a local version of nuttx, and an access to the incubator nuttx
> repository through the git remote with this configuration:
>
> bucher@debian:~/sviluppo/NUTTX/nuttx$ git remote -v
> origing...@github.com:robertobucher/incubator-nuttx.git (fetch)
> origing...@github.com:robertobucher/incubator-nuttx.git (push)
> upstreamhttps://github.com/apache/incubator-nuttx.git (fetch)
> upstreamhttps://github.com/apache/incubator-nuttx.git (push)
>
>
> I did a
>
> git pull upstream master
>
> and it seems that my local version is updated
>
>
>
> When I build an image, the version that I have in the nsh is 10.1.0!
>
> I cloned another nuttx folder directly from the incubator, I built an
> image, but in this new build the version is
>
> NuttX-10.3.0-RC2
>
> What is wrong in my local version?
>
> Thanks in advance
>
> Roberto
>

Re: [VOTE] Apache NuttX 10.3.0 (incubating) RC3 release

[Abdelatif Guettouche]

Hi,
Regarding the disclaimer, the idea was to remove the WIP part _only_,
to end up with a standard disclaimer file and not a WIP disclaimer
file. [1]
I believe we are required to make at least one non WIP release to be
eligible for graduation and given all the work on licensing that has
been done, we can drop the WIP part.

1. https://incubator.apache.org/policy/incubation.html#disclaimers

On Tue, Jun 7, 2022 at 9:38 AM Alin Jerpelea  wrote:
>
> Hello all,
> Apache NuttX (Incubating) 10.3.0 RC3 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-RC3
>   Hash for the release incubating-nuttx tag:
> c4952b7788e6f5891421a24e27371373c25be7a5
>   Hash for the release incubating-nuttx-apps tag:
> bc6f5d6fd775b8ca65870a9ea5dc02ac90a86901
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.3.0-RC3/
> [2]https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.3.0-RC3/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: Suggestion to turn a nwarn into an ninfo in ipv4_input

[Abdelatif Guettouche]

+1 for making it an ninfo (without the extra option).

On Thu, Jun 9, 2022 at 8:45 AM Michael Jung  wrote:
>
> Hi Sebastien,
>
> I have this warning degraded to an informational message in my local
> repository for the exact same reason. In my opinion it should just be
> changed to informational. I.e. no need to make this configurable.
>
> Bye,
> Michael
>
> On Thu, Jun 9, 2022 at 12:45 AM Sebastien Lorquet 
> wrote:
>
> > Hi,
> >
> > Currently in ipv4_input.c we have a warning that a packet was not for us
> > and was dropped. This pollutes the output of the console for no real
> > value when connected to a real network.
> >
> > I suggest we turn this warning into an info to keep things clean.
> >
> > The file contains real warnings that are much more important and
> > relevant that this line.
> >
> >
> > Could be configurable (with a potential CONFIG_NET_IP_NOTFORUS_WARN) or
> > fixed, here is the relevant code.
> >
> > I can send a PR but I would like your general feeling on this issue
> > first, thank you!
> >
> > Sebastien
> >
> >
> > diff --git a/net/devif/ipv4_input.c b/net/devif/ipv4_input.c
> > index bb16940cbf..bb109f353d 100644
> > --- a/net/devif/ipv4_input.c
> > +++ b/net/devif/ipv4_input.c
> > @@ -310,8 +310,13 @@ int ipv4_input(FAR struct net_driver_s *dev)
> >  * packet.
> >  */
> >
> > +#ifdef CONFIG_NET_IP_NOTFORUS_WARN
> > nwarn("WARNING: Not destined for us; not forwardable... "
> >   "Dropping!\n");
> > +#else
> > +  ninfo("WARNING: Not destined for us; not forwardable... "
> > +"Dropping!\n");
> > +#endif
> >
> >   #ifdef CONFIG_NET_STATISTICS
> > g_netstats.ipv4.drop++;
> >
> >

Re: [VOTE] Apache NuttX 10.3.0 (incubating) RC4 release

[Abdelatif Guettouche]

+1 to release.
The only issue we had with the previous RC was the disclaimer, and now
it's there!

On Wed, Jun 8, 2022 at 8:17 AM Alin Jerpelea  wrote:
>
> Hello all,
> Apache NuttX (Incubating) 10.3.0 RC4 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-RC4
>   Hash for the release incubating-nuttx tag:
> 3fb5737958000d6e786a885af1a576e4d7bd5ada
>   Hash for the release incubating-nuttx-apps tag:
> 10c75df01cfb65d3d865313ebc03af6aec8505e5
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.3.0-RC4/
> [2]https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.3.0-RC4/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: "make menuconfig" break build-ability on ESP32-Ethernet-kit

[Abdelatif Guettouche]

> No directory at /home/micha/nuttxspace/nuttx//src

It looks like you are trying to use a custom board but didn't set the
options and the path correctly.

On Thu, Jun 16, 2022 at 8:43 AM  wrote:
>
> Dear all,
>
> I am new to Nuttx, and I try to port Nuttx to our ESP32 board. I
> followed this article
> https://blog.espressif.com/getting-started-with-esp32-and-nuttx-fd3e1a3d182c
> what worked worked out. So good so far.
>
> But then: after a few "make menuconfig" and "make download
> ESPTOOL_PORT=/dev/ttyUSB0 ESPTOOL_BAUD=115200
> ESPTOOL_BINDIR=../esp-bins" cycles (maybe 3 or 5), the build structure
> is broken. Here is the output:
>
> make menuconfig
> make[1]: Entering directory '/home/micha/nuttxspace/nuttx'
> make[2]: Entering directory '/home/micha/nuttxspace/nuttx/boards'
> make[2]: Nothing to be done for 'clean_context'.
> make[2]: Leaving directory '/home/micha/nuttxspace/nuttx/boards'
> make[2]: Entering directory '/home/micha/nuttxspace/apps'
> make[3]: Entering directory '/home/micha/nuttxspace/apps/platform'
> make[3]: Leaving directory '/home/micha/nuttxspace/apps/platform'
> make[3]: Entering directory '/home/micha/nuttxspace/apps/builtin'
> make[3]: Leaving directory '/home/micha/nuttxspace/apps/builtin'
> make[2]: Leaving directory '/home/micha/nuttxspace/apps'
> make[2]: Entering directory '/home/micha/nuttxspace/nuttx/graphics'
> make[3]: Entering directory
> '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> make[3]: Leaving directory
> '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> make[3]: Entering directory
> '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> make[3]: Leaving directory
> '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> make[3]: Entering directory
> '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> make[3]: Leaving directory
> '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> make[2]: Leaving directory '/home/micha/nuttxspace/nuttx/graphics'
> make[1]: Leaving directory '/home/micha/nuttxspace/nuttx'
> make[1]: Entering directory '/home/micha/nuttxspace/nuttx'
> CP: arch/dummy/Kconfig to
> /home/micha/nuttxspace/nuttx/arch/dummy/dummy_kconfig
> CP: boards/dummy/Kconfig to /home/micha/nuttxspace/nuttx//Kconfig
> make[2]: Entering directory '/home/micha/nuttxspace/apps'
> make[3]: Entering directory '/home/micha/nuttxspace/apps/platform'
> LN: platform/board to /home/micha/nuttxspace/apps/platform/dummy
> make[3]: Leaving directory '/home/micha/nuttxspace/apps/platform'
> make[2]: Leaving directory '/home/micha/nuttxspace/apps'
> LN: include/arch to arch/xtensa/include
> LN: include/arch/board to /home/micha/nuttxspace/nuttx//include
> LN: drivers/platform to /home/micha/nuttxspace/nuttx/drivers/dummy
> LN: include/arch/chip to
> /home/micha/nuttxspace/nuttx/arch/xtensa/include/esp32
> /home/micha/nuttxspace/nuttx/tools/link.sh
> /home/micha/nuttxspace/nuttx/arch/xtensa/include/esp32 include/arch/chip
> LN: arch/xtensa/src/chip to
> /home/micha/nuttxspace/nuttx/arch/xtensa/src/esp32
> LN: arch/xtensa/src/board to
> /home/micha/nuttxspace/nuttx/boards/xtensa/esp32/common
> LN: arch/xtensa/src/board/board to /home/micha/nuttxspace/nuttx//src
> No directory at /home/micha/nuttxspace/nuttx//src
> make[1]: *** [tools/Unix.mk:288: arch/xtensa/src/board/board] Error 1
> make[1]: Leaving directory '/home/micha/nuttxspace/nuttx'
> make: *** [tools/Unix.mk:611: menuconfig] Error 2
> micha@iwan-ThinkPad-T440p:~/nuttxspace/nuttx$
>
> My Computer run X86 Ubuntu 22.04, and I got the latest Nuttx via
> git clone https://github.com/apache/incubator-nuttx.git nuttx
>
> Then I was in doubt, if the version of the kconfig-frontend could
> trouble with Ubuntu 22. I installed it with sudo apt install
> kconfig-frontends. So I removed it again, and compiled it from scratch
> from git clone https://bitbucket.org/nuttx/tools.git tools. But the same
> result.
>
> I am now able to reproduce the error:
> 1. delete /nuttxspace/nuttx.
> 2. git clone https://github.com/apache/incubator-nuttx.git nuttx
> 3. ./tools/configure.sh esp32-ethernet-kit:ethernet
> 4. make menuconfig, and modify something. I have attached the modified
> .config, plus the config.old, what is the original .config before
> modification.
> 5. from here on, all make attempts fail(make clean, make menuconfig,
> make distclean).
>
> Any idea how I can fix that?

Re: "make menuconfig" break build-ability on ESP32-Ethernet-kit

[Abdelatif Guettouche]

>From your .config file:

CONFIG_ARCH_BOARD_CUSTOM_NAME=""
CONFIG_ARCH_BOARD_CUSTOM_DIR=""

Please set these to their correct values.

On Thu, Jun 16, 2022 at 9:43 AM Abdelatif Guettouche
 wrote:
>
> > No directory at /home/micha/nuttxspace/nuttx//src
>
> It looks like you are trying to use a custom board but didn't set the
> options and the path correctly.
>
> On Thu, Jun 16, 2022 at 8:43 AM  wrote:
> >
> > Dear all,
> >
> > I am new to Nuttx, and I try to port Nuttx to our ESP32 board. I
> > followed this article
> > https://blog.espressif.com/getting-started-with-esp32-and-nuttx-fd3e1a3d182c
> > what worked worked out. So good so far.
> >
> > But then: after a few "make menuconfig" and "make download
> > ESPTOOL_PORT=/dev/ttyUSB0 ESPTOOL_BAUD=115200
> > ESPTOOL_BINDIR=../esp-bins" cycles (maybe 3 or 5), the build structure
> > is broken. Here is the output:
> >
> > make menuconfig
> > make[1]: Entering directory '/home/micha/nuttxspace/nuttx'
> > make[2]: Entering directory '/home/micha/nuttxspace/nuttx/boards'
> > make[2]: Nothing to be done for 'clean_context'.
> > make[2]: Leaving directory '/home/micha/nuttxspace/nuttx/boards'
> > make[2]: Entering directory '/home/micha/nuttxspace/apps'
> > make[3]: Entering directory '/home/micha/nuttxspace/apps/platform'
> > make[3]: Leaving directory '/home/micha/nuttxspace/apps/platform'
> > make[3]: Entering directory '/home/micha/nuttxspace/apps/builtin'
> > make[3]: Leaving directory '/home/micha/nuttxspace/apps/builtin'
> > make[2]: Leaving directory '/home/micha/nuttxspace/apps'
> > make[2]: Entering directory '/home/micha/nuttxspace/nuttx/graphics'
> > make[3]: Entering directory
> > '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> > make[3]: Leaving directory
> > '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> > make[3]: Entering directory
> > '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> > make[3]: Leaving directory
> > '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> > make[3]: Entering directory
> > '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> > make[3]: Leaving directory
> > '/home/micha/nuttxspace/nuttx/graphics/nxglib'
> > make[2]: Leaving directory '/home/micha/nuttxspace/nuttx/graphics'
> > make[1]: Leaving directory '/home/micha/nuttxspace/nuttx'
> > make[1]: Entering directory '/home/micha/nuttxspace/nuttx'
> > CP: arch/dummy/Kconfig to
> > /home/micha/nuttxspace/nuttx/arch/dummy/dummy_kconfig
> > CP: boards/dummy/Kconfig to /home/micha/nuttxspace/nuttx//Kconfig
> > make[2]: Entering directory '/home/micha/nuttxspace/apps'
> > make[3]: Entering directory '/home/micha/nuttxspace/apps/platform'
> > LN: platform/board to /home/micha/nuttxspace/apps/platform/dummy
> > make[3]: Leaving directory '/home/micha/nuttxspace/apps/platform'
> > make[2]: Leaving directory '/home/micha/nuttxspace/apps'
> > LN: include/arch to arch/xtensa/include
> > LN: include/arch/board to /home/micha/nuttxspace/nuttx//include
> > LN: drivers/platform to /home/micha/nuttxspace/nuttx/drivers/dummy
> > LN: include/arch/chip to
> > /home/micha/nuttxspace/nuttx/arch/xtensa/include/esp32
> > /home/micha/nuttxspace/nuttx/tools/link.sh
> > /home/micha/nuttxspace/nuttx/arch/xtensa/include/esp32 include/arch/chip
> > LN: arch/xtensa/src/chip to
> > /home/micha/nuttxspace/nuttx/arch/xtensa/src/esp32
> > LN: arch/xtensa/src/board to
> > /home/micha/nuttxspace/nuttx/boards/xtensa/esp32/common
> > LN: arch/xtensa/src/board/board to /home/micha/nuttxspace/nuttx//src
> > No directory at /home/micha/nuttxspace/nuttx//src
> > make[1]: *** [tools/Unix.mk:288: arch/xtensa/src/board/board] Error 1
> > make[1]: Leaving directory '/home/micha/nuttxspace/nuttx'
> > make: *** [tools/Unix.mk:611: menuconfig] Error 2
> > micha@iwan-ThinkPad-T440p:~/nuttxspace/nuttx$
> >
> > My Computer run X86 Ubuntu 22.04, and I got the latest Nuttx via
> > git clone https://github.com/apache/incubator-nuttx.git nuttx
> >
> > Then I was in doubt, if the version of the kconfig-frontend could
> > trouble with Ubuntu 22. I installed it with sudo apt install
> > kconfig-frontends. So I removed it again, and compiled it from scratch
> > from git clone https://bitbucket.org/nuttx/tools.git tools. But the same
> > result.
> >
> > I am now able to reproduce the error:
> > 1. delete /nuttxspace/nuttx.
> > 2. git clone https://github.com/apache/incubator-nuttx.git nuttx
> > 3. ./tools/configure.sh esp32-ethernet-kit:ethernet
> > 4. make menuconfig, and modify something. I have attached the modified
> > .config, plus the config.old, what is the original .config before
> > modification.
> > 5. from here on, all make attempts fail(make clean, make menuconfig,
> > make distclean).
> >
> > Any idea how I can fix that?

Re: NuttX-aware debugging.

[Abdelatif Guettouche]

> 1) Using OpenOCD + GDB: some years ago Mr. Masayuki-san submitted
support to OpenOCD get thread awareness;

The current support in upstream OpenOCD is outdated.  If you want to
use OpenOCD maybe you can try building from
https://github.com/Ouss4/openocd-esp32/tree/nuttx
Although I focused on Xtensa and RISC-V and did very little testing on
ARM, most of the code is platform independent.

On Wed, Jun 22, 2022 at 11:37 PM Fotis Panagiotopoulos
 wrote:
>
> Yes I enabled CONFIG_DEBUG_TCBINFO.
> (When disabled, debugging works normally but without being thread-aware).
>
> It seems that it is either a bug in the plugin itself, or something is
> wrong with my build.
>
> If it matters, I am using Fedora 36 with gcc (GCC) 12.1.1 20220507 (Red Hat
> 12.1.1-1)
>
> Maybe someone can provide me with a pre-build .so file to test if this is
> the cause?
>
>
>
>
> On Wed, Jun 22, 2022 at 10:30 PM Xiang Xiao 
> wrote:
>
> > Did you enable CONFIG_DEBUG_TCBINFO in your defconfig:
> > incubator-nuttx/Kconfig at master · apache/incubator-nuttx (github.com)
> >  > >
> > The plugin needs the g_tcbinfo to know the critical offset of the field in
> > tcb_s structure.
> >
> > On Thu, Jun 23, 2022 at 2:10 AM Fotis Panagiotopoulos  > >
> > wrote:
> >
> > > Hello,
> > >
> > > I am in need of debugging NuttX in a thread-aware fashion, as I still
> > hit a
> > > dead-lock in networking that I haven't managed to track down yet.
> > >
> > > I am using a custom target, based on the STM32F427VI and JLink as the
> > > debugger.
> > >
> > > I see that there is a plug-in for JLink GDB that was added in #4810.
> > > Unfortunately, I never got this working. I commented on the PR, but I got
> > > ignored.
> > >
> > > So:
> > >
> > > 1. I cannot build the plug-in.
> > > Running:
> > >
> > > make -C tools -f Makefile.host all
> > >
> > > I get:
> > >
> > > /usr/bin/ld: /tmp/cclxEqhk.o: relocation R_X86_64_32 against
> > > `.rodata.str1.8' can not be used when making a shared object; recompile
> > > with -fPIC
> > > collect2: error: ld returned 1 exit status
> > > make: *** [Makefile.host:231: jlink-nuttx.so] Error 1
> > >
> > > I added the -fPIC option, and it was built successfully.
> > > If this is actually the correct option, then I guess the makefile has to
> > be
> > > fixed?
> > >
> > >
> > > 2. After building the plug-in with -fPIC, it crashes during start with a
> > > segmentation fault.
> > >
> > > Here is an example output:
> > > https://pastebin.com/U1tqtMND
> > >
> > >
> > > Has anyone managed to use this?
> > > Any idea what the fault may be?
> > >
> >

Re: [ANNOUNCE] Apache NuttX 10.3.0-incubating released

[Abdelatif Guettouche]

First non-WIP release!  One step closer to graduation!

On Fri, Jun 24, 2022 at 7:47 AM Tomek CEDRO  wrote:
>
> CONGRATZ! :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: [ANNOUNCE] Apache NuttX 10.3.0-incubating released

[Abdelatif Guettouche]

> 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://incubator.apache.org/guides/graduation.html#before_you_graduate
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, http://www.tomek.cedro.info
> >

Re: [DISCUSS] Graduate NuttX as TLP

[Abdelatif Guettouche]

For the checklist, there are two points where we gonna need external
help, probably from our mentors:

1. Demonstrate ability to create Apache releases
2. Demonstrate community readiness

For the first one, Nathan has summarized above the work that has been
done.  We believe that the project has demonstrated the ability to
create Apache releases, but is there something else to consider?
For the second one, I'm not sure what it means.  If it's regarding the
health of the project technically, again Nathan has summarized the
accomplishments.  If it's regarding the conduct of the project with
regards to the Apache way, I believe we've been on track.

> 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!)

The apps one is confusing.  It doesn't indicate that it's part of
NuttX.  Actually, it doesn't indicate what project it belongs to at
all and I believe a lot of people would ask what this is.

On Mon, Jun 27, 2022 at 6:24 PM Alin Jerpelea  wrote:
>
> +1 for graduation
> and +1 for the joke idea
>
> Thanks
> Alin
>
> On Mon, 27 Jun 2022, 19:18 Alan Carvalho de Assis, 
> wrote:
>
> > Hahaha, I liked that joke! Alin, please use this same joke in the NuttX
> > Online Workshop thread!
> >
> > +1 to graduation!
> >
> > 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!)
> >
> > BR,
> >
> > Alan
> >
> > On Monday, June 27, 2022, Nathan Hartman  wrote:
> >
> > > On Fri, Jun 24, 2022 at 12:46 PM Nathan Hartman
> > >  wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > It's time to start the [DISCUSS] thread about GRADUATION!
> > > >
> > > > Project Highlights Since Incubation:
> > > >
> > > > * Incubating since 2019-12-09
> > > > * New website, nuttx.apache.org
> > > > * Shipped 8 releases under the ASF Incubator, including our first
> > > > non-WIP release
> > > > * Merged more than 7000 PRs across incubator-nuttx and
> > > incubator-nuttx-apps
> > > > * More than 1000 stars on GitHub
> > > > * More than 500 forks on GitHub
> > > > * More than 250 subscribers to dev@nuttx.apache.org
> > > > * 9th most active Apache project of 2021 by number of commits [1]
> > > > * 5 mentors
> > > > * 17 PPMC members
> > > > * 25 committers
> > > > * 75 ICLAs
> > > > * 2 CCLAs
> > > > * 21 SGAs
> > > > * 2 release managers
> > > > * 2 NuttX online workshops
> > > > * And much, much more
> > > >
> > > > Let's go through the checklist [2], discuss any remaining open issues,
> > > > and get this process going!
> > > >
> > > > References:
> > > > [1] https://thestack.technology/top-apache-projects-in-2021-
> > > from-superset-to-nuttx/
> > > > [2] https://incubator.apache.org/guides/graduation.html#before_
> > > you_graduate
> > > >
> > > > Cheers,
> > > > Nathan
> > >
> > > Ping... Don't all reply at once!
> > >
> > > Cheers,
> > > Nathan
> > >
> >

Re: [DISCUSS] Graduate NuttX as TLP

[Abdelatif Guettouche]

Yes, we can do that, and this is what most of us do (although I forgot
the last time I had to clone the repos).  On the other hand,
./configure accepts a different apps path with the -a option.  It just
defaults to ../apps, but technically it can be anywhere and named
anything.

On Tue, Jun 28, 2022 at 12:18 AM Nathan Hartman
 wrote:
>
> On Mon, Jun 27, 2022 at 5:56 PM Alan Carvalho de Assis
>  wrote:
> >
> > On 6/27/22, Abdelatif Guettouche  wrote:
> > > For the checklist, there are two points where we gonna need external
> > > help, probably from our mentors:
> > >
> > > 1. Demonstrate ability to create Apache releases
> > > 2. Demonstrate community readiness
> > >
> > > For the first one, Nathan has summarized above the work that has been
> > > done.  We believe that the project has demonstrated the ability to
> > > create Apache releases, but is there something else to consider?
> > > For the second one, I'm not sure what it means.  If it's regarding the
> > > health of the project technically, again Nathan has summarized the
> > > accomplishments.  If it's regarding the conduct of the project with
> > > regards to the Apache way, I believe we've been on track.
> > >
> > >> 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!)
> > >
> > > The apps one is confusing.  It doesn't indicate that it's part of
> > > NuttX.  Actually, it doesn't indicate what project it belongs to at
> > > all and I believe a lot of people would ask what this is.
> > >
> >
> > Yes, that is the point! Probably they will not accept it because it
> > could confuse other people, but probably having a README.md could be
> > enough to make it clear. Alternatively we could to modify the build
> > system for accept ../apps and ../nuttx_apps.
>
>
> Is it too difficult to do:
>
> (HYPOTHETICAL command, if apps is called nuttx-apps)
>
> $ git clone https://github.com/apache/nuttx-apps apps
>
> ?
>
> In effect we would strip the "incubator-" prefix from both
> repositories and call it done.
>
> Cheers,
> Nathan

Re: [DISCUSS] Graduate NuttX as TLP

[Abdelatif Guettouche]

It would be nice to hear from the mentors or anyone from the IPMC.

On Wed, Jul 13, 2022 at 12:07 AM Nathan Hartman
 wrote:
>
> Hi all,
>
> As this [DISCUSS] thread has quieted down for quite some days now,
> shall we have a [VOTE] thread or does anyone have additional thoughts
> to share?
>
> I'll wait another 72 hours before beginning a [VOTE] thread to give a
> chance to anyone who would like to speak up. Now's the time!!
>
> Cheers,
> Nathan
>
> On Fri, Jun 24, 2022 at 12:46 PM Nathan Hartman
>  wrote:
> >
> > Hi folks,
> >
> > It's time to start the [DISCUSS] thread about GRADUATION!
> >
> > Project Highlights Since Incubation:
> >
> > * Incubating since 2019-12-09
> > * New website, nuttx.apache.org
> > * Shipped 8 releases under the ASF Incubator, including our first
> > non-WIP release
> > * Merged more than 7000 PRs across incubator-nuttx and incubator-nuttx-apps
> > * More than 1000 stars on GitHub
> > * More than 500 forks on GitHub
> > * More than 250 subscribers to dev@nuttx.apache.org
> > * 9th most active Apache project of 2021 by number of commits [1]
> > * 5 mentors
> > * 17 PPMC members
> > * 25 committers
> > * 75 ICLAs
> > * 2 CCLAs
> > * 21 SGAs
> > * 2 release managers
> > * 2 NuttX online workshops
> > * And much, much more
> >
> > Let's go through the checklist [2], discuss any remaining open issues,
> > and get this process going!
> >
> > References:
> > [1] 
> > https://thestack.technology/top-apache-projects-in-2021-from-superset-to-nuttx/
> > [2] https://incubator.apache.org/guides/graduation.html#before_you_graduate
> >
> > Cheers,
> > Nathan

Re: build board from custom directory

[Abdelatif Guettouche]

There is an option for relative links. The you can pass the path to
configure.sh
Like configure.sh ../boards/custom-board/config/nsh

On Thu, Sep 15, 2022 at 12:25 PM TimH  wrote:

> A few weeks ago I moved my custom board out of the NuttX
> "nuttx/nuttx/boards" tree to a folder "nuttx/CustomBoards".
>
>
>
> Make menuconfig allows you to specify that folder
> (CONFIG_ARCH_BOARD_CUSTOM_DIR=)
>
>
>
> To try and rule out .config errors for some issues I have at the moment I
> did a make distclean. Which wipes out the .config and the reference to my
> custom board directory.
>
>
>
> What is the correct syntax to tell configure.sh that the board is in a
> custom folder, please?
>
>

Re: [apache/incubator-nuttx] tools/configure.sh: Update USAGE for custom out-of-tree boards (PR #7103)

[Abdelatif Guettouche]

Did you check the "external" directory or are you looking for something
else?

Basically the external directory allows you to symlink an out of tree
repository (or repositories) that should contain, at least, the minimal
build glues (Makefile and Make.defs).  The build system should pick up the
rest.
The external directory is ignored from the tracking system so nothing
impacts the actual apps repo.

On Tue, Oct 11, 2022 at 8:07 PM Tim Hardisty 
wrote:

> I have walked through the custom apps guide from the cwiki and find that
> it is explaining how to replace the ENTIRE Nuttx Apps directory with a
> custom alternative.
>
> That seems to me to be perhaps of minority interest but I'll include it in
> the documentation I'm writing anyway for completeness.
>
> But is there a way to add a custom folder - in or out of tree - that will
> be included along with the built-in apps and examples? This would allow you
> to include custom appss, and the built-in ones, but not have a problem when
> merging future releases that might cause the building in of the custom apps
> to fail?
>
> Perhaps I'm over thinking it?
>
> On 07/10/2022, 17:25, "TimH"  wrote:
>
> Got it - thanks Nathan. I will probably plunder some text from the
> cwiki then, and not feel guilty :-)
>
> >-Original Message-
> >From: Nathan Hartman 
> >Sent: 07 October 2022 17:23
> >To: dev@nuttx.apache.org
> >Subject: Re: [apache/incubator-nuttx] tools/configure.sh: Update
> USAGE for
> >custom out-of-tree boards (PR #7103)
> >
> >On Fri, Oct 7, 2022 at 11:59 AM TimH  wrote:
> >>
> >> As per request below, I’m happy to add a paragraph or two regarding
> this,
> >but I am not sure where it should go?
> >>
> >> It could be a section in “guides” or I could add it to the FAQ.
> What is
> >preferred, assuming the Documentation folder in the repo is actually
> the right
> >place for this of course?
> >
> >I think it would best fit in guides under the Documentation folder in
> the repo,
> >and I think that's where all "official" documentation should
> ultimately be.
> >
> >> Related to this, what is the significance of the cwiki
> >(https://cwiki.apache.org/confluence/display/NUTTX) as that has a
> lot more
> >information in it compared to the Nuttx distro’s Documentation
> folder, but is
> >outdated and perhaps not maintained I think? The cwiki has
> information on
> >custom app directory usage that could either be a source of info for
> a more
> >complete “custom environment” guide or is the actually the intended
> place
> >for the custom boards info I’ve been asked to add?
> >
> >From my memory, before NuttX joined the Apache.org Incubator, what's
> now
> >in the CWIKI was in a MediaWiki on the NuttX website. When we joined
> the
> >Incubator, this was somehow migrated to the Apache.org CWIKI. Some (or
> >most?) of it was then migrated again into what is now the
> Documentation
> >folder in the repo. However, there are some differences between the
> two
> >because new documentation has been written under Documentation while
> >some of the docs available in the CWIKI may not have been migrated,
> and I
> >think there are still articles in the CWIKI that have not made it into
> >Documentation.
> >
> >As to what's the purpose of the CWIKI: Some time ago, I asked whether
> we
> >should keep the CWIKI around. Now I can't seem to locate that email
> after a
> >quick search, but as I remember, a few people said they would like to
> keep
> >the CWIKI as a place to collaborate on documentation, as it makes
> real-time
> >collaborative writing easier (without the added friction of making
> PRs) and
> >then migrate finished documents into Documentation.
> >
> >In short, there's some work yet to be done on documentation and it
> isn't a
> >secret that we, like probably most community-driven projects, need
> lots of
> >help improving our documentation!!!
> >
> >Hope that helps. I'd like to say a sincere THANK YOU for any
> improvements
> >you're willing to make, large or small!
> >
> >Cheers,
> >Nathan
>
>
>
>

Re: [VOTE] Apache NuttX Community Graduation

[Abdelatif Guettouche]

+1!

On Sat, Oct 22, 2022 at 5:28 AM Xiang Xiao 
wrote:

> +1!!!
>
> On Fri, Oct 21, 2022 at 8:47 PM Nathan Hartman 
> wrote:
>
> > Dear Apache NuttX Community,
> >
> > Following the [DISCUSS] thread which has gone 72 hours without any
> > further issues raised [1]:
> >
> > This is a call to VOTE on Graduation of Apache NuttX from the
> > Incubator to Top-Level Project (TLP).
> >
> > Please vote:
> >
> > [ ] +1: Apache NuttX is ready to graduate to TLP
> > [ ]  0: No opinion
> > [ ] -1: Apache NuttX is NOT ready to graduate; please state reason(s)
> >
> > If this community vote passes, we will proceed to the next steps. The
> > graduation process is documented at [2]. The vote will remain open for
> > at least 72 hours. A minimum of 3 binding +1 votes and more binding +1
> > than binding -1 are required to pass. The ASF requirements for voting
> > can be found at [3].
> >
> > Project Highlights Since Incubation:
> > * Incubating since 2019-12-09
> > * Website migrated to nuttx.apache.org
> > * Shipped 9 releases under the ASF Incubator
> > * Merged 8000 PRs across incubator-nuttx and incubator-nuttx-apps
> > * More than 1000 stars on GitHub
> > * More than 500 forks on GitHub
> > * More than 250 subscribers to dev@nuttx.apache.org
> > * In Top 10 Apache projects of 2021 by number of commits [4]
> > * 5 mentors
> > * 18 PPMC members
> > * 26 committers
> > * 75 ICLAs
> > * 2 CCLAs
> > * 21 SGAs
> > * 2 release managers
> > * 3 NuttX online workshops
> > * And much, much more
> >
> > Let me express a big ***THANK YOU*** to everyone for helping make this
> > possible!
> >
> > [1] https://lists.apache.org/thread/vpj21ofyxmjs528n3b9s72wozh9hjz8f
> >
> > [2]
> >
> https://incubator.apache.org/guides/graduation.html#graduating_to_a_top_level_project
> >
> > [3] https://www.apache.org/foundation/voting.html
> >
> > [4]
> >
> https://thestack.technology/top-apache-projects-in-2021-from-superset-to-nuttx/
> >
> > Cheers,
> > Nathan Hartman
> >
>

Re: libpq and libscpi: how to start

[Abdelatif Guettouche]

> Are there provisions to use a pre-downloaded tarball for external projects?

There is none at the moment. However, an option can be added to just
copy from a local folder instead of downloading them.  Or the makefile
can start with that and fallback to downloading if the tarball is not
present.  Couple of things could be cumbersome here:
   1. Options to choose between local and download.  Plus options for
local path to copy from.
   2. The makefile of every external project interested in this will
need to be updated.


On Thu, Nov 3, 2022 at 11:55 AM Alan C. Assis  wrote:
>
> Hi Sebastien,
>
> Good question, AFAIK there is not yet a command to just download the
> necessary tar balls and keep them in a downloaded area to use later.
>
> If I remember correctly some build systems like Buildroot and Yocto
> has this option.
>
> BR,
>
> Alan
>
> On 11/3/22, Sebastien Lorquet  wrote:
> > Hi,
> >
> > littlefs too.
> >
> > This raises an important question for me: how do I handle such a build
> > in a self-contained, "airgapped" machine?
> >
> > Are there provisions to use a pre-downloaded tarball for external projects?
> >
> > Sebastien
> >
> > Le 28/10/2022 à 18:30, Alan C. Assis a écrit :
> >> Hi Sebastien,
> >>
> >> AFAIK there is not such directive, although it is always need to add
> >> support to NuttX on external projects.
> >>
> >> External projects needs to be integrated to be downloaded and compiled
> >> dynamically, once again like LVGL.
> >>
> >> BR,
> >>
> >> Alan
> >>
> >> On 10/28/22, Sebastien Lorquet  wrote:
> >>> IIRC the idea was that we dont integrate code fom externally maintained
> >>> projects?
> >>>
> >>> Also IIRC the acceptable method is a specific makefile that downloads
> >>> code and patch/builds it.
> >>>
> >>> I agree that such libs go into apps.
> >>>
> >>> Sebastien
> >>>
> >>> Le 27/10/2022 à 19:28, Nathan Hartman a écrit :
>  On Thu, Oct 27, 2022 at 12:19 PM Alan C. Assis 
>  wrote:
> 
> > Hi Michael,
> >
> > I think someone else told some time ago that he used a similar lib for
> > mysql, I think it was Ivan.
> >
> > Those libs inside nuttx/libs/ are libs used by the kernel and apps,
> > but in this case the lib should be put inside apps/databases/postgres
> > for example. It should be a lib just like apps/graphics/lvgl and many
> > others.
>  I agree with that; nothing prevents applications from using the libs
>  under
>  apps.
> 
>  If they require kernel support then that might be another thing.
> 
>  Cheers
>  Nathan
> 
> >

Re: New names of repositories

[Abdelatif Guettouche]

nuttx and nuttx-apps for me too. For the hyphen, as it was said before
people can clone the repo under any name they want.  We've been doing
this ever since we joined the incubator and this is how we're
instructing people too:
https://nuttx.apache.org/docs/latest/quickstart/install.html#download-nuttx

On Sat, Nov 19, 2022 at 6:42 AM fft  wrote:
>
> sorry for my tentative idea!
>
>
> BR,
>
>
>
> ---Original---
> From: "Gregory Nutt" Date: Sat, Nov 19, 2022 08:26 AM
> To: "dev" Subject: Re: New names of repositories
>
>
> > Isn't it possible to merge the nuttx and apps into only one
> repository？e.g:
> >  > |-rtos
> > |-apps
>
> We discussed this option a couple of years ago and decided against it.  I
> was VERY strongly opposed to the idea then and I still am.
>
> - apps is NOT part of NuttX.  It is an achitecturally unrelated, mish 
> mash
> or useful applications for NuttX, but it is not NuttX.
> - I consists of mostly 3rd party code and should not contaminate the clean
> modularity of the OS.
>
> If we want to consider this kind of code change than I would insist on a
> vote and I most certainly would vote -1.  I don't care about care about
> hyphens or other cosmetics but I would not support any such corruption of
> the modularity of the RTOS.
>
> This must never happen.

Re: DISCUSS: migrate licenses to SPDX

[Abdelatif Guettouche]

We need to consider this:
https://www.apache.org/foundation/license-faq.html#Apply-My-Software

> 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://spdx.dev/
>
> Do you think that we should follow the trend and migrate our licenses to
> the SPDX format?
>
> Best regards
> Alin

Re: ESP32 Memory Allocation

[Abdelatif Guettouche]

There is no threshold or a way to decide where malloc will get its memory from.
The memory available for the allocator is both the internal (SRAM) and
external SPIRAM, if your request cannot be honored from the internal
memory then the allocator will look into the external memory (but it's
not deterministic, it depends on the state of the heap.)
In a way you can say that the threshold to choose external memory is
the size + 1 of the available internal memory.

There is also a way to use part of SRAM as a separate heap.  This can
only be used inside the kernel with a specific API and malloc will not
have access to it.

On Mon, Dec 19, 2022 at 2:27 PM Victor Benso  wrote:
>
> Hello,
>
> I'm running NuttX on an ESP32 with SPIRAM, when using malloc in an app,
> what is the threshold, if any,  used in the decision of allocating internal
> or external memory?
> Is this a config parameter?
> Is there a proper way to control which region (internal or external) a
> specific allocation will happen?
>
>
> Victor A. P. Benso
>
> (47) 999-229-599
> (65) 999-186-147

[Test] Joined

[Abdelatif Guettouche]

Reply if you get this message.

Thanks.

Re: [Test] Joined

[Abdelatif Guettouche]

It is!

On Tue, Dec 10, 2019, 00:50  wrote:

>  [Test] Joined
>
> Is it alive?
>
> David
>

Re: Question about structure roadmap

[Abdelatif Guettouche]

Hi,

Some chaos was expected. The project is still on the road of moving.

The main communication channel is the dev list now.
The google group is still operational but that won't be for too long. It
will either get archived or posters will be redirected to the dev mailing
list..
The Slack channel will likely go away.

Changes are still accepted on the Bitbucket repositories until the Apache
ones are up and running.
I don't think you need to sign an ICLA to be able to contribute. (Please
see also the thread "ICLA needed?")



On Sun, Dec 15, 2019 at 9:41 AM Justin Mclean 
wrote:
>
> Hi,
>
> > Can someone make things more clear by making a roadmap or something?
>
> It’s up to the PMC to discuss and do this. I think more discussion need
to happen on this issues on this list.
>
> Thanks,
> Justin

Re: Add some instructions or make the link available on Nuttx home page

[Abdelatif Guettouche]

Hi Flavio,

The dev mailing list seems not updated:
d...@project.incubator.apache.org instead of
d...@nuttx.incubator.apache.org

On Mon, Dec 16, 2019 at 3:05 PM Flavio Junqueira  wrote:
>
> Hi Jincheng,
>
> The status page is now live and being populated:
>
> http://incubator.apache.org/projects/nuttx.html
>
> I'm not sure where the broken link in the main apache.org page is.
>
> -Flavio
>
> > On 16 Dec 2019, at 08:07, jincheng sun  wrote:
> >
> > I found there is a link of NuttX is not work in home page of 
> > `apache.org`[1].
> > So, I create a JIRA for this issue [2]. But I found is not the issue for `
> > apache.org` but something worng in NuttX home page [3]. I do not know how
> > to deal with this kind of problems, so, report the problems in this
> > maillist.
> >
> > Best,
> > Jincheng
> >
> > [1] http://apache.org/
> > [2] https://issues.apache.org/jira/browse/INFRA-19576
> > [3] http://incubator.apache.org/projects/nuttx.html
>

Re: Apache Account Setup

[Abdelatif Guettouche]

Yes they recommend the key to be with an @apache.org email.
But we can add an email to an existing key.

gpg --edit-key 

We then can add an new email through the gpg cli and upload it when we're done.

On Wed, Dec 18, 2019 at 2:12 PM Gregory Nutt  wrote:
>
>
> >> I saw the option to send the SSH keys, so I suppose we will need to fill it
> >> later (for those who didn't it yet).
> > Also if you do not have your PGP keys yet, you should do that soon. These
> > are needed for cryptographically signing releases. Several people need to
> > sign each release in order to release it.
> >
> > See:
> >
> > https://www.apache.org/dev/new-committers-guide.html#set-up-security-and-pgp-keys
> >
> > and the more detailed document here:
> >
> > https://www.apache.org/dev/release-signing.html
>
> I assume that this should be the @apache.org?
>
> Then if we have existing keys all we should have to do is:
>
> |gpg --edit-key @apache.org|
>
> |Right?|
>
> |Greg
> |
>
> ||
>

Re: Getting Started (Was Re: [DISCUSS - NuttX Workflow])

[Abdelatif Guettouche]

Boards readme files contain all the information needed to get started
with a particular board.

On Wed, Dec 18, 2019 at 5:01 PM Gregory Nutt  wrote:
>
> On 12/18/2019 10:47 AM, Nathan Hartman wrote:
> > On Wed, Dec 18, 2019 at 11:04 AM David Sidrane  wrote:
> >> What about the people who are just learning Nuttx? Simple is relative.
> > We never had a Getting Started guide. We need one. And because it's so
> > hard for someone "in the know" not to assume knowledge, we may need
> > the help of some total n00bs to get this guide written -- to see where
> > they get stuck and waste time looking for answers, and write those
> > things in the guide. But that's a subject for another thread.
>
> There is this: http://www.nuttx.org/doku.php?id=wiki:getting-started
> where the "external tutorials" is quite extensive:
> http://www.nuttx.org/doku.php?id=wiki:getting-started:external-tutorials
>

Re: Getting Started (Was Re: [DISCUSS - NuttX Workflow])

[Abdelatif Guettouche]

> I'd prefer that the Getting Started guide should be reachable by one
> click from the front page of the NuttX website (which doesn't exist
> yet), so that a TOTAL newbie who hasn't even gotten the code yet can
> read and get a feel for what's involved.

Agree.
I wanted to point out that much of the content needed to make such a
document is already in place.

> Yes, much of the information is in the README file. Perhaps we can
> modify text files like that to be in Markdown format, which unlike
> HTML, leaves the file looking like a normal ASCII file, but allows the
> file to be converted to other formats, including HTML, using automated
> tools. Then we could convert that information and display it directly
> on the website.

That would helpful.
Some of the readme files are already (almost) in Markdown format.


On Wed, Dec 18, 2019 at 5:46 PM Nathan Hartman  wrote:
>
> On Wed, Dec 18, 2019 at 12:01 PM Gregory Nutt  wrote:
> > There is this: http://www.nuttx.org/doku.php?id=wiki:getting-started
> > where the "external tutorials" is quite extensive:
> > http://www.nuttx.org/doku.php?id=wiki:getting-started:external-tutorials
>
> That's great but I think we need our own basic Getting Started guide
> that gets a total newbie off the ground quickly; it can, of course,
> have an "Additional Resources" section with links to all of these
> other resources.
>
> On Wed, Dec 18, 2019 at 12:31 PM Abdelatif Guettouche
>  wrote:
> > Boards readme files contain all the information needed to get started
> > with a particular board.
>
> Again, that's great, but it presumes that you have the code, know
> about the board READMEs, know where they are...
>
> I'd prefer that the Getting Started guide should be reachable by one
> click from the front page of the NuttX website (which doesn't exist
> yet), so that a TOTAL newbie who hasn't even gotten the code yet can
> read and get a feel for what's involved.
>
> Yes, much of the information is in the README file. Perhaps we can
> modify text files like that to be in Markdown format, which unlike
> HTML, leaves the file looking like a normal ASCII file, but allows the
> file to be converted to other formats, including HTML, using automated
> tools. Then we could convert that information and display it directly
> on the website.
>
> Nathan

Re: Transferring Repositories

[Abdelatif Guettouche]

Hi,

They should be in sync now.
Those were probably created just after the transfer.

On Fri, Dec 20, 2019 at 9:28 PM Gregory Nutt  wrote:

>
> >> I don't know if there are any problems with doing this with tags, but
> >> we cannot do this which commits without eventually really mucking up
> >> the history.
> >>
> >> Commits must go in on direction.  For the time being, I think it must
> >> work like this:
> >>
> >>   * There must be no changes directly to the apache repositories
> >>   * All changes to the apache repositories must be pull from the
> >> Bitbucket repositories.
> >>
> >> Whenever the PPMC determines that it is time for the transition, we
> >> must switch this:
> >>
> >>   * There must be no changs to directly to the Bitbucket repoositories
> >>   * All changes the Bitbuckbucket repositories must be pulled from
> >> the Apache repositories.
> >>
> > Hmm.. I see Xaio Xiang has proposed just the opposite:
> >
> > We can use the mix style before...@nuttx.apache.org  could add the
> attachment:
> >
> > 1.Patch send in the google group
> > 2.Greg commit to ASF' repo
> >
> > And then improvde the process step by step:
> >
> > 1.Instruct people send patch to...@nuttx.apache.org  once the
> attachment work
> > 2.Greg stop submit patch directly once the new automation workflow is
> ready
> >
> > I think once the code transfer to ASF, we should start to commit the
> > patch to ASF' repo immediately, and mirror the change to bitbucket.
> >
> > I suppose we have to decide. I have talking the flow at the top for
> > sometime and assumed that is what we are going. The other is possible
> > too. I suppose the PPMC should decide.
>
> The Apache repository started out 3 commits behind the Bitbucket
> repository:
>
> commit 54d6a0768ccd0e386b67723cc1a24e9e9fff902a
> Author: Daniel Pereira Volpato 
> Date:   Fri Dec 20 13:07:31 2019 -0600
>
>  boards/arm/stm32f0l0g0/:  Fix issues noted by nxstyle.
>
> commit b9638de3887d6a715c95bb4ee311ab4c52c33ff0
> Author: Guillherme Amaral 
> Date:   Fri Dec 20 13:04:34 2019 -0600
>
>  boards/arm/stm32f0l0g0/nucleo-g070rb:  Enable I2C.
>
> commit eeed40aa0ce4e6e343696f2e702cee00ca4e20d9
> Author: Guillherme Amaral 
> Date:   Fri Dec 20 13:02:13 2019 -0600
>
>  arch/arm/src/stm32f0l0g0/ and
> boards/arm/stm32f0l0g0/nucleo-g070rb/include/board.h:  Add I2C
> pinmap.  In Kconfig select I2C2 for this part.  Update I2C pin
> definitions in board.h.
>
> Those are in Bitbucket but not in Apache
>
> Greg
>
>
>

Re: Testing the new repository

[Abdelatif Guettouche]

> When I agreed to mange the commits through the transition period, that
> was conditioned on continuint to use the bitbucket repository that only
> I have access to, and then syncing the Apache repositories to the
> bitbucket repository.  That would work.

Didn't we agree on that?
I said I would do the syncing part.

Couple people suggested to switch all the work to github and make
bitbucket a mirror.
But that didn't get enough attention since we are still trying to
define the workflow.


On Sat, Dec 21, 2019 at 1:24 PM Gregory Nutt  wrote:
>
>
> > In the transition phase, only you(Greg) can merge PR or create branch,
> > other PPMC member shouldn't touch the official repo.
> > So I think there isn't difference between bitbucket and apache? we
> > just change the repo location, no more change until the new workflow
> > setup.
>
> Because of the recent experiences on the Apache repo, I do not want that
> job.  I will let someone else do it.
>
>

Re: [GitHub] [incubator-nuttx] Apache9 commented on issue #1: imxrt fixes

[Abdelatif Guettouche]

We already have a commits@nuttx mailing list.


On Sat, Dec 21, 2019 at 3:23 PM 张铎(Duo Zhang)  wrote:
>
> I think we should create a mailing list called commits@nuttx or something
> else and let the forwarded github message go there...
>
> GitBox  于2019年12月21日周六 下午11:16写道：
>
> > Apache9 commented on issue #1: imxrt fixes
> > URL:
> > https://github.com/apache/incubator-nuttx/pull/1#issuecomment-568188369
> >
> >
> >So we will merge PR to master branch directly? No dev branch?
> >
> > 
> > This is an automated message from the Apache Git Service.
> > To respond to the message, please log on to GitHub and use the
> > URL above to go to the specific comment.
> >
> > For queries about this service, please contact Infrastructure at:
> > us...@infra.apache.org
> >
> >
> > With regards,
> > Apache Git Services
> >

Re: Testing the new repository

[Abdelatif Guettouche]

> >> When I agreed to mange the commits through the transition period, that
> >> was conditioned on continuint to use the bitbucket repository that only
> >> I have access to, and then syncing the Apache repositories to the
> >> bitbucket repository.  That would work.
> > Didn't we agree on that?
> > I said I would do the syncing part.
> Yes, we did agree to that, at least everyone who expressed an opinion
> agreed (there was no vote).

Can we do that for the PR that David created? (I mean applying it on
bitbucket and I bring it to github)


On Sat, Dec 21, 2019 at 8:38 PM Gregory Nutt  wrote:
>
> This discussion is really on the wrong thread.  It should by on the
> *[CALL for TOP Down workflow Requirements]* thread.  I have forward
> every relevant email and document that I can find to the thread.  This
> conversation belongs on that thread in the  proper context as well.
>
> On 12/21/2019 2:30 PM, Gregory Nutt wrote:
> >
> Those people with devops should coordinate in another thread and make 
>  proposals for top-level functional to the broader audience.
> >>> We have enough smart and disciplined people here, I think we can do this.
> >>>
> >>> We should be able to spec from the top-level (no tool speak) process down 
> >>> the the nitty-gritty.  And if we stratify the details, the resultant docs 
> >>> should be welcoming to all.
> >>>
> >>> I’d like to give it a go.  Anyone up for this?
> >>>
> >> I don't believe it is a difficult job.  I think it is like one or two
> >> hours of work for a straw man.  And unless there is fundamental
> >> tool/implementation problem, I don't thing that you need to delve
> >> deeply into git or github.  I think the workflow is really pretty
> >> trivial.
> >>
> >>  1. Receive patches or PRs and put on a branch
> >>  2. Make sure that they conform to the coding standard
> >>  3. [FUTURE] make sure that they conform to Apache licensing
> >> requirements.
> >>  4. Make sure that they don't break the build (trickier than it sounds)
> >>  5. [FUTURE] perform hardware- or simulator-in-loop testing to check
> >> for regressions
> >>  6. Final review for architectural correctness and conformance to
> >> standard.  Make sure that the change follow same pattern as other
> >> instances (if applicable)
> >>  7. Merge the change in master
> >>
> >> Oh, damn!  I just did the job. :-) From my point of view, the is
> >> about 80% of the workflow.  The rest is all the caveats and what to
> >> do if a step fails which will require more words.
> >>
> > It would be best to have a place where we can collaborate on a
> > document.  Something like Google Drive.  Apache, however, is very
> > particular about everything happening in the open.  When asked,
> > Justin, one of our mentors, recommended that we put the collaborative
> > document in the Nuttx Confluence.  As I mentioned to Brennan earlier,
> > it would be good to have a page outside of the User Wiki to hold
> > project documents... a Project Wiki.  But that hasn't stirred up any
> > response.
> >
> > I think we have all become a little jaded :-(
> >
> > Having a fresh point of view would be great!
> >
> > Greg
> >
> >
>

Re: Code review tool

[Abdelatif Guettouche]

Hi Justin,

Nxstyle is a C file that you can find under tools.

You can build it under any OS.
Greg is just using Windows.

On Sun, Dec 22, 2019, 03:50 Justin Mclean  wrote:

> Hi,
>
> Perhaps someone wants to work on making a portable version of this? It
> seems it would be using for checking PRs and part of the CI system.
>
> Thanks,
> Justin

Re: Single Committer

[Abdelatif Guettouche]

This makes sense giving the circumstances. It will get us going.
We can still help reviewing PRs.

On Tue, Dec 24, 2019, 08:03 Disruptive Solutions <
disruptivesolution...@gmail.com> wrote:

> A platform like this could help? Samsung seems to use it? Does Apache has
> something like this “Helix Core” and “Swarm” ??
>
> https://www.perforce.com/products/helix-swarm
>
> Benefit drom these ideas? And you could start with 1 commiter and scale up
> later. The way of working will be getting more clear and get to the
> “standards” Greg sees??
>
>
> Verstuurd vanaf mijn iPhone
>
> > Op 24 dec. 2019 om 06:07 heeft Nathan Hartman 
> het volgende geschreven:
> >
> > On Mon, Dec 23, 2019 at 7:51 PM Gregory Nutt 
> wrote:
> >>
> >> Recent events have made me reconsider some decisions I made.  I threw
> >> off the single committer mantle when I saw the abuse of privilege in the
> >> repositories.  If the PPMC agrees to it, I will take up that role again.
> >>
> >> But let's be frank.  Here is what I think that means:
> >>
> >>  * I would be sole committer of changes.  The repositories would have
> >>to be treated as read-only just as back in the Bitbucket days.
> >>  * I would grandfather in the i.MXRT changes.
> >>  * I will decline all workflow related changes until workflow
> >>requirements are established (that is my only real motivation for
> >>suggesting this:  To make certain that we have proper requirements
> >>in place before we accept PX4 workflow into our repositories.  We
> >>need to do this right and I am willing to protect the repositories
> >>until the workflow requirements are established.  I expect that to
> >>take about two weeks.)
> >>  * I would create a dev branch and expect all PRs to be against that
> >>dev branch.
> >>  * As soon as the PPMC is confident that it has the processes in place
> >>to handle the commit workload I will gladly relinquish this role.
> >>  * THIS IS NOT THE APACHE WAY.  This is an interim dictatorship role to
> >>expedite the avalanche of commits expected after the holidays.
> >>
> >> If any of this concerns people, please "Just Say No."  I am not married
> >> to the idea and I am not forcefully advocating it.  This is what people
> >> wanted me to do a few days ago and if I can protect our right to define
> >> the workflow, then I will do it.  For me it is a sacrifice that I would
> >> take with no pleasure in.
> >>
> >> Pros:  This will provide project continuity until the PPMC is fully
> >> functional.  Having workflow requirements will be a huge step in that
> >> direction.  People stressed about the commit process can relax with
> >> confidence.  This will protect the code base from premature work flow
> >> changes until we have an understanding of what we want.  No harm is done
> >> by deferring workflow changes until we as a team are prepared to deal
> >> with them.
> >>
> >> Cons:  This is not the Apache way.  People who are trying to bulldoze
> >> the PX4 work flow into the repositories will hate the idea.  Mentors
> >> will hate the idea.  An approach more consistent with the Apache way
> >> would just be to let the chaos prevail.  That is fine with me too as
> >> long as we do not let PX4 advocates take away our group right to define
> >> our own workflow.  We can still just put all workflow changes on hold
> >> until we have the requirements in hand.
> >>
> >> I am not pushing anything.  Think about it and let me know what you
> >> would like to do.
> >
> > I agree with this because it is premature to change the way we work
> > before there is a documented workflow that helps us understand what to
> > do.
> >
> > Over the next two weeks, we should focus on designing the top-down
> > workflow. It doesn't have to be final and it doesn't have to be
> > perfect. We can improve it over time. But right now it's not ready,
> > so I appreciate Greg's offer to do that, while the workflow is prepared.
> >
> > Thanks to Greg and everyone,
> > Nathan
>

Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer)

[Abdelatif Guettouche]

> For me on HBase, this depends on lots of things. If it is only a typo then
> I will merge it immediately. If it is a simple bug fix, I will wait a bit
> long and if some committers are familiar with this part, I will try to ask
> their opinions. And if this is a very big new feature, sometimes people
> will even send an email to the mailing list to attract more reviews before
> committing.

Some ASF projects define Obvious Fixes and Emergency Merges.
Obvious Fixes are the like of typos, cosmetics, CS violations that
slipped by the review, etc.
Emergency merges are where nobody is around to review the change and
some subsystem is broken and needs it.
These can be merged by a committer without waiting for another review.

Obvious fixes can be frequent during the release branch period.


On Wed, Dec 25, 2019 at 12:59 PM 张铎(Duo Zhang)  wrote:
>
> What I mean is that, nobody wants its patch to be reverted right? So you
> will find a proper way to archive this. There is no straight forward rule
> on how much time to wait.
>
> For me on HBase, this depends on lots of things. If it is only a typo then
> I will merge it immediately. If it is a simple bug fix, I will wait a bit
> long and if some committers are familiar with this part, I will try to ask
> their opinions. And if this is a very big new feature, sometimes people
> will even send an email to the mailing list to attract more reviews before
> committing.
>
> So in general, I do not think there is an one-for-all rule. NuttX community
> has its own culture, and the ‘rule’ will be set up though practice.
>
> Thanks.
>
> Xiang Xiao 于2019年12月25日 周三19:50写道：
>
> > On Wed, Dec 25, 2019 at 2:30 PM 张铎(Duo Zhang) 
> > wrote:
> > >
> > > Xiang Xiao  于2019年12月25日周三 下午1:36写道：
> > >
> > > > Yes, I agree that we shouldn't make the workflow too hard to scare
> > > > people for contribution.
> > > > NuttX isn't a new project, it's open source for more than ten years
> > > > and has a mature workflow, the whole community is already familiar
> > > > with it.
> > > > Let me summary the current workflow:
> > > > 1.User send patch against master to
> > > > https://groups.google.com/forum/#!forum/nuttx or
> > > > 2.User send PR against master to
> > > > https://bitbucket.org/nuttx/nuttx/src/master/
> > > > 3.Greg review and merge the change to master(with some modification if
> > > > needed)
> > > > 4.Greg make a official release and create a tag to mark the point
> > > > every two(or three?) months
> > > > To "be apache way", the required change is only item 3&4: all
> > > > committer need involve the reviewing and release process.
> > > > So, I suggest that we adapter the current workflow with as minimal
> > > > changes as possible:
> > > > 1.User send patch against master to dev@nuttx.apache.org or
> > > > 2.User send PR against master to
> > https://github.com/apache/incubator-nuttx
> > > > 3.Committer review and merge the change to master(with some
> > > > modification if needed)
> > > > 4.Committer make a official release and create a tag to mark the point
> > > > every two(or three?) months
> > > > We only need to disscuss how committer review the change and make the
> > > > release.
> > > > Since we have two month for the next release, let's focus on the
> > > > review process in this time.
> > > > Here are some questions I have, other may add more:
> > > > a.How many committers need approve the patch before it can merge?
> > > >
> > > Usually one committer is enough, the only different is that, if the patch
> > > is proposed by a committer, then you need another committer to approve
> > it.
> > > We need to make sure that a patch has to be reviewed by a committer other
> > > than the author.
> > >
> > > > b.How much time give the committer the chance to say no?
> > > >
> > > This depends. In general, if a committer thinks it is fine to merge then
> > it
> > > can merge the patch/PR. But other committers have the rights to revert
> > the
> > > patch/PR, for example if you are not an expert of this area but he/she
> > is,
> > > and you even do not ask for his/her comments. So I think
> > > during collaboration, you will find the suitable way to decide whether it
> > > is OK to merge a PR. We do not need to define everything explicitly.
> > >
> >
> > But since people work at the different timezone, it's better to hold
> > the patch for one day at least, so people have a chance to review the
> > change and express the different opinion if they want.
> > It isn't a good practice to submit and then revert patch frequently, I
> > think.
> >
> > > > Once all questions get the resonable answer, we can make a vote.
> > > > If anyone has a new idea(e.g. submodule, dev/pr/release branch,
> > > > backport, LTS) send your proprosal to dev list and let community
> > > > discuss and vote.
> > > > But before the proprosal is accepted by the community, why we stop to
> > > > use the current workflow and make our work stuck?
> > > >
> > > > Thanks
> > > > Xiang
> > > >
> > > > On Wed, D

Re: User Email Account

[Abdelatif Guettouche]

Definitely a good idea.
I believe David also suggested that gitbox messages will be redirected
to their own pr@ mailing list.

There is just too much traffic in dev@

On Wed, Dec 25, 2019 at 2:38 PM 张铎(Duo Zhang)  wrote:
>
> +1 on a user@nuttx mailing list.
>
> Gregory Nutt  于2019年12月25日周三 下午10:34写道：
>
> > There have been quite a few NuttX users who have been put of by the
> > volume and content of emails on this list.  December is not quite over
> > and there have been close to 850 emails so far this month.  And the
> > majority of the community is only interested is discussion technical
> > issues and do not even care about the project-oriented content.
> >
> > So I wonder, would it be good to have a u...@nuttx.apache.org mail list
> > just for user-facing questions?  I see that many other projects have
> > such an email account.  This would allow people to have simple
> > discussions about the OS without the organizational/political content.
> > Such an email would be a replacement for the Google email list.
> > dev@nuttx.apache.org is not.
> >
> > Does this sound like good idea?  Or should should we continue to force
> > users to wad through 100s of emails that they do not way to see?
> >
> >
> >

Re: Podling Nuttx Report Reminder - January 2020

[Abdelatif Guettouche]

Hi,
>
> It’s a good idea to work on the report in the open, you can do this this wiki 
> [1] or this mailing list, it’s also a good idea to work on it well before the 
> due date. Your first report is due 1st January.

I put in a draft to start with
(https://cwiki.apache.org/confluence/display/NUTTXTEST/January+2020)


On Fri, Dec 20, 2019 at 2:49 AM Nathan Hartman  wrote:
>
> On Thu, Dec 19, 2019 at 4:42 PM Justin Mclean 
> wrote:
>
> > Hi,
> >
> > > I don't see a bare bones report for NuttX (or any bare bones template)
> > > at https://cwiki.apache.org/confluence/display/incubator/January2019,
> >
> > That because I copied the wrong link, sorry about that:
> > https://cwiki.apache.org/confluence/display/incubator/January2020
>
>
> Much better. Thank you.
>
> Nathan
>
> 
> >

Re: Podling Nuttx Report Reminder - January 2020

[Abdelatif Guettouche]

Thank you Greg, I appreciate it.

> That’s a good start, but a few sections are missing and a little more detail 
> is needed in a few places.
What sections are missing? I took the template from the incubator.
Or do you mean content is missing?
If that's the case, yes, there are quite some gaps. The rest will be
filled during the next days.


On Wed, Dec 25, 2019 at 11:25 PM Justin Mclean  wrote:
>
> HI,
>
> > I put in a draft to start with
> > (https://cwiki.apache.org/confluence/display/NUTTXTEST/January+2020)
>
> That’s a good start, but a few sections are missing and a little more detail 
> is needed in a few places.
>
> Thanks,
> Justin

Re: Apache NuttX website

[Abdelatif Guettouche]

Did you try this one: https://id.apache.org/

On Fri, Dec 27, 2019 at 4:04 PM Brennan Ashton
 wrote:
>
> Unfortunately that website requires you to double click to edit fields
> (what?) which I cannot do on mobile, so I will have to wait until Saturday
> or Sunday to do that You can tag me @btashton for now.
>
> On Fri, Dec 27, 2019, 5:49 AM Xiang Xiao  wrote:
>
> > Brennan, could you associate your apache and github account here?
> > https://whimsy.apache.org/roster/committer/btashton
> > And enable 2FA here:
> > https://gitbox.apache.org/setup/
> > So you can review the future website related patch.
> > The web technology is far beyond my knowledge, I can't do the depth
> > review except the typo error.
> >
> > Thanks
> > Xiang
> >
> > On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
> >  wrote:
> > >
> > > Could we create the repo for the website.
> > > http://www.apache.org/dev/project-site.html
> > >
> > > The one I created is based off the Jekyll template as discussed here.
> > > https://incubator.apache.org/guides/sites.html#publishing_your_website
> >

Re: User Email Account

[Abdelatif Guettouche]

> The dev list traffic may reduce after we finish the workflow discussion.
> but email from GibBox will become more and more, can we send them to
> rev...@nuttx.apache.org to avoid the review message mess up the dev
> list?

While reading some projects' board reports, I came across this:

> Gitbox traffic is now going to issues@. The community was losing dev@
>  subscribers because of the high volume of traffic from Gitbox.

Once we are all set up and ready to receive patches/PRs, we may run
into the same issue.


On Thu, Dec 26, 2019 at 1:34 PM Xiang Xiao  wrote:
>
> The dev list traffic may reduce after we finish the workflow discussion.
> but email from GibBox will become more and more, can we send them to
> rev...@nuttx.apache.org to avoid the review message mess up the dev
> list?
>
> Thanks
> Xiang
>
> On Thu, Dec 26, 2019 at 8:19 PM spudaneco  wrote:
> >
> > I may grumble a bit bur I always follow Justin's advice.I do think that
> > NuttX is diferent from other new podlings because  began with a huge user
> > base and has a few different needs on day 1 as a mature project.I don't
> > believe that finding new committers will be a problem.Sent from Samsung
> > tablet.
> >  Original message From: Adam Feuer  Date:
> > 12/26/19  1:23 AM  (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: User
> > Email Account I think what Justin is saying is that it's going to seem like
> > uncomfortablechaos for a bit, but will eventually settle down into a better
> > state.From what I know about well-functioning teams, that seems right.
> > Form,storm, norm,
> > perform.
> > :)cheersadamOn Wed, Dec 25, 2019 at 8:28 PM Justin Mclean
> > wrote:> Hi,>> Most of those are not current
> > incubating projects. Some of them did not> become to level projects. Just
> > about all did not start with user lists.> Creating a seperate user list this
> > early in previous incubating projects> has slowed or hindered their
> > community growth. You want users involved so> that they become committers.
> > At no point have I said you can't do this but> the PPMC needs to carefully
> > consider it. My Internet access is limited> right now but if you search on
> > the incubator general list you'll see> several discussions on this.>>
> > Thanks,> Justin>-- Adam Feuer 

Re: Podling Nuttx Report Reminder - January 2020

[Abdelatif Guettouche]

> Nice... Who is going to do this?

It's on going here
https://cwiki.apache.org/confluence/display/NUTTXTEST/January+2020
Fell free to help.


On Sat, Dec 28, 2019 at 7:04 AM Disruptive Solutions
 wrote:
>
> Nice... Who is going to do this?
>
> Verstuurd vanaf mijn iPhone
>
> > Op 28 dec. 2019 om 06:11 heeft jmcl...@apache.org het volgende geschreven:
> >
> > Dear podling,
> >
> > This email was sent by an automated system on behalf of the Apache
> > Incubator PMC. It is an initial reminder to give you plenty of time to
> > prepare your quarterly board report.
> >
> > The board meeting is scheduled for Wed, 15 January 2020, 10:30 am PDT.
> > The report for your podling will form a part of the Incubator PMC
> > report. The Incubator PMC requires your report to be submitted 2 weeks
> > before the board meeting, to allow sufficient time for review and
> > submission (Wed, January 01).
> >
> > Please submit your report with sufficient time to allow the Incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Candidate names should not be made public before people are actually
> > elected, so please do not include the names of potential committers or
> > PPMC members in your report.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> >the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> >towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> >aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> > *   How does the podling rate their own maturity.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > https://cwiki.apache.org/confluence/display/INCUBATOR/January2020
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Note: The format of the report has changed to use markdown.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC

Re: January 2020 Status

[Abdelatif Guettouche]

Hi Greg, Brennan,

Thanks for the heads up.

I just wanted to add one thing under "Actions the we have taken to
protect the trademark. " I think you can say that we (or I) have
registered the NuttX trademark in the US.  That actually happened a
couple of years back, but I think we can take credit for that in the
first report.

I believe thats worth mentioning.
I'll get on it this evening. (We work sundays)



On Sun, Dec 29, 2019, 05:12 Gregory Nutt  wrote:

>
> >> I can no longer add or edit comments to January 2020 report since it
> >> moved from NUTTXTEST to NUTTX.  I have lost whatever privileges I needed
> >> to do that.  I can login, but I cannot add or edit comments.
> >>
> > Greg, I just added the nuttx group with permissions that should be the
> same
> > as it was on NUTTXTEST let me know if there are any more issues. Sorry
> for
> > that.
>
> Thanks.. that did it.  All works fine again.
>
> Greg
>
>
>
>

Re: Apache NuttX website

[Abdelatif Guettouche]

Hi,

Did anyone try to move the website to Apache?
It looks like Xiao ticket [1] got an answer.

If not, what was the hold up?
I need that piece of information to put it in the January report.

1. (https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-19634)

On Fri, Dec 27, 2019 at 5:28 PM Xiang Xiao  wrote:
>
> Sure.
>
> On Sat, Dec 28, 2019 at 1:22 AM Brennan Ashton
>  wrote:
> >
> > That worked perfect.  Xiang you should be able to assign things to me now.
> >
> > On Fri, Dec 27, 2019, 8:06 AM Abdelatif Guettouche <
> > abdelatif.guettou...@gmail.com> wrote:
> >
> > > Did you try this one: https://id.apache.org/
> > >
> > > On Fri, Dec 27, 2019 at 4:04 PM Brennan Ashton
> > >  wrote:
> > > >
> > > > Unfortunately that website requires you to double click to edit fields
> > > > (what?) which I cannot do on mobile, so I will have to wait until
> > > Saturday
> > > > or Sunday to do that You can tag me @btashton for now.
> > > >
> > > > On Fri, Dec 27, 2019, 5:49 AM Xiang Xiao 
> > > wrote:
> > > >
> > > > > Brennan, could you associate your apache and github account here?
> > > > > https://whimsy.apache.org/roster/committer/btashton
> > > > > And enable 2FA here:
> > > > > https://gitbox.apache.org/setup/
> > > > > So you can review the future website related patch.
> > > > > The web technology is far beyond my knowledge, I can't do the depth
> > > > > review except the typo error.
> > > > >
> > > > > Thanks
> > > > > Xiang
> > > > >
> > > > > On Sat, Dec 21, 2019 at 12:54 PM Brennan Ashton
> > > > >  wrote:
> > > > > >
> > > > > > Could we create the repo for the website.
> > > > > > http://www.apache.org/dev/project-site.html
> > > > > >
> > > > > > The one I created is based off the Jekyll template as discussed 
> > > > > > here.
> > > > > >
> > > https://incubator.apache.org/guides/sites.html#publishing_your_website
> > > > >
> > >

Re: User Email Account

[Abdelatif Guettouche]

Hi Justin,

The discussion has shifted more towards redirecting gitbox
notifications to their own mailing list.
Something similar to commit@
We are just concerned that this may cause a lot of noise in dev@

On Mon, Dec 30, 2019 at 9:21 PM Justin Mclean  wrote:
>
> Hi,
>
> Just an observation. You seem to making decisions based and what you think 
> will happen rather than what actually will happening and ignoring advice 
> given. While these things can be corrected, splitting the community so early 
> is not recommended. Did anyone read the links to the conversations I posted?
>
> Thanks,
> Justin