Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[Gregory Nutt]

The new implementation of set_errno require all thread(include IDLE)
initialize the stack related fields in tcb_s correctly. But many
chipset forget to setup them for IDLE thread. TODO contain an item
described this:


... snip ...


  Hello,
I think there's a problem with set_errno() in nx_start(), when 
CONFIG_TLS_ALIGNED is not set:
I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test 
CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a call 
of set_errno().


In addition, nothing within the OS should ever set the errno value.   So 
the first bug is the fs_fdopen() should not call set_errno();


It is a secondary problem that the stack data is not initialized.  It 
should never be needed for the purpose errno access since no logic in 
the OS should ever access the errno.


Greg

Re: Release Notes for the NEXT version of NuttX

[Abdelatif Guettouche]

> You want to find the point at which it was branched, something like
>
> git log master..releasebranch --oneline | tail -1

That actually gives the first commit that's not in master, we'd be
interested in its parent
"git log master..releases/9.0 --oneline --format='%p' | tail -1"


On Fri, May 22, 2020 at 11:47 PM Abdelatif Guettouche
 wrote:
>
> Why are we interested in individual commits?  PRs bundle all the changes and 
> are easier to retrieve.
>
> In any case, we can filter out cherry picked commits with something like
> "git log --oneline --cherry-pick --right-only releases/9.0...master"
>
>
> On Fri, May 22, 2020 at 10:37 PM Nathan Hartman  
> wrote:
>>
>> On Fri, May 22, 2020 at 5:12 PM Gregory Nutt  wrote:
>> > This is what I used to do for the old releases (from 8.2
>> > tools/README.txt, from show 6168f3ebf046e4c3d5561bfa96a39d0f02b771db):
>>
>> snip
>>
>> > -logparser.c
>> > 
>> > -
>> > -  Convert a git log to ChangeLog format.  Recommended usage:
>> > -
>> > -git log --date-order --reverse ..|HEAD >_git_log.tmp
>> > -logparser _git_log.tmp >_changelog.txt
>> > -rm -f _git_log.tmp
>>
>> I think I understand the problem a little better now. It seems that
>> commits that are cherry-picked from master to a release branch get a
>> new commit hash... And if my understanding is correct, that would mean
>> that any attempt to figure out what's new in 9.1 (that didn't slip
>> into 9.0) is going to be futile.
>>
>> For example...
>>
>> $ git log master --not releases/9.0 --not nuttx-9.0.0-RC1 --no-merges > 
>> log.txt
>>
>> That log file contains:
>>
>> [[[
>>
>> commit 4476a16a1a2d68c930f2d1c2476b7f1d53162cb6
>> Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com>
>> Date:   Fri Apr 24 10:17:36 2020 -0400
>>
>> README.txt: Address issues raised in -RC0 review
>>
>>   * Add INTRODUCTION section with a brief summary of Apache NuttX
>> (Incubating), a link to documentation at the project wiki, and
>> a note about the project's incubation status. Most of this
>> text is copied from the project website, with some minor edits
>> for this README format.
>>
>>   * Add COMMUNITY section with information on Getting Help, the
>> project's Mailing Lists, Issue Tracker, Source Code, and
>> Website Source Code. Like the text in INTRODUCTION, most of
>> this text is copied from the project website, with some minor
>> edits for this README format.
>>
>>   * Update download and GIT locations.
>>
>> ]]]
>>
>> Okay, now let's look at 9.0...
>>
>> [[[
>>
>> commit 8f01ded09d7bf3a2958edda8e773d21fa4a38510
>> Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com>
>> Date:   Fri Apr 24 10:17:36 2020 -0400
>>
>> README.txt: Address issues raised in -RC0 review
>>
>>   * Add INTRODUCTION section with a brief summary of Apache NuttX
>> (Incubating), a link to documentation at the project wiki, and
>> a note about the project's incubation status. Most of this
>> text is copied from the project website, with some minor edits
>> for this README format.
>>
>>   * Add COMMUNITY section with information on Getting Help, the
>> project's Mailing Lists, Issue Tracker, Source Code, and
>> Website Source Code. Like the text in INTRODUCTION, most of
>> this text is copied from the project website, with some minor
>> edits for this README format.
>>
>>   * Update download and GIT locations.
>>
>> ]]]
>>
>> Same log. Different commit hash.
>>
>> By the way, it seems that we never tagged the final 9.0 release. There
>> doesn't seem to be a nuttx-9.0.0 tag, only nuttx-9.0.0-RC*.
>>
>> Anyway, I'll have to continue this later.
>>
>> Nathan

Re: Release Notes for the NEXT version of NuttX

[Abdelatif Guettouche]

Why are we interested in individual commits?  PRs bundle all the changes
and are easier to retrieve.

In any case, we can filter out cherry picked commits with something like
"git log --oneline --cherry-pick --right-only releases/9.0...master"


On Fri, May 22, 2020 at 10:37 PM Nathan Hartman 
wrote:

> On Fri, May 22, 2020 at 5:12 PM Gregory Nutt  wrote:
> > This is what I used to do for the old releases (from 8.2
> > tools/README.txt, from show 6168f3ebf046e4c3d5561bfa96a39d0f02b771db):
>
> snip
>
> > -logparser.c
> > 
> > -
> > -  Convert a git log to ChangeLog format.  Recommended usage:
> > -
> > -git log --date-order --reverse ..|HEAD >_git_log.tmp
> > -logparser _git_log.tmp >_changelog.txt
> > -rm -f _git_log.tmp
>
> I think I understand the problem a little better now. It seems that
> commits that are cherry-picked from master to a release branch get a
> new commit hash... And if my understanding is correct, that would mean
> that any attempt to figure out what's new in 9.1 (that didn't slip
> into 9.0) is going to be futile.
>
> For example...
>
> $ git log master --not releases/9.0 --not nuttx-9.0.0-RC1 --no-merges >
> log.txt
>
> That log file contains:
>
> [[[
>
> commit 4476a16a1a2d68c930f2d1c2476b7f1d53162cb6
> Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com>
> Date:   Fri Apr 24 10:17:36 2020 -0400
>
> README.txt: Address issues raised in -RC0 review
>
>   * Add INTRODUCTION section with a brief summary of Apache NuttX
> (Incubating), a link to documentation at the project wiki, and
> a note about the project's incubation status. Most of this
> text is copied from the project website, with some minor edits
> for this README format.
>
>   * Add COMMUNITY section with information on Getting Help, the
> project's Mailing Lists, Issue Tracker, Source Code, and
> Website Source Code. Like the text in INTRODUCTION, most of
> this text is copied from the project website, with some minor
> edits for this README format.
>
>   * Update download and GIT locations.
>
> ]]]
>
> Okay, now let's look at 9.0...
>
> [[[
>
> commit 8f01ded09d7bf3a2958edda8e773d21fa4a38510
> Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com>
> Date:   Fri Apr 24 10:17:36 2020 -0400
>
> README.txt: Address issues raised in -RC0 review
>
>   * Add INTRODUCTION section with a brief summary of Apache NuttX
> (Incubating), a link to documentation at the project wiki, and
> a note about the project's incubation status. Most of this
> text is copied from the project website, with some minor edits
> for this README format.
>
>   * Add COMMUNITY section with information on Getting Help, the
> project's Mailing Lists, Issue Tracker, Source Code, and
> Website Source Code. Like the text in INTRODUCTION, most of
> this text is copied from the project website, with some minor
> edits for this README format.
>
>   * Update download and GIT locations.
>
> ]]]
>
> Same log. Different commit hash.
>
> By the way, it seems that we never tagged the final 9.0 release. There
> doesn't seem to be a nuttx-9.0.0 tag, only nuttx-9.0.0-RC*.
>
> Anyway, I'll have to continue this later.
>
> Nathan
>

Re: Release Notes for the NEXT version of NuttX

[Nathan Hartman]

On Fri, May 22, 2020 at 5:12 PM Gregory Nutt  wrote:
> This is what I used to do for the old releases (from 8.2
> tools/README.txt, from show 6168f3ebf046e4c3d5561bfa96a39d0f02b771db):

snip

> -logparser.c
> 
> -
> -  Convert a git log to ChangeLog format.  Recommended usage:
> -
> -git log --date-order --reverse ..|HEAD >_git_log.tmp
> -logparser _git_log.tmp >_changelog.txt
> -rm -f _git_log.tmp

I think I understand the problem a little better now. It seems that
commits that are cherry-picked from master to a release branch get a
new commit hash... And if my understanding is correct, that would mean
that any attempt to figure out what's new in 9.1 (that didn't slip
into 9.0) is going to be futile.

For example...

$ git log master --not releases/9.0 --not nuttx-9.0.0-RC1 --no-merges > log.txt

That log file contains:

[[[

commit 4476a16a1a2d68c930f2d1c2476b7f1d53162cb6
Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com>
Date:   Fri Apr 24 10:17:36 2020 -0400

README.txt: Address issues raised in -RC0 review

  * Add INTRODUCTION section with a brief summary of Apache NuttX
(Incubating), a link to documentation at the project wiki, and
a note about the project's incubation status. Most of this
text is copied from the project website, with some minor edits
for this README format.

  * Add COMMUNITY section with information on Getting Help, the
project's Mailing Lists, Issue Tracker, Source Code, and
Website Source Code. Like the text in INTRODUCTION, most of
this text is copied from the project website, with some minor
edits for this README format.

  * Update download and GIT locations.

]]]

Okay, now let's look at 9.0...

[[[

commit 8f01ded09d7bf3a2958edda8e773d21fa4a38510
Author: Nathan Hartman <59230071+hartmannat...@users.noreply.github.com>
Date:   Fri Apr 24 10:17:36 2020 -0400

README.txt: Address issues raised in -RC0 review

  * Add INTRODUCTION section with a brief summary of Apache NuttX
(Incubating), a link to documentation at the project wiki, and
a note about the project's incubation status. Most of this
text is copied from the project website, with some minor edits
for this README format.

  * Add COMMUNITY section with information on Getting Help, the
project's Mailing Lists, Issue Tracker, Source Code, and
Website Source Code. Like the text in INTRODUCTION, most of
this text is copied from the project website, with some minor
edits for this README format.

  * Update download and GIT locations.

]]]

Same log. Different commit hash.

By the way, it seems that we never tagged the final 9.0 release. There
doesn't seem to be a nuttx-9.0.0 tag, only nuttx-9.0.0-RC*.

Anyway, I'll have to continue this later.

Nathan

Re: Release Notes for the NEXT version of NuttX

[Gregory Nutt]

This is what I used to do for the old releases (from 8.2 
tools/README.txt, from show 6168f3ebf046e4c3d5561bfa96a39d0f02b771db):


index 42c71fd52d..64666eb550 100644
--- a/tools/README.txt
+++ b/tools/README.txt
@@ -745,15 +745,6 @@ link.sh, link.bat, copydir.sh, copydir.bat, 
unlink.sh, and unlink.bat

   NTFS mklink.exe command instead of copying files.  That logic, however,
   has not been verified as of this writing.

-logparser.c

-
-  Convert a git log to ChangeLog format.  Recommended usage:
-
-    git log --date-order --reverse ..|HEAD >_git_log.tmp
-    logparser _git_log.tmp >_changelog.txt
-    rm -f _git_log.tmp
-

On 5/22/2020 2:54 PM, Brennan Ashton wrote:

On Fri, May 22, 2020, 1:49 PM Brennan Ashton 
wrote:


You want to find the point at which it was branched, something like

git log master..releasebranch --oneline | tail -1

Then you can use it for the base of log

git log branched-commit..master



Nevermind I see what you were asking for. There is no great way to do this
with git directly, usually you track this by using labels (or similar) on
issues or PRs to aggregate it. At least that is that is how I have always
run releases for work.

--Brennan

Re: Release Notes for the NEXT version of NuttX

[Nathan Hartman]

On Fri, May 22, 2020 at 4:54 PM Brennan Ashton
 wrote:
> Nevermind I see what you were asking for. There is no great way to do this
> with git directly, usually you track this by using labels (or similar) on
> issues or PRs to aggregate it. At least that is that is how I have always
> run releases for work.

Ugh, I don't think we've done that. At least, we haven't consistently.

So, I'm guessing we'll have to take the log since that branch point,
but then manually exclude the commits that were cherry-picked to 9.0?
Sounds like a lot of effort. :-(

Nathan

Re: Release Notes for the NEXT version of NuttX

[Brennan Ashton]

On Fri, May 22, 2020, 1:49 PM Brennan Ashton 
wrote:

> You want to find the point at which it was branched, something like
>
> git log master..releasebranch --oneline | tail -1
>
> Then you can use it for the base of log
>
> git log branched-commit..master
>
>

Nevermind I see what you were asking for. There is no great way to do this
with git directly, usually you track this by using labels (or similar) on
issues or PRs to aggregate it. At least that is that is how I have always
run releases for work.

--Brennan

>

Re: Release Notes for the NEXT version of NuttX

[Brennan Ashton]

You want to find the point at which it was branched, something like

git log master..releasebranch --oneline | tail -1

Then you can use it for the base of log

git log branched-commit..master

--Brennan

On Fri, May 22, 2020, 1:30 PM Nathan Hartman 
wrote:

> In preparation for the 9.1 release notes...
>
> What git incantation will get the log, excluding all commits present
> in the 9.0 release?
>
> Specifically, I want to include commits after 9.0 was branched, but
> exclude commits that were cherry-picked to 9.0.
>
> Thanks,
> Nathan
>

Re: Release Notes for the NEXT version of NuttX

[Nathan Hartman]

In preparation for the 9.1 release notes...

What git incantation will get the log, excluding all commits present
in the 9.0 release?

Specifically, I want to include commits after 9.0 was branched, but
exclude commits that were cherry-picked to 9.0.

Thanks,
Nathan

Re: mbedtls

[Gregory Nutt]

I propose that we reuse the same process(Apache Way) for github.com/nuttx(e.g. 
review/merge, select new committer/PMC). The only difference is that 
github.com/nuttx isn't an Apache project and is an optional component.


I think other than the repository location, it can piggyback completely 
on the Apache project.  We don't need a new PMC and we can extend 
existing web resources to include information about applications.


If github.com/apache were properly controlled and verified, as is 
github/apache, I would not have any issues in moving the remaining 
bitbuck repositories there either.


Greg

RE: mbedtls

[Xiang Xiao]

> -Original Message-
> From: Takashi Yamamoto 
> Sent: Friday, May 22, 2020 11:18 PM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
> 
> On Fri, May 22, 2020 at 10:14 PM Xiang Xiao  wrote:
> >
> > On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis
> >  wrote:
> > >
> > > Hi Xiang,
> > >
> > > On 5/22/20, Xiang Xiao  wrote:
> > > sic
> > > >
> > > > But mbedtls can be used in more context than HTTPS/TLS like
> > > > security boot, OTA and TEE, it doesn't make sense to put into
> > > > netutils. A central folder(e.g. external) for 3rd party is a
> > > > better choice
> > > > because:
> > >
> > > The external folder is used for other purpose (to test user own code).
> > > Not it is even in the .gitignore.
> > > And since the code will be there already, it is better to keep the
> > > way NuttX already to it for external application.
> > >
> >
> > We don't need put Makefile/Kconfig into apps/external directly. Like
> > Chao's suggestion, we can create a new apache-nuttx-external git to
> > manage the porting. People can link apps/external to
> > apache-nuttx-external or their own version.
> 
> i guess a user often want to use apache-nuttx-external AND his own version.
> while you can always workaround it with symbolic links, i wonder if it could 
> be more straightforward to use multiple "external" repos.
> 

NuttX build system can find new Makefile/Kconfig automatically once you add a 
new folder(not only external) into apps. You can:
1.Extend apache-nuttx-external with the new 3rd party library or
2.Create a new folder for the new 3rd party library and link it from apps

> >
> > > > 1.New user can find what already provide by NuttX quickly before
> > > > start porting
> > >
> > > Normally new users will look inside menuconfig before looking the
> > > code, so it is not an appealing reason.
> > >
> >
> > Even with menuconfig, user need dig into several level to find, e.g.:
> > Application Configuration->Grahpics Support->Littlev Graphic
> > Libray(LVGL) Considering we have more than 1000 Kconfig options, the
> > new user is hard to find the library he/she want from Kconfig quickly.
> >
> > > > 2.Help PMC check LICENSE file reflect the truth
> > >
> > > It doesn't better since the code is not distributed inside NuttX.
> > >
> > > > 3.Follow other project practice
> > > >
> > >
> > > Hmm, so I think I didn't get it correctly from start. Maybe your
> > > idea is to keep the complete code inside an apps/external or
> > > apps/thirdparty folder, is it?
> >
> > No, just Makefile/Kconfig, but we need a system way to layout 3rd
> > party library if you consider how to find them quickly after we port
> > 100+ libraries which  very likely happen after one or two years.
> >
> > > If this is the idea, maybe in this case other option is to have an
> > > apps-external or thirdparty repository to avoid the apps/ repository
> > > becoming too big with code from external projects.
> > >
> >
> > It's very important to have a common place to share the 3rd party
> > library support. Many user select one RTOS just because it support the
> > library he/she want to use in box. We need catch up here to compete
> > with other RTOS.
> >
> > > >> > 4. how do you think about adding tls support to netutils/webclient?
> > > >> >
> > > >>
> > > >> I think it is better to create the mbedtls as a separated "library"
> > > >> (note the quotes) instead of mixing it directly inside webclient,
> > > >> because it could make it easier to users to use mbedtls on their
> > > >> web applications. But, of course, it should be nice to have an
> > > >> option to compile the webclient with the mbedtls "library"
> > > >> support. There are some examples of "libraries" and applications on 
> > > >> NuttX apps, i.e.:
> > > >> gpsutils/minmea/minmea.c and an application using it: examples/gps.
> > > >>
> > > >
> > > > Yes, mbedtls is better to integrate as a library, and then any
> > > > builtin or 3rd party apps can utilize it.
> > > >
> > >
> > > I suppose this is the way you did at Xiaomi, right?
> > >
> > > BR,
> > >
> > > Alan

RE: mbedtls

[Xiang Xiao]

> -Original Message-
> From: Gregory Nutt 
> Sent: Saturday, May 23, 2020 2:04 PM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
> 
> 
> > i guess a user often want to use apache-nuttx-external AND his own version.
> > while you can always workaround it with symbolic links, i wonder if it
> > could be more straightforward to use multiple "external" repos.
> 
> People have talked about this on and off for some time in various way. There 
> really needs to be a better decoupling between the
> RTOS and the applications that run on top of it.  I would think that 
> incubator-nuttx-apps should be only an application framework with
> highly integrated apps (like NSH) and that ALL other applications reside 
> elsewhere.
> 

Yes, apps is suitable for the code write from scratch for NuttX or the project 
stop the active development. But since Apache Foundation has more strict 
license requirement which mean that the owner of 3rd party code need sign SGA:
https://www.apache.org/licenses/contributor-agreements.html#grants
So if you want to put the source code into apps git, you need:
1.The library is Apache license
2.The library isn't in the active development
3.The owner sign Software Grant Agreement
4.Pass nxstyle check

> Taking this to the next step, this could involve some external repositories 
> containing a variety of applications, original NuttX
> applications and 3rd party applications, along with some configuration tool 
> to setup a NuttX userland.  People, particularly Alan, has
> often advocated this as a "NuttX distro". However, I think the term distro 
> alienates people.  Let's just say repositories outside of
> Apache that integrate applications intothe incubator-nuttx-apps application 
> framework.
> 
> There is a good spot at github.com/nuttx, but that is not currently in-use.  
> It is currently just a free-for-all and not suitable for any

Yes, github.com/nuttx is a good location to mitigate the above constraint.

> critical software development.  But I think we could tighten up the security 
> there, add some automated testing, and create some kind
> of project structure to protect and maintain the repositories.
> 
> Ultimately, you are talking about another non-Apache project. That project 
> would need some organization and support.
> 

I propose that we reuse the same process(Apache Way) for github.com/nuttx(e.g. 
review/merge, select new committer/PMC). The only difference is that 
github.com/nuttx isn't an Apache project and is an optional component.

> 

Re: mbedtls

[Nathan Hartman]

On Fri, May 22, 2020 at 9:18 AM Alan Carvalho de Assis 
wrote:

> Hi Daniel,
>
> Yes, I think an option is to create an apps/thirdparty folder to
> follow with Xiang idea.


I like the idea of glue code.

There are many libraries out there which people may want to use with NuttX,
and we can't/shouldn't fork them all and stick them in our codebase. Not
only would that be a problem for Apache (because Apache doesn't make
"hostile forks" and licensing) but from a technical/management point it
creates a bigger maintenance burden on us to manually track upstream and
bring updates into NuttX.

It is better to work with upstream libraries as-is, and make only the
custom glue code that consists of Kconfig, Make.defs, etc. The glue code
will belong to us and will be Apache licensed. The 3rd party library stays
separate and is not in our repository. Only if the user activates a 3rd
party library, the glue code will (1) download or clone it, if needed, and
(2) integrate it into the NuttX build system.

If a port to NuttX requires patching the 3rd party code, whoever does the
porting should upstream the changes back to the 3rd party project. If the
3rd party project doesn't accept the changes, the patch can be part of our
glue code.

In any case, we will only need to maintain the glue, not the whole project,
and the glue will be Apache licensed so we aren't stepping on anyone's toes.

I think it's a good general solution for integrating 3rd party code.

I think glue code will even allow to make GNU licensed 3rd party code
integrations, because the glue code is ours, and the GNU code is not
downloaded or used unless the user specifically wants it.

One more thing: I think the glue code should provide a way to customize the
download location of the 3rd party code. So if a NuttX user is worried that
the 3rd party code will disappear from the Internet, or if they want to
customize the 3rd party code, they can keep their own local clone and
provide that link to Kconfig.

> Cheers,
Nathan

Re: mbedtls

[Gregory Nutt]

i guess a user often want to use apache-nuttx-external AND his own version.
while you can always workaround it with symbolic links, i wonder if it could
be more straightforward to use multiple "external" repos.


People have talked about this on and off for some time in various way.  
There really needs to be a better decoupling between the RTOS and the 
applications that run on top of it.  I would think that 
incubator-nuttx-apps should be only an application framework with highly 
integrated apps (like NSH) and that ALL other applications reside elsewhere.


Taking this to the next step, this could involve some external 
repositories containing a variety of applications, original NuttX 
applications and 3rd party applications, along with some configuration 
tool to setup a NuttX userland.  People, particularly Alan, has often 
advocated this as a "NuttX distro". However, I think the term distro 
alienates people.  Let's just say repositories outside of Apache that 
integrate applications intothe incubator-nuttx-apps application framework.


There is a good spot at github.com/nuttx, but that is not currently 
in-use.  It is currently just a free-for-all and not suitable for any 
critical software development.  But I think we could tighten up the 
security there, add some automated testing, and create some kind of 
project structure to protect and maintain the repositories.


Ultimately, you are talking about another non-Apache project. That 
project would need some organization and support.

Re: mbedtls

[Takashi Yamamoto]

On Fri, May 22, 2020 at 10:14 PM Xiang Xiao  wrote:
>
> On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis
>  wrote:
> >
> > Hi Xiang,
> >
> > On 5/22/20, Xiang Xiao  wrote:
> > sic
> > >
> > > But mbedtls can be used in more context than HTTPS/TLS like security
> > > boot, OTA and TEE, it doesn't make sense to put into netutils. A
> > > central folder(e.g. external) for 3rd party is a better choice
> > > because:
> >
> > The external folder is used for other purpose (to test user own code).
> > Not it is even in the .gitignore.
> > And since the code will be there already, it is better to keep the way
> > NuttX already to it for external application.
> >
>
> We don't need put Makefile/Kconfig into apps/external directly. Like
> Chao's suggestion, we can create a new apache-nuttx-external git to
> manage the porting. People can link apps/external to
> apache-nuttx-external or their own version.

i guess a user often want to use apache-nuttx-external AND his own version.
while you can always workaround it with symbolic links, i wonder if it could
be more straightforward to use multiple "external" repos.

>
> > > 1.New user can find what already provide by NuttX quickly before start
> > > porting
> >
> > Normally new users will look inside menuconfig before looking the
> > code, so it is not an appealing reason.
> >
>
> Even with menuconfig, user need dig into several level to find, e.g.:
> Application Configuration->Grahpics Support->Littlev Graphic Libray(LVGL)
> Considering we have more than 1000 Kconfig options, the new user is
> hard to find the library he/she want from Kconfig quickly.
>
> > > 2.Help PMC check LICENSE file reflect the truth
> >
> > It doesn't better since the code is not distributed inside NuttX.
> >
> > > 3.Follow other project practice
> > >
> >
> > Hmm, so I think I didn't get it correctly from start. Maybe your idea
> > is to keep the complete code inside an apps/external or
> > apps/thirdparty folder, is it?
>
> No, just Makefile/Kconfig, but we need a system way to layout 3rd
> party library if you consider how to find them quickly after we port
> 100+ libraries which  very likely happen after one or two years.
>
> > If this is the idea, maybe in this case other option is to have an
> > apps-external or thirdparty repository to avoid the apps/ repository
> > becoming too big with code from external projects.
> >
>
> It's very important to have a common place to share the 3rd party
> library support. Many user select one RTOS just because it support the
> library he/she want to use in box. We need catch up here to compete
> with other RTOS.
>
> > >> > 4. how do you think about adding tls support to netutils/webclient?
> > >> >
> > >>
> > >> I think it is better to create the mbedtls as a separated "library"
> > >> (note the quotes) instead of mixing it directly inside webclient,
> > >> because it could make it easier to users to use mbedtls on their web
> > >> applications. But, of course, it should be nice to have an option to
> > >> compile the webclient with the mbedtls "library" support. There are
> > >> some examples of "libraries" and applications on NuttX apps, i.e.:
> > >> gpsutils/minmea/minmea.c and an application using it: examples/gps.
> > >>
> > >
> > > Yes, mbedtls is better to integrate as a library, and then any builtin
> > > or 3rd party apps can utilize it.
> > >
> >
> > I suppose this is the way you did at Xiaomi, right?
> >
> > BR,
> >
> > Alan

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: mbedtls

[Takashi Yamamoto]

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.

>
> 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.

>
> Sebastien
>

Re: FW: SPI slave interface discussion

[Xiang Xiao]

Could we provide two set interface like spi master:
struct spi_ops_s
{
  CODE uint32_t (*send)(FAR struct spi_dev_s *dev, uint32_t wd);
#ifdef CONFIG_SPI_EXCHANGE
  CODE void (*exchange)(FAR struct spi_dev_s *dev,
  FAR const void *txbuffer, FAR void *rxbuffer,
  size_t nwords);
#else
  CODE void (*sndblock)(FAR struct spi_dev_s *dev,
  FAR const void *buffer, size_t nwords);
  CODE void (*recvblock)(FAR struct spi_dev_s *dev, FAR void *buffer,
  size_t nwords);
#endif
};
send for a single word, exchange/sndblock/recvblock for a buffer. So
the new code get the better performance, but the old code still work
as before.

On Fri, May 22, 2020 at 2:16 PM Laitinen, Jukka
 wrote:
>
>
>
> Hi,
>
>
>
> *The attached patch is just for opening a discussion, please don’t merge*
>
>
>
> We used the SPI slave interfaces on stm32h7 platform, in a configuration where
>
> two stm32h7 chips were connected together with SPI bus, one in master 
> simplex-tx and one
>
> in slave simplex-rx mode.
>
>
>
> There was quite high data rate from master to slave, and the slave controller 
> & device interfaces,
>
> which are defined in include/nuttx/spi/slave.h were quite inefficient to use.
>
>
>
> Namely, we needed this kind of features to the slave interfaces:
>
> a possibility for slave controller driver to just buffer incoming data and 
> slave device driver to poll for it at certain interval
> possibility for copying larger buffers of data at one call; now each call to 
> getdata can only return 2 bytes at a time
>
>
>
> I tackled these issues by changing the spi slave interface like in the 
> attached patch. So adding a “poll” function for the controller interface and 
> modifying
>
> the data handling functions in a way that larger blocks of data can be 
> managed in one call.
>
>
>
> Obviously, this approach is incompatible with the existing SPI slave 
> controller & spi slave drivers (on samv7 platform).
>
>
>
> So the questions which arise
>
> Do you think that there is an alternative way to reach those goals using the 
> existing interface?
> Would it be reasonable to re-visit the spi slave interfaces to support high 
> data rates more efficiently?
>
>
>
> Br,
>
> Jukka
>
>

Re: mbedtls

[Alan Carvalho de Assis]

Hi Daniel,

Yes, I think an option is to create an apps/thirdparty folder to
follow with Xiang idea.

BR,

Alan

On 5/22/20, Daniel Pereira Carvalho  wrote:
> What about a new 3rd party folder?
>
> Em sex, 22 de mai de 2020 09:41, Alan Carvalho de Assis 
> escreveu:
>
>> Hi Xiang,
>>
>> On 5/22/20, Xiang Xiao  wrote:
>> sic
>> >
>> > But mbedtls can be used in more context than HTTPS/TLS like security
>> > boot, OTA and TEE, it doesn't make sense to put into netutils. A
>> > central folder(e.g. external) for 3rd party is a better choice
>> > because:
>>
>> The external folder is used for other purpose (to test user own code).
>> Not it is even in the .gitignore.
>> And since the code will be there already, it is better to keep the way
>> NuttX already to it for external application.
>>
>> > 1.New user can find what already provide by NuttX quickly before start
>> > porting
>>
>> Normally new users will look inside menuconfig before looking the
>> code, so it is not an appealing reason.
>>
>> > 2.Help PMC check LICENSE file reflect the truth
>>
>> It doesn't better since the code is not distributed inside NuttX.
>>
>> > 3.Follow other project practice
>> >
>>
>> Hmm, so I think I didn't get it correctly from start. Maybe your idea
>> is to keep the complete code inside an apps/external or
>> apps/thirdparty folder, is it?
>> If this is the idea, maybe in this case other option is to have an
>> apps-external or thirdparty repository to avoid the apps/ repository
>> becoming too big with code from external projects.
>>
>> >> > 4. how do you think about adding tls support to netutils/webclient?
>> >> >
>> >>
>> >> I think it is better to create the mbedtls as a separated "library"
>> >> (note the quotes) instead of mixing it directly inside webclient,
>> >> because it could make it easier to users to use mbedtls on their web
>> >> applications. But, of course, it should be nice to have an option to
>> >> compile the webclient with the mbedtls "library" support. There are
>> >> some examples of "libraries" and applications on NuttX apps, i.e.:
>> >> gpsutils/minmea/minmea.c and an application using it: examples/gps.
>> >>
>> >
>> > Yes, mbedtls is better to integrate as a library, and then any builtin
>> > or 3rd party apps can utilize it.
>> >
>>
>> I suppose this is the way you did at Xiaomi, right?
>>
>> BR,
>>
>> Alan
>>
>

RE: SPI slave interface discussion

[David Sidrane]

Hi Jukka,



Would you mind opening a Draft PR for this disscussion. (See the Drop down
on github [Create pull request] )



David









*From:* Laitinen, Jukka [mailto:jukka.laiti...@intel.com]
*Sent:* Thursday, May 21, 2020 11:23 PM
*To:* dev@nuttx.apache.org
*Subject:* RE: SPI slave interface discussion



Looks like the patch which I tried to attach was lost on the way. Trying
again with .txt suffix…

Re: mbedtls

[Xiang Xiao]

On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis
 wrote:
>
> Hi Xiang,
>
> On 5/22/20, Xiang Xiao  wrote:
> sic
> >
> > But mbedtls can be used in more context than HTTPS/TLS like security
> > boot, OTA and TEE, it doesn't make sense to put into netutils. A
> > central folder(e.g. external) for 3rd party is a better choice
> > because:
>
> The external folder is used for other purpose (to test user own code).
> Not it is even in the .gitignore.
> And since the code will be there already, it is better to keep the way
> NuttX already to it for external application.
>

We don't need put Makefile/Kconfig into apps/external directly. Like
Chao's suggestion, we can create a new apache-nuttx-external git to
manage the porting. People can link apps/external to
apache-nuttx-external or their own version.

> > 1.New user can find what already provide by NuttX quickly before start
> > porting
>
> Normally new users will look inside menuconfig before looking the
> code, so it is not an appealing reason.
>

Even with menuconfig, user need dig into several level to find, e.g.:
Application Configuration->Grahpics Support->Littlev Graphic Libray(LVGL)
Considering we have more than 1000 Kconfig options, the new user is
hard to find the library he/she want from Kconfig quickly.

> > 2.Help PMC check LICENSE file reflect the truth
>
> It doesn't better since the code is not distributed inside NuttX.
>
> > 3.Follow other project practice
> >
>
> Hmm, so I think I didn't get it correctly from start. Maybe your idea
> is to keep the complete code inside an apps/external or
> apps/thirdparty folder, is it?

No, just Makefile/Kconfig, but we need a system way to layout 3rd
party library if you consider how to find them quickly after we port
100+ libraries which  very likely happen after one or two years.

> If this is the idea, maybe in this case other option is to have an
> apps-external or thirdparty repository to avoid the apps/ repository
> becoming too big with code from external projects.
>

It's very important to have a common place to share the 3rd party
library support. Many user select one RTOS just because it support the
library he/she want to use in box. We need catch up here to compete
with other RTOS.

> >> > 4. how do you think about adding tls support to netutils/webclient?
> >> >
> >>
> >> I think it is better to create the mbedtls as a separated "library"
> >> (note the quotes) instead of mixing it directly inside webclient,
> >> because it could make it easier to users to use mbedtls on their web
> >> applications. But, of course, it should be nice to have an option to
> >> compile the webclient with the mbedtls "library" support. There are
> >> some examples of "libraries" and applications on NuttX apps, i.e.:
> >> gpsutils/minmea/minmea.c and an application using it: examples/gps.
> >>
> >
> > Yes, mbedtls is better to integrate as a library, and then any builtin
> > or 3rd party apps can utilize it.
> >
>
> I suppose this is the way you did at Xiaomi, right?
>
> BR,
>
> Alan

Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[Xiang Xiao]

In the pass, the stack info for IDLE thread is just used for debugging
purpose, so the priority is low, but we need boost this to high
priority since TLS(errno) depend on it now


On Fri, May 22, 2020 at 8:25 PM David Sidrane  wrote:
>
> This is super confusing to me.
>
> The todo list says.
>
> Status:  Open
>   Priority:Low.  Things are working OK the way they are.  But the
> design
>could be improved and made a little more efficient with 
> this
>change.
>
> So it sounds like no big deal. Hardfaulting on  set_errno() it is a big
> deal.
>
>
> Did we destroy active acrhs with a partial implementation and not realize
> it?

TLS(errno) implementation is fully completed, it's an arch problem not
the core OS issue.

>
> Why was this work not done on a branch and tested?
>

This work initially do on a branch and merge into master after finish.

> Where is the process? Where is the PMC agreeing on these sweeping changes?

PR follow the process, the contributor sumbit the path, PMC review the
code and approve. Here is the email:
https://lists.apache.org/thread.html/r76ac7aa434cf982acd4c7227ede7221ad7a09b9235a99c188f716199%40%3Cdev.nuttx.apache.org%3E

>
> David
>
>
>
> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Friday, May 22, 2020 4:51 AM
> To: dev@nuttx.apache.org
> Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not
> set
>
> The new implementation of set_errno require all thread(include IDLE)
> initialize the stack related fields in tcb_s correctly. But many
> chipset forget to setup them for IDLE thread. TODO contain an item
> described this:
>   Task:IDLE THREAD TCB SETUP
>   Description: There are issues with setting IDLE thread stacks:
>
>1. One problem is stack-related data in the IDLE threads TCB.
>   A solution might be to standardize the use of
> g_idle_topstack.
>   That you could add initialization like this in nx_start:
>
>   @@ -344,6 +347,11 @@ void nx_start(void)
>  g_idleargv[1]  = NULL;
>  g_idletcb.argv = g_idleargv;
>
>   +  /* Set the IDLE task stack size */
>   +
>   +  g_idletcb.cmn.adj_stack_size =
> CONFIG_IDLETHREAD_STACKSIZE;
>   +  g_idletcb.cmn.stack_alloc_ptr = (void
> *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE);
>   +
>  /* Then add the idle task's TCB to the head of
> the ready to run list */
>
>  dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR
> dq_queue_t *)_readytorun);
>
>   The g_idle_topstack variable is available for almost
> all architectures:
>
>   $ find . -name *.h | xargs grep g_idle_top
>   ./arm/src/common/up_internal.h:EXTERN const uint32_t
> g_idle_topstack;
>   ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack;
>   ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack;
>   ./hc/src/common/up_internal.h:extern uint16_t
> g_idle_topstack;
>   ./mips/src/common/up_internal.h:extern uint32_t
> g_idle_topstack;
>   ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack;
>   ./renesas/src/common/up_internal.h:extern uint32_t
> g_idle_topstack;
>   ./renesas/src/m16c/chip.h:extern uint32_t
> g_idle_topstack; /* Start of the heap */
>   ./risc-v/src/common/up_internal.h:EXTERN uint32_t
> g_idle_topstack;
>   ./x86/src/common/up_internal.h:extern uint32_t
> g_idle_topstack;
>
>   That omits these architectures: sh1, sim, xtensa, z16,
> z80,
>   ez80, and z8.  All would have to support this common
>   global variable.
>
>   Also, the stack itself may be 8-, 16-, or 32-bits wide,
>   depending upon the architecture and do have differing
>   alignment requirements.
>
>2. Another problem is colorizing that stack to use with
>  stack usage monitoring logic.  There is logic in some
>  start functions to do this in a function called
> go_nx_start.
>  It is available in these architectures:
>
>  ./arm/src/efm32/efm32_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/kinetis/kinetis_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/sam34/sam_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/samv7/sam_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/stm32/stm32_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  

Re: mbedtls

[Alan Carvalho de Assis]

Hi Greg,

On 5/22/20, Gregory Nutt  wrote:
>
>>> 2. if yes, which repository is appropriate? apps?
>> Yes, apps of course.
>>
>>> 3. if apps, in which directory? netutils? crypto?
>> Although crypto could be an option (but it doesn't exist inside apps/
>> yet), I think netutils/ is a better option.
>
> I think we should use a new apps/crypto.  There will be other userspace
> crypto support in the future, I am sure.  Perhaps, Intel's TinyCrypt
> cryptographic library, for example.  I don't think it all belows under
> netutils, does it?
>

Yes, I was only focusing on mbedtls for HTTPS application, but as
Xiang pointed it coud be used for other applications. So yes, it is
better to be inside apps/crypto.

BR,

Alan

Re: mbedtls

[Daniel Pereira Carvalho]

What about a new 3rd party folder?

Em sex, 22 de mai de 2020 09:41, Alan Carvalho de Assis 
escreveu:

> Hi Xiang,
>
> On 5/22/20, Xiang Xiao  wrote:
> sic
> >
> > But mbedtls can be used in more context than HTTPS/TLS like security
> > boot, OTA and TEE, it doesn't make sense to put into netutils. A
> > central folder(e.g. external) for 3rd party is a better choice
> > because:
>
> The external folder is used for other purpose (to test user own code).
> Not it is even in the .gitignore.
> And since the code will be there already, it is better to keep the way
> NuttX already to it for external application.
>
> > 1.New user can find what already provide by NuttX quickly before start
> > porting
>
> Normally new users will look inside menuconfig before looking the
> code, so it is not an appealing reason.
>
> > 2.Help PMC check LICENSE file reflect the truth
>
> It doesn't better since the code is not distributed inside NuttX.
>
> > 3.Follow other project practice
> >
>
> Hmm, so I think I didn't get it correctly from start. Maybe your idea
> is to keep the complete code inside an apps/external or
> apps/thirdparty folder, is it?
> If this is the idea, maybe in this case other option is to have an
> apps-external or thirdparty repository to avoid the apps/ repository
> becoming too big with code from external projects.
>
> >> > 4. how do you think about adding tls support to netutils/webclient?
> >> >
> >>
> >> I think it is better to create the mbedtls as a separated "library"
> >> (note the quotes) instead of mixing it directly inside webclient,
> >> because it could make it easier to users to use mbedtls on their web
> >> applications. But, of course, it should be nice to have an option to
> >> compile the webclient with the mbedtls "library" support. There are
> >> some examples of "libraries" and applications on NuttX apps, i.e.:
> >> gpsutils/minmea/minmea.c and an application using it: examples/gps.
> >>
> >
> > Yes, mbedtls is better to integrate as a library, and then any builtin
> > or 3rd party apps can utilize it.
> >
>
> I suppose this is the way you did at Xiaomi, right?
>
> BR,
>
> Alan
>

RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[Schock, Johannes - NIVUS GmbH]

I implemented the change in nx_start.c with a quick and dirty

extern const uintptr_t g_idle_topstack;

just to see if it's working. It works.

But since nx_start.c is not architecture specific and (according to the TODO) 
g_idle_topstack is not available in all architectures, this is no solution.

> But many chipset forget to setup them for IDLE thread.

If I understand correctly all(?) chipsets use nx_start, so the idle task tls 
seems to be never initialized.

What about changing the call to nx_start(idle_stack_ptr, idle_stack_size)?

Regards, Johannes

> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Friday, May 22, 2020 1:51 PM
> To: dev@nuttx.apache.org
> Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED
> not set
> 
> The new implementation of set_errno require all thread(include IDLE)
> initialize the stack related fields in tcb_s correctly. But many
> chipset forget to setup them for IDLE thread. TODO contain an item
> described this:
>   Task:IDLE THREAD TCB SETUP
>   Description: There are issues with setting IDLE thread stacks:
> 
>1. One problem is stack-related data in the IDLE threads TCB.
>   A solution might be to standardize the use of 
> g_idle_topstack.
>   That you could add initialization like this in nx_start:
> 
>   @@ -344,6 +347,11 @@ void nx_start(void)
>  g_idleargv[1]  = NULL;
>  g_idletcb.argv = g_idleargv;
> 
>   +  /* Set the IDLE task stack size */
>   +
>   +  g_idletcb.cmn.adj_stack_size = 
> CONFIG_IDLETHREAD_STACKSIZE;
>   +  g_idletcb.cmn.stack_alloc_ptr = (void
> *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE);
>   +
>  /* Then add the idle task's TCB to the head of
> the ready to run list */
> 
>  dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR
> dq_queue_t *)_readytorun);
> 
>   The g_idle_topstack variable is available for almost
> all architectures:
> 
>   $ find . -name *.h | xargs grep g_idle_top
>   ./arm/src/common/up_internal.h:EXTERN const uint32_t
> g_idle_topstack;
>   ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack;
>   ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack;
>   ./hc/src/common/up_internal.h:extern uint16_t 
> g_idle_topstack;
>   ./mips/src/common/up_internal.h:extern uint32_t
> g_idle_topstack;
>   ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack;
>   ./renesas/src/common/up_internal.h:extern uint32_t
> g_idle_topstack;
>   ./renesas/src/m16c/chip.h:extern uint32_t
> g_idle_topstack; /* Start of the heap */
>   ./risc-v/src/common/up_internal.h:EXTERN uint32_t
> g_idle_topstack;
>   ./x86/src/common/up_internal.h:extern uint32_t
> g_idle_topstack;
> 
>   That omits these architectures: sh1, sim, xtensa, z16, z80,
>   ez80, and z8.  All would have to support this common
>   global variable.
> 
>   Also, the stack itself may be 8-, 16-, or 32-bits wide,
>   depending upon the architecture and do have differing
>   alignment requirements.
> 
>2. Another problem is colorizing that stack to use with
>  stack usage monitoring logic.  There is logic in some
>  start functions to do this in a function called go_nx_start.
>  It is available in these architectures:
> 
>  ./arm/src/efm32/efm32_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/kinetis/kinetis_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/sam34/sam_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/samv7/sam_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/stm32/stm32_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/stm32f7/stm32_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/stm32l4/stm32l4_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/tms570/tms570_boot.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
>  ./arm/src/xmc4/xmc4_start.c:static void
> go_nx_start(void *pv, unsigned int nbytes)
> So, it become a block issue and need immedately fix now.
> 
> On Fri, May 22, 2020 at 7:40 PM Schock, Johannes - NIVUS GmbH
>  wrote:
> >
> > Hello,
> > I think there's a problem with set_errno() in nx_start(), when
> CONFIG_TLS_ALIGNED is not set:
> > I disabled SERIAL_CONSOLE and 

Re: mbedtls

[Alan Carvalho de Assis]

Hi Xiang,

On 5/22/20, Xiang Xiao  wrote:
sic
>
> But mbedtls can be used in more context than HTTPS/TLS like security
> boot, OTA and TEE, it doesn't make sense to put into netutils. A
> central folder(e.g. external) for 3rd party is a better choice
> because:

The external folder is used for other purpose (to test user own code).
Not it is even in the .gitignore.
And since the code will be there already, it is better to keep the way
NuttX already to it for external application.

> 1.New user can find what already provide by NuttX quickly before start
> porting

Normally new users will look inside menuconfig before looking the
code, so it is not an appealing reason.

> 2.Help PMC check LICENSE file reflect the truth

It doesn't better since the code is not distributed inside NuttX.

> 3.Follow other project practice
>

Hmm, so I think I didn't get it correctly from start. Maybe your idea
is to keep the complete code inside an apps/external or
apps/thirdparty folder, is it?
If this is the idea, maybe in this case other option is to have an
apps-external or thirdparty repository to avoid the apps/ repository
becoming too big with code from external projects.

>> > 4. how do you think about adding tls support to netutils/webclient?
>> >
>>
>> I think it is better to create the mbedtls as a separated "library"
>> (note the quotes) instead of mixing it directly inside webclient,
>> because it could make it easier to users to use mbedtls on their web
>> applications. But, of course, it should be nice to have an option to
>> compile the webclient with the mbedtls "library" support. There are
>> some examples of "libraries" and applications on NuttX apps, i.e.:
>> gpsutils/minmea/minmea.c and an application using it: examples/gps.
>>
>
> Yes, mbedtls is better to integrate as a library, and then any builtin
> or 3rd party apps can utilize it.
>

I suppose this is the way you did at Xiaomi, right?

BR,

Alan

RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[David Sidrane]

This is super confusing to me.

The todo list says.

Status:  Open
  Priority:Low.  Things are working OK the way they are.  But the
design
   could be improved and made a little more efficient with this
   change.

So it sounds like no big deal. Hardfaulting on  set_errno() it is a big
deal.


Did we destroy active acrhs with a partial implementation and not realize
it?

Why was this work not done on a branch and tested?

Where is the process? Where is the PMC agreeing on these sweeping changes?

David



-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Friday, May 22, 2020 4:51 AM
To: dev@nuttx.apache.org
Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not
set

The new implementation of set_errno require all thread(include IDLE)
initialize the stack related fields in tcb_s correctly. But many
chipset forget to setup them for IDLE thread. TODO contain an item
described this:
  Task:IDLE THREAD TCB SETUP
  Description: There are issues with setting IDLE thread stacks:

   1. One problem is stack-related data in the IDLE threads TCB.
  A solution might be to standardize the use of
g_idle_topstack.
  That you could add initialization like this in nx_start:

  @@ -344,6 +347,11 @@ void nx_start(void)
 g_idleargv[1]  = NULL;
 g_idletcb.argv = g_idleargv;

  +  /* Set the IDLE task stack size */
  +
  +  g_idletcb.cmn.adj_stack_size =
CONFIG_IDLETHREAD_STACKSIZE;
  +  g_idletcb.cmn.stack_alloc_ptr = (void
*)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE);
  +
 /* Then add the idle task's TCB to the head of
the ready to run list */

 dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR
dq_queue_t *)_readytorun);

  The g_idle_topstack variable is available for almost
all architectures:

  $ find . -name *.h | xargs grep g_idle_top
  ./arm/src/common/up_internal.h:EXTERN const uint32_t
g_idle_topstack;
  ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack;
  ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack;
  ./hc/src/common/up_internal.h:extern uint16_t
g_idle_topstack;
  ./mips/src/common/up_internal.h:extern uint32_t
g_idle_topstack;
  ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack;
  ./renesas/src/common/up_internal.h:extern uint32_t
g_idle_topstack;
  ./renesas/src/m16c/chip.h:extern uint32_t
g_idle_topstack; /* Start of the heap */
  ./risc-v/src/common/up_internal.h:EXTERN uint32_t
g_idle_topstack;
  ./x86/src/common/up_internal.h:extern uint32_t
g_idle_topstack;

  That omits these architectures: sh1, sim, xtensa, z16,
z80,
  ez80, and z8.  All would have to support this common
  global variable.

  Also, the stack itself may be 8-, 16-, or 32-bits wide,
  depending upon the architecture and do have differing
  alignment requirements.

   2. Another problem is colorizing that stack to use with
 stack usage monitoring logic.  There is logic in some
 start functions to do this in a function called
go_nx_start.
 It is available in these architectures:

 ./arm/src/efm32/efm32_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/kinetis/kinetis_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/sam34/sam_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/samv7/sam_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/stm32/stm32_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/stm32f7/stm32_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/stm32l4/stm32l4_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/tms570/tms570_boot.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/xmc4/xmc4_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
So, it become a block issue and need immedately fix now.

On Fri, May 22, 2020 at 7:40 PM Schock, Johannes - NIVUS GmbH
 wrote:
>
> Hello,
> I think there's a problem with set_errno() in nx_start(), when
> CONFIG_TLS_ALIGNED is not set:
> I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test
> CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a
> call of set_errno().
> But since tls_get_info() returns NULL pointer for 

Re: mbedtls

[Xiang Xiao]

On Fri, May 22, 2020 at 7:51 PM Alan Carvalho de Assis
 wrote:
>
> Hi Takashi-san,
>
> On 5/22/20, Takashi Yamamoto  wrote:
> > 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?
>
> Yes, mbedtls should be a great contribution.
> Many users want to use NuttX with HTTPS/TLS support and will spend
> time doing this port themselves.
>
> > 2. if yes, which repository is appropriate? apps?
>
> Yes, apps of course.
>
> > 3. if apps, in which directory? netutils? crypto?
>
> Although crypto could be an option (but it doesn't exist inside apps/
> yet), I think netutils/ is a better option.
>

But mbedtls can be used in more context than HTTPS/TLS like security
boot, OTA and TEE, it doesn't make sense to put into netutils. A
central folder(e.g. external) for 3rd party is a better choice
because:
1.New user can find what already provide by NuttX quickly before start porting
2.Help PMC check LICENSE file reflect the truth
3.Follow other project practice

> > 4. how do you think about adding tls support to netutils/webclient?
> >
>
> I think it is better to create the mbedtls as a separated "library"
> (note the quotes) instead of mixing it directly inside webclient,
> because it could make it easier to users to use mbedtls on their web
> applications. But, of course, it should be nice to have an option to
> compile the webclient with the mbedtls "library" support. There are
> some examples of "libraries" and applications on NuttX apps, i.e.:
> gpsutils/minmea/minmea.c and an application using it: examples/gps.
>

Yes, mbedtls is better to integrate as a library, and then any builtin
or 3rd party apps can utilize it.

> BR,
>
> Alan

Re: mbedtls

[Xiang Xiao]

BTW, Xiaomi already port many 3rd party library(include mbedtls) and
can share the result to community to avoid the duplicated work.

On Fri, May 22, 2020 at 7:51 PM Alan Carvalho de Assis
 wrote:
>
> Hi Takashi-san,
>
> On 5/22/20, Takashi Yamamoto  wrote:
> > 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?
>
> Yes, mbedtls should be a great contribution.
> Many users want to use NuttX with HTTPS/TLS support and will spend
> time doing this port themselves.
>
> > 2. if yes, which repository is appropriate? apps?
>
> Yes, apps of course.
>
> > 3. if apps, in which directory? netutils? crypto?
>
> Although crypto could be an option (but it doesn't exist inside apps/
> yet), I think netutils/ is a better option.
>
> > 4. how do you think about adding tls support to netutils/webclient?
> >
>
> I think it is better to create the mbedtls as a separated "library"
> (note the quotes) instead of mixing it directly inside webclient,
> because it could make it easier to users to use mbedtls on their web
> applications. But, of course, it should be nice to have an option to
> compile the webclient with the mbedtls "library" support. There are
> some examples of "libraries" and applications on NuttX apps, i.e.:
> gpsutils/minmea/minmea.c and an application using it: examples/gps.
>
> BR,
>
> Alan

Re: mbedtls

[Alan Carvalho de Assis]

Hi Takashi-san,

On 5/22/20, Takashi Yamamoto  wrote:
> 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?

Yes, mbedtls should be a great contribution.
Many users want to use NuttX with HTTPS/TLS support and will spend
time doing this port themselves.

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

Yes, apps of course.

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

Although crypto could be an option (but it doesn't exist inside apps/
yet), I think netutils/ is a better option.

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

I think it is better to create the mbedtls as a separated "library"
(note the quotes) instead of mixing it directly inside webclient,
because it could make it easier to users to use mbedtls on their web
applications. But, of course, it should be nice to have an option to
compile the webclient with the mbedtls "library" support. There are
some examples of "libraries" and applications on NuttX apps, i.e.:
gpsutils/minmea/minmea.c and an application using it: examples/gps.

BR,

Alan

Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[Xiang Xiao]

The new implementation of set_errno require all thread(include IDLE)
initialize the stack related fields in tcb_s correctly. But many
chipset forget to setup them for IDLE thread. TODO contain an item
described this:
  Task:IDLE THREAD TCB SETUP
  Description: There are issues with setting IDLE thread stacks:

   1. One problem is stack-related data in the IDLE threads TCB.
  A solution might be to standardize the use of g_idle_topstack.
  That you could add initialization like this in nx_start:

  @@ -344,6 +347,11 @@ void nx_start(void)
 g_idleargv[1]  = NULL;
 g_idletcb.argv = g_idleargv;

  +  /* Set the IDLE task stack size */
  +
  +  g_idletcb.cmn.adj_stack_size = CONFIG_IDLETHREAD_STACKSIZE;
  +  g_idletcb.cmn.stack_alloc_ptr = (void
*)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE);
  +
 /* Then add the idle task's TCB to the head of
the ready to run list */

 dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR
dq_queue_t *)_readytorun);

  The g_idle_topstack variable is available for almost
all architectures:

  $ find . -name *.h | xargs grep g_idle_top
  ./arm/src/common/up_internal.h:EXTERN const uint32_t
g_idle_topstack;
  ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack;
  ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack;
  ./hc/src/common/up_internal.h:extern uint16_t g_idle_topstack;
  ./mips/src/common/up_internal.h:extern uint32_t
g_idle_topstack;
  ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack;
  ./renesas/src/common/up_internal.h:extern uint32_t
g_idle_topstack;
  ./renesas/src/m16c/chip.h:extern uint32_t
g_idle_topstack; /* Start of the heap */
  ./risc-v/src/common/up_internal.h:EXTERN uint32_t
g_idle_topstack;
  ./x86/src/common/up_internal.h:extern uint32_t
g_idle_topstack;

  That omits these architectures: sh1, sim, xtensa, z16, z80,
  ez80, and z8.  All would have to support this common
  global variable.

  Also, the stack itself may be 8-, 16-, or 32-bits wide,
  depending upon the architecture and do have differing
  alignment requirements.

   2. Another problem is colorizing that stack to use with
 stack usage monitoring logic.  There is logic in some
 start functions to do this in a function called go_nx_start.
 It is available in these architectures:

 ./arm/src/efm32/efm32_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/kinetis/kinetis_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/sam34/sam_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/samv7/sam_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/stm32/stm32_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/stm32f7/stm32_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/stm32l4/stm32l4_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/tms570/tms570_boot.c:static void
go_nx_start(void *pv, unsigned int nbytes)
 ./arm/src/xmc4/xmc4_start.c:static void
go_nx_start(void *pv, unsigned int nbytes)
So, it become a block issue and need immedately fix now.

On Fri, May 22, 2020 at 7:40 PM Schock, Johannes - NIVUS GmbH
 wrote:
>
> Hello,
> I think there's a problem with set_errno() in nx_start(), when 
> CONFIG_TLS_ALIGNED is not set:
> I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test 
> CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a 
> call of set_errno().
> But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board 
> goes into hardfault.
> For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer from 
> arm_getsp() which accesses the stack pointer directly.
> I think thread local storage for nx_start() should be handled differently, or 
> the stack_alloc_ptr should be set to a sane value.
> I attach my config for reference, perhaps I'm missing something.
>
> Regards, Johannes
>
>

RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[Schock, Johannes - NIVUS GmbH]

Another try with ".txt" extension.

> -Original Message-
> From: Schock, Johannes - NIVUS GmbH
> [mailto:johannes.sch...@nivus.com]
> Sent: Friday, May 22, 2020 1:40 PM
> To: 'dev@nuttx.apache.org'
> Subject: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not
> set
> 
> Hello,
> I think there's a problem with set_errno() in nx_start(), when
> CONFIG_TLS_ALIGNED is not set:
> I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test
> CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads
> to a call of set_errno().
> But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board
> goes into hardfault.
> For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer
> from arm_getsp() which accesses the stack pointer directly.
> I think thread local storage for nx_start() should be handled differently, or
> the stack_alloc_ptr should be set to a sane value.
> I attach my config for reference, perhaps I'm missing something.
> 
> Regards, Johannes
> 

#
# Automatically generated file; DO NOT EDIT.
# Nuttx/x86_64 Configuration
#

#
# Build Setup
#
# CONFIG_EXPERIMENTAL is not set
# CONFIG_DEFAULT_SMALL is not set
CONFIG_DEFAULT_TASK_STACKSIZE=4096
CONFIG_HOST_LINUX=y
# CONFIG_HOST_MACOS is not set
# CONFIG_HOST_WINDOWS is not set
# CONFIG_HOST_OTHER is not set

#
# Build Configuration
#
CONFIG_APPS_DIR="../apps"
CONFIG_BUILD_FLAT=y
# CONFIG_BUILD_2PASS is not set

#
# Binary Output Formats
#
CONFIG_INTELHEX_BINARY=y
# CONFIG_MOTOROLA_SREC is not set
CONFIG_RAW_BINARY=y
# CONFIG_UBOOT_UIMAGE is not set
# CONFIG_DFU_BINARY is not set

#
# Customize Header Files
#
# CONFIG_ARCH_HAVE_STDINT_H is not set
# CONFIG_ARCH_HAVE_STDBOOL_H is not set
# CONFIG_ARCH_HAVE_MATH_H is not set
# CONFIG_ARCH_FLOAT_H is not set
CONFIG_ARCH_HAVE_STDARG_H=y
# CONFIG_ARCH_STDARG_H is not set
CONFIG_ARCH_HAVE_SETJMP=y
# CONFIG_ARCH_SETJMP_H is not set
# CONFIG_ARCH_DEBUG_H is not set

#
# Debug Options
#
CONFIG_DEBUG_ALERT=y
CONFIG_DEBUG_FEATURES=y

#
# Debug SYSLOG Output Controls
#
# CONFIG_DEBUG_ERROR is not set
# CONFIG_DEBUG_ASSERTIONS is not set

#
# Subsystem Debug Options
#
# CONFIG_DEBUG_BINFMT is not set
# CONFIG_DEBUG_FS is not set
# CONFIG_DEBUG_GRAPHICS is not set
# CONFIG_DEBUG_LIB is not set
# CONFIG_DEBUG_MM is not set
# CONFIG_DEBUG_POWER is not set
# CONFIG_DEBUG_SCHED is not set

#
# OS Function Debug Options
#
# CONFIG_DEBUG_IRQ is not set

#
# Driver Debug Options
#
# CONFIG_DEBUG_LEDS is not set
# CONFIG_DEBUG_GPIO is not set
# CONFIG_DEBUG_MEMCARD is not set
# CONFIG_DEBUG_SPI is not set
# CONFIG_DEBUG_TIMER is not set
# CONFIG_DEBUG_USB is not set
CONFIG_ARCH_HAVE_STACKCHECK=y
# CONFIG_STACK_COLORATION is not set
# CONFIG_ARCH_HAVE_HEAPCHECK is not set
CONFIG_DEBUG_SYMBOLS=y
CONFIG_ARCH_HAVE_CUSTOMOPT=y
CONFIG_DEBUG_NOOPT=y
# CONFIG_DEBUG_CUSTOMOPT is not set
# CONFIG_DEBUG_FULLOPT is not set

#
# System Type
#
CONFIG_ARCH_ARM=y
# CONFIG_ARCH_AVR is not set
# CONFIG_ARCH_HC is not set
# CONFIG_ARCH_MIPS is not set
# CONFIG_ARCH_MISOC is not set
# CONFIG_ARCH_RENESAS is not set
# CONFIG_ARCH_RISCV is not set
# CONFIG_ARCH_SIM is not set
# CONFIG_ARCH_X86 is not set
# CONFIG_ARCH_X86_64 is not set
# CONFIG_ARCH_XTENSA is not set
# CONFIG_ARCH_Z16 is not set
# CONFIG_ARCH_Z80 is not set
# CONFIG_ARCH_OR1K is not set
CONFIG_ARCH="arm"

#
# ARM Options
#
# CONFIG_ARCH_CHIP_A1X is not set
# CONFIG_ARCH_CHIP_AM335X is not set
# CONFIG_ARCH_CHIP_C5471 is not set
# CONFIG_ARCH_CHIP_DM320 is not set
# CONFIG_ARCH_CHIP_EFM32 is not set
# CONFIG_ARCH_CHIP_IMX1 is not set
# CONFIG_ARCH_CHIP_IMX6 is not set
# CONFIG_ARCH_CHIP_IMXRT is not set
CONFIG_ARCH_CHIP_KINETIS=y
# CONFIG_ARCH_CHIP_KL is not set
# CONFIG_ARCH_CHIP_LC823450 is not set
# CONFIG_ARCH_CHIP_LM is not set
# CONFIG_ARCH_CHIP_LPC17XX_40XX is not set
# CONFIG_ARCH_CHIP_LPC214X is not set
# CONFIG_ARCH_CHIP_LPC2378 is not set
# CONFIG_ARCH_CHIP_LPC31XX is not set
# CONFIG_ARCH_CHIP_LPC43XX is not set
# CONFIG_ARCH_CHIP_LPC54XX is not set
# CONFIG_ARCH_CHIP_MAX326XX is not set
# CONFIG_ARCH_CHIP_MOXART is not set
# CONFIG_ARCH_CHIP_NRF52 is not set
# CONFIG_ARCH_CHIP_NUC1XX is not set
# CONFIG_ARCH_CHIP_S32K1XX is not set
# CONFIG_ARCH_CHIP_SAMA5 is not set
# CONFIG_ARCH_CHIP_SAMD2X is not set
# CONFIG_ARCH_CHIP_SAML2X is not set
# CONFIG_ARCH_CHIP_SAMD5X is not set
# CONFIG_ARCH_CHIP_SAME5X is not set
# CONFIG_ARCH_CHIP_SAM34 is not set
# CONFIG_ARCH_CHIP_SAMV7 is not set
# CONFIG_ARCH_CHIP_STM32 is not set
# CONFIG_ARCH_CHIP_STM32F0 is not set
# CONFIG_ARCH_CHIP_STM32L0 is not set
# CONFIG_ARCH_CHIP_STM32G0 is not set
# CONFIG_ARCH_CHIP_STM32F7 is not set
# CONFIG_ARCH_CHIP_STM32H7 is not set
# CONFIG_ARCH_CHIP_STM32L4 is not set
# CONFIG_ARCH_CHIP_STR71X is not set
# CONFIG_ARCH_CHIP_TMS570 is not set
# CONFIG_ARCH_CHIP_TIVA is not set
# CONFIG_ARCH_CHIP_XMC4 is not set
# CONFIG_ARCH_CHIP_CXD56XX is not set
# CONFIG_ARCH_ARM7TDMI is not set
# CONFIG_ARCH_ARM920T is not set
# 

Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set

[Schock, Johannes - NIVUS GmbH]

Hello,
I think there's a problem with set_errno() in nx_start(), when 
CONFIG_TLS_ALIGNED is not set:
I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test 
CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a call 
of set_errno().
But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board 
goes into hardfault.
For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer from 
arm_getsp() which accesses the stack pointer directly.
I think thread local storage for nx_start() should be handled differently, or 
the stack_alloc_ptr should be set to a sane value.
I attach my config for reference, perhaps I'm missing something.

Regards, Johannes

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

RE: NuttX on the IMXRT1060-EVK

[Thomas Axelsson]

Hi Erdem,

I'm not actively developing using IMXRT at the moment, but one thing that lead 
to problems with debugging was NuttX entering the ARM low-power mode Wait For 
Interrupt.

The quick fix is to comment out the following line in 
arch/arm/src/imxrt/imxrt_idle.c:

asm("WFI");


Maybe it will help you.

I don't have the user guides at hand, but I suspect J46 and J47, that you 
mention, are the jumpers for bypassing the on-board debugger - so you have 
overcome that hurdle.

BR
Thomas

-Original Message-
From: Erdem MEYDANLI  
Sent: den 19 maj 2020 14:41
To: dev@nuttx.apache.org
Subject: NuttX on the IMXRT1060-EVK

Hello,

I've been playing with the IMX1060-EVK board for some time. I wanted to test it 
by running NuttX on it with networking support enabled.

./tools/configure.sh -l imxrt1060-evk/netnsh

The configurations below have been enabled, referring to the explanation in the 
README file.

CONFIG_IMXRT_ENET_PHYINIT=y
CONFIG_IMXRT_GPIO1_0_15_IRQ=y
CONFIG_IMXRT_GPIO_IRQ=y
CONFIG_NETDEV_IOCTL=y
CONFIG_NETDEV_PHY_IOCTL=y
CONFIG_NSH_NETINIT_MONITOR=y
CONFIG_NSH_NETINIT_RETRYMSEC=2000
CONFIG_NSH_NETINIT_SIGNO=18
CONFIG_NSH_NETINIT_THREAD=y
CONFIG_NSH_NETINIT_THREAD_PRIORITY=80
CONFIG_NSH_NETINIT_THREAD_STACKSIZE=1568

In addition to the items above, I also changed the IPv4 address.

CONFIG_NETINIT_IPADDR=0xc0a8b2fa
CONFIG_NETINIT_DRIPADDR=0xc0a8b201

Then, I built the code. Flashed it (via J-Link). The NSH console appears and 
works well. Here is the output of 'ifconfig':

eth0Link encap:Ethernet HWaddr 00:e0:de:ad:be:ef at DOWN
inet addr:192.168.178.250 DRaddr:192.168.178.1 Mask:255.255.255.0
inet6 addr: fc00::2/112
inet6 DRaddr: fc00::1/112

RX: Received Fragment Errors
  
IPv4 IPv6 ARP  Dropped
   
TX: Queued   Sent Errors   Timeouts
   
Total Errors: 


The addresses seem fine, but the eth0 interface is DOWN. To bring up eth0, I 
use ifup eth0. But this time, the NSH becomes irresponsive, and I have to 
perform hard-reset.

I doubted that there was a problem with the hardware. Therefore, I also tried 
with the examples (i.e., lwip_httpsrv_freertos) of the MCUXpresso IDE, and 
everything worked as expected. I can do step by step debugging with the help of 
J-Link and the IDE.

Why I also mentioned J-Link? Because I, too, would like to debug via J-Link to 
be able to understand the issue. However, when I try to debug NuttX via J-Link, 
the adapter gets disconnected, an I get some weird errors. This is another 
story though... (Optimizations suppressed. Debug symbols enabled.)

I spent too much time on it but still haven't come to a solution. Any hints and 
tips from the experts on IMXRT platform would be appreciated.

(Here is my setup: Ubuntu 18, Segger J-Link Base, the board is powered through 
USB. J46 and J47 are removed. SW7 OFF-OFF-ON-OFF -> QSPI flash is
enabled.)

Best regards,
Erdem

Re: mbedtls

[Xiang Xiao]

On Fri, May 22, 2020 at 4:12 PM Takashi Yamamoto
 wrote:
>
> On Fri, May 22, 2020 at 4:52 PM Sebastien Lorquet  
> wrote:
> >
> > 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.
> >

Yes, the transition phase make chaos, but the first Apache NuttX
official release(9.0.0) annaunce at May 15th:
https://lists.apache.org/thread.html/rf7678c2a47c71ba9acb2c4a5392cea75d936a44f32d49f4f287b4aa9%40%3Cdev.nuttx.apache.org%3E
So it's time to come back and try/improve the Apache workflow.

> > 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.
>
> i'm not suggesting to include the whole mbedtls code in nuttx repo.
> just a Makefile/Kconfig glue.
>

Yes, the download may be the only method to support the 3rd party code
after we join Apache Foundation even the package has the compatible
license or stop the active development since Apache Foundation has the
more strict license requirement.


> > > 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.
>
> can you explain what's "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.
>
> by "crypto", i meant a new directory.
> i guess you are talking about some project i'm not aware of,
> which happens to use the same directory name. right?
>

How about we put all 3rd party library to external folder like Android
or TizenRT:
https://android.googlesource.com/platform/external/
https://github.com/Samsung/TizenRT/tree/master/external
This approach make we can identify the 3rd party code and license more quickly.

> >
> > > 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.
>
> do you mean openssl BIO and mbedtls mbedtls_ssl_read/mbedtls_ssl_write/etc?
> (i don't know gnutls api)
>
> >
> > 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
> >
> >

答复: [External Mail]mbedtls

[安超]

Hi,

I think this is a general 3rd-party package management issue, anyone who uses 
nuttx will encounter a similar situation.

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

Neglect the license issues, I think any excellent open source library will be 
accepted by nuttx,
which is not only for nuttx kernel,  also for all developer using nuttx

>> 2. if yes, which repository is appropriate? apps?
>> 3. if apps, in which directory? netutils? crypto?
>> 4. how do you think about adding tls support to netutils/webclient?

From the experience of XiaoMi, "apps/external" is a good choice.
"external/" is not included in the git repository of apps,  just only a dummy 
symbol link:

archer@c :~/code/m1/apps$ ls -l external
lrwxrwxrwx 1 archer archer 11 Mar 2 10:17 external -> ../external

This repository have the same directory level as nuttx and apps.
It's a real git repository but not completely repository, "external/" only 
stores "kconfig/Makefile/Make.defs":

archer@c :~/code/m1/external$ tree -L 2
.

├── Make.defs // Wildcard subdirectories
├── Makefile// include $(APPDIR)/ Directory.mk , traversing 
subdirectories
├── ...
├── bluetooth
├── btstack
├── curl
├── ffmpeg
├── iperf3
├── libcoap
├── mbed-crypto
│   ├── Kconfig   // all 3rd-party projects only contain "kconfig, 
Make.defs and Makefile"
│   ├── Make.defs
│   └── Makefile  // the package will be downloaded dynamically from 
Makefile
├── mbedtls
│   ├── Kconfig
│   ├── Make.defs
│   └── Makefile
├── mosquitto
├── nghttp2
├── protobuf-c
├── tinycrypt
├── unqlite
├── zlib
├── ...

In the external directory, we need to create the directory named as project,
and then complete the Makefile/Make.defs/Kconfig porting and configuration,
all of the 3rd-party projects in nuttx can follow this way.
This will greatly reduce the repeated porting work of different developers.

Assuredly, it is necessary to create a new "external" project if we really need 
this strategy?

apache/incubator-external
apache/incubator-nuttx
apache/incubator-apps

BRs,


发件人: Takashi Yamamoto 
发送时间: 2020年5月22日 15:41
收件人: dev@nuttx.apache.org
主题: [External Mail]mbedtls

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?
2. if yes, which repository is appropriate? apps?
3. if apps, in which directory? netutils? crypto?
4. how do you think about adding tls support to netutils/webclient?
#/**本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
 This e-mail and its attachments contain confidential information from XIAOMI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!**/#

Re: mbedtls

[Takashi Yamamoto]

On Fri, May 22, 2020 at 4:52 PM Sebastien Lorquet  wrote:
>
> 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.

i'm not suggesting to include the whole mbedtls code in nuttx repo.
just a Makefile/Kconfig glue.

> > 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.

can you explain what's "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.

by "crypto", i meant a new directory.
i guess you are talking about some project i'm not aware of,
which happens to use the same directory name. right?

>
> > 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.

do you mean openssl BIO and mbedtls mbedtls_ssl_read/mbedtls_ssl_write/etc?
(i don't know gnutls api)

>
> 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,

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

mbedtls

[Takashi Yamamoto]

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?
2. if yes, which repository is appropriate? apps?
3. if apps, in which directory? netutils? crypto?
4. how do you think about adding tls support to netutils/webclient?

Jenkins build is back to normal : NuttX-Nightly-Build #167

[Apache Jenkins Server]

See 

RE: SPI slave interface discussion

[Laitinen, Jukka]

Looks like the patch which I tried to attach was lost on the way. Trying again 
with .txt suffix...


From 292153fc368976c8abbd65fdd1b48b3bbc93e998 Mon Sep 17 00:00:00 2001
From: Jukka Laitinen 
Date: Fri, 20 Sep 2019 09:17:10 +0300
Subject: [PATCH] Update to SPI slave intefaces

Make it possible to enqueue and receive full buffers of data with
single call, to avoid call overhead when sending / receiving large amounts
of data.

Also make it possible for the slave device to leave received data in the
controller receive buffers and retrieve it from there by polling

Signed-off-by: Jukka Laitinen 
---
 arch/arm/src/samv7/sam_spi_slave.c |  6 ++--
 include/nuttx/spi/slave.h  | 56 ++
 2 files changed, 45 insertions(+), 17 deletions(-)

diff --git a/arch/arm/src/samv7/sam_spi_slave.c 
b/arch/arm/src/samv7/sam_spi_slave.c
index 9845ce83f5..6095d465b2 100644
--- a/arch/arm/src/samv7/sam_spi_slave.c
+++ b/arch/arm/src/samv7/sam_spi_slave.c
@@ -485,7 +485,7 @@ static int spi_interrupt(int irq, void *context, FAR void 
*arg)
 
   /* Report the receipt of data to the SPI device driver */
 
-  SPI_SDEV_RECEIVE(priv->sdev, data);
+  SPI_SDEV_RECEIVE(priv->sdev, (const uint16_t*), sizeof(data));
 }
 
   /* When a transfer starts, the data shifted out is the data present
@@ -763,6 +763,7 @@ static void spi_bind(struct spi_sctrlr_s *sctrlr,
   struct sam_spidev_s *priv = (struct sam_spidev_s *)sctrlr;
   uint32_t regval;
   int ret;
+  const uint16_t* data;
 
   spiinfo("sdev=%p mode=%d nbits=%d\n", sdv, mode, nbits);
 
@@ -812,7 +813,8 @@ static void spi_bind(struct spi_sctrlr_s *sctrlr,
* be shifted out the SPI clock is detected.
*/
 
-  priv->outval = SPI_SDEV_GETDATA(sdev);
+  SPI_SDEV_GETDATA(sdev, );
+  priv->outval = *data;
   spi_putreg(priv, priv->outval, SAM_SPI_TDR_OFFSET);
 
   /* Setup to begin normal SPI operation */
diff --git a/include/nuttx/spi/slave.h b/include/nuttx/spi/slave.h
index a979d22c42..b7f7682ee1 100644
--- a/include/nuttx/spi/slave.h
+++ b/include/nuttx/spi/slave.h
@@ -109,18 +109,20 @@
  *
  * Input Parameters:
  *   sctrlr - SPI slave controller interface instance
- *   data   - Command/data mode data value to be shifted out.  The width of
- *the data must be the same as the nbits parameter previously
- *provided to the bind() methods.
+ *   data   - Pointer to the command/data mode data to be shifted out.
+ *The alignment of the data must be the same as the nbits parameter
+ *previously provided to the bind() methods.
+ *   len- Number of bytes to enqueue
  *
  * Returned Value:
- *   Zero if the word was successfully queue; A negated errno valid is
- *   returned on any failure to enqueue the word (such as if the queue is
- *   full).
+ *   Number of data items successfully queued, or a negated errno:
+ *  - "len" if all the data was successfully queued
+ *  - "0..len-1" if queue is full
+ *  - "-errno" in any other error
  *
  /
 
-#define SPI_SCTRLR_ENQUEUE(c,v)  ((c)->ops->enqueue(c,v))
+#define SPI_SCTRLR_ENQUEUE(c,v,l)  ((c)->ops->enqueue(c,v,l))
 
 /
  * Name: SPI_SCTRLR_QFULL
@@ -157,6 +159,23 @@
 
 #define SPI_SCTRLR_QFLUSH(c)  ((c)->ops->qflush(c))
 
+/
+ * Name: SPI_SCTRLR_RXQPOLL
+ *
+ * Description:
+ *   Tell the controller to output all the receive queue data.
+ *
+ * Input Parameters:
+ *   sctrlr - SPI slave controller interface instance
+ *
+ * Returned Value:
+ *   Number of bytes left in the rx queue. If the device accepted all the
+ *   data, the return value will be 0
+ *
+ /
+
+#define SPI_SCTRLR_RXQPOLL(c)  ((c)->ops->rxqpoll(c))
+
 /
  * Name: SPI_SDEV_SELECT
  *
@@ -222,9 +241,11 @@
  *
  * Input Parameters:
  *   sdev - SPI device interface instance
+ *   data - Pointer to the data buffer pointer to be shifed out.
+ *  The device will set the data buffer pointer to the actual data
  *
  * Returned Value:
- *   The next data value to be shifted out
+ *   The number of data bytes to be shifted out from the data buffer
  *
  * Assumptions:
  *   May be called from an interrupt handler and the response is usually
@@ -232,7 +253,7 @@
  *
  /
 
-#define SPI_SDEV_GETDATA(d)  ((d)->ops->getdata(d))
+#define SPI_SDEV_GETDATA(d,v)  ((d)->ops->getdata(d,v))
 
 /
  * Name: SPI_SDEV_RECEIVE
@@ -245,10 +266,12 @@
  *
  * Input Parameters:
  *   sdev - SPI device interface instance
- *   data - 

FW: SPI slave interface discussion

[Laitinen, Jukka]

Hi,

*The attached patch is just for opening a discussion, please don't merge*

We used the SPI slave interfaces on stm32h7 platform, in a configuration where
two stm32h7 chips were connected together with SPI bus, one in master 
simplex-tx and one
in slave simplex-rx mode.

There was quite high data rate from master to slave, and the slave controller & 
device interfaces,
which are defined in include/nuttx/spi/slave.h were quite inefficient to use.

Namely, we needed this kind of features to the slave interfaces:

  *   a possibility for slave controller driver to just buffer incoming data 
and slave device driver to poll for it at certain interval
  *   possibility for copying larger buffers of data at one call; now each call 
to getdata can only return 2 bytes at a time

I tackled these issues by changing the spi slave interface like in the attached 
patch. So adding a "poll" function for the controller interface and modifying
the data handling functions in a way that larger blocks of data can be managed 
in one call.

Obviously, this approach is incompatible with the existing SPI slave controller 
& spi slave drivers (on samv7 platform).

So the questions which arise

  *   Do you think that there is an alternative way to reach those goals using 
the existing interface?
  *   Would it be reasonable to re-visit the spi slave interfaces to support 
high data rates more efficiently?

Br,
Jukka