Re: Question about structure roadmap

[Sebastien Lorquet]

I would rather use an IRC channel than slack :p

Where is this channel? Freenode? #nuttx ?

Sebastien

On 12/15/19 11:05 PM, Gregory Nutt wrote:



Communication stuff
I still see the slack channels, but they will go away? The IRC 
channel will get back up in IRC apache? Linked in yes no? What the 
communication plan??!

Slack is shutting down. I tried to login earlier to deactivate myself
and it turns out that I was already deactivated. So it might be gone
already.


Any member listed as inactive (meaning they are not actively using 
Slack) get deactivated.  When all members are deactivated, Slack will 
disappear.


You may as well stop using Slack.  There will not be anything there to 
talk to and no one will read the posts.  That would be helpful.


Apache supports a Slack.  But it is only available for posting by 
project members. 
https://cwiki.apache.org/confluence/display/INFRA/Slack+Guest+Invites 
No members can join into a single channel, but I am not sure exactly 
how that works.  The sign-up is here http://s.apache.org/slack-invite



I don't think IRC plans were discussed at all. We should start a
separate thread about that too.


Do people still use the IRC channel?  I haven't been there is months, 
maybe years.

Re: Project Emails

[Sebastien Lorquet]

hello,

I am not favorable personally with submodules. They are a pain to keep 
in sync across multiple remotes and branches.


This was used in the past in NuttX, and it was aborted.

Sebastien

On 12/13/19 3:28 AM, Anthony Merlino wrote:

I think submodules are a good way to go. That would leave us with 3 repos
as the core Apache NuttX. One for 'nuttx' which, is Greg suggests, should
always be exclusively the OS. One for 'apps'. And one for "linking" them
together, and for providing other NuttX infrastructure that may not be
appropriate in the core OS repo.

[image: photo]
*Anthony Merlino*
CTO & Co-founder, Verge Aero
(609)-319-1399



On Thu, Dec 12, 2019 at 8:17 PM David Sidrane 
wrote:


How about sub modules? We atomically tag across both to keep the project in
proper synchronization.

David

-Original Message-
From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
Sent: Thursday, December 12, 2019 10:55 AM
To: dev@nuttx.apache.org
Subject: Re: Project Emails

On Thu, Dec 12, 2019 at 1:36 PM Gregory Nutt  wrote:

A NuttX release consists of two tarballs nuttx/ and apps/. nuttx/ is the
operating system proper; apps/ is a collection of applications that may
or maynot be used with the operating system proper.  These applications
including some key things and I think most people want to incorporate
some subset of applications into their project.

But since the applications are NOT part of the operating system they do
need to remain separate.  I would argue against trying to merge
application code into the operating system.  So I think we have to
consider these two separate releases.  We historically release them
together as a matched pair so that the use can be user that they
interoperate properly.

+1 : I agree that nuttx and apps should stay separate.

That begs the question, are we going to have two separate Git
repositories? Because Git lacks support for multiple projects in one
repository. (There's nothing in Git that prevents you from trying, but
Git does not have the features that make the "monorepo"/"megarepo"
pattern work; e.g., it does not have sparse/partial working copies or
clones. Trying to combine nuttx and apps into one repository would
force everyone to clone a lot of content they may not need/want and
which may complicate building the RTOS with only their custom
applications.)

Nathan

Re: [DISCUSS - NuttX Workflow]

[Sebastien Lorquet]

why completely change what has worked for years?

2 repos as always. Submodules are an absolute pain to manage when you have 
branches.

people have always been cloning two repos.

devs were sending patches for one of them.

Now they send pull request instead. Better tracking, ability to fix while being
reviewed...

pull requests require branches, that will be annoying with submodules. This will
still require separate pull requests for apps and nuttx.

I have NEVER seen any contribution that really required an exactly atomic update
to both repos.

People often send patches for nuttx, and sometimes for apps.

Why change that?

Sebastien

Le 18/12/2019 à 11:46, David Sidrane a écrit :
>> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps 
>> master branch
> Are you suggesting we have one repo NuttX with 2 folders apps and nuttx?
>
> That will simplify everything! - but I suspect we will receive STRONG 
> arguments against it.
>  
> So you  say "one pull request" 
>
> Where? You have 2 repos. PR are against a single repo.
>
> This it what the Knot does. - It is the where
>
> On 2019/12/18 10:09:26, Alan Carvalho de Assis  wrote: 
>> Hi Liu,
>>
>> On Wednesday, December 18, 2019, Haitao Liu  wrote:
>>> How about just keep two separate git repositories (apps and nuttx
>>> projects) instead
>>> of add a parent knot repo with apps and nuttx as sub-modules?
>>> As to jenkins CI, I haven’t found proper github plugin to get PRs from
>>> multiple repos(especially PRs dependency in apps & nuttx ) in one Jenkins
>>> job.  Before that, I wonder whether we could keep it simple and
>>> directly, create
>>> one jenkins job for apps and another  jenkins job for nuttx to process PR
>>> trigger accordingly.  Just make sure the jenkins pipeline or build script
>>> to sync both apps and nuttx repos, then pick the apps or nuttx PR to do
>>> full build.
>>>
>>> Since nuttx and apps projects keeps same as before, developers adapt to
>>> github workflow as usual:
>>> 1 fork the official apache nuttx & apps projects in github
>>> 2 git clone your fork projects locally
>>> 3 edit locally and then git commit to local branch
>>> 4 git push to your github fork nuttx/apps branch
>>> 5 issue one pull request from your fork nuttx/apps to apache nuttx/apps
>>> master branch
>>> 6 jenkins CI auto-trigger: style check, build or test, if failed, go to
>>> step 3, continue 3 ~ 7
>>> 7 PMC start to review PR, review ok, merge to master; or review failed, go
>>> to step 3, continue 3~7
>>>
>>> Detailed info about GitHub workflow:
>>>
>> https://help.github.com/en/github/collaborating-with-issues-and-pull-requests
>> I agree! Using two repositores is better than creating submodules.
>>
>> We Just need to guarantee that users will clone both directories. The build
>> system can do it when the user try to build without the ../apps.
>>
>> BR,
>>
>> Alan
>>

Re: [DISCUSS - NuttX Workflow]

[Sebastien Lorquet]

Wait,

what advantage does in fact the submodule method bring?

Even with a hat repository that contains two submodules (apps and nuttx), you
will have to send separate pull requests for each submodule, right?

Sebastien

Le 18/12/2019 à 14:40, Gregory Nutt a écrit :
> On 12/18/2019 4:23 AM, David Sidrane wrote:
>> That is precisely what submodules do:submodules aggregate on a single SHAL N
>> repositories.
>>
>> The problem is: How to have atomic checkout of the correct configuration with
>> out a temporal shift?
>>
>> Please describe how you would do this. Give detailed steps.
>
> I don't see any difference in versioning with submodules.  You have to
> explicitly state the UUID you are using in the submodule (unless there is a
> GIT sub-module trick I don't know).
>
> So how would you checkout the correct configuration with sub-modules.  Seems
> to me that it is the same issue.
>
> I would vote about 18billion minus for this change.  But architecture designs
> are not justified by blantant expediency.
>
> Let's not go this way.
>
>

Re: [DISCUSS - NuttX Workflow]

[Sebastien Lorquet]

Looks really complex to me, if any contributor has to master all of this
perfectly to contribute officially.

the submodule sync with these specific options is already too much.

do you really realize all that has to be memorized just for a hat repo?


to put it another way: if you assure me that this hat repo is completely
optional and that I will never ever have to use it, I'm okay. let me use my two
repos as usual and play with your hat submodules without annoying anyone else.


But, if this workflow requires such a complex string of git commands including
rebase anytime I have to push anything to the apps or nuttx repo, I dont want to
do it.


Again just my opinion.

But the endless list of complex git commands with additional options is probably
a blocker for many other people too.

I dont even want to read it all.

Sebastien

Le 18/12/2019 à 15:20, David Sidrane a écrit :
>> what advantage does in fact the submodule method bring?
> See below
>
>> Even with a hat repository that contains two submodules (apps and nuttx),
>> you
>> will have to send separate pull requests for each submodule, right?
> Yes. But they com nit in 1 Atomic operation.
>
>
> Submodules 101
>
> This example is with write access on the repo - for committers
>
> git clone  NuttX
> cd NuttX
> git checkout master
> git submodule sync --recursive && git submodule update --init --recursive
>
> git checkout -b master_add_tof_driver
>
> cd nuttx
> git checkout -b master_add_tof_driver
>
> #work and commit - rebase on self and remove drabble.
> rebase -i master
> #reorder, squash and fixup the commits (learn about mv-changes is your
> friend) - you will look organized.
>
> cd apps
> git checkout -b master_add_tof_driver
>
> #work and commit - rebase on self and remove cruft and noise.
> rebase -i master
> #reorder, squash and fixup the commits (learn about mv-changes it is your
> friend) - you will look organized.
>
> #Build and test locally.
> ## AOK
>
> cd apps
> git push origin master_add_tof_driver
>
> cd nuttx
> git push origin master_add_tof_driver
>
> cd .. (NuttX)
> git add nuts apps
> git commit "Update NuttX with TOF driver"
>
> git push origin master_add_tof_driver
>
> Ok so now (shal simplified to compare them)
>
> NuttX master shal  point to
>   \nuttx master shal 
>   \apps master shal 
>
> NuttX master_add_tof_driver 
>   \nuttx master shal aaa
>   \apps master shal bbb
>
> merge PR from apps to master apps
> merge PR from nuttx to master nuttx
>
> NuttX master shal  point to (still builds and runs)
>   \nuttx master shal 
>   \apps master shal 
>
> But the branch master of the submodules
>
>   \nuttx master shal aaa
>   \apps master shal bbb
>
>
> merge PR from NuttX to master NuttX (atomic replacement)
> NuttX master shal z point to
>   \nuttx master shal aaa
>   \apps master shal bbb
>
>
>
> -Original Message-
> From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
> Sent: Wednesday, December 18, 2019 5:52 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS - NuttX Workflow]
>
> Wait,
>
> what advantage does in fact the submodule method bring?
>
> Even with a hat repository that contains two submodules (apps and nuttx),
> you
> will have to send separate pull requests for each submodule, right?
>
> Sebastien
>
> Le 18/12/2019 à 14:40, Gregory Nutt a écrit :
>> On 12/18/2019 4:23 AM, David Sidrane wrote:
>>> That is precisely what submodules do:submodules aggregate on a single
>>> SHAL N
>>> repositories.
>>>
>>> The problem is: How to have atomic checkout of the correct configuration
>>> with
>>> out a temporal shift?
>>>
>>> Please describe how you would do this. Give detailed steps.
>> I don't see any difference in versioning with submodules.  You have to
>> explicitly state the UUID you are using in the submodule (unless there is
>> a
>> GIT sub-module trick I don't know).
>>
>> So how would you checkout the correct configuration with sub-modules.
>> Seems
>> to me that it is the same issue.
>>
>> I would vote about 18billion minus for this change.  But architecture
>> designs
>> are not justified by blantant expediency.
>>
>> Let's not go this way.
>>
>>

Re: userspace/kernel isolation question

[Sebastien Lorquet]

Hello,

I dont agree. A fundamental feature to avoid widespread developement of 
the so-called Internet of Shit is basic embedded security.



Some thoughts:

An embedded system can have a minimal security. Of course security has 
several levels from non-existent to ideal.


Not having a full PKI protected secure boot does not mean some 
protections could not be used.



The question here is not adressable generally in ALL embedded systems, 
but the use of the ARM MPU could help a lot.


As anyone probably already knows, the ARM MPU is a MMU with a one-one 
virtual/physical mapping. It can be used to enforce access rights on 
selected memory zones. The MPU could be updated at each task switch to 
ensure that only the mem zones for the current task are usable.


The MPU could prevent the user app from reading the kernel flash and RAM 
when running in user space. Starting a system call then enables the MPU 
settings for supervisor mode.


The system calls could check the validity of passed pointers against the 
currently valid memory protection settings to avoid clobbering and 
reading kernel and/or other task memory zones. This single feature does 
not even need an MPU, just knowledge of application address boundaries.


True, it is complex and would need linker support or loadable apps.

True, it could be bypassed, but the requirements to do that would be a 
bit more complex than nothing.


Any security feature available should be used.

It is a common fallacy to state that bypassable security is not useful.

It is still better than no security at all.

It can also be useful to prevent... well, plain memory corruption bugs.


Sebastien

Le 25/02/2020 à 17:08, Nathan Hartman a écrit :

On Tue, Feb 25, 2020 at 10:59 AM Gregory Nutt  wrote:

I think that most syscall which contain pointer has the security issue
in PROTECTED/KERNEL mode.

Certainly if high security is need, they all should be reviewed. Linux
goes to a lot of trouble to access data pointed to by user-provided
pointers. We might need to add all of those access macros in the future.

KERNEL mode is a little more complex in that you also have to assure
that the correct MMU mappings are in place before to access user data
from a different kernel thread (like a work queue).

The whole point of using a RTOS is to get a LIGHTWEIGHT operating
system. This is for embedded microcontrollers costing from cents up to
a few dollars in products that run embedded software logic.

If you need the sort of "security" that makes it possible to run
totally untrusted code, then maybe you need a full blown operating
system, which also comes with a full blown computer and not an
embedded microcontroller.

Cheers,
Nathan

Re: Why the text displayed by SSD1306 / I2C is reversed along the vertical axis

[Sebastien Lorquet]

hello

IIRC the config menus allow you to flip the display direction. Did you have a
look over there?

Sebastien

Le 24/12/2019 à 08:39, Nii Jyeni a écrit :
> Hi~
> I am trying the graphics module of nuttx. I just used the nxtext sample 
> program and found that the text displayed on oled is reversed. It seems that 
> each character is flipped vertically. Does anyone know what is going on here? 
> how should I solve this? Thank you!
>
> BOARD:STM32F407VE（compatible stm32f4discovery）
> HOST:macOS

Re: Single Committer

[Sebastien Lorquet]

Not sure throwing more tools at the current mess will fix anthing.

Full support to Greg for benevolent dictatorship extension until things are 
settled.

Sebastien

Le 24/12/2019 à 08:03, Disruptive Solutions a écrit :
> 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: mbedtls

[Sebastien Lorquet]

Hello,

I have seriously slowed down my nuttx contributions because of the 
apache turmoil but I am still reading this list and will have to work on 
this topic at one point.


See my opinions below.

Sebastien

Le 22/05/2020 à 09:41, Takashi Yamamoto a écrit :

hi,

i'm working on mbedtls Makefile/Kconfig glue for NuttX.
right now, it downloads and uses the mbedtls source code from
the upstream as it is. (similarly to what netutils/cjson does)

questions:

1. if we decide to contribute it, is there a chance to be accepted by NuttX?

No. NuttX does not include alive projects.

2. if yes, which repository is appropriate? apps?


HTTPS implementation should be a lib in apps that uses a common TLS 
socket library. which should be replaceable.


At first, make it use mbedts, or other, then later, have this replaced 
by real nuttx code.



3. if apps, in which directory? netutils? crypto?


Crypto is a crypto framework for basic crypto operations. I didnt know 
that it had been upstreamed.


Yes, this folder could provide resources for a tls implementation. It is 
intended to be a modular crypto framework like a compact pkcs#11.



4. how do you think about adding tls support to netutils/webclient?


Please make the TLS implementation replaceable. At one point NuttX will 
get a built it TLS.


A customer has formally ordered this feature so I will be paid to 
develop it, but my schedule is loaded and I dont know when I will 
complete this.


I understand that no one can wait for this to happen before having TLS, 
so mbedTLS is a good temporary option.


But please anyone integrating TLS in NuttX, please provide options and 
hooks to replace the implementation.


I believe the interface should be a user lib that provides TLS sockets 
as in openssl or gnutls.


It looks like a low-level interface with known semantics that could be 
started with a downloaded mbedtls and then easily replaced with a native 
nuttx solution based on what is in the crypto folder.


Sebastien

Re: mbedtls

[Sebastien Lorquet]

Hello

Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit :

can you explain what's "real nuttx code"?


For me, code specifically written for NuttX with good integration and 
performance. Different from a third-party library.


The makefile glue is OK for NuttX contribution.

Crypto is a directory that exists in some personal forks of NuttX and is 
(IIRC) used by Xiaomi with probably many changes, but it is not 
integrated yet. (your remark made me believe it had been already)


It is intended to provide a PKCS#11 like library that any app can use 
and any board can extend with new algs, including hardware implemented.


If you are interested in a crypto API we can talk about that and discuss 
what is already done and designed, no need to fully reinvent anything.


Sebastien

crypto api again (was: Re: mbedtls)

[Sebastien Lorquet]

Le 22/05/2020 à 17:00, Takashi Yamamoto a écrit :

On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet  wrote:

Hello

Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit :

can you explain what's "real nuttx code"?

For me, code specifically written for NuttX with good integration and
performance. Different from a third-party library.

i'm afraid that a third-party library is likely a better choice for
things like tls.


Probably not, my company is already working in the domain of security 
and we will have some testing to ensure things work.


Yes I know it's bad to roll your own crypto but it's not rolling crypto, 
it's rolling known algorithms, so these can be tested and fixed.


To finish with, the security envelope of a normal IoT SoC is pretty bad 
so already. If you get physical access you can put break points at the 
right places and do whatever you want.


So the goal is more compactness and integration.

We will not be as comprehensive as mbedtls probably, but we will do it 
well for sure. The customer that ordered it is a large french company 
that does not sh*t on security. Domain is industrial, not 
iot/startup/customer.



Moreover mbedtls comes with a full crypto lib which will be duplicated 
if something else in the system requires cryptography, and these lib 
wont take advantage of any crypto hardware that might be available in a 
particular SoC.


Using a backend crypto library improves modularity.




The makefile glue is OK for NuttX contribution.

Crypto is a directory that exists in some personal forks of NuttX and is
(IIRC) used by Xiaomi with probably many changes, but it is not
integrated yet. (your remark made me believe it had been already)

It is intended to provide a PKCS#11 like library that any app can use
and any board can extend with new algs, including hardware implemented.

If you are interested in a crypto API we can talk about that and discuss
what is already done and designed, no need to fully reinvent anything.

i'm interested.


It's here: https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/

Still a legacy nuttx, not migrated to apache stuff yet.

You can see the suggested API here. it's based on IOCTL and chardevs

https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/ioctl.h

constant definitions

https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/manager.h

"OS side" crypto module operations (kind of service provider API)

https://bitbucket.org/slorquet/nuttx/src/crypto/include/nuttx/crypto/module.h

chardev interface

https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/manager.c

Implementation of module manager

https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/libmanager.c

Module designed to test the behaviour

https://bitbucket.org/slorquet/nuttx/src/crypto/crypto/softmodule.c


cryptoapps is a repo that can be cloned in a working APPS repository. 
new folder is automatically detected by the build system, this is what 
you can do for mbedtls porting.


https://bitbucket.org/slorquet/cryptoapps/src/master/

user-side of the API that calls the chardev:

https://bitbucket.org/slorquet/cryptoapps/src/master/libcrypto/

openssl-like test tool used during development

https://bitbucket.org/slorquet/cryptoapps/src/master/ct/

export should be linked as crypto in apps/include to provide headers to 
other apps.



It is extensively documented with comments.


The great question was : how to make this API available to user space?

My initial development was based on a character device because it was 
very simple and had probably the less impact on performance.


I know that gregory would prefer something else, possibly a kind of 
socket like netlink. I think it's bloat to require the network stack for 
simple straightforward stuff like this, and situation was left on this 
lack of solution the last time I remember.


I dont know how things are now. is the char device still unacceptable? 
is netlink the preferred solution? Is something else possible? I dont know.


Sebastien

Re: api stability in apps/netutils/webclient

[Sebastien Lorquet]

I think the web client could be rewritten to benefit from the curl port 
I started a while a go, which is available upstream:


https://github.com/apache/incubator-nuttx-apps/tree/master/netutils/libcurl4nx

Improving this curl port would benefit any app using it, not just the 
web client.


Sebastien

Le 29/05/2020 à 08:23, Takashi Yamamoto a écrit :

hi,

On Fri, May 29, 2020 at 7:00 AM Gregory Nutt  wrote:



i want to add some stuff to apps/netutils/webclient.
for example,

* ability to report http status to the caller
* ability to add some request headers
* put
* other content-type for post
* tls

a question: how much api stability is expected for this?

Of course we would like the code to be stable in the sense that it
continues to behave correctly; I assume that you would carefully verify
new features. But I think by stable you are referring to a fixed API.  I
don't think that is necessary either.  This is not a standard interface
and it is not even documented.  People using non-standard, undocumented
interfaces need to accept that they are subject to change without notice.

A good explanation in comments of how to get legacy behavior I think is
sufficient.  Do other people agree with that?


can i just add extra arguments to wget() etc?
or should i keep wget() intact and introduce a new set of symbols?

I don't see any problems with extending wget().   We should do that
wisely.  Perhaps it would be better if wget took a structure as an
argument rather than a long, long parameter list.  I would personally
prefer to see one wget() rather than the old wget() with a new wget2()
which is the same but with different parameters.

All current usage of wget() should be modified to use any changes that
you make to the interface.  I find only examples/wget/ and nshlib/.  Is
that everything?

right now i'm thinking
1. introduce something like the following. keep wget() etc as wrappers
of this in the meantime
2. once things get stable, inline the existing users of wget() etc in
the tree, like examples/wget, one-by-one
3. consider removing wget() etc

struct webclient_context
{
 /* request parameters */

 FAR const char *method;
 FAR const char *url;
 FAR const char * FAR const *headers;
 unsigned int *nheaders;

 /* other parameters */

 FAR char *buffer;
 int buflen;
 wget_callback_t callback,
 FAR void *callback_arg;
 FAR const struct webclient_tls_ops *tls_ops;
 FAR void *tls_ctx;

 /* result */

 int http_status;
};

struct webclient_context ctx;
webclient_set_defaults();
ctx.method = "GET";
ctx.url = "..."
:
ret = webclient_perform();

Re: 68k?

[Sebastien Lorquet]

Never seen this done but I am highly interested.

An extremely cool 68k platform to run nuttx would be the Texas 
Instruments 68k calculators. The V200 has 4M of flash and 256k of RAM. 
The TI89 and 92+ also have that kind of memories. There is a fully 
working emulator with a built in debugger, tiemu.


I know some people that would likely offer help to code the display and 
keyboard driver.


I also have a pair of 68008 somewhere that would love to run a 68k NuttX 
port on a breadboard with a creepy parallel bus!


If you start a port, please keep me informed.

Sebastien

Le 04/08/2020 à 06:28, David Alessio a écrit :

Hello,

Does anyone know whether NuttX was ever ported to the 68k or ColdFire?  I
thought I remember seeing an early port some time ago, but I may
be mistaken.

Regards,
-david

Re: Setting MAC address on STM32.

[Sebastien Lorquet]

Hello

my previous board has the same setup 32f427 and mac in eeprom.

To achieve this programmatically (without using a shell command), I have 
used my application.


The application boots a system app instead of NSH. This app starts some 
useful threads.


If I need to use NSH, I can start the shell from here by just calling 
nsh_main. My damon threads continue to run in the background, and exit 
from nsh returns to my application main loop.



Part of the app initialization calls hn70ap_netmonitor_init here:

https://github.com/f4grx/hn70ap/blob/master/apps/sysdaemon/sysdaemon_netmonitor.c#L412

This is where I read the EEPROM and set the MAC address using 
netlib_setmacaddr. This function does not depend on the platform being 
stm32 or other.



Then I start a netmonitor thread to detect cable plugs and run DHCP 
negotiation whenever the cable is plugged, this is useful to know, but 
unrelated.


Sebastien


Le 02/08/2020 à 12:59, Fotis Panagiotopoulos a écrit :

Hi,

I am using an STM32F427 MCU on a project that I am porting to NuttX.
For the moment everything seems to be working, apart from the Ethernet MAC.
I really can't find the correct way to set the MAC address to the Ethernet
driver.

My hardware uses an I2C EEPROM to store the MAC address. I will have to
read the EEPROM, and pass the address to the MAC driver.


Which is the correct function to use to set the MAC address?

When is the correct time during system initialization to do so?

Re: [OT] Linux now using 100 char lines as default

[Sebastien Lorquet]

So sorry to be a radical humorist.

Sebastien

Le 03/06/2020 à 15:57, Gregory Nutt a écrit :



-1

I like it the way it is.  And thoroughly opposed to increate the 
default line width.  There has been BS talk about it.  But it is just 
BS and amounts to nothing. No one should be taking this seriously.


There has been no change to the coding standard.  There has been no 
change to default line width.  Any PR C file with 100, 128, or 132 
character line with will be declined. 
Critical parts of the coding standard can be changed with a full vote 
of the PPMC.  It is not going to happen by a few radicals commenting 
on an [OT] conversation.

Re: [OT] Linux now using 100 char lines as default

[Sebastien Lorquet]

Or, Let's stick with usual console widths and make it 132?

sebastien

Le 01/06/2020 à 15:30, David Sidrane a écrit :

Let's one up them and keep it binary at the same time 128! :)

-Original Message-
From: Alan Carvalho de Assis [mailto:acas...@gmail.com]
Sent: Monday, June 01, 2020 4:22 AM
To: dev
Subject: [OT] Linux now using 100 char lines as default

Interesting:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144

Re: Markdown READMEs?

[Sebastien Lorquet]

Please make sure the readmes are still easily readable in vim and other 
plain text editors.


Plain text is good.

underlined plain text interpreted by github is still readable (markdown?)

anything that requires writing explicit tag in the readme text files 
should be avoided imho.



also, anything that requires non-trivial tools for reading is to be 
excluded.


asciidoctor requires ruby

Not sure that throwing more tools in the mix is even useful...


Sebastien

Le 16/07/2020 à 17:56, Adam Feuer a écrit :

I like the idea of doing a ReStructured Text build in CI. I'd help convert
READMEs and other docs to RST. And I'd be willing to contribute the RST
docs I have already as a starting place if people are interested. They are
already Apache 2.0 Licensed.

-adam

On Thu, Jul 16, 2020 at 6:45 AM Matias N.  wrote:


Documenting boards using the README's in each subdirectory (by converting
them to Markdown and having them rendered somewhere) is indeed to most
direct approach. Although I would say it is an intermediate solution.

I think having an explicit repo holding documentation written in something
more powerful (ReStructured text, or whatever) would probably allow to get
better results. In this repo a CI system could use python or whatever
dependency necessary. No need to add build-dependencies to NuttX codebase
for that.

In that scenario, I would try to move most of the user-friendly
documentation towards that repo away from the board READMEs, leaving them
only with technical details that are better described there. I would still
use Markdown in that case, due to how GitHub renders them.

So, until something like that is done I think it would be appropriate to
move all READMEs to Markdown and have them available somewhere, but as I
mentioned, I think having a doc.nuttx.org site or something similar to
Zephyr's would really increase the user-friendliness of NuttX.

That said, I can help in both efforts, this is something I've been meaning
to work on for sometime and there was simply no infrastructure available at
the moment (that is why I worked on the NuttX GitBook but such effort is
definitely not for just one person).

Best,
Matias

On Thu, Jul 16, 2020, at 01:20, Adam Feuer wrote:

Zephyr uses Sphinx  and

ReStructured

Text (RST) for their docs.

I'm a

fan obviously, it's great for writing hyperlinked technical

documentation.

Sphinx requires Python, though.

The board list with pictures is a great idea, and I'd be willing to help
with it.

-adam

On Wed, Jul 15, 2020 at 9:11 PM Maciej Wójcik  wrote:


what do you think about using Markdown for README files?

Since the project was very conservative so far, I used regular

expression

to parse some existing files into Markdown. Although it is not

completely

reliable. I also think that markdown in repository would be great.

Even trying to sneak in some first Markdown file already :D



https://github.com/apache/incubator-nuttx-apps/blob/2fdd7529251919315bce62ceb0b130d7f135c506/graphics/lvgl/README.md

One of the reasons I really like the Zephyr docs...

Yes, it is also my impression. This is why I am trying to create
interactive documentation right now.

Kconfig NuttX data is extracted using the same library as Zephyr does.

Here are some existing READMES parsed into markdown
http://nuttx-config.nxtlabs.pl/#/apps. To be more specific
apps/*/README.txt files.

I would like to add boards section as well in form of tiles with

pictures

and board configuration support comparison inspired by this
https://node.green.

Complete tree of READMEs with a search is also in my mind
https://gitlab.com/nuttx-upm/kconfig-browser/web-ui/-/issues/25

How it works: currently there is a pipeline which runs for multiple
tags/branches (master, releases/9.1, releases/9.0, ...) and extracts

data

into static JSON. Then Vue.js application is trying to render it.

Pipeline

triggers automatically weekly to keep the master fresh.


Am Do., 16. Juli 2020 um 03:55 Uhr schrieb Matias N. :


On Wed, Jul 15, 2020, at 22:45, Brennan Ashton wrote:

I would be huge fan of this.  It makes it a lot more approachable,

I

had

started converting the main readme in particular but I did not get

very

far. It's a lot of work.

I can help with that if you want


Did you see Adams work here
https://nuttx-companion.readthedocs.io/en/latest/

I thought it would be really nice to integrate the board list with

the

readme content into it. (While keeping the content readable in the

source

control).

Yes, I was actually imagining some sort of CI command on the website

(not

sure the wiki handles that) that could build a list with all boards
containing a README, link to it and display it there nicely

formatted.

Something like readthedocs could possibly do it already, not sure.

One of the reasons I really like the Zephyr docs is because of this,

you

can see how they present their supported boards 

Re: api stability in apps/netutils/webclient

[Sebastien Lorquet]

Hello,

I have introduced nxcurl as a simplified curl for NuttX. It is a real 
port, only the function names are different.


The interface is similar to the real curl.

It is not abandoned, the implemented features work.

IIRC it supports what is required for reimplementing webclient on top of 
it. If it was broken in the apache transition mess, it's not because of me.


The name is weird, but it can be renamed if that helps anyone. Meanwhile 
a trivial header file can rename functions.


I use it in an internal unpublished project. I have only implemented 
what was required, but it works well.


If anyone requires extension, like the multi api, you are welcome to 
provide patches. I can review them.


Sebastien


Le 31/07/2020 à 06:38, Takashi Yamamoto a écrit :

On Wed, Jun 3, 2020 at 4:23 AM Alan Carvalho de Assis  wrote:

Hi Takashi,

Do you think it could be possible to create a HTTP REST framework for
NuttX similar to Ulfius:

https://babelouest.github.io/ulfius/

https://www.hackster.io/babelouest/http-rest-framework-in-c-for-embedded-systems-d34b0c

It should be very useful feature.

do you mean the particular api? or its feature set?
anyway i can't think of any reason it's impossible for nuttx.

in case you are asking if i volunteer to create such a rich framework,
no, i don't. (sorry!)


BR,

Alan

On 5/29/20, Takashi Yamamoto  wrote:

hi,

On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet 
wrote:

I think the web client could be rewritten to benefit from the curl port
I started a while a go, which is available upstream:

https://github.com/apache/incubator-nuttx-apps/tree/master/netutils/libcurl4nx

Improving this curl port would benefit any app using it, not just the
web client.

i have looked at libcurl4n before i decided to use webclient.
my problem with libcurl4nx were:

* weird name :-)
* it looked even less mature and incomplete than webclient.
* no users as far as i know.
* "easy" api was not that attractive. i hope it were "multi" api.
* it looked like an abandoned project. (i guess i was wrong on this
point as apparently you still care.)

btw, is it a curl port?
i thought it was an independent project with a similar api.


Sebastien

Le 29/05/2020 à 08:23, Takashi Yamamoto a écrit :

hi,

On Fri, May 29, 2020 at 7:00 AM Gregory Nutt 
wrote:

i want to add some stuff to apps/netutils/webclient.
for example,

* ability to report http status to the caller
* ability to add some request headers
* put
* other content-type for post
* tls

a question: how much api stability is expected for this?

Of course we would like the code to be stable in the sense that it
continues to behave correctly; I assume that you would carefully
verify
new features. But I think by stable you are referring to a fixed API.
I
don't think that is necessary either.  This is not a standard
interface
and it is not even documented.  People using non-standard,
undocumented
interfaces need to accept that they are subject to change without
notice.

A good explanation in comments of how to get legacy behavior I think
is
sufficient.  Do other people agree with that?


can i just add extra arguments to wget() etc?
or should i keep wget() intact and introduce a new set of symbols?

I don't see any problems with extending wget().   We should do that
wisely.  Perhaps it would be better if wget took a structure as an
argument rather than a long, long parameter list.  I would personally
prefer to see one wget() rather than the old wget() with a new wget2()
which is the same but with different parameters.

All current usage of wget() should be modified to use any changes that
you make to the interface.  I find only examples/wget/ and nshlib/.
Is
that everything?

right now i'm thinking
1. introduce something like the following. keep wget() etc as wrappers
of this in the meantime
2. once things get stable, inline the existing users of wget() etc in
the tree, like examples/wget, one-by-one
3. consider removing wget() etc

struct webclient_context
{
  /* request parameters */

  FAR const char *method;
  FAR const char *url;
  FAR const char * FAR const *headers;
  unsigned int *nheaders;

  /* other parameters */

  FAR char *buffer;
  int buflen;
  wget_callback_t callback,
  FAR void *callback_arg;
  FAR const struct webclient_tls_ops *tls_ops;
  FAR void *tls_ctx;

  /* result */

  int http_status;
};

struct webclient_context ctx;
webclient_set_defaults();
ctx.method = "GET";
ctx.url = "..."
:
ret = webclient_perform();

Re: [Discuss] Migrate the build system to CMake

[Sebastien Lorquet]

Hello,

I believe in a stong principle, applied successfully numerous time in my 
embedded development company:



It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary in 
the first place


- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external 
tool with bugs in itself, and its idiosyncrasies and workarounds.



Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of the 
nuttx documentation will become fully obsolete overnight.



Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because 
anyone can bring it change without a single damn given to customer since 
the code has no warranty of fitness of etc etc open source legalese.



If it was me, I would not do this change. If I had to take a decision 
about something similar in my company, it would be a strong no.



Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the migration
to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the focus
can be put mostly at the board level and on test and validation on different
platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the interest it
requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing forward with 
this.

(*) As a commiter (non-PPMC member), I'm not sure if I can formally call on
a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:

I am interested and I'll try to help with boards I can test. It will take a
few days to get around to it because this has been a busy month, but I'm
catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis mailto:acassis%40gmail.com>>
wrote:


I think we can divide the effort to port all the boards to the new CMake.

I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N. mailto:matias%40imap.cc>> wrote:

Hi,
just wanted to add that until this is ready, the gap between master and

the

branch
widens with every merged PR and this increases the backporting effort.
I'm willing to do most of the remaining work but as I mentioned I cannot
possibly test everything so
help is needed.
I'd really like your feedback on this before I continue and ensure the
effort will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:

Hi,
for anyone not following the relevant PR, please have a look at the
current state here:

https://github.com/apache/incubator-nuttx/pull/3704

This is now at a point where it can be tested by others. It would be

very

good to get some
help testing what I got so far (sim and stm32f4discovery, both on Linux
and mac), by running
examples and test. There are some brief instructions at the end of the

PR

description for building.

Other than that, I can continue porting other arch's and boards with the
help of CI but it would be
best if others with more boards could help testing (and ideally with

some

PRs, as the hard part
is mostly done) those as well.

Also, note that this is a PR against a branch so we could eventually

merge

it before adding support
for other arch/boards. And finally, I will provide documentation to the
new build system in a separate
PR at some point, which I hope will ease the transition and help
reviewing.

Best,
Matias

On Sat, Apr 10, 2021, at 18:43, Xiang Xiao wrote:

A new issue is opened recently to address this topic:
https://github.com/apache/incubator-nuttx/issues/3455
This proposal has the depth of the impact in our daily working, so it's
very important 

Re: [Discuss] Migrate the build system to CMake

[Sebastien Lorquet]

Opponents should raise their voice.

They are part of this "community" and have the ability to weight in this 
decision.


Sebastien

Le 09/06/2021 à 15:46, Gregory Nutt a écrit :
I think that there a lot of people like myself who are opposed to the 
CMake change but are remain silent to let the community make the 
decision.  I suspect that the advocates of CMake are having a larger 
voice in the decision.


On 6/9/2021 7:38 AM, Sebastien Lorquet wrote:

Hello,

I believe in a stong principle, applied successfully numerous time in 
my embedded development company:



It it's not broken, dont fix it.


That applies precisely to this change.

The build system we have have the following characteristics

-it works for its intended purposes

-it is pretty complex

-ALL USERS have become used to it


Changing it

- will bring a lot of new bugs

- along with the annoying feeling that these bugs were not necessary 
in the first place


- No one will understand the build system anymore

- since makefiles are now generated, we rely on yet another external 
tool with bugs in itself, and its idiosyncrasies and workarounds.



Moreover:

-the doc about nuttx is not hosted by the nuttx project, so 99 % of 
the nuttx documentation will become fully obsolete overnight.



Gratuitous changes are a hell, they destroy efficiency.

They tend to appear more frequently in open source projects, because 
anyone can bring it change without a single damn given to customer 
since the code has no warranty of fitness of etc etc open source 
legalese.



If it was me, I would not do this change. If I had to take a decision 
about something similar in my company, it would be a strong no.



Sebastien


Le 09/06/2021 à 14:57, Matias N. a écrit :

Hi everyone,

this thread has received little engagement from the community
in general, for a change with such impact on daily use of NuttX
for everyone.

While there was positive feedback on GH and a few people have
expressed more interest, not much has really happened. Meanwhile,
the backlog of changes that would need to be backported continues
to increase.

At the same time, I see many PRs addressing subtle issues with
current build system, which are mostly already solved with the 
migration

to CMake. So there's continued effort in maintaining the current system
which could be in part dedicated to the migration to a better system.

I have offered technical guidance on testing and extending to other
platforms and also to add base support for other arch's so that the 
focus
can be put mostly at the board level and on test and validation on 
different

platforms and target hardware. However, after having worked on this
for more than a month I feel this is not really picking up the 
interest it

requires for proper adoption by the community.

Maybe the proper approach would be to call on a vote (*)
for this feature to have explicit support from the community and
ensure involvement from others than me to move forward.
Otherwise, or if the vote does not pass, I will not be pushing 
forward with this.


(*) As a commiter (non-PPMC member), I'm not sure if I can formally 
call on

a vote and what the exact procedure is, but maybe other PPMC member
can do so.

Best,
Matias

On Tue, Jun 1, 2021, at 15:05, Nathan Hartman wrote:
I am interested and I'll try to help with boards I can test. It 
will take a
few days to get around to it because this has been a busy month, 
but I'm

catching up.

Cheers
Nathan

On Tue, Jun 1, 2021 at 11:25 AM Alan Carvalho de Assis 
mailto:acassis%40gmail.com>>

wrote:

I think we can divide the effort to port all the boards to the new 
CMake.


I can start take care of ESP32, ESP32-C3 and ESP32-S2.

Let see if we get more people involved in this effort.

BR,

Alan

On 6/1/21, Matias N. mailto:matias%40imap.cc>> 
wrote:

Hi,
just wanted to add that until this is ready, the gap between 
master and

the

branch
widens with every merged PR and this increases the backporting 
effort.
I'm willing to do most of the remaining work but as I mentioned I 
cannot

possibly test everything so
help is needed.
I'd really like your feedback on this before I continue and 
ensure the

effort will not go to waste.

Best,
Matias

On Sat, May 29, 2021, at 14:06, Matias N. wrote:

Hi,
for anyone not following the relevant PR, please have a look at the
current state here:

https://github.com/apache/incubator-nuttx/pull/3704

This is now at a point where it can be tested by others. It 
would be

very

good to get some
help testing what I got so far (sim and stm32f4discovery, both 
on Linux

and mac), by running
examples and test. There are some brief instructions at the end 
of the

PR

description for building.

Other than that, I can continue porting other arch's and boards 
with the

help of CI but it would be
best if others with more boards could help testing (and ideally 
with

some

PRs, as the hard part
is mostly done) those as well.

Also, note that this is a PR 

Re: [Discuss] Migrate the build system to CMake

[Sebastien Lorquet]

Le 10/06/2021 à 16:34, Nathan Hartman a écrit :

Second, we need a new Documentation page, "Migrating From Older
NuttX." In this documentation, every compatibility change should be
documented, going from the present to at least as far back as NuttX
7.31. We can get all of these from the ReleaseNotes, but they should
be consolidated somewhere, so that someone like Sebastien who wants to
upgrade from version X to version Y can just go step by step and make
the necessary changes.
That would be an extremely good thing to have. It would ensure an 
exhaustive migration path for legacy installations.


That page should then explain how to migrate to cmake.

If this doc is easy to find, I have less issues with cmake.

Also thank you for fixing the release notes. This triplication is not 
easy to manage.


Sebastien

Re: Memory locations

[Sebastien Lorquet]

Hello,

The correct syntax is:

.isramdata (NOLOAD) :  /*<- this is the segment name in the output, 
NOLOAD means that this segment is not to be initialized, like BSS, but 
the linker alread knows that BSS is NOLOAD*/

    {
    *(.isramdata)    /*<- this is the input sections from the 
relocatable object files*/

    } > isram

If you dont add names between the braces, no symbol from object files 
get included in this segment.


And you should not initialize the variable declaration.

Sebastien

Le 08/06/2021 à 13:23, Tim Hardisty a écrit :
I have added this to my linker script (and other variations on that 
theme, all of which compile OK with no warnings or errors)


    .isramdata :
    {
    } > isram

and declared

static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] 
__attribute__((section(".isramdata"))) = {0};

But it does not place the array in isram :(

Re: Memory locations

[Sebastien Lorquet]

what I would check here (just a live tought process)

* check that the ld file is actually used (ld file is pointed by main 
Make.defs IIRC) (easy: just add garbage in it and verify build actually 
breaks)


* check that the driver source with the definition is being recompiled

* check that the object file that contains the isram based definition 
actually shows the use of the new section


* make distclean, restart with a fresh build tree, rebuild all

* reboot machine if possible (im not joking)

Seems obvious, but sometimes bugs are hiding where we're assuming 
they're not


Sebastien

Le 08/06/2021 à 15:12, Tim Hardisty a écrit :

Thanks, but still no cigar :(

I have tried:

    .isramdata_reserve (NOLOAD) :
    {
    *(.isramdata)
    . = ALIGN(4);
    _isramdata_heap_start = ABSOLUTE(.);
    } > isram

and also just

    .isramdata(NOLOAD) :
    {
    *(.isramdata)
    } > isram

along with trying

staticuint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS] 
aligned_data(MCAN_ALIGN) locate_data(".isramdata");

where MCAN_ALIGN is ARMV7A_DCACHE_LINESIZE, which is 32
or
static uint32_t g_mcan0_msgram[MCAN0_MSGRAM_WORDS] __attribute__ 
((section (".isramdata")));

and all methods still report this as in SDRAM not ISRAM
On 08/06/2021 13:33, David Sidrane wrote:

Here is a working example.


https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/stm32h7/stm32_spi.c#L715-L716 



https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32h7/nucleo-h743zi/scripts/flash.ld#L179-L184 



You can check it the arm-none-eabi-nm -C nuttx.elf | grep g_mcan0_msgram

David

-Original Message-
From: Tim Hardisty [mailto:t...@jti.uk.com]
Sent: Tuesday, June 08, 2021 4:23 AM
To: dev@nuttx.apache.org
Subject: Re: Memory locations


On 07/06/2021 19:06, Nathan Hartman wrote:

On Mon, Jun 7, 2021 at 12:24 PM Tim wrote:
I will, I believe, need to declare - place - MCAN related 
structures such

that they (or at least some elements of them) are in SRAM.


Yes. It is possible. It is done by adding attributes in the code which
tell the compiler that an object should be located at a particular
address or section.

I have added this to my linker script (and other variations on that
theme, all of which compile OK with no warnings or errors)

  .isramdata :
  {
  } > isram

and declared

static uint32_tg_mcan0_msgram[MCAN0_MSGRAM_WORDS]
__attribute__((section(".isramdata"))) = {0};
But it does not place the array in isram :(
system.map states: 20053fc4 D g_mcan0_msgram
which is confirmed by the debugger and an info debug message
Is there anything overruling this? Or a silly mistake, given my
inexperience with linker scripts?
Any guidance much appreciated!

external board build failure

[Sebastien Lorquet]

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: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

done, what a process for a 7-character change...

The PHY and cable detection worked perfectly fine in our project.

Sebastien

Le 24/05/2021 à 23:04, Nathan Hartman a écrit :

On Mon, May 24, 2021 at 11:36 AM Sebastien Lorquet  wrote:

Hello,

There is a typo in the PCA9555 driver at line 817:
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be
CONFIG_PCA9555_INT_NCALLBACKS.

Good catch! Please feel free to open a PR.


After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.

Nathan

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

[Sebastien Lorquet]

No, the workflow is very clear, the pull request model is a defacto 
standard that works everywhere.


But it is heavy for trivial changes. fork, mess with remotes, make a 
branch, forget to change the git config --local user.name, push, deal 
with github and my ssh agent messing with multiple ssh keys for 
different github users, etc etc and then wait for the CI to build 
megabytes of useless tests just for an obvious typo.


It was just easier to send a patch inline and have Greg merge that 
immediately. I was never happy with this change and there is no reason 
to feel better now. But there is no way back now.Just less contributions 
from me.


Sebastien

Le 25/05/2021 à 16:11, Nathan Hartman a écrit :

On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet  wrote:

done, what a process for a 7-character change...

The PHY and cable detection worked perfectly fine in our project.

Sebastien

Thanks so much for doing that!

Regarding the process, did you have any difficulty, i.e., anything
that should be improved in our docs explaining the workflow?

Cheers,
Nathan

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

[Sebastien Lorquet]

it will be easier next time.


Does any of the 21 queued test that I see waiting in github enable this 
driver?


Because if they dont (which I suspect, hence this typo) these tests are 
useless.


Sebastien

Le 25/05/2021 à 16:17, Sebastien Lorquet a écrit :
No, the workflow is very clear, the pull request model is a defacto 
standard that works everywhere.


But it is heavy for trivial changes. fork, mess with remotes, make a 
branch, forget to change the git config --local user.name, push, deal 
with github and my ssh agent messing with multiple ssh keys for 
different github users, etc etc and then wait for the CI to build 
megabytes of useless tests just for an obvious typo.


It was just easier to send a patch inline and have Greg merge that 
immediately. I was never happy with this change and there is no reason 
to feel better now. But there is no way back now.Just less 
contributions from me.


Sebastien

Le 25/05/2021 à 16:11, Nathan Hartman a écrit :
On Tue, May 25, 2021 at 10:05 AM Sebastien Lorquet 
 wrote:

done, what a process for a 7-character change...

The PHY and cable detection worked perfectly fine in our project.

Sebastien

Thanks so much for doing that!

Regarding the process, did you have any difficulty, i.e., anything
that should be improved in our docs explaining the workflow?

Cheers,
Nathan

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

[Sebastien Lorquet]

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 _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 properly, I
probably have to check for differences between my code and the
stm32f429i-disco built-in board (on which I based my board).

Sebastien

Le 25/05/2021 à 21:26, Nathan Hartman a écrit :

On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet 
Back to the business

After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.

Release notes are ha

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

[Sebastien Lorquet]

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

85    if (!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

82    mm_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
82    mm_free(heap, address); <-- address == 0x70fb460b
83  }
84  #endif
85  }
86

(gdb) print _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 properly, I 
probably have to check for differences between my code and the 
stm32f429i-disco built-in board (on which I based my board).


Sebastien

Le 25/05/2021 à 21:26, Nathan Hartman a écrit :

On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet 
wrote:


Back to the business

After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.

Release notes are hard to read but I did not find anything special about
phy interrupts.

Note that it may not be the phy interrupt. Here is my log:

stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
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

A lot of OS

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

[Sebastien Lorquet]

Back to the business

After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I would first start by looking through the Release Notes between v7.30
and v10.1. Many big improvements and bug fixes happened and some of
them are mentioned in Compatibility Concerns along with some changes
you might need to make to configuration etc.

Also another thing you can try: Has this board and PHY worked
correctly with v7.30? If so, you can bisect and with very few tests
(I'm guessing fewer than 20) find the exact commit that broke it.


Release notes are hard to read but I did not find anything special about 
phy interrupts.


Note that it may not be the phy interrupt. Here is my log:

stm32_netinitialize: Enabling PHY power
stm32_netinitialize: PHY reset...
stm32_netinitialize: PHY reset done.
stm32_netinitialize: Configuring PHY int
F
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

A lot of OS initialization things happen at the point, marked by the 
letter F.


It seems that an unexpected IRQ happens in this interval, around the 
time the filesystem is initialized. The backtrace goes down to memory 
allocation routines through the initialization of the root inode.


My guess is that AN external IRQ is triggered (possibly not the PHY IRQ) 
but the ISR handler for that one is not ready yet. I will add debug 
messages.



I would expect that situation to be a simple NOP, but it seems that 
undefined handlers are set to this function "irq_unexpected_isr"


Is that a new behaviour? a default config that I did not set properly 
when porting our old defconfig?


Sebastien



Nathan

Re: external board build failure (stm32 specific)

[Sebastien Lorquet]

Thats because the stm32l4 boards dont have a common folder.

Same for stm32f7

The problem is specific to stm32 (f4 and others). But it's significant 
because it's one of the most used stm32 product families.


I guess the common folder should be avoided.

Sebastien

Le 20/05/2021 à 15:46, Daniel Pereira Carvalho a écrit :

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

1 - Clone nuttx and nuttx-apps on base dir
2 - Created a new dir called board
 $ mkir board
 $ cd board
3 - Copied nucleo-l432kc board directory
 $  cp -r ../nuttx/boards/arm/stm32l4/nucleo-l432kc/ ./
4 - Configure nuttx to build the external board. From nuttx folder
 $ ./tools/configure.sh ../board/nucleo-l432kc/configs/nsh/
5 - Build
 $ make

These steps seems to work fine for me.

Thanks

Daniel Pereira de Carvalho


Em qui., 20 de mai. de 2021 às 10:35, Alan Carvalho de Assis <
acas...@gmail.com> escreveu:


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: external board build failure

[Sebastien Lorquet]

: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

CONFIG_CAN_PASS_STRUCTS disappeared ?

[Sebastien Lorquet]

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: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

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


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


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


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

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


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


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

Sebastien

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

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

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

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

BR,

Alan

On 5/27/21, Sebastien Lorquet  wrote:

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

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

Sebastien

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

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

Thank you.

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

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

Sebastien


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

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




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

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


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

the heap for the main RAM at 0x2000?

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

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

Hello,

Thanks for the remarks.

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

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

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

Sebastien

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

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


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

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


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

I have enabled memory management debug:

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

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

the mm_free(0x70fb460b

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

[Sebastien Lorquet]

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


Thank you.

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


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

Sebastien


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

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


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

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


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

the heap for the main RAM at 0x2000?

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

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

Hello,

Thanks for the remarks.

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

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

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

Sebastien

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

If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85
I remember that at some point I had a similar hardfault in mm which doesn't
make sense and it was due to outdated board Make.defs.

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


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

I have enabled memory management debug:

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

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

the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but 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 _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 properly, I
probably have to check fo

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

[Sebastien Lorquet]

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


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


Sebastien

Le 27/05/2021 à 09:38, Sebastien Lorquet a écrit :
Boom, that was the extrastuff. The board now boots. We're going to run 
a lot of functional tests to make sure everything is okay, but I dont 
have this strange hardfault at boot.


Thank you.

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


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

Sebastien


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

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




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

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


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

the heap for the main RAM at 0x2000?

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

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

Hello,

Thanks for the remarks.

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

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

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

Sebastien

Le 26/05/2021 à 18:08, raiden00pl a écrit :
If you use CONFIG_BUILD_FLAT=y, make sure that __KERNEL__ flag is 
set here:
https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/mm/mm.h#L85 

I remember that at some point I had a similar hardfault in mm which 
doesn't

make sense and it was due to outdated board Make.defs.

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

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

in mm_alloc

I have enabled memory management debug:

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

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

the heap for the main RAM at 0x2000?

the mm_free(0x70fb460b) is not what causes the hardfault (it comes
later), but 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
85    if (!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
82    mm_free(heap, address);
(gdb) list
77
78    /* The address should always be non-NULL since that was
checked in the
79 * 'wh

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

[Sebastien Lorquet]

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


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


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


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


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



Abdelatif replied something while I was writing:

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


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



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



Sebastien

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

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

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

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

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


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

I completely missed that! Thanks!

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

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

Thanks,
Nathan

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

[Sebastien Lorquet]

Code was working perfectly before the nuttx upgrade so I tend to think 
that stack is sufficient.


Sebastien

Le 26/05/2021 à 21:49, David Sidrane a écrit :

Hi Sebastien,

Stack crashing into heap?

Have you upped the stack sizes across the board?


David

-Original Message-
From: Sebastien Lorquet [mailto:sebast...@lorquet.fr]
Sent: Wednesday, May 26, 2021 9:22 AM
To: dev@nuttx.apache.org
Subject: Re: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

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 _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 properly, I
probably have to check for differences between my code and the
stm32f429i-disco built-in board (on which I based my board).

Sebastien

Le 25/05/2021 à 21:26, Nathan Hartman a écrit :

On Tue, May 25, 2021 at 12:02 PM Sebastien Lorquet 
Back to the business

After this we managed to recompile our project using the latest NuttX
sources, but it fails when trying to init the PHY irq on our
STM32F427
board: We get "unexpected IRQ".

Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this
domain, before I dig the jtag probe to fix it (tomorrow) ?

I

Re: CONFIG_CAN_PASS_STRUCTS disappeared ?

[Sebastien Lorquet]

Okay, thanks.

Sebastien

Le 24/05/2021 à 11:23, Abdelatif Guettouche a écrit :

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: Port of project from NuttX 7.30 to 10.1 RC1: Unexpected IRQ

[Sebastien Lorquet]

https://github.com/apache/incubator-nuttx/issues/3769

Le 24/05/2021 à 17:36, Sebastien Lorquet a écrit :

Hello,

There is a typo in the PCA9555 driver at line 817: 
CONFIG_TCA64XX_INT_NCALLBACKS is a bad copy paste, should be 
CONFIG_PCA9555_INT_NCALLBACKS.


After this we managed to recompile our project using the latest NuttX 
sources, but it fails when trying to init the PHY irq on our STM32F427 
board: We get "unexpected IRQ".


Yes I know that's pretty vague :-)

Is there anything obvious I should have been careful with in this 
domain, before I dig the jtag probe to fix it (tomorrow) ?


Sebastien

Re: LPC1769 Progmem

[Sebastien Lorquet]

Hello

Note that in "real" field-deployed product this sector512 layer should 
NOT be used since it will wear the flash much faster than using a real 
MTD filesystem.


One thing to keep in mind is that flash takes a significant time to 
erase and write, and that if interrupted, a flash memory zone can be 
half-erased or half-written, because in the end, we are talking about 
injecting a bunch of electrons in a floating silicon gate.


In that case data will have the potential to become unstable, since 
sometimes the number of electrons will be just at the limit where the 
sense amplifiers distinguish a one or a zero, leading to transient flash 
errors.


A real flash file system SHALL use error detection via CRCs and 
redundancy. it is not correct to assume that a flash will be stable like 
a hard disk in a real product that can sustain power interruptions.


The use of FAT filesystems is noticeably horrifying in this context.

Notice that here I am talking about all kind of flashes, not just NAND. 
NOR flash (spi-based and internal to MCUs) can also have these partial 
states.


At least, a resilient product should have a large storage cap on its 
VCC/flash vcc and use a GPIO interrupt to detect the power interruption 
(many switching converters have a PWROK output), so the flash can at 
least finish its current operation. In case of power failure, flash 
writes after the current operation to finish shall be forbidden. A 
built-in brown-out detector may not be sufficient, since it only 
guarantees operation of the CPU core, not ability to write flash.


Sebastien

Le 08/07/2021 à 16:28, Gregory Nutt a écrit :

The pagesize should be the same as the erase block size.. 4k.

You will probably want 512b sectors (pages, or whatever we call them 
now) at the file system interface. You can also read-modify-write 
operations to "simulate" smaller erase blocks. Most MTD drivers do 
that.  In that case they report the simulated erase block size.  The 
overhead is an internal, large 4Kb buffer.


You can also use drivers/mtd/sector512.c to get a "generic" 
read-modify-write implementation and 512 b "simulated" erase blocks like:


   FAR struct mtd_dev_s *raw_mtd = progmem_initialize();
   FAR struct mtd_dev_s *s512_mtd = s512_initialize(raw_mtd);


On 7/8/2021 7:30 AM, Fotis Panagiotopoulos wrote:

Still looking at this driver, and how to improve it.

The LPC1769 needs data to be written in 256 bytes chunks, but Flash 
sectors

are erased in 4k or 32k sizes.

So, a couple of questions:

1. What should up_progmem_pagesize return , 256 or 4k/32k?
By the description I suppose it should be 256.
This is not true however for the STM32 arch.

2. What should up_progmem_getpage return?
I guess 256 again...?

But how up_progmem_eraseblock is expected to work?
There is no up_progmem_getblock, so there is no way that the application
knows which block to pass.
In STM32 I used up_progmem_getpage, but by checking the functions
descriptions now, I guess this shouldn't be correct?

Or should "page" here refer to the 4k/32k sectors?



Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:


Oh, that's great. That should definitely make the interface better.

But nevertheless, I tried to "ignore" the terms, and still I can't make
any sense of it.

This is what I try to do (which works fine on an STM32F4):

int write_data(intptr_t addr, BootData_t * data){
if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
    return 0;

if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
    return -EIO;

return up_progmem_write(addr, data, sizeof(BootData_t));}


I see that up_progmem_getpage() makes an unreasonable calculation.
It calculates the "page" as if it is 256 bytes, while in fact 
LPC1769 has

4k and 32k sectors...



Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
xiaoxiang781...@gmail.com> έγραψε:


Here has some discussion about the naming:
https://github.com/apache/incubator-nuttx/pull/3834

On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos 

wrote:


Hello,

I am porting an old application to NuttX.
This is running on a hardware board that uses the NXP LPC1769 MCU.
I am in need of the up_progmem interface.

Unfortunately, I see that this driver is broken. It is not working,

always

returning an error.
I checked its internals, but it is quite a mess. It makes wrong
calculations on the sector sizes, it confuses the terms "page" and

"sector"

etc.
I see that it makes some calculations on the addresses, that to my
knowledge do not reflect the hardware in any way.

Is it actually that broken, or am I using it so incorrectly?
Has anyone used it before successfully?

I would appreciate a MWE of this driver. Or someone to confirm 
that it

is

not working before I start to rewrite it.

Re: Duplicate task_spawn()

[Sebastien Lorquet]

I see that around the time of this discussion the userland API of 
task_spawn has been changed in incompatible ways.


by this commit:

https://github.com/apache/incubator-nuttx-apps/commit/58293abb8e896bb04f3a76bf8b48206debe68f26?branch=58293abb8e896bb04f3a76bf8b48206debe68f26=unified

My apps, cloned from a nuttx repo that did not have this change, are 
suddenly broken in places I do not even care about.


An example:

In file included from exec_builtin.c:49:0:
/home/slo/nuttx/include/spawn.h:150:5: note: expected 'char * const*' 
but argument is of type 'posix_spawnattr_t * {aka struct 
posix_spawnattr_s * '

 int task_spawn(FAR const char *name, main_t entry,
 ^~
exec_builtin.c:195:13: error: too many arguments to function 'task_spawn'
   ret = task_spawn(, builtin->name, builtin->main, _actions,


This is rather annoying. On the long term, this project becomes unstable 
in multiple ways.


I suggest that user API breaks are documented in the same place as was 
used for other breaking changes.


This is how I feel right now: https://www.youtube.com/watch?v=_LueFhQk5hg


Sebastien


Le 01/06/2020 à 16:43, Gregory Nutt a écrit :

On 5/30/2020 1:27 AM, Yang Chung Fan wrote:

Hi,

Did anyone also noticed that when building with CONFIG_LIB_SYSCALL=y,
the linker is unhappy about the duplicated task_spawn() symbols?

One of them is in sched/ and other one is in libs/libc.


PR 1168 should take care of this.

Re: LPC1769 Progmem

[Sebastien Lorquet]

hello,

cool if you have a proper storage system :)

The STM32F4 also has these variable sector sizes, and IIRC it is not 
accessible as MTD.


Yes, usually, the write size is much smaller than the erase size.

Sebastien

Le 08/07/2021 à 16:47, Fotis Panagiotopoulos a écrit :

The pagesize should be the same as the erase block size.. 4k.

If it is so (which makes sense, regardless of what the comments say), then
what is the purpose of  up_progmem_erasesize ?
It should return the same thing I guess?

The function up_progmem_erasesize was what made me think that pagesize is a
different thing.

---

Regarding the MTD comments.
Thank you very much for your advice.
Fortunately my driver handles all of these cases quite well.
It accesses the Flash memory directly, and ensures all needed wear-leveling
and error checking
(at least to the extent that it is necessary in this specific application).

I just need a working progmem interface, to provide it with.
STM32 works correctly for me till now; LPC is the one that needs fixing.


Στις Πέμ, 8 Ιουλ 2021 στις 5:28 μ.μ., ο/η Gregory Nutt 
έγραψε:


The pagesize should be the same as the erase block size.. 4k.

You will probably want 512b sectors (pages, or whatever we call them
now) at the file system interface. You can also read-modify-write
operations to "simulate" smaller erase blocks.  Most MTD drivers do
that.  In that case they report the simulated erase block size.  The
overhead is an internal, large 4Kb buffer.

You can also use drivers/mtd/sector512.c to get a "generic"
read-modify-write implementation and 512 b "simulated" erase blocks like:

 FAR struct mtd_dev_s *raw_mtd = progmem_initialize();
 FAR struct mtd_dev_s *s512_mtd = s512_initialize(raw_mtd);


On 7/8/2021 7:30 AM, Fotis Panagiotopoulos wrote:

Still looking at this driver, and how to improve it.

The LPC1769 needs data to be written in 256 bytes chunks, but Flash

sectors

are erased in 4k or 32k sizes.

So, a couple of questions:

1. What should up_progmem_pagesize return , 256 or 4k/32k?
By the description I suppose it should be 256.
This is not true however for the STM32 arch.

2. What should up_progmem_getpage return?
I guess 256 again...?

But how up_progmem_eraseblock is expected to work?
There is no up_progmem_getblock, so there is no way that the application
knows which block to pass.
In STM32 I used up_progmem_getpage, but by checking the functions
descriptions now, I guess this shouldn't be correct?

Or should "page" here refer to the 4k/32k sectors?



Στις Παρ, 2 Ιουλ 2021 στις 2:08 μ.μ., ο/η Fotis Panagiotopoulos <
f.j.pa...@gmail.com> έγραψε:


Oh, that's great. That should definitely make the interface better.

But nevertheless, I tried to "ignore" the terms, and still I can't make
any sense of it.

This is what I try to do (which works fine on an STM32F4):

int write_data(intptr_t addr, BootData_t * data){
  if (memcmp((BootData_t*)addr, data, sizeof(BootData_t)) == 0)
  return 0;

  if (up_progmem_eraseblock(up_progmem_getpage(addr)) < 0)
  return -EIO;

  return up_progmem_write(addr, data, sizeof(BootData_t));}


I see that up_progmem_getpage() makes an unreasonable calculation.
It calculates the "page" as if it is 256 bytes, while in fact LPC1769

has

4k and 32k sectors...



Στις Παρ, 2 Ιουλ 2021 στις 1:39 μ.μ., ο/η Xiang Xiao <
xiaoxiang781...@gmail.com> έγραψε:


Here has some discussion about the naming:
https://github.com/apache/incubator-nuttx/pull/3834

On Fri, Jul 2, 2021 at 6:28 PM Fotis Panagiotopoulos <

f.j.pa...@gmail.com

wrote:


Hello,

I am porting an old application to NuttX.
This is running on a hardware board that uses the NXP LPC1769 MCU.
I am in need of the up_progmem interface.

Unfortunately, I see that this driver is broken. It is not working,

always

returning an error.
I checked its internals, but it is quite a mess. It makes wrong
calculations on the sector sizes, it confuses the terms "page" and

"sector"

etc.
I see that it makes some calculations on the addresses, that to my
knowledge do not reflect the hardware in any way.

Is it actually that broken, or am I using it so incorrectly?
Has anyone used it before successfully?

I would appreciate a MWE of this driver. Or someone to confirm that it

is

not working before I start to rewrite it.

asynchronous sockets

[Sebastien Lorquet]

Hello,

I need to implement an asynchronous server in NuttX.

What infrastructure is currently working best? performance and 
functionality wise...


select or epoll?

Thanks for any advice

Sebastien

Re: Using NuttX with custom bootloader

[Sebastien Lorquet]

Hello

I did that and it works in a consumer product with a stm32 since, well, 
2018 I think. Also in an open source product.


my board uses a custom linker script that locates the start of the flash 
a bit farther than the usual start (one stm32 block or 16k IIRC) . Then 
I compile nuttx as usual.


The bootloader happens to be built by the same process, and all the 
bootloader code goes into a separate named text section and memory zone. 
It could be built separately but this is convenient. Only problem is I 
cant use inline strings for debug because I could not find how to 
control the section these litteral strings are affected to. So I use 
global const arrays. ugly but it does the job.


when the boards are manufactured the whole HEX file is flashed, which 
includes BOTH the bootloader and the initial OS.


After that the board can be updated "over the air".

A python scripts extract the "OS image" from the ELF file and wrap it 
appropriately, then an update file is built.


Our NuttX then includes some applicative code to retrieve and validate 
this update file.


The contents are written to SPI flash (via a char driver wrapper to MTD 
devices to bypass the nuttx FTL)


The board reboots

the bootloader code detects the update in the SPI flash and writes the 
contents to the STM32 flash.


once complete and verified, the SPI contents is disabled. Else the 
bootloader can restart the process. We could have emergency serial code 
to upload an image from the bootloader, but we never had to, this 
process works fine, we never had bricked boards.


This method prevents updating the bootloader.

So we can ship special OS updates that includes an updated bootloader as 
a static const.


The nuttx board start code is then able to update the bootloader. We 
rarely use this feature, only once IIRC.


In our case, the bootloader has to disable the SPI peripheral before 
booting the OS, else NuttX will find it initialized and will not 
initialize it correctly.


Our system is rather complex but is also quite failsafe.

Sebastien

Le 21/04/2021 à 20:54, Flavio Castro Alves Filho a écrit :

Hello,

I intend to use a NuttX firmware with a custom bootloader on a
STM32F4DISCOVERY board.

The bootloader will be executed on the first available memory block in
flash, and the firmware will start from the second block - position
0x0802.

I believe I know what to do regarding linker script.

But I don't know if there is anything to be done directly in NuttX source code.

I ask this because in a standard STM32 firmware using STM32Cube, there
is a FLASH_BASE constant that must be set correctly for the firmware
to work correctly. My worry is if there is something similar in NuttX
for the board.

Best regards,

Flavio

Re: Using NuttX with custom bootloader

[Sebastien Lorquet]

Sorry, forgot to say that of course, VTOR is updated by the bootloader 
prior to jumping into the OS.



BOOTCODE __attribute__((naked, noreturn)) void __boot_app(void)
  {
    __asm__ __volatile__ ("\t"
    /* load SP (from 08004000) */

    "movw r0, #0x4000  \n\t"
    "movt r0, #0x0800  \n\t"
    "ldr  sp, [r0] \n\t"

    /* load LR (from 08004004) */

    "movw r0, #0x4004  \n\t"
    "movt r0, #0x0800  \n\t"
    "ldr  r0, [r0] \n\t"
    "mov  lr, r0   \n\t"

    /* setup VTOR (at E000ED08) to remap vectors*/

    "movw r0, #0xED08    /*adr lo*/ \n\t"
    "movt r0, #0xE000    /*adr hi*/ \n\t"
    "movw r1, #0x4000    /*val lo*/ \n\t"
    "movt r1, #0x0800    /*val hi*/ \n\t"
    "str  r1, [r0]   /*store value at address*/ \n\t"

    "bx   lr /*take the jump*/ \n"
    );

  }


Le 22/04/2021 à 09:59, Sebastien Lorquet a écrit :

Hello

I did that and it works in a consumer product with a stm32 since, 
well, 2018 I think. Also in an open source product.


my board uses a custom linker script that locates the start of the 
flash a bit farther than the usual start (one stm32 block or 16k IIRC) 
. Then I compile nuttx as usual.


The bootloader happens to be built by the same process, and all the 
bootloader code goes into a separate named text section and memory 
zone. It could be built separately but this is convenient. Only 
problem is I cant use inline strings for debug because I could not 
find how to control the section these litteral strings are affected 
to. So I use global const arrays. ugly but it does the job.


when the boards are manufactured the whole HEX file is flashed, which 
includes BOTH the bootloader and the initial OS.


After that the board can be updated "over the air".

A python scripts extract the "OS image" from the ELF file and wrap it 
appropriately, then an update file is built.


Our NuttX then includes some applicative code to retrieve and validate 
this update file.


The contents are written to SPI flash (via a char driver wrapper to 
MTD devices to bypass the nuttx FTL)


The board reboots

the bootloader code detects the update in the SPI flash and writes the 
contents to the STM32 flash.


once complete and verified, the SPI contents is disabled. Else the 
bootloader can restart the process. We could have emergency serial 
code to upload an image from the bootloader, but we never had to, this 
process works fine, we never had bricked boards.


This method prevents updating the bootloader.

So we can ship special OS updates that includes an updated bootloader 
as a static const.


The nuttx board start code is then able to update the bootloader. We 
rarely use this feature, only once IIRC.


In our case, the bootloader has to disable the SPI peripheral before 
booting the OS, else NuttX will find it initialized and will not 
initialize it correctly.


Our system is rather complex but is also quite failsafe.

Sebastien

Le 21/04/2021 à 20:54, Flavio Castro Alves Filho a écrit :

Hello,

I intend to use a NuttX firmware with a custom bootloader on a
STM32F4DISCOVERY board.

The bootloader will be executed on the first available memory block in
flash, and the firmware will start from the second block - position
0x0802.

I believe I know what to do regarding linker script.

But I don't know if there is anything to be done directly in NuttX 
source code.


I ask this because in a standard STM32 firmware using STM32Cube, there
is a FLASH_BASE constant that must be set correctly for the firmware
to work correctly. My worry is if there is something similar in NuttX
for the board.

Best regards,

Flavio

Re: which filesystem?

[Sebastien Lorquet]

SmartFS DOES actually works and will not shred the flash sectors to 
pieces as it's aware of flash memory behaviour and limited erases.


Reading the original paper I found that LittleFS was VERY well made to 
ensure FS operations are atomic and recoverable in the event of a power cut.


Protection against random power cuts at ANY time IS a very important 
point in any embedded project, and is usually not taken very seriously 
by every maker, pro or not.


Sebastien

Le 25/08/2021 à 20:01, Tim Hardisty a écrit :

Hi Ken,

  


You fell for my 100% unintentional trap…thread title didn’t match content! I’d 
started one message, saved it as a draft, then changed my mind on what to ask 
but didn’t change the title. Doh!

  


I did try SmartFS and really like the sound of it, but it didn’t work “out of 
the box”. I think it is because it can’t cope with 256Mbit devices; I got a 
number of errors to do with sector sizes (from memory) and a quick debug 
suggestion that perhaps some variables are defined as 16 bit: not sure, and 
might return to it.

  


To answer your question – which was the original intent of this help request, 
the aim is fundamentally data logging. Users will log data (at 20Hz, say; 
multiple parameters) then occasionally pull them off for external analysis, 
delete, and start again. So I don’t think wear levelling is actually an issue; 
just speed and ease of pulling data off to spit out over USB or Bluetooth LE, 
on an occasional basis.

  


One file open for write is fine with what I currently envision, but who knows. 
SmartFS has much appeal as a “just in case”.  I have more DRAM than I know what 
to do with :)

  


Tim.

  

  

  


From: Ken Pettit 
Reply to: 
Date: Wednesday, 25 August 2021 at 18:12
To: 
Subject: Re: which filesystem?

  


Hey Tim,

  


Selection of filesystem is kind of a personal choice.  Each filesystem

has different features / benefits.  I have never used NXFFS but I know

it absolutely works with the caveat that you can only have one file open

for writing at a time.  Because of this, I wrote SmartFS, which doesn't

have this limitation, but also adds extra RAM usage for each open file.

So as you see, there are tradeoffs.  There is also LittleFS and SPIFFS

to choose from to make it even more complicated.

  


So I guess you first should ask, what features do I need from the FS?

Directory support?  Wear leveling?  Multiple open files for write?

Maybe a list of the features needed from the FS will help.

  


Ken

  


On 8/25/21 10:04 AM, Tim wrote:

I seem to have got over most of my SPI flash and EEPROM issues now and my

256Mb SPI flash is properly recognised.

  

  

  


I think I am at the last hurdle. Here is the console output, along with my

question of the day :)

  

  

  


Successfully initialized M25P SPI

  


m25p_initialize: dev: 0x2005b970

  


m25p_readid: priv: 0x2005b990

  


m25p_readid: manufacturer: 20 memory: ba capacity: 19

  


m25p_initialize: Return 0x2005b990

  


Successfully bound SPI0 CS1 to the SPI FLASH driver

  


m25p_ioctl: cmd: 1537

  


m25p_ioctl: blocksize: 256 erasesize: 4096 neraseblocks: 8192

  


m25p_ioctl: return 0

  


m25p_bread: startblock:  nblocks: 1

  


m25p_read: offset:  nbytes: 256

  


m25p_waitwritecomplete: Complete

  


m25p_read: return nbytes: 256

  


nxffs_nextentry: No entry found

  


nxffs_limits: No inodes found

  


nxffs_limits: Free FLASH region begins at offset: 5

  


nxffs_limits: First inode at offset 5

  


Succesfully initialised NXFSS

  


nx_mount: ERROR: Failed to find block driver (null)

  


Failed to mount the NXFSS volume -15

  

  

  


I believe the block driver would be "/dev/M25P" (M25P, for example) but

there is no code I have found that specifies the block driver location. I

have:

  

  

  


ret = nxfss_initialize(mtd);

  

  

  


then

  

  

  


ret = nx_mount("NULL, "/mnt/M25P", 0, NUL);

  

  

  


and that seems to be in common with other "bringup" code; using NULL rather

than "/dev/something".

  

  

  


Just need the last piece of this jigsaw if anyone could be so kind :)

  

  

  

Re: nxfss on MT25Q nor flash

[Sebastien Lorquet]

that is the best and usual way to get documentation about nuttx

you need some grep-fu

the system.map trick is a generic debug technique that you can't invent 
if someone else doesnt tell you about it :)


sebastien

Le 24/08/2021 à 18:57, Tim a écrit :

No, it's not in the system map. Having now searched for it I see there's a 
possibly useful example in stm32_appinit.c so I will wade through that.

How was I supposed to know what to look for!!??


Ok, did you open your System.map and searched for m25p_initialize() ?

Few days ago I gave someone else this same tip (and another) and he got things
working, please take a look on our email history.

BR,

Alan

Re: MTD device aggregation, questions for other developers

[Sebastien Lorquet]

Hello,

Thanks for these ideas.

I need aggregation at MTD layer, not at filesystem layer.

No NuttX FS at that time was immune against tearing in the way we 
required it, so we wrote our own in app space (the fs layer could not 
accomodate a special append-only file type we require). I cant change 
that design for this product.


Next product will probably use littlefs but it was not available at the 
time.


And we still need the full space for writing, so, a unionfs cannot be 
used in any case :)


Sebastien


Le 30/11/2021 à 18:10, Gregory Nutt a écrit :

Hi, Sebastian,

I think you need to use the UnionFS (fs/unionfs).  It basically lets 
you mount two file systems at the same location with the content 
combined.


There is an example at apps/examples/unionfs:

   140   ret = mount(MOUNT_DEVNAME_A, CONFIG_EXAMPLES_UNIONFS_TMPA,
   "romfs",
   141   MS_RDONLY, NULL);
   168   ret = mount(MOUNT_DEVNAME_B, CONFIG_EXAMPLES_UNIONFS_TMPB,
   "romfs",
   169   MS_RDONLY, NULL);
   178   ret = unionfs_mount(CONFIG_EXAMPLES_UNIONFS_TMPA, NULL,
   179   CONFIG_EXAMPLES_UNIONFS_TMPB, "offset",
   180   CONFIG_EXAMPLES_UNIONFS_MOUNTPT);

apps/thttpd also has an option to mount a binfs with "real" file 
system on other media.  This permits in-FLASH builtin apps to be 
intermixed or replaced by ELF modules in the "real" file system.


Greg

On 11/30/2021 11:01 AM, Sebastien Lorquet wrote:

Hello,

For history our board need 128 Mbit of flash, but the 128 Mbit parts 
are slw and have gigantic erase blocks.


So as an alternative our plan was to have two 64 Mbit SST parts (fast 
and small erases) and aggregate them in software, so that we can 
present the other drivers a single 128 Mbit device.


I can do this alone my own way, but I thought this would be of 
interest for all NuttX developers.



This is the reverse of the mtd_partition driver.

You give it a list of MTD devices (with similar geometries, this will 
be checked) and the result is one larger MTD device that span all the 
small ones.


This is a kind of raid0 for MTD devices.


I have questions about the API. Basically there are two choices:

-have an empty initialiser (mtd_agg_init()) that return the larger 
device, and a function mtd_agg_adddev(child) to grow the device


-have an initializer that takes as parameter the list of devices to 
aggregate



The assumption is that the returned MTD devices are pointers to 
malloc()ed ram. So it makes no sense to have the list of child 
pointers as a const array. it is inherently dynamic device construction.



What is your preference?

The separate add() function requires realloc. This is probably an 
argument against it.


The initializer with parameters need allocation of a ram array to 
store the MTD pointers. Not nice.



Should I copy the pointers in my own privately allocated mtd device 
or should I rely on a stable, externally allocated device list?



Do you have any design advice here, so NuttX can benefit from the 
best API?


Coding has not started yet, so I have no personal preference.


Sebastien

Re: USB MSD problem

[Sebastien Lorquet]

Hello,

just an idea:

When adding more nested function calls causes a crash, I check stack 
overflows.


Sometimes the default stack size specified when defining apps (2048) is 
too small, specially you have buffers on this stack, and printf consumes 
a lot of stack itself when calling nested formatting/conversion/stream 
writing functions.


Sebastien

Le 22/12/2021 à 17:34, Tim a écrit :

Usb_msc_main.c

If I add a "return OK" as the first line of main, msconn runs and returns.

If I put a printf statement before it, I get a crash.

If I do the same in an example app I've written, it is fine.

If I put a breakpoint at the printf statement and step over it, into there it gets to 
"void exit(int status)", then nxtask_exithook(tcb, status, false), then 
group_leave(tcb).

This is crazy...I just don't get this - surely a built in system app should not 
be crashing like this!!!

linker updates

[Sebastien Lorquet]

recently the linker command was changed from ld to gcc


The release notes for 10.2 indicates required changes in local board 
files. I did that.



however I found that the required changes are not in local files, but in 
nuttx itself, eg for arm it's at arch/arm/src/Makefile



A grep call still shows a large number of places that use --start-group 
instead of -Wl,--start-group and related calls



So as of now, the master branch is broken and requires a local patch to 
build.


I wonder why this was not caught by your testing of pull requests, since 
you should be building some arm configs in these tests.



Sebastien

Re: linker updates

[Sebastien Lorquet]

I dont work on nuttx regularly... so I get surprises when I have to work 
on it.


I have an external board and did the required changes as per the 10.2 
release notes.


Also, this question applies to the current trunk, not to the release. I 
mentioned that I have read the release notes, because I feel that they 
are somewhat relevant for the current master.



However, this point is not critical, it was easy to find and change.


Nevertheless, is it okay that arch/arm/src/Makefile still uses 
--start-group when the release notes ask users to change this to 
-Wl,--start-group?



Sebastien

Le 29/11/2021 à 12:10, Alan Carvalho de Assis a écrit :

Hi Sebastien,

All boards are compiling correctly here. Are you using external files
boards?

Please ... next time try to test the release candidates before the final
release is done.

Too late to complaint when the house is done! TM

BR,

Alan

On Monday, November 29, 2021, Sebastien Lorquet 
wrote:


recently the linker command was changed from ld to gcc


The release notes for 10.2 indicates required changes in local board
files. I did that.


however I found that the required changes are not in local files, but in
nuttx itself, eg for arm it's at arch/arm/src/Makefile


A grep call still shows a large number of places that use --start-group
instead of -Wl,--start-group and related calls


So as of now, the master branch is broken and requires a local patch to
build.

I wonder why this was not caught by your testing of pull requests, since
you should be building some arm configs in these tests.


Sebastien

Re: Article: SPI on BL602 and ESP32

[Sebastien Lorquet]

lora is just a RF modulation scheme like FSK or BPSK

lorawan is the network protocol.

it can work with "any" rf transceiver, on top of any RF modulation, 
usually it's used with lora, but can also be used with FSK or any other.


Sebastien

Le 13/12/2021 à 14:06, MIGUEL ALEXANDRE WISINTAINER a écrit :

Yes, today we only have LoRa, right ? Not LoRaWAN ?


De: Xiang Xiao 
Enviado: segunda-feira, 13 de dezembro de 2021 03:46
Para: dev@nuttx.apache.org 
Assunto: Re: Article: SPI on BL602 and ESP32

It will be a good addition if you can mainline the integration of LoRa high
level stack.

On Mon, Dec 13, 2021 at 9:57 AM Lee, Lup Yuen  wrote:


Here's my new article about NuttX SPI on BL602 and ESP32...

https://lupyuen.github.io/articles/spi2

Now that NuttX is talking OK to Semtech SX1262 (LoRa Transceiver), I'll
start porting the LoRaWAN Stack to NuttX. Thanks :-)

Support for multiple SST26 devices on a SPI bus

[Sebastien Lorquet]

...has been submitted and hopefully will be ok.

https://github.com/apache/incubator-nuttx/pull/4924

Sebastien

MTD device aggregation, questions for other developers

[Sebastien Lorquet]

Hello,

For history our board need 128 Mbit of flash, but the 128 Mbit parts are 
slw and have gigantic erase blocks.


So as an alternative our plan was to have two 64 Mbit SST parts (fast 
and small erases) and aggregate them in software, so that we can present 
the other drivers a single 128 Mbit device.


I can do this alone my own way, but I thought this would be of interest 
for all NuttX developers.



This is the reverse of the mtd_partition driver.

You give it a list of MTD devices (with similar geometries, this will be 
checked) and the result is one larger MTD device that span all the small 
ones.


This is a kind of raid0 for MTD devices.


I have questions about the API. Basically there are two choices:

-have an empty initialiser (mtd_agg_init()) that return the larger 
device, and a function mtd_agg_adddev(child) to grow the device


-have an initializer that takes as parameter the list of devices to 
aggregate



The assumption is that the returned MTD devices are pointers to 
malloc()ed ram. So it makes no sense to have the list of child pointers 
as a const array. it is inherently dynamic device construction.



What is your preference?

The separate add() function requires realloc. This is probably an 
argument against it.


The initializer with parameters need allocation of a ram array to store 
the MTD pointers. Not nice.



Should I copy the pointers in my own privately allocated mtd device or 
should I rely on a stable, externally allocated device list?



Do you have any design advice here, so NuttX can benefit from the best API?

Coding has not started yet, so I have no personal preference.


Sebastien

MTD partition check error

[Sebastien Lorquet]

Hello

new board has a new flash part that is smaller than the previous one.

however without changing the rest of my code, the creation of a 
partition that is too large for the new small device was accepted.


I noticed that erase sector numbers were compared to write blocks 
(calculated specifically for this)


This is wrong and I submitted a pull request

https://github.com/apache/incubator-nuttx/pull/4920


I also did this email because I think that the mailing list does not 
represent the amount of changes that happens in the repository.


Millions of code changes are applied each day, leading to unpleasant 
surprises, while the mailing list is too calm.



I will soon submit a MTD agregation driver that works like raid0 and 
creates one MTD device from several small ones.



Sebastien

Re: Move to C99 for common code

[Sebastien Lorquet]

Hi,

SDCC recently added a 6502 port, based on their HC08 port. I think it 
has a chance to be better than cc65 or any gcc arsenal.


Yes, the 6502 8-bit hardware stack is very limited, but by paying the 
price of a less efficient code, a software stack is possible.


Of course, such a port would probably be EXTREMELY limited and possiby 
just a proof of concept, but a fun one for sure.



Speaking of the Z80, would it be possible to run NuttX in a Grant Searle 
/ RC2014 platform with a 8k ROM /56k RAM split, or would any attempt 
require banked memory?



I appreciate this discussion about protecting the NuttX supported platforms.

So many RTOS are just for arm.

Sebastien


Le 08/01/2022 à 15:46, Alan Carvalho de Assis a écrit :

Yes, now I remember the reason to it has been removed.

BTW, I think 6502 will face same issue because the stack point is only
8-bits (it will be limited to 256 bytes), correct?

On 1/8/22, Gregory Nutt  wrote:

Support for the 8051 was removed for other reasons... that family has a
very small hardware stack that had to be saved and restored on each context
switch.  That provided bigtime compatibility issues with other
architectures.  That combined with the facts that (1) I never could get the
8051 running reliably without stack overflows, and (2) the 8051 was not
really a viable platform for NuttX because it was so limited in other ways.

That is ancient history from 2014.  I used to carefully document why any
feature was removed from the OS and kept that here:
https://bitbucket.org/patacongo/obsoleted/src/60ec01456d8b09f5b813a5fd8865cdbd5a0ccc20/ChangeLog#lines-4

On Sat, Jan 8, 2022 at 7:45 AM Alan Carvalho de Assis 
wrote:


Hi Tomasz,

Currently NuttX doesn't support 6502 and even the support to 8051 was
removed some years ago.

BTW, I think it could be possible to support C99 for 6502 if you use gcc:
https://github.com/itszor/gcc-6502-bits

BR,

Alan

On 1/8/22, Tomasz CEDRO  wrote:

On Sat, Jan 8, 2022 at 1:53 PM Gregory Nutt wrote:

z80 holds all 8-bit ZiLOG architectures.  That means

z80 using the SDCC compiler
z180 using the SDCC compiler
ez80 which normally uses the ZiLOG compiler, but there is an

experimental

version of GCC for the ez80

z16 uses only ZiLOG compiler

Also consider SH1

This will also require changes to INVIOLABLES.md and the coding

standard.

I would also recommend a formal vote to assure that you are following

the

will of the user base and not a personal agenda.  There used to be a
small
but important group of retro computer folk using NuttX; this
eliminates
support for them. There is language in the INVIOLABLES that is there
specifically to protect them from actions like this.

I have not heard of anyone using these architectures recently.  I
would
say
that only ez80 is active with active development boards.  There are
occasional developments with z180-like hardware.

One day I would love to run NuttX on 6502.. it would be nice if C99
wont make it impossible (why should it?).. but my knowledge is too
small so I will look how the thread goes :-)

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

Re: Pascal

[Sebastien Lorquet]

Hi,

It's great to get a compiler for a mainstream programming language 
inside NuttX!


I will try to get a look at this.

Thank you!

Sebastien

Le 12/03/2022 à 01:51, Gregory Nutt a écrit :

Now that I am not longer on the critical path for NuttX support, I am much
less involved in the RTOS.  I thought, perhaps, people might be interested
in what I have been up to.

I have spent the last 6 months or so working on that Pascal compiler that I
used to use with NuttX a few years ago. This is just fun stuff; I don't
think it has has any applicability to businesses at all.

I have basically done these things:

- I have upgraded the language definition to state of most current desktop
Pascal compilers (FreePascal, Lazarus, GNU Pascal) but avoiding the trend
to make it object-oriented Pascal.  Pascal with classes, exceptions, etc.
doesn't feel right to me.

- I have ported the toolchain and P-Code VM to run on NuttX again.  The
toolchain is rather large, but not so large that you could not use it on
some MCUs with more resources.  For more resource constrained platforms,
the VM alone is pretty small and perfectly usable.

- I have a VM start-up C task that can boot the OS into Pascal (for
example, the Pascal shell).

- There is the beginning of a Pascal shell that supports a few commands.
In particular, it supports running multiple Pascal threads (by spawning
multiple copies of the VM).

- Currently it runs on Linux and NuttX.  But I would like to get the VM
running on near-bare metal too.

- I would like to see the compiler work JIT so that I could send Pascal
source to the target and it just runs.

- And lots of other fun ideas.

You can see the code here:  https://github.com/patacongo/Pascal and there
is a WIP document with some history and language specifics here:
https://github.com/patacongo/Pascal/blob/main/doc/PascalNotes.md

The code is pretty stable but still not too difficult to produce compile
errors, although those are getting rarer and rarer.

Greg

Re: NuttX github code review practices

[Sebastien Lorquet]

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.


And a lot of board breaking changes are committed regularly. when you 
have a custom board it's not fun.


I believe a LOT of things including new features happens "silently" in 
github comments only, and very little is discussed on this mailing list.


Sebastien


Le 28/03/2022 à 11:30, Jukka Laitinen a écrit :

Another example:

https://github.com/apache/incubator-nuttx/pull/5731

A PR which looks like 0 gain, 100 risk of breaking everything (breaks 
our stuff at least), and can only work in FLAT_BUILD mode (if even in 
that?).


How does stuff like this get in? Xiaomi does and approves by 
themselves? Sorry for being blunt, but this is really irritating.


-Jukka


On 25.3.2022 21.47, Xiang Xiao wrote:

On Fri, Mar 25, 2022 at 6:53 PM Jukka Laitinen 
wrote:


Hi,

I was trying to make a more general statement than starting discussion
on separate PRs, but let me shortly answer still

On 25.3.2022 10.32, Xiang Xiao wrote:

On Fri, Mar 25, 2022 at 3:35 PM Jukka Laitinen 
wrote:


Hi,


As an another example, we would very much like to bring in
CONFIG_BUILD_KERNEL support for RISC-V for NuttX, as we have 
worked hard
on this for some time, and have it working. Now, even when this 
work it

is only additions, not breaking anything for FLAT_BUILD users,
Yes, it doesn't break FLAT_BUILD, but doesn't mean KERNEL design or 
code

is

perfect, that's why the interesting people can give the comment.

But of course!

is stuck
in endless debate where half of the comments show that the reviewer
doesn't know the RISC-V ISA thoroughly,


Sorry, I give you this impression, but I have worked on RiSCV since

2018:(.

I wasn't referring to you with the above comment... and I am sorry 
about

this. I'll try to avoid anything that can be interpreted as comments to
person, in the future.


and is referring to how things
are done in ARM world. And the other half is largely useless style
nitpicking.

I think the most debate is about how S-mode talks with M-mode in 
this PR.
The module design and standard compliant is always NuttX core value 
and

highlight in:
https://github.com/apache/incubator-nuttx/blob/master/INVIOLABLES.md
Since OpenSBI is adopted by many OS to interact with M-mode firmware:
https://github.com/riscv-software-src/opensbi
It's always good to follow the best practice and what I insist in this

PR:

we can implement a minimal subset of OpenSBI to support S-mode NuttX,

We (TII, it's research partners and subcontractors) will not be using
OpenSBI for interfacing between S-mode and M-mode inside NuttX, 
since it
doesn't make any sense for us. For running NuttX in kernel mode, we 
will

not "implement a subset of OpenSBI". We (Ville) have implemented the
"native SBI for NuttX". OpenSBI is not a standard, it is just a library
maintained by a few people. It is much better to just do what is needed
to do what is good for NuttX, following the standard RISC-V ISA spec,
and not blindly go with a 3rd party bloated library.

Ok, if you still prefer native SBI, please at least add a choice 
option in

Kconfig,
so other people can support OpenSBI later.



   but
don't invent a private interface since M-mode firmware mayn't run 
NuttX

at

all.

Now this is fair request, and I don't see any problems in implementing
this also for the mpfs in the future. Currently that PR (IMHO) doesn't
prevent having another M-mode firmware+any custom SBI such as 
OpenSBI on

other platforms. Currently there are also parts under mpfs board, which
can be generalized later on to avoid code copy paste, if others want to
use our implementation on other risc-v archs. Right now there is no
copy-paste code added, since this is not used in any other risc-v 
archs.


I see bringing in CONFIG_BUILD_KERNEL as a very important step, and I
see it a huge step forward if we can get in even one new 
architecture in

supporting that. But putting too much pressure on making world perfect
for the whole risc-v/nuttx community at once is just too much.
Incremental steps forward is much better way... First make it work on
one board, then generalize functionality when taking it into use in
another and so on...


Sure, but since it's a bigger change and the implementation is unique in
many places, it's expected that the review process will be a bit longer.



Anyhow, let's try to keep the discussion regarding a single PR within
that PR in github. And I am really sorry if you felt that I was 
accusing

you of something. it was not my intention. I truly appreciate that you
are putting so much time and effort for reviewing patches to NuttX.

Thanks,

Jukka

Re: NuttX github code review practices

[Sebastien Lorquet]

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: MT25P vs MT25Q bulk erase difference - how to fix?

[Sebastien Lorquet]

Hello,

If the Die Erase is similar in function to the bulk erase, then it can 
be used instead, but this has to be done at runtime to support all the 
chips in the same driver. So no @define or CONFIG_ option, because 
choosing one would excude the others, and if you have both on a board 
this would be bad.


The runtime fix is not heavy. My recommended way is:

-add a uint8_t device_manufacturer field in the m25px structure, 
initialized when the JEDEC ID is obtained from the device (IIRC, 
m25px_initialize or something like that)


-then, use this field in the m25px_erase method to choose the correct 
command(, and parameters if needed).



I woud appreciate if you agreed to share your changes beforehand (eg 
pull request) so I can review this simple change, because i'm using this 
driver in a professional project and I would like to make sure there are 
no regressions.


Thank you,

Sebastien

Le 18/01/2022 à 16:41, Tim a écrit :

As I still get deeper and deeper into why FAT doesn't work on my MT25Q NOR
flash device, I have found a minor error in m25px.c

The M25P devices have a bulk erase command (0xC7) but this is not supported
by the MT25Q, which has a "die erase" command (0xC4) instead and 0xC7 is
meaningless.

There is a #define for this as expected:

#define M25P_BE 0xc7

Adding

#define M25Q_DE 0xc4

Make sense but...

When the device manufacturer ID is read this is actually saved, so it can't
be tested at runtime to choose the right command.

The straightforward fix is to move the #define for M25_BE to within the code
that tests the manufacturer ID (to ensure it's a valid device for these
functions) but that is a bit messy and moves the #define away from all the
other related #defines. Doesn't feel right.

There is no unique CONFIG_ attribute that says whether it is or isn't
expecting to find an M25P or M25Q (which is reasonable) so I can't use
conditional #defines.

And don't want to mess up other people's boards by changing Kconfig in any
way that isn't backwards compatible, although the inviolable "Sometimes Code
Duplication is OK" might suggest it would be better to copy out m25px.c as
m25lx.c and make the change so that Kconfig demands you choose one or the
other or both of the two types...and if I find more errors/differences that
may ultimately make sense of course.

Can anyone suggest the "NuttX way" to do this, assuming I don't find a
myriad of other errors/differences that "force" duplication?

Re: SD Card in Simulation

[Sebastien Lorquet]

Hi

The closest way to achieve this, eg if you want to exercise the SD 
drivers, would be to simulate a SPI/SD device that the main SD driver 
could talk to.


The simulated SPI or SD would have to get,recognize and execute SD 
commands, and it would get its storage from the host disk or memory.


This is a bit cumbersome, so if only a more functional file storage is 
required, romfs or hostfs could be enough.


Sebastien

Le 24/01/2022 à 12:07, Fotis Panagiotopoulos a écrit :

Hello,

I am working on a system that uses an SD card to read various files.
I am also using the simulator for testing this firmware.

I would like to test the parts of the system that read and parse these
files, so I need a way to simulate the SD card.

Is there any way to achieve this?

Ideally, I would like to mount a directory of the host system directly in
NuttX.
Or maybe select a set of files to be included in compile time?

Thank you!

Re: ID page of EEPROM

[Sebastien Lorquet]

Hello,

Yes, EEPROMs are small and are managed as a virtual fixed-size file.

The EEPROM bytes can be erased and written individually, which means the 
erase block size of the associated mtd device would be one byte long, 
which is uselessly complex. Using larger block sizes would make the 
driver worse as changing one byte would require a read-modify-write from 
user space.


And EEPROM usually dont have an ERASE command, just a WRITE, so it's not 
a good match for the MTD framework. No JEDEC RDID identification either.


Also, when I wrote the EEPROM driver, there was no generic way to access 
MTD devices.


-

You can add ioctls to the EEPROM drivers, just make sure you define 
these in terms of generic functions that have potential for 
implementation on several devices.


For some devices, the built-in MAC address is part of the main memory 
plane, so there is no specific access function, but ID page is one of 
these functions that would benefit from dedicated IOCTLs.


Please plan a way to indicate the size of this ID page to the user, 
because I'm sure the size is not the same on all devices.


Also please add flags to devices supported by the driver so the ID page 
IOCTLs are not activated for devices that dont have ID memory.


I can proof read your code to offer suggestions if you wish.

Sebastien


Le 07/11/2023 à 15:31, Gregory Nutt a écrit :

On 11/4/2023 6:12 PM, Robert Middleton wrote:
I'm a little confused as to what the difference is between the MTD 
folder

and the EEPROM folder. It seems that both folders have support for the
at24xx and at25xx series of chips, so it's not obvious which one is
better.


MTD is more of a "heavyweight" solution that can support a higher 
level of functionality on Memory Technology Devices (MTDs) such as 
file systems or wear-leveling layers.


Most EEPPROMs are small, however, and it may not be practical to 
support a file system on top of the EEPROM.  So the lightweight 
character driver layer from Sebastien Lorquet.  This lightweight layer 
will support only character-oriented I/O via lseek, read, and write

Re: CTU CAN FD driver multi-licence for Nuttx

[Sebastien Lorquet]

Are you seriously taking legal advice, on behalf of an apache project, 
from a generative language model?


Sebastien


Le 17/10/2023 à 22:22, Alan C. Assis a écrit :

Oops, it was: you cannot enforce both at same time.

Actually I think I was wrong (not about enforcing), but the main issue
about Dual license is how the contributions will evolve.

I decided to ask about it to ChatGPT:

"
Question: if an open-source software X was released as dual license
GPL and Apache License, can we used it in our project NuttX that used
Apache License?

If an open-source software X is released under both the GPL (GNU
General Public License) and the Apache License, you generally have
some flexibility in how you can use it in your project NuttX, which is
licensed under the Apache License. However, there are important
considerations and potential complications to keep in mind:

 Compatibility of Licenses:
 The Apache License and the GPL are generally considered to be
compatible licenses. This means that you can include Apache-licensed
code in a GPL-licensed project and vice versa without violating the
terms of either license.

 License Choice:
 When incorporating dual-licensed code into your project, you
have a choice in which license to follow. If you choose the Apache
License, you can do so without any issues, as the Apache License is
permissive. However, if you choose the GPL, you must comply with the
terms of the GPL, which may include open-sourcing your entire project
under the GPL.

 Potential GPL Implications:
 Using the GPL-licensed version of software X may have
implications for the licensing of your entire project. The GPL is a
more restrictive license that requires you to release your entire
project under the GPL if you use GPL-licensed code. This could affect
how you distribute your project and any proprietary components within
it.

 Be Careful with License Mixing:
 It's important to carefully manage the licensing of each
component within your project. Ensure that you clearly identify and
understand the licensing terms of each component and only include code
in your project that is compatible with the licensing choices you want
to make.

 Consult Legal Advice:
 Dual licensing can be complex, and the specific terms of
software X may have variations or nuances that need legal
interpretation. It's advisable to consult with a legal expert who is
well-versed in open source licensing if you have any doubts or
concerns.

In summary, you can use the dual-licensed software X in your project
NuttX that is under the Apache License. However, you need to make a
conscious choice about which license to follow for the code from
software X, and be aware of the potential implications, especially if
you decide to use the GPL-licensed version, as it may affect the
licensing of your entire project. Consulting with a legal expert is a
wise step when dealing with complex licensing issues.
"

So, we are back to square one!

BR,

Alan

On 10/17/23, Alan C. Assis  wrote:

Hi Tomek,

On 10/17/23, Tomek CEDRO  wrote:

To be honest I don't see a big issue of a driver as dual license, we
already have SocketCAN and other drivers as dual license (GPL and
Apache, BSD and Apache, etc). The original Author said the want is to
be released as dual license: A or license B.

Isn't is more A AND B ?

A OR B == I want A but not B so I stick to A ? :-P


No, because technically you can enforce two at same time, in that case
GPL could prevail! :-)


The License war is terrible, I think there is not a single license
compatible with all, even CC0, BSD or public domain cannot be used as
freely was we think. Many countries law, companies, patents, etc,
involved.

BSD and MIT seems most liberal. Apache also clarifies patent stuff.
GPL is viral and enforces GPL on all further works.

As above, if the case is "A AND B" then GPL taints everything to be GPL
too..?


See, the Author defines it as dual license (so yes A "AND" B), but if
project X uses license A it will stick to license A instead of B. If
project Y uses license B it will stick with B instead of A.

So, more precisely it is A XOR B.


Quck search (query: gpl vs apache vs bsd license) resulting quote :

"
I will mainly talk about the practical consequences and not go into
the nitty gritty. By GPL compatible I mean that a GPL project can use
your code (NOT you can use GPL code).

The MIT and BSD 2 clause licenses have similar requirements: keep the
license file. The BSD 3 clause license adds a term to the BSD 2 that
prevents someone from claiming false endorsement. These three licenses
are compatible with GPLv2 and v3.

The Apache 2.0 license requires you to keep the license file, the
NOTICE file if there is one, and show notice for modified files. It
also addresses some patent-related issues, so companies use it a lot.
It is compatible with GPLv3 but not v2 (due to the patent clauses).

There is also an old BSD license that has an clause 

Re: CTU CAN FD driver multi-licence for Nuttx

[Sebastien Lorquet]

Hi Alan,

Sure, I understand the motivation.

Still, as entertaining as it might be, let's not forget (and not just on 
this point) that language models are generally unreliable. So I would 
tend to be cautious before calling language model output a "point of view".


Whatever, this is not the most important aspect of the discussion.

Best regards,

Sebastien

Le 19/10/2023 à 17:14, Alan C. Assis a écrit :

Hi Sebastien,

I think you missed the point: we are not asking legal advice for an
AI, we are just trying to find other point of view that it could have
found "chewing" millions of thread about license issues.

BR,

Alan

On 10/19/23, Sebastien Lorquet  wrote:

Are you seriously taking legal advice, on behalf of an apache project,
from a generative language model?

Sebastien


Le 17/10/2023 à 22:22, Alan C. Assis a écrit :

Oops, it was: you cannot enforce both at same time.

Actually I think I was wrong (not about enforcing), but the main issue
about Dual license is how the contributions will evolve.

I decided to ask about it to ChatGPT:

"
Question: if an open-source software X was released as dual license
GPL and Apache License, can we used it in our project NuttX that used
Apache License?

If an open-source software X is released under both the GPL (GNU
General Public License) and the Apache License, you generally have
some flexibility in how you can use it in your project NuttX, which is
licensed under the Apache License. However, there are important
considerations and potential complications to keep in mind:

  Compatibility of Licenses:
  The Apache License and the GPL are generally considered to be
compatible licenses. This means that you can include Apache-licensed
code in a GPL-licensed project and vice versa without violating the
terms of either license.

  License Choice:
  When incorporating dual-licensed code into your project, you
have a choice in which license to follow. If you choose the Apache
License, you can do so without any issues, as the Apache License is
permissive. However, if you choose the GPL, you must comply with the
terms of the GPL, which may include open-sourcing your entire project
under the GPL.

  Potential GPL Implications:
  Using the GPL-licensed version of software X may have
implications for the licensing of your entire project. The GPL is a
more restrictive license that requires you to release your entire
project under the GPL if you use GPL-licensed code. This could affect
how you distribute your project and any proprietary components within
it.

  Be Careful with License Mixing:
  It's important to carefully manage the licensing of each
component within your project. Ensure that you clearly identify and
understand the licensing terms of each component and only include code
in your project that is compatible with the licensing choices you want
to make.

  Consult Legal Advice:
  Dual licensing can be complex, and the specific terms of
software X may have variations or nuances that need legal
interpretation. It's advisable to consult with a legal expert who is
well-versed in open source licensing if you have any doubts or
concerns.

In summary, you can use the dual-licensed software X in your project
NuttX that is under the Apache License. However, you need to make a
conscious choice about which license to follow for the code from
software X, and be aware of the potential implications, especially if
you decide to use the GPL-licensed version, as it may affect the
licensing of your entire project. Consulting with a legal expert is a
wise step when dealing with complex licensing issues.
"

So, we are back to square one!

BR,

Alan

On 10/17/23, Alan C. Assis  wrote:

Hi Tomek,

On 10/17/23, Tomek CEDRO  wrote:

To be honest I don't see a big issue of a driver as dual license, we
already have SocketCAN and other drivers as dual license (GPL and
Apache, BSD and Apache, etc). The original Author said the want is to
be released as dual license: A or license B.

Isn't is more A AND B ?

A OR B == I want A but not B so I stick to A ? :-P


No, because technically you can enforce two at same time, in that case
GPL could prevail! :-)


The License war is terrible, I think there is not a single license
compatible with all, even CC0, BSD or public domain cannot be used as
freely was we think. Many countries law, companies, patents, etc,
involved.

BSD and MIT seems most liberal. Apache also clarifies patent stuff.
GPL is viral and enforces GPL on all further works.

As above, if the case is "A AND B" then GPL taints everything to be GPL
too..?


See, the Author defines it as dual license (so yes A "AND" B), but if
project X uses license A it will stick to license A instead of B. If
project Y uses license B it will stick with B instead of A.

So, more precisely it is A XOR B.


Quck search (query: gpl vs apache vs bsd license) resulting quote :

"
I will 

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

[Sebastien Lorquet]

Hi,

Le 25/08/2023 à 11:48, raiden00pl a écrit :

Forcing people using cmake to support make is the worst thing that can
happen.
Open source is voluntary, any contribution is voluntary, any form of
forcing
others to do anything is unacceptable.
Modifying both systems will be good practice (and an act of kindness), but
only
if the contributor wants it. In other cases, a community interested in a
particular
build system should take care of it.


Yes, but this project has rules that were set by Greg.

This situation would not have happened if people had not introduced 
cmake in the first place


Sebastien

Re: [DISCUSS] Out-of-tree builds should be standard? -> no

[Sebastien Lorquet]

Hello

Why should you change the experience and make life difficult for 
everyone, just to support a pair of specific configuration?


If you need to build twice, build twice, one project for h7, one project 
for m4, then one python or other script to combine the images.


All users matter (eg, not just the little comfort of AMP users) This is 
in inviolables.txt


Sebastien

Le 24/08/2023 à 21:28, Nathan Hartman a écrit :

PR # 10328 is bringing support for STM32 MCUs that have two different kinds
of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style
(Asymmetric Multi Processing) chip. This requires building NuttX twice,
once for each core, with two different configs.

In the GitHub comments, it was mentioned that we should not make cmake
mandatory for certain boards, and then mentioned that with make the problem
is that you have to make distclean between the two builds. Copying the
comments here:

slorquet writes:


It would be good to avoid cmake-specific features.
Is make a supported build system or was it deprecated?
If it's supported no feature should work only with cmake. Thanks.

xiaoxiang781216 writes:


The change should work with make too. But make doesn't support out of

tree build, it's very annoying to develop AMP system like this patch
because you have to `make distclean` and `make` every time.

This makes me wonder whether we should consider making out-of-tree builds
the blessed way to build, with both make and cmake.

I realize that this might disrupt many people's builds -- including myself.
I have been building in-tree from the start, so this will require me to
change my workflows.

However, after the dust settles, this could have several advantages:

1. Not polluting the source tree with build artifacts and temporary files.

2. Simplifying the.gitignore rules throughout.

3. Allowing AMP builds and builds for multiple different boards without
make distclean. To switch between boards, just change to a different build
dir.

I am starting this thread here because this kind of proposal really needs a
discussion on the mailing list.

Thoughts?

Cheers
Nathan

Re: [DISCUSS] Out-of-tree builds should be standard? -> no

[Sebastien Lorquet]

Others selected parts of inviolables.txt :


All support must apply equally to all supported platforms. At present 
this includes Linux, Windows MSYS, Windows Cygwin, Windows Ubuntu, 
Windows native, macOS, Solaris, and FreeBSD. No tool/environment 
solutions will be considered that limit the usage of NuttX on any of the 
supported platforms.


Inclusive rather than exclusive.

Hobbyists are valued users of the OS including retro computing hobbyists 
and DIY “Maker” hobbyists.


No changes to build system should limit use of NuttX by any user.

We must resist the pull to make NuttX into a Linux-only, GCC-only, and 
ARM-only solution.



So the question asked in this thread should be answered : No, out of 
tree builds should not be standard.



Sebastien


Le 25/08/2023 à 09:38, Sebastien Lorquet a écrit :

Hello

Why should you change the experience and make life difficult for 
everyone, just to support a pair of specific configuration?


If you need to build twice, build twice, one project for h7, one 
project for m4, then one python or other script to combine the images.


All users matter (eg, not just the little comfort of AMP users) This 
is in inviolables.txt


Sebastien

Le 24/08/2023 à 21:28, Nathan Hartman a écrit :
PR # 10328 is bringing support for STM32 MCUs that have two different 
kinds

of cores on chip: Cortex M7 and Cortex M4. In other words, AMP-style
(Asymmetric Multi Processing) chip. This requires building NuttX twice,
once for each core, with two different configs.

In the GitHub comments, it was mentioned that we should not make cmake
mandatory for certain boards, and then mentioned that with make the 
problem

is that you have to make distclean between the two builds. Copying the
comments here:

slorquet writes:


It would be good to avoid cmake-specific features.
Is make a supported build system or was it deprecated?
If it's supported no feature should work only with cmake. Thanks.

xiaoxiang781216 writes:


The change should work with make too. But make doesn't support out of

tree build, it's very annoying to develop AMP system like this patch
because you have to `make distclean` and `make` every time.

This makes me wonder whether we should consider making out-of-tree 
builds

the blessed way to build, with both make and cmake.

I realize that this might disrupt many people's builds -- including 
myself.

I have been building in-tree from the start, so this will require me to
change my workflows.

However, after the dust settles, this could have several advantages:

1. Not polluting the source tree with build artifacts and temporary 
files.


2. Simplifying the.gitignore rules throughout.

3. Allowing AMP builds and builds for multiple different boards without
make distclean. To switch between boards, just change to a different 
build

dir.

I am starting this thread here because this kind of proposal really 
needs a

discussion on the mailing list.

Thoughts?

Cheers
Nathan

Network debug info level breaks nx_start -> group_setupidlefiles

[Sebastien Lorquet]

Hi,

I have a nucleo-h743zi, in which I have enabled network.

It seems to work so far.

When I enable Network Info Debug, I get a crash.

The crash does not happen with Network info disabled (Enabling network 
warnings and errors is ok)


I am writing on the mailing list to get feedback and discussion.

Here is the crash, pretty obvious cause:

A▒DE
stm32_ethinitialize: intf: 0
stm32_ifdown: Taking the network down
netdev_register: Registered MAC: 2e:7e:27:a2:69:88 as dev: eth0
up_assert: Assertion failed at file:init/nx_start.c line: 703 task: Idle 
Task


First of all I dont know where this MAC is obtained but whatever, thats 
not my problem. I will put the real mac later.



Note that nx_start is a pretty general file for nuttx, not related to 
board or chip.


(gdb) break nx_start.c:703
Breakpoint 1 at 0x8002b9a: file init/nx_start.c, line 703.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) mon reset init
SWD DPIDR 0x6ba02477
target halted due to debug-request, current mode: Thread
xPSR: 0x0100 pc: 0x080002e0 msp: 0x240059fc
(gdb) c
Continuing.

Breakpoint 1, nx_start () at init/nx_start.c:703
703 DEBUGVERIFY(group_setupidlefiles(_idletcb[i]));
(gdb) s
group_setupidlefiles (tcb=0x24001114 ) at 
group/group_setupidlefiles.c:61

61    FAR struct task_group_s *group = tcb->cmn.group;
(gdb) n
66    DEBUGASSERT(group != NULL);
(gdb) n
74    fd = nx_open("/dev/console", O_RDWR);
(gdb) n
75    if (fd == 0)
(gdb) n
88    if (fd > 0)
(gdb) n
98    return -ENFILE;

=>assert

This function group_setupidlefiles fails to open /dev/console and 
triggers an assert.


Now please dont tell me that this code will work when I remove debug, I 
dont care. This is not the root cause.



Does this code fails to open the console because some network debug has 
been emitted first?


What to do, then?

It is pretty common to have boards emit debug messages before the OS is 
started. I cant believe I'm the only one that will see this.


It seems to happen before I have CONFIG_DEV_CONSOLE, which is the 
default, and is ok, since i'm just using a serial port with this board.


If I disable CONFIG_DEV_CONSOLE, then nsh does not start, so I believe 
this setting is required.


USB console is not enabled nor planned to be used.


Can you please help me understand and fix this?

It does not look to be recent code.

Thanks,

Sebastien

Re: [DISCUSS] Graduate NuttX as TLP

[Sebastien Lorquet]

hi,

yes, this solution "just" requires a sed on all defconfig files, and 
avoids having to specify the directory name in the git clone command, 
which can easily be forgotten.


if I can express my taste on this extra minor choice I think nuttx-apps 
looks better than nuttx_apps


Sebastien

On 6/28/22 06:15, alin.jerpe...@sony.com wrote:

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

Best regards
Alin

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

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


On Mon, Jun 27, 2022 at 6:18 PM Alan Carvalho de Assis wrote:

I don't know you guys but I hate this incubator-nuttx and
incubator-nuttx-apps repositories names.

I hope we get github.com/apache/nuttx and github.com/apache/apps soon
(hope they accept we use this /apps name, will make our users life
easier!)

+1 :-)

How about something like nuttx_rtos and nuttx_apps ?

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

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

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

Suggestion to turn a nwarn into an ninfo in ipv4_input

[Sebastien Lorquet]

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: Suggestion to turn a nwarn into an ninfo in ipv4_input

[Sebastien Lorquet]

Hello,

I also agree an option is useless. I was just suggesting this in case 
some people still want to see it as warning.


I'll send a pull request a bit later.

Thanks for the feedback!

Sebastien

Le 09/06/2022 à 14:17, Alan Carvalho de Assis a écrit :

I completely agree!

We need to reduce the number of configurations, not increase it.

Just converting it to ninfo() is enough.

Other OS has a good documentation to educate developers to avoid
creating unnecessary Kconfig entries:

https://doc.riot-os.org/kconfig-in-riot.html
https://docs.zephyrproject.org/2.6.0/guides/kconfig/tips.html

BR,

Alan

On 6/9/22, 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: Suggestion to turn a nwarn into an ninfo in ipv4_input

[Sebastien Lorquet]

Here it is, I hope it does not take two full days for merging :)

https://github.com/apache/incubator-nuttx/pull/6399

Sebastien

Le 09/06/2022 à 14:30, Sebastien Lorquet a écrit :

Hello,

I also agree an option is useless. I was just suggesting this in case 
some people still want to see it as warning.


I'll send a pull request a bit later.

Thanks for the feedback!

Sebastien

Le 09/06/2022 à 14:17, Alan Carvalho de Assis a écrit :

I completely agree!

We need to reduce the number of configurations, not increase it.

Just converting it to ninfo() is enough.

Other OS has a good documentation to educate developers to avoid
creating unnecessary Kconfig entries:

https://doc.riot-os.org/kconfig-in-riot.html
https://docs.zephyrproject.org/2.6.0/guides/kconfig/tips.html

BR,

Alan

On 6/9/22, 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: CRC32 what gives?

[Sebastien Lorquet]

@Nathan:

Yes, of course.

@Alan:

Of course not, the structure passed to init can be set up to describe 
the required algorithm.


But the partial update situation can be useful for protocols where the 
message is fragmented (eg radio transceivers with short FIFOs), or where 
only some fields enter the crc (I have seen this happen several times). 
you cant call the global crc() function on several buffers in sequence 
if bits are inverted on crc output.


Sebastien

On 7/15/22 20:21, Nathan Hartman wrote:

On Fri, Jul 15, 2022 at 1:40 PM Alan Carvalho de Assis
 wrote:

Hi Sebastien, I think we don't need these three functions for each
CRC, just one like in the Linux kernel is enough:

https://www.kernel.org/doc/htmldocs/kernel-api/API-crc-ccitt.html

BR,

Alan


Could have one generic function and then thin wrappers that call it
with the correct parameters for different uses.

Cheers,
Nathan

Re: Assertion failed using the nucleo-H743ZI2 board

[Sebastien Lorquet]

Hi,

I'm working with the exact same board and struggled for several days 
with a similar problem.


Breakpoints did not help since the issue was fugitive and not always 
crashing at the same place.


There also were debug/release variations.

It turned out to be a stack issue.

The default stack size for new stacks is 2048 and all problems went away 
by defining a 4k default stack size.


You may not have the same issue, but it's worth trying that point.

Sebastien


On 7/12/22 21:34, Roberto Bucher wrote:

Hi

I' working on a STM32 NUCLEO-H743ZI2 board, and I have sporadic errors 
in the shell when I launch some utilities like "ifconfig" or "renew" 
(but it seems not to be related to the network).


Sometimes the command runs without problems, sometimes it gives an 
Assertion failure and I have to switch off and on the board to restart 
the shall. It seems to be a problem related to the shell application.


Does somebody have similar problems? How can I try to find out the 
bugs related to this error? (breakpoints where?)


Thanks in advance

Roberto

Re: STM32F4 Ethernet Issues

[Sebastien Lorquet]

Hi,

We have deployed hundreds of boards with stm32f427 and ethernet, they 
have all been working reliably for months without stopping, we know it 
because they critically depend on network functionality and we have 
reports if a card becomes unreachable. None has so far outside of 
dedicated tests.


So I believe that there is no obvious hard bug in these drivers.

Most certainly a build option on your particular config. debug is a 
possible issue, thread problems is another possibility.


Sebastien


On 7/19/22 13:47, Fotis Panagiotopoulos wrote:

Hello!

I am using Ethernet on an STM32F427 target, but I am facing some issues.

Initially the device works correctly. After some hours of continuous
operation I completely lose all network communications.
Trying to troubleshoot the issue, I enabled assertions and various other
debug features.

Again the device works correctly for some hours, and then I get a failed
assertion at stm32_eth.c, line 1372:

DEBUGASSERT(dev->d_len == 0 && dev->d_buf == NULL);

No other errors are reported (e.g. stack overflows etc).


I have observed that this issue usually manifests itself when there is
insufficient stack on a task.
But in my case, all tasks have oversized stacks. Typically they do not
exceed 50% utilization.
I have plenty of room available in the heap too (> 100kB).

Regarding the rest of the firmware, I cannot see any other misbehaviour or
problem.
I haven't ever seen any other unexplained problem, assertion fail,
hard-fault etc.
The application code passes all of our tests.
In fact, even when this issue happens, although I lose network
connectivity, the rest of the system works perfectly.

Please note that I have checked the contents of dev->d_len and dev->d_buf,
and they seem to contain valid data.
The address lies within the normal address space of the MCU, and the size
is sane.
So it doesn't look like any kind of memory corruption.


At this point I believe that this is an actual bug either on the STM32 MAC
driver, or at the TCP/IP stack itself.
I had a look at the driver code, but I didn't see anything suspicious.


Has anyone observed the same issue before?
Can it be affected in any way with my configuration?
Or maybe, do you have any recommendations on what to test next?


Thank you!

Re: STM32F4 Ethernet Issues

[Sebastien Lorquet]

Hi,

good find but

-I dont think any usual application tinkers with PHY regs during its 
lifetime except the ethernet monitor


-the fix is certainly a lock somewhere but global or fine grained I dont 
know.


Not all calls need to be locked, eg the one that returns the PHY 
address. Probaby not needed by default, but a PHY access lock would 
prevent any issue you describe.


I will wait for people with more expertise about this.

Just a note, dont forget that not all PHY have an interrupt, the one on 
the nucleo stm32h743zi[2] board does not have one.


Sebastien

Le 26/07/2022 à 11:05, Fotis Panagiotopoulos a écrit :

Hello,

I have eventually found 2 issues regarding networking in my application.
I would like to discuss the first one.


My code contains something like this:

int sd = socket(AF_INET, SOCK_DGRAM, 0);

struct ifreq ifr;
memset(, 0, sizeof(struct ifreq));
strncpy(ifr.ifr_name, CONFIG_NETIF_DEV_NAME, IFNAMSIZ);
ifr.ifr_mii_phy_id = CONFIG_STM32_PHYADDR;
ifr.ifr_mii_reg_num = MII_LAN8720_SECR;
ifr.ifr_mii_val_out = 0;
ioctl(sd, SIOCGMIIREG, (unsigned long));

// Do stuff with ifr.ifr_mii_val_out.

close(sd);

I realized that this type of ioctl will directly access the hardware,
without any locking.
That is, if any other task needs to use the PHY in any other way, it will
eventually corrupt its register data.


Two questions on this:
1. Is there any good reason for this?
2. What is the best way to fix it? Shall I add a driver level lock, or
should net_lock() be used in any higher layer?



On Tue, Jul 19, 2022 at 10:30 PM Fotis Panagiotopoulos 
wrote:


Hello,


We have deployed hundreds of boards with stm32f427 and ethernet, they
have all been working reliably for months without stopping, we know it
because they critically depend on network functionality and we have
reports if a card becomes unreachable. None has so far outside of
dedicated tests.
So I believe that there is no obvious hard bug in these drivers.

Good to hear that!
Although, I may be using a feature or protocol that you are not.
Of course, I don't believe that NuttX is broken per se, but a minor bug
may lurk somewhere...



I have seen that when I enable the network debugging features, it seems

to

hit an assertion failure before getting to nsh prompt at startup. This

was

on a quite recent master. I haven't had a chance to diagnose this

further.

Have you tried enabling these and if so, do they work?

If you refer to CONFIG_DEBUG_NET, then yes I have enabled it and it works.
I have some devices under test, waiting to reproduce the issue to see if
this option provides any useful information.



Also, out of curiosity, have you tried running ostest on your board?

I just tried.
It passed all the tests.

On Tue, Jul 19, 2022 at 4:44 PM Sebastien Lorquet 
wrote:


Hi,

We have deployed hundreds of boards with stm32f427 and ethernet, they
have all been working reliably for months without stopping, we know it
because they critically depend on network functionality and we have
reports if a card becomes unreachable. None has so far outside of
dedicated tests.

So I believe that there is no obvious hard bug in these drivers.

Most certainly a build option on your particular config. debug is a
possible issue, thread problems is another possibility.

Sebastien


On 7/19/22 13:47, Fotis Panagiotopoulos wrote:

Hello!

I am using Ethernet on an STM32F427 target, but I am facing some issues.

Initially the device works correctly. After some hours of continuous
operation I completely lose all network communications.
Trying to troubleshoot the issue, I enabled assertions and various other
debug features.

Again the device works correctly for some hours, and then I get a failed
assertion at stm32_eth.c, line 1372:

DEBUGASSERT(dev->d_len == 0 && dev->d_buf == NULL);

No other errors are reported (e.g. stack overflows etc).


I have observed that this issue usually manifests itself when there is
insufficient stack on a task.
But in my case, all tasks have oversized stacks. Typically they do not
exceed 50% utilization.
I have plenty of room available in the heap too (> 100kB).

Regarding the rest of the firmware, I cannot see any other misbehaviour

or

problem.
I haven't ever seen any other unexplained problem, assertion fail,
hard-fault etc.
The application code passes all of our tests.
In fact, even when this issue happens, although I lose network
connectivity, the rest of the system works perfectly.

Please note that I have checked the contents of dev->d_len and

dev->d_buf,

and they seem to contain valid data.
The address lies within the normal address space of the MCU, and the

size

is sane.
So it doesn't look like any kind of memory corruption.


At this point I believe that this is an actual bug either on the STM32

MAC

driver, or at the TCP/IP stack itself.
I had a look at the driver code, but I didn't see anything suspicious.


Has anyone observed the same issue before?
Can it be affected in any wa

Re: Wikipedia: "Proposal deletion of NuttX"

[Sebastien Lorquet]

Hi,

The NuttX page should obviously not be deleted by it is not exactly 
written in an encyclopedic style


I see text like (because Mr Greg did something and something) - you 
should try to edit that so that it sounds more formal and neutral


This is not biased opinions, but is clearly not academic enough.

Also I can understand how the endless list of features looks like and 
excerpt of the website and promotes too much. It should be shorter and 
contain more explanations as paragraphs of text than lists. This list 
sounds like bragging.


Inspiration could be obtained on other RTOS pages... 
https://en.wikipedia.org/wiki/FreeRTOS


Sebastien

Le 21/07/2022 à 16:19, Tomek CEDRO a écrit :

On Thu, Jul 21, 2022 at 3:56 PM Alan Carvalho de Assis wrote:

Hi Tomek,
Thank you for your support on it.
I don't know how we could avoid it, if someone decided that NuttX is
not relevant they can go on and try to suggest to remove the article.

Hmm looking at the activities from the IP address (USA/California?)
that stated bias there were also some good commits for NuttX page.
This may be someone from our community? Maybe a FitBit developer? :-P

https://en.wikipedia.org/wiki/Special:Contributions/96.46.149.166



Fortunately I was on my computer today and saw it, but imagine if I
was in vacation?

Yup, exactly, people not familiar with the subject are deciding on
knowledge removal, quite frightening.



Maybe others here need to setup some notification to receive case
someone edit the NuttX page, I think wikipedia support it.

I did some small update (stated FOSS directly after NuttX and before
RTOS should be clear enough what kind of project this is) and thus
subscribed to the page, I should get notifications too :-)



In the other hand, the only way we could get more awareness and making
NuttX more popular. Unfortunately nobody here replied to Alin emails
asking for help to NuttX Workshop, seems like nobody really cares
about NuttX and it is really sad.

I would be more that glad to attend this kind of workshop but have
nothing to offer to present yet sorry :-(

World now seems a bit messy, probably on purpose by some groups of
interests, people often have problems with basic life conditions now
like food and accommodation, struggling to fulfill the Edison's vision
of paying the bills, a time is most precious now and this is really
sad I we cannot focus on important creative tasks as we would really
wanted, its not always matter of "care" but "can" I guess.

Re: CRC32 what gives?

[Sebastien Lorquet]

Hi,

Sorry to throw a rock in the pond but having a single function named 
"crc32" is very wrong and is not sufficient.


As you have discussed the polynomial length is just not enough to 
describe a crc, the initial value, bit orders of input and output, and 
bit inversion on input and output are all used to derive actual crc 
functions.


A proper API for an evolved project like nuttx should have a set of 
functions like crc_init, crc_update and crc_final, all acting on a crc 
context, just like sha and md5.


This would also allow specific implementations to use the hardware crc 
resources provided by specific circuits.


This would allow each use of the crc routines to define and use its own 
version of the crc, without interfering on other uses.


For example I agree it would be very unwise to change the CRC kind used 
by file systems as it would break so many systems.


Sebastien

On 7/15/22 18:54, Karel Kočí wrote:

Excerpts from Nathan Hartman's message of July 15, 2022 6:47 pm:

On Fri, Jul 15, 2022 at 12:45 PM Karel Kočí  wrote:

The impact might be pretty significant from my search and that is also why I
rather discuss instead of suggesting changes.

The significant place where the current crc32 implementation is used is in
file systems (such as smartfs or nxffs). The change would break any existing
formating of those FSs. Thus I also do not think it should be done.


Are these file systems readable by other operating systems besides NuttX?

Those are NuttX only up to my knowledge. The change would break old formated
device on NuttX version update which sounds bad to me and "fix" (or rather let's
say change to some other crc32 algorithm) won't fix compatibility with some
other systems...

Re: Reevaluate the C89 Requirement

[Sebastien Lorquet]

Hi,

That would be -1 for me too.

Reason 1 from Nathan could change my vote.

But reason 2 would be a shame. We have one of the few a RTOS that 
support CPUs outside ARM.



TBH, there is no solid technical reason to change this rule. Most of the 
things mentioned in this comment are syntactic sugar that can be 
supported with macros.



Sebastien

Le 30/08/2022 à 03:18, Nathan Hartman a écrit :

On Mon, Aug 29, 2022 at 7:54 PM Alan Rosenthal 
wrote:


Hi!

What needs to be done to open the discussion to consider changing the
rules?

Also please see a very detailed comment on the github issue here by
@robertlipe:
https://github.com/apache/incubator-nuttx/issues/6896#issuecomment-1227971503



Basically what Greg said: motivate someone of the PPMC to call a vote.

Just FYI, based on what Byron points out with regard to the Zilog families
needing C89 (and possibly other archs that weren't mentioned), I would
probably vote -1 unless either:

1) there is a toolchain, which is complete (not "experimental") that
supports these platforms, or:

2) someone can convince me that no one cares about these architectures
anymore, such as if it's shown that NuttX already contains significant
breakage on these platforms that prevents them from working anyway, no one
has complained, and it has gone unfixed for several years

If 1 or 2 (or both) I'm okay with it. But if changing the rules will leave
users in the dust, then I'm not okay with it.

Just my thoughts... I'll be glad to hear the thoughts of others.

Cheers,
Nathan

STM32H7 SPI status ?

[Sebastien Lorquet]

Hi all,


SPI bus driver in STM32H7 requires the CONFIG_EXPERIMENTAL feature.

Is that still true as of today?


I will do some tests later but I would like to know if someone has 
information about these peripherals, are these working or not, with 
interrupt, dma etc?


Thanks for any info


Sebastien

Re: STM32H7 SPI status ?

[Sebastien Lorquet]

Hi,

Thank you, I have confirmed that SPI seems to work with a serial eeprom 
with the default slew rate.


Sebastien

Le 31/08/2022 à 13:37, David Sidrane a écrit :

Hi Sebastien,

I think it is a stale artifact from before the DMA was fleshed out.

We are using DMA on the H7  SPI in PX4. The only caveat is that the default
drive strength may be too high and we reduced it with the macro:
https://github.com/PX4/PX4-Autopilot/blob/main/boards/px4/fmu-v6x/nuttx-config/include/board.h#L417-L437


We had a sensor that worked when polled but when DMA was enabled. I could
see massive overshoot on the clock.


*Regards,*


*David*







On Wed, Aug 31, 2022 at 6:26 AM Sebastien Lorquet 
wrote:


Hi all,


SPI bus driver in STM32H7 requires the CONFIG_EXPERIMENTAL feature.

Is that still true as of today?


I will do some tests later but I would like to know if someone has
information about these peripherals, are these working or not, with
interrupt, dma etc?

Thanks for any info


Sebastien

Re: STM32F4 Ethernet Issues

[Sebastien Lorquet]

Hi,

is there any follow up on this point?

Sebastien


Le 13/08/2022 à 16:44, Fotis Panagiotopoulos a écrit :

Ok, I just managed to reproduce the issue on a NUCLEO-F429ZI, using the
NuttX apps.

Please check my fork on
https://github.com/fjpanag/incubator-nuttx-apps/tree/tcp_issue
See the branch tcp_issue.

I have "hacked" the NSH code to reproduce the issue.
A TCP connection is opened, and then closed. Then the network interface is
brought down. At this point the system crashes immediately.

Note that I have locked the scheduler when the connection is closed.
This is to simulate an ifdown action BEFORE the FIN ACK is processed (as it
happens in my case).
My code does not have this locking, this is only for simulation purposes.

Please use the provided defconfig. It is stored in the root of my apps fork.
I guess it is not related to the configuration, but my "working" sample is
provided.



On Fri, Aug 12, 2022 at 7:15 PM Alan Carvalho de Assis 
wrote:


Hi Fotis,

Yes, I understood the point. Because it needs the right timing it
could be trick to duplicate.

Did you try to create a simple host server to try to emulate this
connection issue?

BR,

Alan

On 8/12/22, Fotis Panagiotopoulos  wrote:

I think I understand the nature of the bug.

When closing a socket, tcp_close_eventhandler() is set as a callback in

the

dev->d_devcb list.

Typically, the server's response (FIN ACK) will have as a result
tcp_callback() to be executed, and thus the callback to be properly

called,

with proper arguments.
Then the cb is properly free'd.

If however devif_dev_event() has the chance to execute before
tcp_callback() (e.g. server's response was lost), then the callbacks take
NULL as a conn argument.
This crashes the whole system horribly.

As you see, this requires specific timings with the server communication,
that's why this is so hard to reproduce.


On Fri, Aug 12, 2022 at 5:13 PM Fotis Panagiotopoulos <

f.j.pa...@gmail.com>

wrote:


Hi Alan,

I am trying hard to reproduce the issue reliably, but I haven't been

able

to do so yet.

I noticed that when I disable CONFIG_NET_TCP_WRITE_BUFFERS, the problem
does not disappear, rather it changes form.
Now I occasionally get a failed assertion in wdog/wd_cancel.c line 95.

I have to mention that everything in my system is commented out.
Currently the only thing working is the network thread that opens the

TCP

connection, nothing else.
I have disabled all of my usage of the workers, all signals etc.
I verify that when the fault occurs, this thread is not interrupted by
anything (using Segger SystemView).
It looks like a scheduling issue is unlikely.

I also increased the stacks more, and I added padding to the very few
malloc's that I use.

---

At this moment I observe something very interesting.
I am calling netlib_ifdown(), which causes the attached stack trace.

So:
1. netdev_ifdown() calls devif_dev_event() with the argument pvconn set
explicitly to NULL.
2. devif_dev_event() eventually calls tcp_close_eventhandler()
3. tcp_close_eventhandler() assumes that conn is NOT NULL. Which causes
the crash.

This is wrong, but I don't have the understanding of it yet.
Shall there be a check for a NULL conn?
Or maybe tcp_close_eventhandler() is wrong to be in the cb's list in the
first place?
Or tcp_close_eventhandler() should be tolerant to a NULL conn argument?





On Thu, Aug 11, 2022 at 12:05 PM Alan Carvalho de Assis

wrote:


Hi Fotis,

Are you in sync with mainline?

If you can create a host application to induce the issue will be
easier for us to test.

BR,

Alan

On 8/9/22, Fotis Panagiotopoulos  wrote:

Hello,

still trying to make the network work reliably.
After fixing another issue of my application, I hit another problem.

The following sequence causes NuttX to crash:

1. My application is creating a TCP socket and communicates with a

server.

2. At one point the server stops responding (unrelated to NuttX /

network

issue).
3. The application detects the timeout, and calls close() on the
socket.
4. A new socket is created, and it is connected to the server.
5. At this point, the server decides to send a FIN message for the

previous

connection.
6. I get a failed assertion in devif_callback.c at line 85.

Note that I haven't managed to manually reproduce this issue.
No matter what I do manually, everything seems to be working
correctly.
I just have to wait for it to happen.
It seems that it is only triggered if a FIN arrives **after** a SYN.

I am sure that this is only happening with
CONFIG_NET_TCP_WRITE_BUFFERS
enabled.
I have no problems without buffering.

The assertion seems right to fire.
When a FIN is received for a closed connection, the same callback is

free'd

both by tcp_lost_connection() and later on by
tcp_close_eventhandler().
All these are happening within the same execution of tcp_input().

Any ideas?



















On Tue, Jul 26, 2022 at 3:44 PM Sebastien Lorquet

Hi,

good find but

-I don

Re: [VOTE] Apache NuttX Community Graduation

[Sebastien Lorquet]

+1: Apache NuttX is ready to graduate to TLP

Sebastien

On 10/23/22 19:53, Abdelatif Guettouche wrote:

+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: Dev-Board for Nuttx

[Sebastien Lorquet]

Hi,

A devboard with no jtag makes no sense for me! When you have a hw 
revision with both the esp32 and the rp2040 debug ports broken out on 
HE10-1.27mm headers (or pads if space is tight), I'm interested to get 
one :)


The internal wifi antenna close to the IO header metal pins is also not 
RF-optimal. Your version 2 was better on this aspect.


Also another suggestion, a large user flash available on esp32 or rp2040 
spi gpios would be very useful for data logging and storage. Using the 
esp32 code flash for this is not the best design. The 2KB fram is good 
for parameter storage but is quite limited, no useful FS can be mounted 
on it.


Best regards,

Sébastien

Le 26/10/2022 à 08:57, michael.sch...@mdc-service.de a écrit :

Dear Nuttx developers,

we have developed the EsPiff (ESP32+RP2040 on the Raspberry Pi Form 
Factor), a open source board to replace RasPi's and there clones, 
where the high processing power and/or Linux is not needed, but 
stability and the reuse of RasPi HATs are required.


The github home is https://github.com/MDCservice/EsPiFF

We will also offer the EsPiFF on CrowdSupply 
https://www.crowdsupply.com/mdc-service-wittenburg-gmbh/espiff


We would like to send a few boards for free to Nuttx developers, to 
improve Nuttx compatibility. Would there be interest?


A high level summary about the EsPiFF:
An ESP32-WROVER-I module with 16 MB Flash, 8 MB PSRAM is taking care
- wired Ethernet via a IP101 PHY,
- Wifi (need an external Wifi Antenna with uFL connector),
- 3 serial UARTs,
- one the 3 serial UARTs is used for programming via a CH340 USB-UART 
chip, what can be enabled/disabled with jumpers,
- I2C port expander PCA 9557 for some chip select signals and 3 user 
LEDs,

- SDcard in SPI mode,
- external real time clock, with supervisior,
- 2kB FRAM,
- USB Type-C connector for up to 5V/3A, connected to the CH340 
USB-UART to program the ESP32


An RP2040 (Pi Pico) what takes care the 40 pin RasPi header,
- connected to the ESP32 via SPI,
- UAB-A connector, also used to program the RP2040 (need to hold the 
boot button while power the board).


In earlier versions, we had the LAN8720 PHY, but as others (Olimex, 
wESP) we also got problems and replaced it with the IP101 since v3.1.


Currently, there is no HW debugging broken out on the board. But we 
could add a JTAG header on the bottom side, with TDO, TDI, TCK, TMS, 
GND, 3V3 in the next board production run. The ESP32 has the JTAG pins 
on GPIO12, 13, 14, 15, what are used for SPI on the EsPiFF, so code 
using the SPI could not be debugged while JTAG is using the pins. 
Would it still make sense to build in the JTAG header?


Would be glad to get your feedback,
Michael

Re: Dev-Board for Nuttx

[Sebastien Lorquet]

Hi,

-The external wifi antenna is the best option. I also agree that wired 
ethernet is essential and preferred in an industrial application. So 
thats fine.


-SD cards are very unreliable and to achieve their goal (be usable on 
desktop computers), they have to use FAT filesystems, which are 
EXTREMELY NOT reliable in case of surprise power loss, which is an 
unavoidable design constraint in an embedded system, so I disagree with 
you on the choice of a SD card, because this does not match the level of 
reliability you seem to intend with the rest of this board (which is 
really well done).


ISSI now has some large fast and available flash chips with 4KB erase 
blocks.


Which are VERY RELIABLE and very well managed by LittleFS regarding to 
wear leveling, with atomic/or replayable filesystem operations. I insist 
a lot, mass storage reliability in embedded devices is CRITICAL and very 
OVERLOOKED. I am a smart card engineer, and we constantly have to deal 
with half-erased data bits, undefined and unstable bits that can change 
every time you read them, duration and energy required for correct page 
erases, etc. So even if a "normal" embedded system does not need to deal 
with this, at least a reliable flash storage is a must, IMHO. With a 
large cap on the power rail to finish the current write, and ideally a 
powerok GPIO to disable further flash writes in case of power failure.


I could understand that reliable storage is not in your scope, but the 
rest of the board seems to be reliable, so thats a surprise. A broken 
out SPI+power and a few /CS lines from the ESP32 could be a solution on 
a crowded board,  so that spi flash storage can be added as an optional 
daugter board.


Yes, this board would be cool to test. Times having changed, we could 
even use that kind of esp32+rp2040 system in future products.


Sebastien

Le 26/10/2022 à 11:39, michael.sch...@mdc-service.de a écrit :

Hello Sebastian,

thanks for your interest! About the Wifi antenna: The used 
ESP32-WROVER-I has the wifi signal connected to the uFL connector by 
default, the PCB antenna would request to solder a 0 Ohm resistor, to 
use it. Because of the space limitations, we drop the idea to use the 
PCB antenna. In our use cases, the EsPiFF is build into a metal 
enclosure, what makes the useage of an PCB antenna impossible. As the 
EsPiFF is optimized for high availability applications, the wired 
Ethernet also prefered over Wifi. Because the PCB antenna is not used, 
the placement close to the IO header is no problem.


It would be great, if there where smaller ESP32 modules, with 16 MB of 
flash and 8 MB of PSRAM available. But unfortunatly, the smaller ESP32 
modules does not have 8 MB PSRAM, and we see this as a killer feature 
of the ESP32.


About data logging: There is the SDcard socket, and this is the 
prefered way for data logging. Otherwise, the 16MB flash on the ESP32 
could be used as well, but frequent writing on the flash limit its 
live time. Nuttx have special flash files systems, to minimize this 
problem, but with the SDcard available, I would prefer this. Finally, 
all pins from the 40 pol header go to he RP2040, so a RasPi HAT can 
add any functionality.


About FRAM: the initial idea was, to mount the FRAM into the malloc() 
address range, as a fast non-volatile memory. After a power cut, a 
program could continue where it was stopping before. The FRAM is byte 
adressable, and with 20MHz not so slow. Footprint and protocol 
compatible FRAMs are offered in various sizes, up to 256 kBytes. If 
needed, we could offer a version with more FRAM, what would then cost 
a little more. By also having the SDcard, what size for the FRAM would 
you choose?


We will make a board revsion with JTAG headers. I will update you as 
soon as we have it.


regards,
Michael

Am 2022-10-26 10:44, schrieb Sebastien Lorquet:

Hi,

A devboard with no jtag makes no sense for me! When you have a hw
revision with both the esp32 and the rp2040 debug ports broken out on
HE10-1.27mm headers (or pads if space is tight), I'm interested to get
one :)

The internal wifi antenna close to the IO header metal pins is also
not RF-optimal. Your version 2 was better on this aspect.

Also another suggestion, a large user flash available on esp32 or
rp2040 spi gpios would be very useful for data logging and storage.
Using the esp32 code flash for this is not the best design. The 2KB
fram is good for parameter storage but is quite limited, no useful FS
can be mounted on it.

Best regards,

Sébastien

Le 26/10/2022 à 08:57, michael.sch...@mdc-service.de a écrit :

Dear Nuttx developers,

we have developed the EsPiff (ESP32+RP2040 on the Raspberry Pi Form 
Factor), a open source board to replace RasPi's and there clones, 
where the high processing power and/or Linux is not needed, but 
stability and the reuse of RasPi HATs are required.


The github home is https://github.com/MDCservice/EsPiFF

We will also offer the EsPiFF on CrowdSup

Re: libpq and libscpi: how to start

[Sebastien Lorquet]

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

STM32H7 UART issue

[Sebastien Lorquet]

Hi,

I'm copying below the text of github issue #7138 I just opened, so that 
more people can help.


I think this is quite an important bug to be fixed for the quality of 
all upcoming releases.


Sebastien


Hi,

The stm32h7 does not properly drain the UARTs on close().

The console works perfectly and hides the problem, because nsh keeps the 
UART opened indefinitely.


However, a custom program that sends data to an UART sporadically (like 
the built in command echo or an application that open/write/close) shows 
this important issue.


echo does not even emit anything if I write less than 16 characters, 
which happens to be half the DMA buffer / cache line size (no idea if 
this is related). This is not a buffering issue as sending several small 
chunks in succession does not lead to the delayed emission of a large block.


in my program, cfmakeraw does not change anything.
calling tcdrain before close does nothing either.

Inserting a one second delay after a serial write ( with sleep(1) ) 
allows my output to be written.
Leaving the UART open in my program does not help, since the devices are 
closed after the program ends. This also happens in the echo command.


Disabling DMA peripherals and options entirely has no effect and I dont 
think it's wise since the serial driver and others parts of the stm32h7 
serial code clearly assumes DMA is enabled.


I wonder if there are bugs in the stm32h7 driver, specifically related 
to DMA or something else, or if the issue is known, or if I missed some 
config options.


Any help investigating this is highly appreciated, since the serial 
driver is surprisingly complex and I do not know how to start debugging 
this dynamic issue.


It can probably be reproduced in ANY stm32h7 board with a secondary uart 
and the echo command.


Thanks

Sebastien

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

[Sebastien Lorquet]

Hi,

I think there is an important issue in the stm32h7 uarts that was 
untested up to now and is quite worrying.


Not sure this qualifies as a blocker for a release.

See my other email.

Sebastien

Le 19/09/2022 à 23:42, Alan Carvalho de Assis a écrit :

Guys, please help!!!

The idea is to have the NuttX 11.0.0 available before this weekend (guess why?)

https://nuttx.events/2022/09/19/list-of-presentation-of-the-nuttx-international-2022/

BR,

Alan

On 9/19/22, alin.jerpe...@sony.com  wrote:

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

Best regards
Alin Jerpelea


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

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

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

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

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

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

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

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

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

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


Hello all,
Apache NuttX (Incubating) 11.0.0 RC2 has been staged under [1] and
it's time to vote on accepting it for release. If approved we will
seek final release approval from the IPMC. Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

The Apache requirements for approving a release can be found here [3]
"Before voting +1 [P]PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, along with also verifying that the
package meets the requirements of the ASF policy on releases."

A document to walk through some of this process has been published on
our project wiki and can be found here [4].

[ ] +1 accept (indicate what you 

Re: [RESULT] Release Apache NuttX (Incubating) 11.0.0 [RC2]

[Sebastien Lorquet]

Hi,

If you want to play with 68k, tell me, the ti68k calculators 
(ti89,92+,v200,titanium) should be great platforms: 256K RAM and 2-4M 
flash, full keyboard and lcd screen.


They have some peculiarities, I could help with drivers or find friends 
that could.


The cemetech/tiplanet communities should like it.

Sebastien

On 10/8/22 18:06, Tomek CEDRO wrote:

On Sat, Oct 8, 2022 at 4:58 PM Alan C. Assis wrote:

Hi Tomek,
I think 6502 compiler are evolving, but I don't know if they are compatible.
There is a interesting comparison here:
https://gglabs.us/node/2293
CC. Gabriele here, since I don't know if here is in our list!

Thank you Alan :-) 8-bit platforms are on list, but before I would
like to make smooth out-of-the box experience with NuttX on FreeBSD,
then port MicroPython to NuttX, then as a training in porting I would
prefer to target 16-bit MC68000 in the first place (Atari + Amiga),
then 8-bit Atari, in that order, and all of that in my free time
between other tasks, so there is no rush :-)

Re: [VOTE] Apache NuttX 12.0.0 RC1 release

[Sebastien Lorquet]

Hi,

+1

NuttX 12.0.0-RC1 building and working fine on my proprietary STM32H7 board.

Compiler: arm-none-eabi-gcc (GNU Arm Embedded Toolchain
  10-2020-q4-major) 10.2.1 20201103 (release)

Sebastien

Le 11/01/2023 à 10:32, Alin Jerpelea a écrit :

Hello all,
Apache NuttX 12.0.0 RC1 has been staged under [1] and it's
time to vote on accepting it for release.
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
required to pass.

The Apache requirements for approving a release can be found here [3]
"Before voting +1 [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,


SCM Information:
   Release tag: nuttx-12.0.0-RC1
   Hash for the release nuttx tag: ccf0b5af0d6ba555f549d8d00531fa4a3a432a1b
   Hash for the release nuttx-apps tag: 5592e38253bc74c65f4d105f837d8bc048ac1859

[1] https://dist.apache.org/repos/dist/dev/nuttx/12.0.0-RC1/
[2] https://raw.githubusercontent.com/apache/nuttx/nuttx-12.0.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: Port to M5Stamp-C3U

[Sebastien Lorquet]

Hi,

OK I got the bootloading part figured out (eg, it shoud work because the 
esp32c3 has a serial bootloader mode in ROM that should support usb CDC, 
and I see a serial port by pushing the GPIO9 button while plugging it 
in), I will try to use my board as a esp32c3 devkit for now, it shoud be 
similar.


(later)

So the esp32c3-devkit:usbconsole configuration works on the m5stamp-c3u.

nsh> uname -a
NuttX 10.1.0-RC1 512be93c36 Dec  9 2022 12:32:21 risc-v esp32c3-devkit

Nice.

Sebastien


Le 09/12/2022 à 11:21, Sebastien Lorquet a écrit :

Hi,

As an introduction to the RISCV, I would like to use NuttX on my 
M5stamp C3U, which I can get for 8 dollars at a local store.


https://docs.m5stack.com/en/core/stamp_c3u

The module does not use a usb serial chip but direct USB connection 
(there is a schematic in the bottom of the page).


I wonder how it works: Is serial on USB supported by an internal 
bootloader or does this require firmware support that will disappear 
after I flash this board for the first time?


I ask this dumb question here because I know there are ESP32 people on 
this list.


Thanks for the help,

Sebastien

Port to M5Stamp-C3U

[Sebastien Lorquet]

Hi,

As an introduction to the RISCV, I would like to use NuttX on my M5stamp 
C3U, which I can get for 8 dollars at a local store.


https://docs.m5stack.com/en/core/stamp_c3u

The module does not use a usb serial chip but direct USB connection 
(there is a schematic in the bottom of the page).


I wonder how it works: Is serial on USB supported by an internal 
bootloader or does this require firmware support that will disappear 
after I flash this board for the first time?


I ask this dumb question here because I know there are ESP32 people on 
this list.


Thanks for the help,

Sebastien

Re: New names of repositories

[Sebastien Lorquet]

nuttx and nuttxapps

Sébastien

Le 18/11/2022 à 17:30, Gregory Nutt a écrit :



why can’t we just have :

nuttx, apps

as it has been for a long time (before Apache) …


Ultimately, the repository names would appear here: 
https://github.com/orgs/apache/repositories


nuttx/ would probably be fine, but apps/ probably would not be 
appropriate at that level.

Re: New names of repositories

[Sebastien Lorquet]

Hi,

I would also very much prefer nuttx and nuttx_apps but the other option 
will not prevent me from sleeping well at night.


Sebastien

Le 18/11/2022 à 15:46, Gregory Nutt a écrit :


But NuttX has more features than traditional RTOS(e.g. FreeRTOS). 
Actually,

Xiaomi uses it in the IoT space which has less real time requirements.
Other similar OS(e.g. Zephyr) doesn't append rtos suffix.
So, I prefer keep nuttx and nuttx-apps.


I just endorsed nuttx_rtos and nuttx_apps, but Xiao is correct. 
nuttx_rtos is redundant since nuttx is the name of the RTOS. 
nuttx_apps are miscellaneous applications tailored for the NuttX 
RTOS.  It really is semantically cleaner.

Re: New names of repositories

[Sebastien Lorquet]

Hi,

Also voting to let as-is

One more reason to keep the OS code under the "nuttx" name without some 
sort of suffix: this is the main name of the project, and has been for 
years.


When you want to clone this repo from a command line, you dont want to 
go check on github if this is nuttx-core nuttx-main nuttx-foobar or 
nuttx-whatever. This is just nuttx.


Minor reason but for day-to-day usability it could be useful to many 
people :)


Sebastien

Le 20/11/2022 à 21:09, Alin Jerpelea a écrit :

+1 let is as it is :)

On Sun, 20 Nov 2022, 20:23 Tomek CEDRO,  wrote:


On Sun, Nov 20, 2022 at 8:20 PM Gregory Nutt wrote:

On 11/20/2022 1:18 PM, Tim Hardisty wrote:

Might I humbly suggest that "if it isn't broken, don't fix it"?

Just stick with the names already in use (minus the incubator, as will

happen anyway). Just tried searching the Apache website for "RTOS" and
NuttX is top of the list; searching the Apache GitHub repositories
similarly and NuttX is the only repo that comes up.

If it does go to a vote, you can guess what mine will be for :)

...

After flip-flopping for a couple of days, I have come to the same
conclusion as well.

+1 :-) :-) :-)

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

Re: Post Graduation TO DO List

[Sebastien Lorquet]

Congrats!

Sébastien

Le 17/11/2022 à 17:20, Nathan Hartman a écrit :

Hi All,

NuttX graduated from the Incubator! Kudos to the whole NuttX
community. Here's to a great continuation of this journey for many
years to come!

Some post-graduation TODOs -- Help will be appreciated!!

* Change NuttX and NuttX apps repo names
   - Finalize new names
   - Ask Infra to make the change
   - Update all links inside our repos
   - Announce the git incantations to update forks/clones

* Remove DISCLAIMER from both repos
   - See PR #7613 at NuttX repo
   - See PR #1422 at NuttX apps repo

* Update website:
   - Change from Incubator to Top Level Project
   - Update links to repos

Cheers,
Nathan

Re: Debugging a specific application

[Sebastien Lorquet]

Dont think about nuttx like you do with linux with isolated processes 
and apps loaded from disk files :)


it's more like a *very* advanced set of arduino libs in most usual cases.

(others dont hit me, I know this is extreme simplification.)


if the microros app is compiled in your os image, then you can probably 
put a breakpoint on the microros_main() function, then launch microros 
with nsh, and your breakpoint will just trip.


For that you need to connect to your nucleo stlink using openocd and 
gdb. There are tutorials around there, this is just about generic 
embedded debugging techniques.


Sebastien

Le 01/12/2022 à 07:41, Roberto Bucher a écrit :

Danke Sebastien

The application (microros) is configured and compiled by the nuttx 
generation. But if the routine is in the shell, how can I start it 
from the debugger?


Thanks in advance

Roberto

On 11/30/22 22:17, Sebastien Lorquet wrote:

Hi,

If your OS is built in monolithic mode (no protected mode) then 
applications are just routines, so you can put a breakpoint in any 
app routine and let it run until there.


To replace nsh by your app, do make menuconfig, menu RTOS features, 
menu Tasks and scheduling, text config "Application entry point".


But it is not necessary to replace the default app, you can launch it 
with nsh and still hit a breakpoint in your launched app.


Sebastien

On 11/30/22 06:40, Roberto Bucher wrote:

Hi

I'm working on my nucleo-144 board, trying to get a microROS working 
again under NuttX.


Thanks to a unique change in a microROS file, I've reached to 
recompile all the files again and I can obtain the microros 
application as described here:


https://github.com/micro-ROS/micro_ros_nuttx_app apps/microros

The application doesn't correctly work yet, and I'm looking for the 
problem. I'd like to debug the microros application, but the 
debugger shows (as expected) the nsh task. It is possible to start 
the specific "microros" generated program or I have to set it as 
entry point? Otherwise, how can I attach this task to the debugger? 
I'm able to debug the nsh application with the methods described on 
the NuttX documentation about debugger. Thanks in advance Roberto

Re: Debugging a specific application

[Sebastien Lorquet]

Hi,

If your OS is built in monolithic mode (no protected mode) then 
applications are just routines, so you can put a breakpoint in any app 
routine and let it run until there.


To replace nsh by your app, do make menuconfig, menu RTOS features, menu 
Tasks and scheduling, text config "Application entry point".


But it is not necessary to replace the default app, you can launch it 
with nsh and still hit a breakpoint in your launched app.


Sebastien

On 11/30/22 06:40, Roberto Bucher wrote:

Hi

I'm working on my nucleo-144 board, trying to get a microROS working 
again under NuttX.


Thanks to a unique change in a microROS file, I've reached to 
recompile all the files again and I can obtain the microros 
application as described here:


https://github.com/micro-ROS/micro_ros_nuttx_app  apps/microros

The application doesn't correctly work yet, and I'm looking for the 
problem. I'd like to debug the microros application, but the debugger 
shows (as expected) the nsh task. It is possible to start the specific 
"microros" generated program or I have to set it as entry point? 
Otherwise, how can I attach this task to the debugger? I'm able to 
debug the nsh application with the methods described on the NuttX 
documentation about debugger. Thanks in advance Roberto

Re: New names of repositories

[Sebastien Lorquet]

+1, too

Sébastien

Le 22/11/2022 à 14:30, Nathan Hartman a écrit :

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

https://github.com/apache/nuttx
https://github.com/apache/nuttx-apps

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

Cheers,
Nathan