Re: NuttX at FOSDEM 2020

[Gregory Nutt]

Hi, Philippe,

Some feeback from FOSDEM,
Alin Jerpelea and I were able to present in IoT room,
and It was recorded and published at:

https://fosdem.org/2020/schedule/event/iotnuttx/


Just watched the video.  Interesting stuff.  You needed a little more 
time to cover everything.


It is good to have a face that goes with the name after all of these 
years.  Good to see you again too, Alin,


Greg

Re: NuttX at FOSDEM 2020

[Alin Jerpelea]

Thanks Greg

Unfortunately there was little time to talk about everything that we wanted



On Wed, Feb 12, 2020, 16:39 Gregory Nutt  wrote:

> Hi, Philippe,
> > Some feeback from FOSDEM,
> > Alin Jerpelea and I were able to present in IoT room,
> > and It was recorded and published at:
> >
> > https://fosdem.org/2020/schedule/event/iotnuttx/
>
> Just watched the video.  Interesting stuff.  You needed a little more
> time to cover everything.
>
> It is good to have a face that goes with the name after all of these
> years.  Good to see you again too, Alin,
>
> Greg
>
>
>

Re: NuttX at FOSDEM 2020

[Brennan Ashton]

Nice work!   Wish our sessions had not overlapped. Maybe next year we can
organize a hackfest or something ahead of the conference.

--Brennan

On Wed, Feb 12, 2020, 7:55 AM Alin Jerpelea  wrote:

> Thanks Greg
>
> Unfortunately there was little time to talk about everything that we wanted
>
>
>
> On Wed, Feb 12, 2020, 16:39 Gregory Nutt  wrote:
>
> > Hi, Philippe,
> > > Some feeback from FOSDEM,
> > > Alin Jerpelea and I were able to present in IoT room,
> > > and It was recorded and published at:
> > >
> > > https://fosdem.org/2020/schedule/event/iotnuttx/
> >
> > Just watched the video.  Interesting stuff.  You needed a little more
> > time to cover everything.
> >
> > It is good to have a face that goes with the name after all of these
> > years.  Good to see you again too, Alin,
> >
> > Greg
> >
> >
> >
>

[GitHub] [incubator-nuttx-testing] maht commented on issue #2: Multibranch pipeline job example

[GitBox]

maht commented on issue #2: Multibranch pipeline job example
URL: 
https://github.com/apache/incubator-nuttx-testing/pull/2#issuecomment-585334298
 
 
   Well, not sure if the pipeline shared library can work from a subdirectory, 
according with documentation 
(https://jenkins.io/doc/book/pipeline/shared-libraries/). I agree it would be 
desirable, but if possible, it would require some extra research. I think that 
if not really a strong impediment and just I suggestion, we should go with 
default expected usage (or maybe just create an additional repository for the 
shared library, but this is also troublesome, I guess).
   
   I still have no Apache Jenkins access nor LDAP account. I think it would 
help to speed up the setup if I had access (possibly limited to a previously 
created job/folder inside Jenkins only for NuttX). Maybe @justinmclean can help 
with that, but not sure. If not I can help you setting the job, as commented 
before.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Using the network in the NuttX simulator

[Adam Feuer]

Thanks to Xiang and Greg, I got Internet networking running in the
simulator.

Xiang, your configuration as you sent it didn't work for me, but using it
as a base with some modifications, I got the simulator to compile.
Then with some debugging and using your simbridge script, I was able to get
the simulator's network working. I had some problems with /dev/net/tun file
permissions and capabilities– apparently on Ubuntu (and maybe other recent
Linuxes?) to access /dev/net/tun as a regular user, the program has to have
the cap_net_admin capability. This is detailed in the Linux TUN/TAP Readme
.
I was able to get the nuttx simulator working as root. Then I got it
running as a regular user by doing this:

sudo chmod 0666 /dev/net/tun
> sudo setcap cap_net_admin+ep ./nuttx
>

I can execute the tcpecho command, so now I can use it as a comparison to
the SAMA5D36-Xplained board while debugging the GMAC.

I'm not using the simbridge.sh script, I wrote a different one based on it,
and instead of bridging I use local routes and iptables to let the nuttx
box access the Internet. (The simbridge.sh script caused some problems with
how I accessed my VMWare linux installation.)

I will write a more full guide to getting everything set up in the next few
days.

Thank you both for your help!

cheers
adam

On Mon, Feb 10, 2020 at 10:44 PM Adam Feuer  wrote:

> Xiang,
>
> Thank you! It's late here in Seattle WA USA; I'll try it tomorrow!
>
> cheers
> adam
>
> On Mon, Feb 10, 2020 at 10:40 PM Xiang Xiao 
> wrote:
>
>> MAC is assigned through:
>> tapdev_init->set_macaddr->netdriver_setmacaddr
>>
>> netinit task is responsible for the networking initialization, so it
>> is a good indicator that the iniitaliation finish succesfully if ps
>> doesn't list it any more.
>>
>> Here is my config:
>> #
>> # This file is autogenerated: PLEASE DO NOT EDIT IT.
>> #
>> # You can use "make menuconfig" to make any modifications to the
>> installed .config file.
>> # You can then do "make savedefconfig" to generate a new defconfig
>> file that includes your
>> # modifications.
>> #
>> CONFIG_ARCH="sim"
>> CONFIG_ARCH_BOARD="sim"
>> CONFIG_ARCH_BOARD_SIM=y
>> CONFIG_ARCH_CHIP="sim"
>> CONFIG_ARCH_SIM=y
>> CONFIG_BOARDCTL_POWEROFF=y
>> CONFIG_BUILTIN=y
>> CONFIG_CLOCK_MONOTONIC=y
>> CONFIG_DEBUG_ASSERTIONS=y
>> CONFIG_DEBUG_ERROR=y
>> CONFIG_DEBUG_FEATURES=y
>> CONFIG_DEBUG_INFO=y
>> CONFIG_DEBUG_SYMBOLS=y
>> CONFIG_DEBUG_WARN=y
>> CONFIG_DEV_LOOP=y
>> CONFIG_DEV_ZERO=y
>> CONFIG_DRIVERS_VIDEO=y
>> CONFIG_ELF=y
>> CONFIG_EXAMPLES_FTPC=y
>> CONFIG_EXECFUNCS_HAVE_SYMTAB=y
>> CONFIG_FS_BINFS=y
>> CONFIG_FS_HOSTFS=y
>> CONFIG_FS_LITTLEFS=y
>> CONFIG_FS_PROCFS=y
>> CONFIG_FS_TMPFS=y
>> CONFIG_IDLETHREAD_STACKSIZE=2048
>> CONFIG_INPUT=y
>> CONFIG_IOB_NOTIFIER=y
>> CONFIG_LIBC_EXECFUNCS=y
>> CONFIG_LIBC_IOCTL_VARIADIC=y
>> CONFIG_LIBC_LOCALE=y
>> CONFIG_LIBC_LOCALTIME=y
>> CONFIG_LIBM=y
>> CONFIG_MTD=y
>> CONFIG_NET=y
>> CONFIG_NETDB_DNSCLIENT=y
>> CONFIG_NETDB_DNSCLIENT_MAXRESPONSE=176
>> CONFIG_NETDB_DNSCLIENT_RECV_TIMEOUT=3
>> CONFIG_NETDB_DNSSERVER_IPv4ADDR=0x771d1d1d
>> CONFIG_NETDEVICES=y
>> CONFIG_NETDEV_STATISTICS=y
>> CONFIG_NETINIT_DHCPC=y
>> CONFIG_NETINIT_THREAD=y
>> CONFIG_NETUTILS_DHCPC=y
>> CONFIG_NETUTILS_FTPC=y
>> CONFIG_NETUTILS_TELNETD=y
>> CONFIG_NETUTILS_TFTPC=y
>> CONFIG_NETUTILS_WEBCLIENT=y
>> CONFIG_NET_ARP_SEND=y
>> CONFIG_NET_BROADCAST=y
>> CONFIG_NET_ICMP=y
>> CONFIG_NET_ICMP_SOCKET=y
>> CONFIG_NET_ICMPv6=y
>> CONFIG_NET_ICMPv6_AUTOCONF=y
>> CONFIG_NET_ICMPv6_NEIGHBOR=y
>> CONFIG_NET_ICMPv6_SOCKET=y
>> CONFIG_NET_IPv6=y
>> CONFIG_NET_LOOPBACK=y
>> CONFIG_NET_SENDFILE=y
>> CONFIG_NET_SLIP=y
>> CONFIG_NET_SOLINGER=y
>> CONFIG_NET_STATISTICS=y
>> CONFIG_NET_TCP=y
>> CONFIG_NET_TCPBACKLOG=y
>> CONFIG_NET_TCP_WRITE_BUFFERS=y
>> CONFIG_NET_UDP=y
>> CONFIG_NET_UDP_BINDTODEVICE=y
>> CONFIG_NET_UDP_WRITE_BUFFERS=y
>> CONFIG_NSH_ARCHINIT=y
>> CONFIG_NSH_BUILTIN_APPS=y
>> CONFIG_NSH_FILE_APPS=y
>> CONFIG_NSH_READLINE=y
>> CONFIG_NSH_TELNETD_CLIENTSTACKSIZE=4096
>> CONFIG_POSIX_SPAWN_PROXY_STACKSIZE=2048
>> CONFIG_PSEUDOFS_SOFTLINKS=y
>> CONFIG_PSEUDOTERM=y
>> CONFIG_PSEUDOTERM_BSD=y
>> CONFIG_PTHREAD_CLEANUP=y
>> CONFIG_PTHREAD_CLEANUP_STACKSIZE=2
>> CONFIG_PTHREAD_MUTEX_TYPES=y
>> CONFIG_PTHREAD_STACK_DEFAULT=8192
>> CONFIG_RAMMTD=y
>> CONFIG_READLINE_CMD_HISTORY=y
>> CONFIG_READLINE_TABCOMPLETION=y
>> CONFIG_SCHED_CHILD_STATUS=y
>> CONFIG_SCHED_HAVE_PARENT=y
>> CONFIG_SCHED_HPWORK=y
>> CONFIG_SCHED_ONEXIT=y
>> CONFIG_SERIAL_TERMIOS=y
>> CONFIG_SIG_DEFAULT=y
>> CONFIG_SIG_EVTHREAD=y
>> CONFIG_SIM_M32=y
>> CONFIG_SIM_NET_BRIDGE=y
>> CONFIG_STACK_COLORATION=y
>> CONFIG_SYSLOG_BUFFER=y
>> CONFIG_SYSLOG_CHARDEV=y
>> CONFIG_SYSLOG_TIMESTAMP=y
>> CONFIG_SYSTEM_CLE=y
>> CONFIG_SYSTEM_NSH=y
>> CONFIG_SYSTEM_NSH_STACKSIZE=4096
>> CONFIG_SYSTEM_NTPC=y
>> CONFIG_SYSTEM_PING6=y
>> CONFIG_SYSTEM_PING6_STACKSIZE=4096
>> CONFIG_SYSTEM_PING=y
>> CONFIG_SYSTEM_PING_STAC

Re: problems with TCP send sizes greater than ETH_PKTSIZE (SAMA5D36)

[Adam Feuer]

The nuttx simulator running tcpecho doesn't appear to have any problem with
large TCP sends or large number of large TCP sends. So the problem with
tcpecho / tcpblaster on the SAMA5D36 seems to be in the SAMA5 code
somewhere.

The GMAC driver fix that I have only works when net logging is turned, and
it tested it more thoroughly today. It definitely works. But I don't
understand how it works, or why it doesn't work at high speeds.

-adam

On Tue, Feb 11, 2020 at 6:18 PM Adam Feuer  wrote:

> I did some more debugging today. It seems like the GMAC is sending
> multiple buffers sometimes when the TCP send is larger than MSS. So it's
> not sending not just a single one by itself. When that happens, the GMAC
> driver marks the first TX buffer descriptor as used (sent), txdesc->status
> = GMACTXD_STA_USED; but subsequent buffers are unmarked until the last,
> which is marked with GMACTXD_STA_LAST. Buffers that are not marked never
> get returned to the free pool. Hence the GMAC driver leaks buffers,
> eventually runs out of TX buffers, stops receiving, can't send, and
> eventually the txtimeout happens. Then the driver reinitializes the GMAC
> and the TX buffer pool, and frames start sending again. And the process
> repeats.
>
> I have a fix that works at slow speeds– with some logging turned on. It
> can do unlimited TCP sends of any size. With logging off, it hangs. I'm
> guessing that's because at high speeds it can send longer chains of packets
> and buffers all at once. I'm probably not handling chains of more than two
> consecutive packets correctly. I'll work on it some more tomorrow.
>
> -adam
>
> On Mon, Feb 10, 2020 at 5:38 PM Adam Feuer  wrote:
>
>> I put a log statement in sam_txdone()... what appears to be happening is
>> that the TX descriptor-in-use case is executed at sam_txdone(), line 1364,
>> in sam_gmac.c, so the TX buffer fills up.
>>
>> So it seems like the GMAC driver or hardware gets into a state where it
>> is not able to send packets until the driver and hardware is reset. Still
>> not sure why that's happening.
>>
>> -adam
>>
>> On Mon, Feb 10, 2020 at 3:50 PM Adam Feuer  wrote:
>>
>>> It seems like the SAMA5D36 GMAC driver in sam_gmac.c is running out of
>>> TX buffers. I can set a large number of buffers, but it always seems to run
>>> out. I get these entries in the log:
>>>
>>> [  402.31] sam_transmit: Disabling RX interrupts
>>>
>>> That seems to come from line 769 which notes that it's doing this
>>> because it can't transmit due to lack of TX buffers. Immediately
>>> afterwards, the transmission stalls, and then a minute later there is a
>>> txtimeout fired, the driver restarts, packets can be sent again until it
>>> runs out of TX buffers again.
>>>
>>> So it seems like there might be something wrong here. Could it be my
>>> configuration? Or could it be that the GMAC driver is leaking TX buffers?
>>> Does anyone have any ideas on how to find the leak?
>>>
>>> cheers
>>> adam
>>>
>>> On Mon, Feb 10, 2020 at 1:51 PM Adam Feuer  wrote:
>>>
 Well, at least that is a lot of progress for a day.  Going from
 clueless

> to pinpointing the failure.
>

 Greg,

 Yes! Thank you for the help.

 cheers
 adam
 --
 Adam Feuer 

>>>
>>>
>>> --
>>> Adam Feuer 
>>>
>>
>>
>> --
>> Adam Feuer 
>>
>
>
> --
> Adam Feuer 
>


-- 
Adam Feuer 

Re: problems with TCP send sizes greater than ETH_PKTSIZE (SAMA5D36)

[Gregory Nutt]

The nuttx simulator running tcpecho doesn't appear to have any problem with
large TCP sends or large number of large TCP sends. So the problem with
tcpecho / tcpblaster on the SAMA5D36 seems to be in the SAMA5 code
somewhere.

The GMAC driver fix that I have only works when net logging is turned, and
it tested it more thoroughly today. It definitely works. But I don't
understand how it works, or why it doesn't work at high speeds.


If the TX packets are going into DMA memory but are are never sent, then 
there could only be a few things wrong:  The MAC configuration, the DMA 
configuration, or the PHY setup.  I would tend to think that the PHY 
setup would be the most suspicious. That driver (in its various forms on 
different Atmel parts) has been very well exercised over many years.


That doesn't mean it is error free, just not the first place I would look.

Re: problems with TCP send sizes greater than ETH_PKTSIZE (SAMA5D36)

[Adam Feuer]

Greg,

Yeah I get what you are saying about the driver being quite well-used. This
is a strange problem. Thank you for the ideas about the MAC configuration,
the DMA configuration, and the PHY setup. I will look into those. I didn't
even consider that the PHY could be part of the problem, but it is a
complex little chip...

I'll look into it more tomorrow and see what I can find out.

cheers
adam


On Wed, Feb 12, 2020 at 7:03 PM Gregory Nutt  wrote:

>
> > The nuttx simulator running tcpecho doesn't appear to have any problem
> with
> > large TCP sends or large number of large TCP sends. So the problem with
> > tcpecho / tcpblaster on the SAMA5D36 seems to be in the SAMA5 code
> > somewhere.
> >
> > The GMAC driver fix that I have only works when net logging is turned,
> and
> > it tested it more thoroughly today. It definitely works. But I don't
> > understand how it works, or why it doesn't work at high speeds.
>
> If the TX packets are going into DMA memory but are are never sent, then
> there could only be a few things wrong:  The MAC configuration, the DMA
> configuration, or the PHY setup.  I would tend to think that the PHY
> setup would be the most suspicious. That driver (in its various forms on
> different Atmel parts) has been very well exercised over many years.
>
> That doesn't mean it is error free, just not the first place I would look.
>
>

-- 
Adam Feuer 

Re: dev board recommendation?

[Ishikawa, Masayuki (SHES)]

I think the settings look very basic. So it should work.
But I'm not sure if GS2200 has any problems with AR9223 Wi-Fi chip.
Can you try another Wi-Fi router which does not have AR9223 chip?

On 2020/02/12 16:56, "Takashi Yamamoto"  wrote:

hi,

what settings do you have in mind?

the wifi router is in the same room, a few meters away from the board.
the smart person managing the network told me:
Wireles N fixed on channel 5 (20MHz width), AP in WMM Mode, Short
Preamble, WPA2 PSK (CCMP) encryption, with "key reinstallation (KRACK)
countermeasures" enabled
it is OpenWrt 18.06.3 firmware using Atheros AR9223 wifi chip


On Wed, Feb 12, 2020 at 1:09 PM Ishikawa, Masayuki (SHES)
 wrote:
>
> Or what happens if you move GS2200M near the Wi-Fi router?
>
>
> On 2020/02/12 13:02, "Ishikawa, Masayuki (SHES)" 
 wrote:
>
> Thanks for the details.
>
> I think it's a GS2200M firmware issue.
> Could you tell me a product name of the Wi-Fi router?
> And the issue might be mitigated if you change Wi-Fi router settings.
>
>
> On 2020/02/12 12:32, "Takashi Yamamoto" 
 wrote:
>
> On Tue, Feb 11, 2020 at 1:40 PM Ishikawa, Masayuki (SHES)
>  wrote:
> >
> > Yamamoto-san,
> >
> > Could you tell me what kind of network applications you
> > are trying with Spresense + GS2200M?
>
> for now, just a mqtt client.
> (i know gs2200m has some mqtt functionalities. but i'm not going 
to use it)
>
> >
> > Also, are you using a Wi-Fi router or directly connecting to
> > a PC in AP mode? I'd like to know about your network
> > environment.
>
> i'm using station mode. connecting to the existing AP. using WPA2.
> it sometimes work, sometimes not.
>
> when it doesn't work, usually AT+WA gets ERROR response. ("WLAN
> CONNECT ERROR" if you raise log level of gs2200m)
> it's somehow mitigated by the following change.
> 
https://github.com/apache/incubator-nuttx-apps/commit/2f4b309b1b9faad87788d0668617b07bcfbca305
>
> occasiionally AT+WA even timeouts (SPI_TIMEOUT) and it causes
> assertion failures in the following AT commands because the driver
> and gs2200m are now out of sync. i guess the driver should reset 
the
> chip after giving up waiting for it.
>
> even when it's working, tcp connections are occasionally dropped.
> usually it recovers if i tcp-reconnect. i haven't investigated 
this
> symptom.
>
> >
> > On 2020/02/11 1:20, "Takashi Yamamoto" 
 wrote:
> >
> > Thank you.
> > It looks like the same board as I have.
> > For me I feel it works 30% of the time.
> > I wonder what's the difference.
> >
> > On Tue, Feb 11, 2020, 01:10 Alin Jerpelea 
 wrote:
> >
> > > I am using this one
> > >
> > > 
https://www.chip1stop.com/SWE/en/product/detail?partId=IDYC-001&mpn=iS110B&keyword=spresense&zaikoFlg=false&partSameFlg=false
> > >
> > > On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao 

> > > wrote:
> > >
> > > > Ubuntu 18.04 run on VirtualBox with NAT. For me, I just 
spend the time
> > > > with the hardware my project will use or the simulator.
> > > >
> > > > On Mon, Feb 10, 2020 at 11:53 PM Takashi Yamamoto
> > > >  wrote:
> > > > >
> > > > > which host os are you using?
> > > > >
> > > > > On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao 
 > > >
> > > > wrote:
> > > > > >
> > > > > > We use sim which work very well and stable, all
> > > > > > TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) 
stack can run in
> > > > > > this virtual environment.
> > > > > >
> > > > > > On Mon, Feb 10, 2020 at 11:41 PM Takashi Yamamoto
> > > > > >  wrote:
> > > > > > >
> > > > > > > hi,
> > > > > > >
> > > > > > > i'm working on some apps which need network 
connectivity.
> > > > > > > does anyone have a recommendation of a board for 
development on
> > > which
> > > > > > > i can run nuttx reliably with network? (wifi or 
ethernet)
> > > > > > > either a real board i can purchase, or 
emulators/simulators.
> > > > > > >
> 

Re: Jenkins CI

[Haitao Liu]

After practise with Apache Jenkins CI and Github action CI for a time and
do some CI problems search in Apache maillist and google, let's sum up as
below:

 Apache Jenkins
   |Github action



Provide Linux/Windows real Machines, but MacOS not available
   | Provide Linux/MacOS/Windows VM

 Apache jenkins slaves are limited and shared with other ASF projects
| The computing power can be accessed for each user
at first time

 Github PRs may wait nearly hours to be scheduled, for nightly build it
works well | Integrate with the github workflow smoothly

Restrict accounts access to update jenkins configs
   | Free to Make PRs to update github
action workflow

More info on Jenkins and Github action for reference:

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/about-github-actions#usage-limits

https://knapsackpro.com/ci_comparisons/jenkins/vs/github-actions // sth
maybe obsolete for github action

So, I think we could consider to use apache jenkins ci as nightly build
and use github action ci as PR check build accordingly.

1. Apache Jenkins CI for Nightly Build

There is an existing freestyle NuttX Nightly Build do cron job at
midnight each day. However, it's very simple. And there is still flock
issue to resolve to make parallel build all pass.

https://builds.apache.org/view/Incubator%20Projects/job/NuttX-Nightly-Build/

 Thanks to @Maht, he made multibranch jenkins pipeline PR which would make
the Nightly build more robust. But it may still need some time to switch to
it because of Apache Jenkins access control. The PRs as below:

https://github.com/apache/incubator-nuttx-testing/pull/2

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

Also, there is still travis CI pull request form @yamt, we could integrate
it into incubator-nuttx-testing as maht do.

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



2. Github action CI for Check Build

I have just make two PRs to incubator-nuttx and inucbator-nuttx-apps
accordingly as below:

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

https://github.com/apache/incubator-nuttx-apps/pull/65

The two PRs are not intended to be merged right now. They still need align
to check testlist update under incubator-nuttx-testing.

For example, Consider have a minimal check testlist set that always run.

As for github action check build CI, there are still more space to optimize:

1. Matrix builds to allow concurrent jobs and even multi-platorms

To speed up the check build time, use multiple jobs in github action
workflow to do parallel builds as @btashton and @davids suggest.

2. Use docker images with tools preinstalled

Now it takes several minitues to install all essential tools in ubuntu vm.

we may build nuttx with docker images which tools preinstalled in the
future.

Anyway, These are just  some thoughts from our previous discussions,
welcome more reviews and feedbacks from community.
 Thanks!


Miguel Ángel Herranz  于2020年2月4日周二 下午7:23写道：

> Hi Haitao,
>
> I will take a look.
>
> By the way, do Apache Jenkins slave includes Docker? Or alternatively, does
> Apache Jenkins have Docker Slave [1] plugin available?
>
> If we could use either launch Docker containers in the slave or launch the
> jobs in a Docker container we could use an image with all the tools pre
> installed.
>
> Please someone with read privileges on Jenkins check that whenever possible
> (Xiang? Justin?).
>
> Thanks,
> Miguel
>
> [1] https://plugins.jenkins.io/docker-slaves
>
> On Tue, Feb 4, 2020 at 12:04 PM Haitao Liu  wrote:
>
> > Thanks Xiang!
> > Another PR https://github.com/apache/incubator-nuttx-testing/pull/4
> since
> > Apache jenkins slave haven't gperf preinstalled,
> > so switch to use our owned prebuilt gperf. Xiang and Miguel please help
> to
> > review.
> > Or in another way, may I ask Justin Apache Infra team to apt-get install
> > gperf instead?
> >
> > Xiang Xiao  于2020年2月4日周二 下午2:36写道：
> >
> > > I will merge it.
> > >
> > > On Tue, Feb 4, 2020 at 12:50 PM Haitao Liu  wrote:
> > > >
> > > > Hi, Greg,
> > > > Thanks to Miguel's careful review, could you please help to finish
> the
> > PR
> > > > merge?
> > > > Then I and Miguel can continue the development with more PRs and
> > > refinement.
> > > >
> > > > Gregory Nutt  于2020年1月31日周五 下午11:30写道：
> > > >
> > > > >
> > > > > > I have just added the CI scripts and testlist files in
> > > > > > https://github.com/apache/incubator-nuttx-testing/pull/3
> > > > > > And asked XiaoXiang help to create Nuttx Nightly build job in
> > > > > > builds.apache.org before. But it's just a freestyle CI job
> > > > > > which call cibuild.