Re: [PATCH] nshlib/nsh_codeccmd.c: fix potential NULL dereference and check malloc return values

[Juha Niskanen (Haltian)]

Hi Xiang,
Are the PRs really any efficient if there is someone else doing nxstyle 
cleanups after each change? The build failures due to obvious misspellings 
should be corrected *fast*, so I don't want to delay things by going through 
entire file with nxstyle.

I'm not very keen on this whole Apache stuff and workflows saying how to 
contribute. I have used PRs for big changes that add new functionality, but 
don't like that mechanism much. I've actually grown to like the "traditional 
nuttx" highly unorthodox method of Greg editing incoming patches.

Best Regards,
   Juha


From: Xiang Xiao 
Sent: Friday, April 17, 2020 5:29 AM
To: dev@nuttx.apache.org 
Subject: Re: [PATCH] nshlib/nsh_codeccmd.c: fix potential NULL dereference and 
check malloc return values

Juha,
Since you contribute many code to NuttX and work with NuttX daily, it
will be more efficient and collaborative if you can send the patch
through github PR.

Thanks
Xiang

On Thu, Apr 16, 2020 at 8:53 PM Alan Carvalho de Assis
 wrote:
>
> Hi Juha,
>
> I just created apps PR #183 with your patch.
>
> Thank you!
>
> BR,
>
> Alan
>
> On 4/16/20, Juha Niskanen (Haltian)  wrote:
> > Hi,
> >
> > Small thing I found when reading through nsh code.
> >
> > Best Regards,
> >Juha
> >

RE: Adding support for STM32G474RET6

[David Sidrane]

How about in the commit hooks?

-Original Message-
From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
Sent: Thursday, April 16, 2020 7:47 PM
To: dev@nuttx.apache.org
Subject: Re: Adding support for STM32G474RET6

On Fri, Apr 17, 2020 at 5:54 AM David Sidrane 
wrote:
>
> Thank you for fixing the typos. I am sure I can make them faster than you
> can fix them. :)
>

Actually, checkpatch.sh support -c option which do the spell check by
invoke codespell(the same tool used by Linux):
https://github.com/codespell-project/codespell
How about we enable -c option in github check action?



> I started to lean heavier on the side of Kconfig. You should know
> historically, there was a pre Kconfig time, so this is an organic
> trajectory.
>
> The dividing lines for me are invariant vs variant and user selectable vs
> chip selected.
>
> For KINETIS_PMC_VERSION_05 - the context is fixed in terms of the chips,
> we
> are not building chips in Kconfig - that would hurt, it would also not be
> as
> clear, the h file is richer than the Kconfig files comments wise.
>
> While looking at the part number breakdown for the F3's and having to add
> a
> chip that had only a different size Flash drove the
> STM32H7_FLASH_CONFIG_x -
> That seemed like and easy win and one a user could benefit from.
>
> David
>
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Thursday, April 16, 2020 12:39 PM
> To: dev@nuttx.apache.org
> Subject: Re: Adding support for STM32G474RET6
>
> On Thu, Apr 16, 2020 at 1:00 PM David Sidrane 
> wrote:
> > If you look at the Kinetis,
> > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
> >
> > You can see the gist of that approach.
> >
> > It idea was as developers on the outside of the MFG, we only see the
> > deltas
> > in datasheets. We do not know, the feature set that was added to add to
> > the
> > silicon.
> > So if the IP versioning is not described by the MFG we can make up
> > names.
> >
> > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
> >
> > Then add the "HAS"s. To a feature set or chip and have reuse at the chip
> > level and not litter the code with partnumber.
>
> Thanks. I looked at that...
>
> I'd like to ask: It seems that some decisions are made in Kconfig
> logic using hidden configs, e.g.,
>
> select KINETIS_HAVE_LPUART0, or
> select STM32H7_FLASH_CONFIG_I
>
> while other decisions are made in code, e.g.,
>
> #if defined(CONFIG_ARCH_CHIP_MK28FN2M0VMI15)
> #define KINETIS_PMC_VERSION KINETIS_PMC_VERSION_05
>
> Is there a policy or rule of thumb as to when MCU-specific stuff is
> decided in Kconfig and when it's decided in code?
>
> Thanks,
> Nathan
>
> P.S., I couldn't help myself, if I see a typo, I have to fix it, or I
> don't sleep well at night. :-)

Re: Adding support for STM32G474RET6

[Xiang Xiao]

On Fri, Apr 17, 2020 at 6:26 PM David Sidrane  wrote:
>
> How about in the commit hooks?
>

Yes, we can add pre-commit script to tools folder, but developer still
need to copy the hook into .git/hooks folder manually.
 And we also need enable all same check on github/apache server as the
last quality guard.

> -Original Message-
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Sent: Thursday, April 16, 2020 7:47 PM
> To: dev@nuttx.apache.org
> Subject: Re: Adding support for STM32G474RET6
>
> On Fri, Apr 17, 2020 at 5:54 AM David Sidrane 
> wrote:
> >
> > Thank you for fixing the typos. I am sure I can make them faster than you
> > can fix them. :)
> >
>
> Actually, checkpatch.sh support -c option which do the spell check by
> invoke codespell(the same tool used by Linux):
> https://github.com/codespell-project/codespell
> How about we enable -c option in github check action?
>
>
>
> > I started to lean heavier on the side of Kconfig. You should know
> > historically, there was a pre Kconfig time, so this is an organic
> > trajectory.
> >
> > The dividing lines for me are invariant vs variant and user selectable vs
> > chip selected.
> >
> > For KINETIS_PMC_VERSION_05 - the context is fixed in terms of the chips,
> > we
> > are not building chips in Kconfig - that would hurt, it would also not be
> > as
> > clear, the h file is richer than the Kconfig files comments wise.
> >
> > While looking at the part number breakdown for the F3's and having to add
> > a
> > chip that had only a different size Flash drove the
> > STM32H7_FLASH_CONFIG_x -
> > That seemed like and easy win and one a user could benefit from.
> >
> > David
> >
> > -Original Message-
> > From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> > Sent: Thursday, April 16, 2020 12:39 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: Adding support for STM32G474RET6
> >
> > On Thu, Apr 16, 2020 at 1:00 PM David Sidrane 
> > wrote:
> > > If you look at the Kinetis,
> > > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
> > >
> > > You can see the gist of that approach.
> > >
> > > It idea was as developers on the outside of the MFG, we only see the
> > > deltas
> > > in datasheets. We do not know, the feature set that was added to add to
> > > the
> > > silicon.
> > > So if the IP versioning is not described by the MFG we can make up
> > > names.
> > >
> > > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63
> > >
> > > Then add the "HAS"s. To a feature set or chip and have reuse at the chip
> > > level and not litter the code with partnumber.
> >
> > Thanks. I looked at that...
> >
> > I'd like to ask: It seems that some decisions are made in Kconfig
> > logic using hidden configs, e.g.,
> >
> > select KINETIS_HAVE_LPUART0, or
> > select STM32H7_FLASH_CONFIG_I
> >
> > while other decisions are made in code, e.g.,
> >
> > #if defined(CONFIG_ARCH_CHIP_MK28FN2M0VMI15)
> > #define KINETIS_PMC_VERSION KINETIS_PMC_VERSION_05
> >
> > Is there a policy or rule of thumb as to when MCU-specific stuff is
> > decided in Kconfig and when it's decided in code?
> >
> > Thanks,
> > Nathan
> >
> > P.S., I couldn't help myself, if I see a typo, I have to fix it, or I
> > don't sleep well at night. :-)

Re: Test jobs failing due to timeouts?

[Xiang Xiao]

The situation become more worse today: many PR fail with timeout even
I manually rerun the job several time.:(

On Fri, Apr 17, 2020 at 3:52 AM Brennan Ashton
 wrote:
>
> This is an issue with GitHub unfortunately and got worse recently. I'll
> make some changes to the job that should help make this more robust later
> this week.
>
> On Thu, Apr 16, 2020, 12:26 PM Nathan Hartman 
> wrote:
>
> > In my PRs I seem to get a lot of test failures, and I have to re-run
> > the tests, because of:
> >
> > [[[
> >
> > Unable to find image
> > '
> > docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
> > '
> > locally
> > /usr/bin/docker: Error response from daemon: Get
> > https://docker.pkg.github.com/v2/: net/http: request canceled
> > (Client.Timeout exceeded while awaiting headers).
> >
> > ]]]
> >
> > I wonder if we need a longer timeout, and/or some kind of retry loop?
> >
> > Thanks,
> > Nathan
> >

Algorithm and Nuttx integration other platforms AI..Kalman..et....

[disruptivesolutionsnl]

All,

 

I want to experiment with sensor fusion. Nuttx is the sensor "collector" and
does this in a great way. I want to use python for adding algorithms and
micro python is gone. With reason I think. And the embedded platform
Cortex-M4's mostly are not suited for this job. To slow in general.

 

Say I want to keep using Nuttx as a data collector and I want to "add"
python algorithms in say another platform (Raspberry Pi Zero?) .. Which do
you guys recommend?

 

SPI slave (when I do this all my SPI's on my Nuttx platform become slave?
And this is not wanted with the used sensors and Nuttx as a master on SPI).
SPI is maybe to slow? Max 10Mbps?

USBOTG HS?

 

Maybe not a Nuttx specific question, but Nuttx related and more of an
integration question?

 

Thanks again.

Ben

 

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Daniel Pereira Carvalho]

Hi,

Did you think about an asymmetric multiprocessor? This way you can use a
Cortex-M4 with nuttx and a Cortex-A5/A7 to run the sensor fusion algorithm.

Daniel Pereira de Carvalho


Em sex., 17 de abr. de 2020 às 08:54, 
escreveu:

> All,
>
>
>
> I want to experiment with sensor fusion. Nuttx is the sensor "collector"
> and
> does this in a great way. I want to use python for adding algorithms and
> micro python is gone. With reason I think. And the embedded platform
> Cortex-M4's mostly are not suited for this job. To slow in general.
>
>
>
> Say I want to keep using Nuttx as a data collector and I want to "add"
> python algorithms in say another platform (Raspberry Pi Zero?) .. Which do
> you guys recommend?
>
>
>
> SPI slave (when I do this all my SPI's on my Nuttx platform become slave?
> And this is not wanted with the used sensors and Nuttx as a master on SPI).
> SPI is maybe to slow? Max 10Mbps?
>
> USBOTG HS?
>
>
>
> Maybe not a Nuttx specific question, but Nuttx related and more of an
> integration question?
>
>
>
> Thanks again.
>
> Ben
>
>
>
>

RE: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[disruptivesolutionsnl]

Very interesting... but Openamp was removed right?

Ben

-Oorspronkelijk bericht-
Van: Daniel Pereira Carvalho  
Verzonden: vrijdag 17 april 2020 14:27
Aan: dev@nuttx.apache.org
Onderwerp: Re: Algorithm and Nuttx integration other platforms 
AI..Kalman..et

Hi,

Did you think about an asymmetric multiprocessor? This way you can use a
Cortex-M4 with nuttx and a Cortex-A5/A7 to run the sensor fusion algorithm.

Daniel Pereira de Carvalho


Em sex., 17 de abr. de 2020 às 08:54, 
escreveu:

> All,
>
>
>
> I want to experiment with sensor fusion. Nuttx is the sensor "collector"
> and
> does this in a great way. I want to use python for adding algorithms 
> and micro python is gone. With reason I think. And the embedded 
> platform Cortex-M4's mostly are not suited for this job. To slow in general.
>
>
>
> Say I want to keep using Nuttx as a data collector and I want to "add"
> python algorithms in say another platform (Raspberry Pi Zero?) .. 
> Which do you guys recommend?
>
>
>
> SPI slave (when I do this all my SPI's on my Nuttx platform become slave?
> And this is not wanted with the used sensors and Nuttx as a master on SPI).
> SPI is maybe to slow? Max 10Mbps?
>
> USBOTG HS?
>
>
>
> Maybe not a Nuttx specific question, but Nuttx related and more of an 
> integration question?
>
>
>
> Thanks again.
>
> Ben
>
>
>
>

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Nathan Hartman]

On Fri, Apr 17, 2020 at 8:49 AM  wrote:

> Very interesting... but Openamp was removed right?


Removed?!

It's in the root directory of nuttx repo.

Did something break it?

Nathan

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Alan Carvalho de Assis]

Hi Nathan,

Yes, OpenAMP still here on NuttX and AFAIK everything is fine.

But I think OpenAMP is not feasible for this scenario where you have
two isolated boards, but Xiang could tell us, he and his team
integrated it on NuttX.

BR,

Alan

On 4/17/20, Nathan Hartman  wrote:
> On Fri, Apr 17, 2020 at 8:49 AM  wrote:
>
>> Very interesting... but Openamp was removed right?
>
>
> Removed?!
>
> It's in the root directory of nuttx repo.
>
> Did something break it?
>
> Nathan
>

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Xiang Xiao]

On Fri, Apr 17, 2020 at 9:13 PM Nathan Hartman  wrote:
>
> On Fri, Apr 17, 2020 at 8:49 AM  wrote:
>
> > Very interesting... but Openamp was removed right?
>
>
> Removed?!
>
> It's in the root directory of nuttx repo.
>
> Did something break it?
>

Yes, the recent change break some functionality, but ZhongAn already
provide several patch fix issues found so far:
https://github.com/apache/incubator-nuttx/pull/797

There are several patch pending to review:
https://github.com/OpenAMP/open-amp/pulls/xiaoxiang781216
I plan to work with OpenAMP community merge them to mainline in the
next couple weeks. before thtat happen, I will modify openamp/Makefile
apply these patches after download the official code.

Anchao also provide a demo OpenAMP implementation in simulator which
use two instance to simulate two CPU core. You can try
rpserver/rpproxy under boards/sim(boards/sim/sim/sim/README.txt has
some introduction).

> Nathan

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Xiang Xiao]

On Fri, Apr 17, 2020 at 9:20 PM Alan Carvalho de Assis
 wrote:
>
> Hi Nathan,
>
> Yes, OpenAMP still here on NuttX and AFAIK everything is fine.
>
> But I think OpenAMP is not feasible for this scenario where you have
> two isolated boards, but Xiang could tell us, he and his team
> integrated it on NuttX.
>

OpenAMP is most suitable for shared memory based IPC. If two isolated
boards connect with PCIE, OpenAMP may work well(actaully we are
working on a project like this).

> BR,
>
> Alan
>
> On 4/17/20, Nathan Hartman  wrote:
> > On Fri, Apr 17, 2020 at 8:49 AM  wrote:
> >
> >> Very interesting... but Openamp was removed right?
> >
> >
> > Removed?!
> >
> > It's in the root directory of nuttx repo.
> >
> > Did something break it?
> >
> > Nathan
> >

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Gregory Nutt]

Yes, OpenAMP still here on NuttX and AFAIK everything is fine.

But I think OpenAMP is not feasible for this scenario where you have
two isolated boards, but Xiang could tell us, he and his team
integrated it on NuttX.

Assumed that the poster was referring to the many processors with 
built-in Cortex-M4 and Cortex-A[7-9].  I believe there are some i.MX6's 
with that configuration.


There is also STM32H7x5 and STM32H7x7 are two of the more recent and 
more popular chips (Cortex-M4 at 240MHz and Cortex-M7 at 480MHz).

RE: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[disruptivesolutionsnl]

I added (git cloned some elementary files: libmetal and open-amp) and I have 
got it build and compiled in Nuttx again.

Now looking at videos how I could use it. My "sensor" core (slave..?) is a 
STM32F4VE.

Ben

-Oorspronkelijk bericht-
Van: Gregory Nutt  
Verzonden: vrijdag 17 april 2020 15:42
Aan: dev@nuttx.apache.org
Onderwerp: Re: Algorithm and Nuttx integration other platforms 
AI..Kalman..et


> Yes, OpenAMP still here on NuttX and AFAIK everything is fine.
>
> But I think OpenAMP is not feasible for this scenario where you have 
> two isolated boards, but Xiang could tell us, he and his team 
> integrated it on NuttX.
>
Assumed that the poster was referring to the many processors with built-in 
Cortex-M4 and Cortex-A[7-9].  I believe there are some i.MX6's with that 
configuration.

There is also STM32H7x5 and STM32H7x7 are two of the more recent and more 
popular chips (Cortex-M4 at 240MHz and Cortex-M7 at 480MHz).

RE: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[disruptivesolutionsnl]

@Nathan
Maybe I am just a simple soul .but the root concept is (seems to be)  
shared memory. Memory which is some sort of "topic" where an MCU is a 
"subscriber" and where there is some sort of "applicational" orchestration. A 
kafka bus on memory 😉

I think I am getting it, but where I am struggling with is... how are the MCU 
physical connected?? XiLink/Zync seem to have made some sort of "mux" solution 
to "orchestrate" which MCU is "using" memory. Or a dual port EEPROM with 
DSP/DDC or something... So "both" MCU's can be master. Or I2C but that’s 
slow...

 Say I have a STM32F4 (Cortex-M4) and a Raspberry Pi [Zero] 
([BCM2835]/Cortex-A7).  One should think DMA/SPI would be an option? If I could 
get the Raspberry Pi in "slave" mode I could make some sort of "PoC". Where I 
could "store" the measurements on the Pi and let it do its Kalman stuff and 
send the predicted values back over SPI to Nuttx..

Nuttx in "slave" mode is no option...this because I have SPI sensors.

Ben

-Oorspronkelijk bericht-
Van: Nathan Hartman  
Verzonden: vrijdag 17 april 2020 15:13
Aan: dev@nuttx.apache.org
Onderwerp: Re: Algorithm and Nuttx integration other platforms 
AI..Kalman..et

On Fri, Apr 17, 2020 at 8:49 AM  wrote:

> Very interesting... but Openamp was removed right?


Removed?!

It's in the root directory of nuttx repo.

Did something break it?

Nathan

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Gregory Nutt]

Maybe I am just a simple soul .but the root concept is (seems to be)  shared memory. Memory which is some 
sort of "topic" where an MCU is a "subscriber" and where there is some sort of 
"applicational" orchestration. A kafka bus on memory 😉

I think I am getting it, but where I am struggling with is... how are the MCU physical connected?? XiLink/Zync seem to 
have made some sort of "mux" solution to "orchestrate" which MCU is "using" memory. Or a 
dual port EEPROM with DSP/DDC or something... So "both" MCU's can be master. Or I2C but that’s slow...

  Say I have a STM32F4 (Cortex-M4) and a Raspberry Pi [Zero] ([BCM2835]/Cortex-A7).  One should think DMA/SPI 
would be an option? If I could get the Raspberry Pi in "slave" mode I could make some sort of 
"PoC". Where I could "store" the measurements on the Pi and let it do its Kalman stuff 
and send the predicted values back over SPI to Nuttx..

Nuttx in "slave" mode is no option...this because I have SPI sensors.
You should consider the i.MX 6SoloX: 
https://www.nxp.com/docs/en/brochure/FLYRIMXPRDCMPR.pdf

Re: Algorithm and Nuttx integration other platforms AI..Kalman..et....

[Alan Carvalho de Assis]

Interesting solution for MCU to FPGA comm:
https://jeelabs.org/2016/11/a-fast-%C2%B5c-to-fpga-bus/

On 4/17/20, disruptivesolution...@gmail.com
 wrote:
> @Nathan
> Maybe I am just a simple soul .but the root concept is (seems to be)
> shared memory. Memory which is some sort of "topic" where an MCU is a
> "subscriber" and where there is some sort of "applicational" orchestration.
> A kafka bus on memory 😉
>
> I think I am getting it, but where I am struggling with is... how are the
> MCU physical connected?? XiLink/Zync seem to have made some sort of "mux"
> solution to "orchestrate" which MCU is "using" memory. Or a dual port EEPROM
> with DSP/DDC or something... So "both" MCU's can be master. Or I2C but
> that’s slow...
>
>  Say I have a STM32F4 (Cortex-M4) and a Raspberry Pi [Zero]
> ([BCM2835]/Cortex-A7).  One should think DMA/SPI would be an option? If I
> could get the Raspberry Pi in "slave" mode I could make some sort of "PoC".
> Where I could "store" the measurements on the Pi and let it do its Kalman
> stuff and send the predicted values back over SPI to Nuttx..
>
> Nuttx in "slave" mode is no option...this because I have SPI sensors.
>
> Ben
>
> -Oorspronkelijk bericht-
> Van: Nathan Hartman 
> Verzonden: vrijdag 17 april 2020 15:13
> Aan: dev@nuttx.apache.org
> Onderwerp: Re: Algorithm and Nuttx integration other platforms
> AI..Kalman..et
>
> On Fri, Apr 17, 2020 at 8:49 AM  wrote:
>
>> Very interesting... but Openamp was removed right?
>
>
> Removed?!
>
> It's in the root directory of nuttx repo.
>
> Did something break it?
>
> Nathan
>
>

Re: Test jobs failing due to timeouts?

[Brennan Ashton]

There has been a workaround in place for the last few hours, but if anyone
notices a failure please tag me in the PR and I'll try and dig in further.

--Brennan

On Fri, Apr 17, 2020, 4:26 AM Xiang Xiao  wrote:

> The situation become more worse today: many PR fail with timeout even
> I manually rerun the job several time.:(
>
> On Fri, Apr 17, 2020 at 3:52 AM Brennan Ashton
>  wrote:
> >
> > This is an issue with GitHub unfortunately and got worse recently. I'll
> > make some changes to the job that should help make this more robust later
> > this week.
> >
> > On Thu, Apr 16, 2020, 12:26 PM Nathan Hartman 
> > wrote:
> >
> > > In my PRs I seem to get a lot of test failures, and I have to re-run
> > > the tests, because of:
> > >
> > > [[[
> > >
> > > Unable to find image
> > > '
> > >
> docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest
> > > '
> > > locally
> > > /usr/bin/docker: Error response from daemon: Get
> > > https://docker.pkg.github.com/v2/: net/http: request canceled
> > > (Client.Timeout exceeded while awaiting headers).
> > >
> > > ]]]
> > >
> > > I wonder if we need a longer timeout, and/or some kind of retry loop?
> > >
> > > Thanks,
> > > Nathan
> > >
>

Build failed in Jenkins: NuttX-Nightly-Build #99

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 296.07 KB...]

Configuration/Tool: sim/sixlowpan

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Skipping: sim/cxxtest

Configuration/Tool: sim/nettest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Skipping: sim/nxwm

Configuration/Tool: sim/ipforward

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/nx

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/ostest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/mount

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/module

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/minibasic

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=