apache/incubator-nuttx

Apache NuttX is a mature, real-time embedded operating system (RTOS)

Apache NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 64-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOSs (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments (such as fork()).

For brevity, many parts of the documentation will refer to Apache NuttX as simply NuttX.

Getting Started

First time on NuttX? Read the Getting Started guide! If you don't have a board available, NuttX has its own simulator that you can run on terminal.

Documentation

You can find the current NuttX documentation on the Documentation Page.

Alternatively, you can build the documentation yourself by following the Documentation Build Instructions.

The old NuttX documentation is still available in the Apache wiki.

Supported Boards

NuttX supports a wide variety of platforms. See the full list on the Supported Platforms page.

Contributing

If you wish to contribute to the NuttX project, read the Contributing guidelines for information on Git usage, coding standard, workflow and the NuttX principles.

License

The code in this repository is under either the Apache 2 license, or a license compatible with the Apache 2 license. See the License Page for more information.

incubator-nuttx's Issues

Can't read from CAN dev using internal OS interface

In drivers/can/can.c @walmis added support of multiple readers of the same port with 7d112f5, but in current state it breaks ability to work with CAN using internal OS interface.

Issue in current logic:

1. file_open() with reference to user-provided file structure *filep;
2. file_open() calls nx_vopen() that allocate a file structure for inode and call can_open() with reference to this file structure.
3. In can_open() https://github.com/apache/incubator-nuttx/blob/177c037aa9f0536c4d9baf25cf060c0633957b94/drivers/can/can.c#L475 can_reader is added to the list with the reference to file structure (from point 2). And returned
4. nx_vopen returns file descriptor
5. and that file descriptor is detached in file_open() if fact by duplicate the 'struct file' content into the user-provided file structure.
6. then during reading in can_read() https://github.com/apache/incubator-nuttx/blob/177c037aa9f0536c4d9baf25cf060c0633957b94/drivers/can/can.c#L635 appropriate reader is chosen from list by filep value. But in this point filep argument of can_read() is the pointer to user-provided file structure, but the appropriate can_reader has pointer to another file structure (from point 2)! So can_read will not find any reader and fails this debug assertion if enabled: https://github.com/apache/incubator-nuttx/blob/177c037aa9f0536c4d9baf25cf060c0633957b94/drivers/can/can.c#L642

I'm not really good in all this things with inodes, files and descriptors, but as for me the solution will be to distinct readers in can driver not by filep itself, but by for example f_priv field of it.
Could we store value of filep in f_priv on can opening and use it in can_read? What happens with file structure (from point 2) with detaching, is there a chance this pointer be reused before file will be closed by user-provided reference?

p.s. maybe this issue also related to other devices, for instance serial

NuttX UINT32_C portability issue

In stdint.h UINT32_C has not been defined.
Per section 7.20.4.1 of the ISO C11 standard, these macros shall be defined by a compliant implementation of the standard library.

#if 0 /* REVISIT: Depends on architecture specific implementation */
#define INT8_C(x)           x
#define INT16_C(x)          x
#define INT32_C(x)          x ## l
#define INT64_C(x)          x ## ll

#define UINT8_C(x)          x
#define UINT16_C(x)         x
#define UINT32_C(x)         x ## ul
#define UINT64_C(x)         x ## ull
#endif

What would be a correct solution to define these macros for the corresponding CPU architecture?

tools/Makefile.unix: Remove FORBIDDEN CXD56 code in common Makefile.

Because of modularity concerns, this logic must be removed from tools/Makefile.unix:

483 ifeq ($(CONFIG_CXD56_BINARY),y)
484         $(Q) if [ ! -f "tools/cxd56/mkspk" ] ; then \
485                 echo ""; \ 
486                 echo "Please run the following command to build the needed tool"; \
487                 echo ""; \
488                 echo "cd tools/cxd56 && make && cd ../.."; \
489                 echo ""; \
490                 echo "run make again to create the nuttx.spk image."; \
491         else \
492                 echo "Generating: $(NUTTXNAME).spk"; \
493                 tools/cxd56/mkspk -c2 nuttx nuttx nuttx.spk; \
494         fi
495 endif

If is FORBIDDEN to include platform specific logic in common build logic.

Don't use nxsem_wait_uninterruptible in read()/write()

In many places, nxsem_wait_uninterruptible() is used directly in directly in the read() or write() methods of character drivers. POSIX, however, requires that these methods return EINTR if interrupted by a signal.

For read(), EINTR should be returned to indicate "The read operation was terminated due to the receipt of a signal, and no data was transferred." https://pubs.opengroup.org/onlinepubs/009695399/functions/read.html

For write(), EINTR means that "The write operation was terminated due to the receipt of a signal, and no data was transferred."

POSIX also requires that the open() and close() method return EINTR if any signal is received (although I think supporting this in close() would cause issues since people seldom check the return value from close).

More general, the read() and write() methods should return EINTR if a signal is received even if there is no underlying character driver. This means that the block read/write methods of block and MTD drivers also must return EINTR if interrupt.

Video: Correct use of global variable

Reported to me via email:

The v4l2-like layer (video.c) uses a global variable inappropriately. A global variable is used instead of creating a struct in /boards/ and passing it. So we have g_video_devops->set_buf(...) for example
g_video_devops being declared in video.h: FAR const struct video_devops_s *g_video_devops;

And being used in the CXD56xx board here: boards/arm/cxd56xx/spresense/src/cxd56_bringup.c: g_video_devops = isx012_initialize();

Wouldn't it be better to create the pointer in boards and pass it as argument ? Using global variables at inter-module interfaces is not good design and anathema to embedded systems. From the INVIOLABLES.txt:

Modular Architecture
--------------------

  o The internal modular architecture of the OS must be maintained.
  o This means formalizing and documenting all internal interfaces (in the
    porting guide), minimal use of global variables at the interface, and
    only well defined functional interfaces.

nxstyle: "Operator/assignment must be preceded with whitespace"

nxstyle doesn't like the following line in apps/examples/sotest/sotest_main.c

  testfunc = (CODE void (*)(FAR const char *))dlsym(handle2, "testfunc1");

to me, the style seems perfectly fine.

Would a PR to switch to '#pragma once' be accepted?

Would switch the #ifdef, #define, #endif entries to a single #pragma once at the top of each header file. #pragma once is widely supported at this point.

problem with nxsig_timeout (sig_timedwait.c)

On 3/19/2020 10:38 AM, Sebastian Perta wrote:

Initially the was reported to me as a problem in the compiler however when I investigated I found there no problem
In the compiler, the problem was in nuttx/sched/signal/sig_timedwait.c at line 359-360:

wd_start(rtcb->waitdog, waitticks,
(wdentry_t)nxsig_timeout, 1, wdparm.pvarg);

Looking at the declarations of nxsig_timeout and wdentry_t:

static void nxsig_timeout(int argc, wdparm_t itcb)
typedef CODE void (*wdentry_t)(int argc, uint32_t arg1, ...);

We can see those declarations are incompatible, if we remove the cast the most compilers (GCC for example) will return
an warning (other compilers will go as far as to return an error).
... warning: passing argument ... from incompatible pointer type [-Wincompatible-pointer-types]
... note: expected 'wdentry_t' {aka 'void ()(int, int, ...)'} but argument is of type 'void ()(int, int)'

One might think this warning can be safely ignored, especially since it works in many cases, however this is not
generally true it can fail on some targets depending on ABI specification. This is made clear in the
ISO/IEC standard chapter 7.6 more exactly the following statement:
"The rightmost parameter plays a special role in the access mechanism, and will be designated parmN in this description."

What this means is that "itcb" from nxsig_timeout can be at a different location from where "arg1" from wdentry_t is expected it to be.

The target for which I've see this problem is Renesas RX. In case of RX itcb is placed in register R2 while arg1 is placed on the stack.

The majority of functions in the code used in this way (casted to wdentry_t) are variadic as well so this is not a problem in general,
just in a few cases (nxsig_timeout is the only one I found so far there might be a few others)
In order to make the code ANSI/ISO compliant nxsig_timeout needs to be made variadic as well:
static void nxsig_timeout(int argc, wdparm_t itcb, ...)

I hope you agree with my finding and fix it as this will make the code more robust (incompatible pointer assignment is unsafe)
and more portable (other targets besides Renesas RX in which I have a vested interest).

Uninterruptible semaphore waits breaks cancellation.

In NuttX, thread or tasks may be canceled using pthread_cancle() or task_delete() These can also be cancel via signals if default signal actions are enabled.

When threads or tasks are canceled asynchronously, resources may be stranded. For example, if memory is allocated, it will not be deallocated when the task/thread is canceled in the FLAT build. These kind on leaks can be handled with pthread_cleanup() or on_exit(), but others cannot.

The generic solution for NuttX is through the use of cancellation points. Cancellation points are a mechanism that assures that all resources used internal by OS interface calls are cleaned-up automatically at designated cancellation points. An interface is normally a cancellation point if it has any possibility of blocking.

In NuttX, when threads are blocked waiting of a semaphore when they are canceled, nxsem_wait() will return -ECANCELED and the correct behavior to let the error ripple back to the cancellation point where the thread/task will be canceled after all resources have been cleaned up.

Many internal OS functions use nxsem_wait_uninterruptible() for waiting. nxsem_wait_uninterruptible() is defined in include/nuttx/semaphore.h. nxsem_wait_uninterruptible wraps a call to nxsem_wait() in a loop like:

static inline int nxsem_wait_uninterruptible(FAR sem_t *sem)
{
  int ret;

  do
    {
      /* Take the semaphore (perhaps waiting) */

      ret = nxsem_wait(sem);
    }
  while (ret == -EINTR || ret == -ECANCELED);

  return ret;
}

The correct behavior is to continue waiting on -EINTR only. If the task/thread is awakened by a signal just continue waiting. The behavior for -ECANCELED is not correct. It should not loop. Looping like this will prevent the cancellation from working. Instead of returning through the cancellation point, the code will be stuck in the above loop (in defferred cancellation mode) and cannot be cancelled.

The correct behavior is to return when -ECANCELED is encountered, not to continue looping:

-  while (ret == -EINTR || ret == -ECANCELED);
+  while (ret == -EINTR);

The only complexity to this suggested change is that the callers of nxsem_wait_uninterruptible() must also check the return value for any errors and make sure that that error is returned to the caller. The error must propogate all the way back up to the cancellation point.

These are other related inline functions in include/nuttx/semaphore.h that behave in this same way. This issue applies to them as well.

Corollary: If cancellation points are enabled, the default cancellation mode should be deferred mode.

A error in sched\timer\timer_gettime.c?

89: clock_ticks2time(timer->pt_last, &value->it_interval);
Why use timer->pt_last to set value->it_interval,value->it_interval is the period value.
so maybe use timer->pt_delay is right!
test.txt

Inlined documentation files for the wiki should be built by CI

Right now when the documentation files are updated they have to be manually built and upload to the wiki. This build step is a done manually by a commiter today and while simple requires npm which not everyone here if familier. WIth github actions we can do the build an generate the artifacts that can be downloaded and uploaded to the Wiki by any commiter.

References to bitbucket still exist in wiki

There are a bunch of pages on the wiki that still refer to the bitbucket repos and we should get those links cleaned up.

The search is really poor in Confluence to do this, but you can export the space as HTML and then grep for the instances.

https://cwiki.apache.org/confluence/spaces/exportspacewelcome.action?key=NUTTX

There are approximately 162 pages that likely need updating (some of these are false positives). It would be good to start with places that new users would likely interact with first.

❯ grep -L -r "bitbucket" | grep -v "attach" | grep -v "image" 
139629395.html
Archived-Proposals_141724728.html
CONFIG_NET_GUARDSIZE_145724178.html
Reading-CAN-Messages_139629546.html
SMP_139629514.html
139629543.html
NuttX-Channel_139629435.html
Graphics_139629472.html
Project-Administration_148641516.html
Porting-Drivers-to-the-STM32-F7_139629452.html
SAMA5D3-Notes_139629518.html
SMP-Critical-Sections_139629502.html
styles/site.css
Network-Link-Management_139629532.html
Forum_139629552.html
New-Apache-Nuttx-Logo_148647310.html
139629392.html
User-Guide_139629403.html
January-2020_142642100.html
NxWM-Threading_139629478.html
Nuttxbook_139629427.html
Multiple-NSH-Sessions_139629544.html
Releases_148644709.html
Platforms_139629516.html
139629444.html
Levato-STM32F103_139629429.html
Coding-Standard_139629417.html
Kernel-Modules-vs-Shared-Libaries_139629508.html
Detaching-File-Descriptors_139629489.html
Custom-Application-Directories_139629536.html
NxWidgets-Interface_139629420.html
POSIX-Timers_139629468.html
Debugging-ELF-Loadable-Modules_139629537.html
NuttX-Developers_139629425.html
Task-Exit-Sequence_139629494.html
License-Clearing_148641518.html
Developers_139629423.html
Documentation_139629402.html
139629534.html
The-README_139629438.html
Logging-to-a-RAM-Buffer_139629460.html
Release-Checklist-Template_148644703.html
139629390.html
Analyzing-Cortex-M-Hardfaults_139629445.html
On-Demand-Paging_139629415.html
Release-9.0-Checklist_148644707.html
Delayed-ACK-and-TCP-Performance_139629531.html
IPv6_139629461.html
Continuous-integration----Miguel-Herranz_145722717.html
139629398.html
NuttX-Overview_139629406.html
NuttX-Tasking_139629485.html
139629487.html
Device-Drivers-vs.-Bus-Drivers-and-GPIO-Drivers_139629504.html
139629388.html
Framebuffer-Character-Driver_139629476.html
Removing-Device-Drivers-with-NSH_139629547.html
139629399.html
Nuttx_139629557.html
Effects-of-Disabling-Interrupts-or-Pre-Emption-on-Response-Latency_139629493.html
Device-Nodes_139629484.html
Short-Time-Delays_139629486.html
139629538.html
Disabling-the-Stack-Dump-During-Debugging_139629449.html
NuttX-9.0_148644489.html
Getting-Started-Presentations_139629433.html
STM32-CCM-Allocator_139629459.html
Running-Applications-from-NSH_139629549.html
February-2020_145722524.html
NuttX-Initialization-Sequence_139629500.html
Special-Files-and-Device-Numbers_139629526.html
NuttX-Presentations_139629386.html
Naming-FAQ_139629499.html
STM32-Null-Pointer-Detection_139629467.html
Gregory-Nutt_139629424.html
Oneshot-Timers-and-CPU-Load-Measurement_139629503.html
External-Tutorials_139629430.html
NuttX-SDRAM_139629456.html
How-NXFFS-Works_139629523.html
139630111.html
139629397.html
139629501.html
NFS-Client-How-To_139629404.html
NSH-Network-Link-Management_139629540.html
139629474.html
menuconfig_139629416.html
Project-Resources_142642063.html
Per-Thread-Interrupt-Controls_139629513.html
Semihosting_139629446.html
Dynamic-Clocking_139629498.html
index.html
USB-Device-Trace_139629421.html
March-2020_148639823.html
Critical-Section-Monitor_139630201.html
139629439.html
Release-Notes_148644487.html
CNxConsole-Keyboard-Input_139629475.html
Tickless-OS_139629483.html
Work-Queue-Deadlocks_139629528.html
139629473.html
APPNAME-vs.-PROGNAME_139629539.html
Tasks-vs.-Threads-FAQ_139629511.html
SLIP-Configuration_139629529.html
139629466.html
Board-Reports_142642097.html
ARMv7-M-Run-Time-Stack-Checking_139629451.html
139629393.html
Analysis-March-2020_148643071.html
April-2020_148646033.html
Networking_139629527.html
Validating-a-staged-Release_152112242.html
Codeblocks_139629432.html
Draft-Proposals_141724724.html
139629530.html
Code-Contribution-Workflow_141724732.html
Supported-Platforms_139629517.html
139629401.html
139629488.html
139629396.html
Auto-Mounter_139629455.html
139629389.html
Upper-Half-and-Lower-Half-Drivers_139629496.html
139629394.html
Getting-Started_139629413.html
139629391.html
NuttX-File-System_139629525.html
Memory-Configurations_139629512.html
TCP-Network-Performance_139629533.html
Pseudo-File-System_139629522.html
I2C-Character-Driver-Example_139629440.html
Power-Management---Final-Report_139629419.html
Platform-Directories_139629441.html
Bottom-Half-Interrupt-Handlers_139629507.html
Accepted-Proposals_141724726.html
Cancellation-Points_139629509.html
NuttX-Protected-Build_139629469.html
chip.h-FAQ_139629492.html
Wide-Font-Support_139629477.html
Getting-Started-with-NuttX_139629426.html
Signal-Handler-Tour_139629491.html
Smaller-Vector-Tables_139629448.html
Virtual-File-System_139629520.html
Integrating-with-Newlib_139629458.html
SmartFS-Internals_139629524.html
Driver-Types_139629505.html
Using-SmartFS_139629521.html
Updating-a-Release-System-with-ELF-Programs_139629541.html
NuttX-And-OpenAMP_152112290.html
Signaling-Semaphores-and-Priority-Inheritance_139629457.html
MiSoC_139629519.html
Including-Files-in-board.h_139629464.html
139629400.html
139629542.html
Signaling-Events-from-Interrupt-Handlers_139629465.html
NxWM-Threading-Model_139629414.html
Accessing-Apache-GitHub-as-a-Committer_142642065.html
Linux-Processes-vs-NuttX-Tasks_139629481.html
Wiki_139629422.html
Pre-Apache-Release-Checklist_148646428.html
139629479.html
SYSLOG_139629480.html
Proposals_141724722.html

missing DISCLAIMER file

All ASF incubating projects need a DISCLAIMER file. One of two needs to be chosen see [1]

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

up_mdelay multiple definitions

In file:
nuttx/arch/arm/src/common/up_mdelay.c

void up_mdelay(unsigned int milliseconds)
{
  volatile unsigned int i;
  volatile unsigned int j;

  for (i = 0; i < milliseconds; i++)
    {
      for (j = 0; j < CONFIG_BOARD_LOOPSPERMSEC; j++)
        {
        }
    }
}

is defined. But if you enable the timer driver you get:

void up_mdelay(unsigned int milliseconds)
{
  up_udelay(USEC_PER_MSEC * milliseconds);
}

in file nuttx/drivers/timers/arch_timer.c

And thus the compiler error becomes:

nuttx/nuttx/staging/libdrivers.a(arch_timer.o): In function `up_mdelay':
arch_timer.c:(.text+0x208): multiple definition of `up_mdelay'
nuttx/nuttx/staging/libkarch.a(up_mdelay.o):up_mdelay.c:(.text+0x0): first defined here

to introduce a new function timerfd_settime() and timerfd_gettime()

Is it possible to introduce a new function timerfd_settime () and timerfd_gettime ()?

multiple definition of `up_mdelay'

Hi ,
multiple definition of up_mdelay occurs when enabled CONFIG_ALAM_ARCH.
In nuttx/arch/xxxx/common/up_mdelay.c there is a implementation of up_mdelay.
But if follows the steps as below to enabled CONFIG_ALARM_ARCH:
make menuconfig
Device Drivers -->
Timer Driver Support -->
[x] Oneshot timer driver -->
[x] Alarm Arch Implementation // will enabled CONFIG_ALARM_ARCH.
in nuttx/drivers/timers/Make.defs

ifeq ($(CONFIG_ALARM_ARCH),y)
  CSRCS += arch_alarm.c
  TMRDEPPATH = --dep-path timers
  TMRVPATH = :timers
endif

In arch_alarm.c, a up_delay also can be found here.

void up_mdelay(unsigned int milliseconds)
{
  up_udelay(USEC_PER_MSEC * milliseconds);
}

BR
Kevin Liu

usbhost/usbhost_xboxcontroller.c compilation error

CC:  usbhost/usbhost_xboxcontroller.c
usbhost/usbhost_xboxcontroller.c: In function 'usbhost_notify':
usbhost/usbhost_xboxcontroller.c:561:36: error: 'struct usbhost_state_s' has no member named 'fds'
       FAR struct pollfd *fds = priv->fds[i];
                                    ^~
usbhost/usbhost_xboxcontroller.c: In function 'usbhost_poll':
usbhost/usbhost_xboxcontroller.c:2136:20: error: 'struct usbhost_state_s' has no member named 'fds'
           if (!priv->fds[i])
                    ^~
usbhost/usbhost_xboxcontroller.c:2140:19: error: 'struct usbhost_state_s' has no member named 'fds'
               priv->fds[i] = fds;
                   ^~
usbhost/usbhost_xboxcontroller.c:2141:35: error: 'struct usbhost_state_s' has no member named 'fds'
               fds->priv    = &priv->fds[i];
                                   ^~
usbhost/usbhost_xboxcontroller.c:2159:11: warning: implicit declaration of function 'usbhost_pollnotify' [-Wimplicit-function-declaration]
           usbhost_pollnotify(priv);
           ^~~~~~~~~~~~~~~~~~

Think it's missing:

  /* The following is a list if poll structures of threads waiting for
   * driver events. The 'struct pollfd' reference for each open is also
   * retained in the f_priv field of the 'struct file'.
   */

  struct pollfd *fds[CONFIG_HIDMOUSE_NPOLLWAITERS];

inside struct usbhost_state_s

But I'm not entirely sure if that's the right fix.

Can we change armv8-m porting to apache license?

@patacongo, we are porting armv8-m arch base on armv7-m code base. Should we keep BSD license in the intial commit and wait you modify to apache license later?

nxstyle: Does not check for braces.

There is no check to assure that the statements following if, else, while, and for keywords are enclosed in braces. This requirement is true if even if no statments follow or if only a single statement follows: https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#ifthenelse

Wrong:
if (a == b)
return;

  while (foobar == 0);

drivers/video/isx012.c: Make forbidden calls into CXD56xx code

Common drivers must never call directly in architecture specific code. That is FORBIDDEN.

The driver at drivers/video/isx012.c does just that:

$ grep cxd56 drivers/video/isx012.c
  ret = cxd56_cisifinit();
      imagererr("Fail cxd56_cisifinit %d\n", ret);
  ret = cxd56_cisifstopcapture();
      imagererr("Fail cxd56_cisifstopcapture %d\n", ret);
  ret = cxd56_cisiffinalize();
      imagererr("Fail cxd56_cisiffinalize %d\n", ret);
      ret = cxd56_cisifsetdmabuf(&sarea);
      ret = cxd56_cisifstartcapture(&cis_param, &sarea);
  ret =  cxd56_cisifstopcapture();

That is in complete violation of the requirements of the NuttX modular design. This driver must either be corrected so that it uses a standard upper/lower half design as all other drivers do, or it must be removed, or it must be moved to boards/arm/cxd56xx/drivers/

nxstyle reporting error: Space precedes right parenthesis

There are case where we need to align the right parenthesis.

(it appears dealigned here, but if you copy to text editor you will see it is aligned)

const struct trace_msg_t g_usb_trace_strings_deverror[] =
{
TRACE_STR(STM32L4_TRACEERR_ALLOCFAIL ),
TRACE_STR(STM32L4_TRACEERR_BADCLEARFEATURE ),
TRACE_STR(STM32L4_TRACEERR_BADDEVGETSTATUS ),
TRACE_STR(STM32L4_TRACEERR_BADEPGETSTATUS ),
TRACE_STR(STM32L4_TRACEERR_BADEPNO ),
TRACE_STR(STM32L4_TRACEERR_BADEPTYPE ),
TRACE_STR(STM32L4_TRACEERR_BADGETCONFIG ),
TRACE_STR(STM32L4_TRACEERR_BADGETSETDESC ),
TRACE_STR(STM32L4_TRACEERR_BADGETSTATUS ),
TRACE_STR(STM32L4_TRACEERR_BADSETADDRESS ),

Please fix nxstyle to access this code beautification

pthread_mutex_lock() does not resume waiting after signal

According to the description of pthread_mutex_lock() (in the function's comment block):

"If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread resumes waiting for the mutex as if it was not interrupted."

But the code does not appear to do this.

pthread_mutex_lock() is a thin wrapper around pthread_mutex_timedlock() with a NULL abs_timeout. pthread_mutex_timedlock() calls pthread_mutex_take() with a intr value of true, which in turn calls pthread_sem_take() with intr value of true, which calls nxsem_wait(). nxsem_wait() returns -EINTR if awakened by a signal.

In the above mentioned callers, there does not appear to be logic to detect this case and resume waiting for the mutex as if it was not interrupted per the specification.

Notes:

(1) While the comment block above pthread_mutex_timedlock() does not make a similar statement as pthread_mutex_lock() regarding interruption by a signal, OpenGroup.org seems to suggest that it should: "The pthread_mutex_timedlock() function shall lock the mutex object referenced by mutex. If the mutex is already locked, the calling thread shall block until the mutex becomes available as in the pthread_mutex_lock() function."

(2) See the dev@ mailing list thread entitled "pthread_mutex_lock() and signals" started 13 Mar 2020, archived here: https://lists.apache.org/thread.html/rc366bf8ab1291e3f4d36ef90a2a2b4dc25d4f89db7ffc57df320e7ce%40%3Cdev.nuttx.apache.org%3E

nxstyle: No line with check on single line comments.

I haven't really verified this thoroughly, but nxstyle appears to skeip the line with check on some or all single line comments.

Certainly, it ignores the line width check on right hand comments all or most of the time. Those often extend will beyond the section headers.

Fixing the later would probably cause more problems than it would be worth. We would need to consider that carefully. Forcing all right hand commits to conform to the line width would like generate a lot of work for us and likely some discontent from contributors.

In .h files, it is not such a big issue because you can always extend the block comment with a little if need be. But this problem also occurs in the Pre-processor Definitions, Private Types, and Private Data sections of .c files. We would not want to have to extend the line width of the whole C file to accomodate that.

So I think there is a issue with the current nxstyle behavior and probably issues with correcting that behavior in all cases.

unclear coding standard examples

NuttXCCodingStandard.html lists the following examples in both of "Preferred" and "Acceptable".

extern int g_someint;
static int g_anotherint;

nxstyle include check is too strict

As a rule, all #include pre-processor commands must appear in the "Included Files" section: That section header must be in the file and all of the #include commands must follow.

However, there are exceptions. For example:

$ tools/nxstyle.exe arch/arm/include/xmc4/irq.h
arch/arm/include/xmc4/irq.h:81:3: warning: #include outside of 'Included Files' section
arch/arm/include/xmc4/irq.h:83:3: warning: #include outside of 'Included Files' section
arch/arm/include/xmc4/irq.h:85:3: warning: #include outside of 'Included Files' section

This kind of problem is the case with many architectures. I have been ignoring this error in the past, but it is harder to ignore with this automated style checker.

And in this case, the #include cannot be moved because it depends on a #define that must precede it. And you cannot move the #define or your will get a similar error. I think that there is no alternative but you use good engineering judgement and accept the change as is.

This kind of logic is very common in architecure specific code:

Set up some definitions, then
include some architecture specific code

You will see this a lot in arch/xyz/include and arch/src/xyz/hardware directories. This usually occurs int he "Pre-processor Definitions" section, and not in the "Included Files" section.

Ideally, then all #include's should be in the "Included Files" section. But there are exceptions where it makes sense to relax this requirement. So example iss one and there are several others.

I don't know of any way to programmatically "relax" the requirement other than inspecting the nxstyle complaint and then making a good, informed engineering decision. One possibility to to assure that "Included Files" was encountered sometime prior to the #include command. That would allow the #include to occur in any section after the "Included Files" section but would have the odd side-effect of requiring that an "Included Files" section is present even when there are no other files to include. That would, however, be rare.

nxstyle: Suppress checking in strings/comments.

nxstyle does not detect when it is within a string and will report crazy things because it is parsing the strng content. For example, if the string contains "Hello", nxstyle would probleam complain about mixed case identifiers, if the strong contains "https://", it would probably complete about C++ style comments. If the string contains "yes/no" it would probably complain about missing spaces before and after an operator.

Below is a even more obsure false alarm example:

junk.c:

/****************************************************************************
 * Private Data
 ****************************************************************************/

static const char g_blabber[] = "Yadda, yadda, yadda, yadda";

/****************************************************************************
* Public Functions
****************************************************************************/

then you see:

$ tools/nxstyle.exe junk.c
junk.c:5:39: error: Multiple data definitions

In this case, nxstyle should ignore the ',' characters is within a string.

Most of this also applies to comments. You will see the same kinds of errors for similer sub-strings within a comment. nxstyle does detect that it is within a comment, however, it does not use that information to suppress certain error reports.

Remove CONFIG_FS_WRITABLE

This is kind of a useless configuration variable that occurs in many places and adds a lot of complexity and makes debug a lot more difficult.

It makes debug more difficult because it is not consistently set and requires a lot of debug time before you finally figure out "I need to set CONFIG_FS_WRITABLE.

In most places affected by CONFIG_FS_WRITABLE, the configuration option is stupid: Who needs read-only MMC or read-only SmartFS. Just not a useful thing. And many places that do need CONFIG_FS_WRITABLE do not automatically set it. Like drivers/mtd/ftl.c. In that case, you can debug for most of the day before you finally figure out why the you can't access flash via character driver (which is a really common configuration for resource limited platforms).

It is hard to imagine a platform that supports a file system but has no writing enabled. I could imagine a system with only ROMFS or only CROMFS. But that is really about it and, in those cased, CONFIG_FS_WRITABLE has no effect. I am not aware of any such case, but that would be the only kind of platform that would suffer from the change.

But my opinion is that in the bigger picture, NuttX would be cleaner, less complex, and more usable with CONFIG_FS_WRITABLE removed.

Document checkpatch.sh arguments with examples.

from #448 (comment)

Missing LICENSE and NOTICE file

All ASF project need a LICENSE and NOTICE file. I note view license is pointing to COPYING which contains possible out of date information.

Use lcd ssd1289 in stm32f4discovery failed

I use the config "CONFIG_EXAMPLES_LVGLDEMO=y, CONFIG_LCD_SSD1289=y and CONFIG_VIDEO_FB=y" in "stm32f4discovery:usbnsh", and can be compiled. But when I run the lvgldemo application in nsh, I get the error "ERROR: Failed to open /dev/fb0: 2". I don't know what went wrong. How can i solve this problem?

tools/nxstyle.c: FALSE alarms on right hand aligned comments.

When ran against any file that has comments to the right of definitions, a false alarm can occur. Such right-hand comments should be vertically aligned, but have not specific alignment requirement with regard to the start of the line or any indentation.

In many casese, there are comments on a separate line are correctly aligned with the other right hand comments. This is necessary for the visually alignment, but results in a false alarm error from nxstyle. Consider the following from include/nuttx/can/can.h:

579   struct can_txfifo_s  cd_xmit;          /* Describes transmit FIFO */
580 #ifdef CONFIG_CAN_TXREADY
581   struct work_s        cd_work;          /* Use to manage can_txready() work */
582 #endif
583                                          /* List of pending RTR requests */
584   struct can_rtrwait_s cd_rtr[CONFIG_CAN_NPENDINGRTR];
585   FAR const struct can_ops_s *cd_ops;    /* Arch-specific operations */

Running nxstyle against that file generates this false alarm:

include/nuttx/can/can.h:583:1: error: Missing blank line after comment

Analysis: Notice that there is no error about the missing blank line BEFORE the comment at 583. That is because there is information that the preceding line is right-hand aligned.

498   bool brhcomment;      /* True: Comment to the right of code */
499   bool prevbrhcmt;      /* True: previous line had comment to the right of code */

The problem is that the state information is not propagated at line 583. Could the solution be as simple as just make sure that brhcomment is set true again when the conditioni of line 583 is encountered?

tools/testbuild.sh breaks non-git usage

Regarding commit 27142b2e3c4c6498dc198818ec9b260d8ffff12f, this means
that tools/testbuild.sh now depends on git and on the NuttX
distribution being a git clone.

The problem with depending on git is that users who work with release
tarballs and/or don't have git can no longer use NuttX.

We should not clean with git unless doing so in a git clone. If not a git clone, we should invoke 'make distclean' as we were doing previously.

Windows Configure Warnings

For the past few weeks, I have bee seen new warnings when I configure any board under Cygwin or MSYS. There are the warning I see right now on MSYS (same warnings on Cygwin):

$ tools/configure.sh -g z20x:sdboot
  Copy files
  Select CONFIG_HOST_WINDOWS=y
  Select CONFIG_WINDOWS_MSYS=y
  Refreshing...
.config:54:warning: override: reassigning to symbol HOST_WINDOWS
.config:54:warning: override: HOST_WINDOWS changes choice state

I think the first is caused by

# CONFIG_HOST_WINDOWS is not set

followed by

CONFIG_HOST_WINDOWS=y

That is invalid because CONFIG_HOST_WINDOWS is both disable and enabled. The correctly solution would be either (2) use kconfig-tweak which will to both or (2) use sed to expicitly remove CONFIG_HOST_WINDOWS before adding CONFIG_HOST_WINDOWS=y

NXStyle: Ignore alignments of block comments at right of code

NXstyle rightfully ignores single comments at right of code, for instance within a struct declaration.
But complaints about a block comment.

struct a_struct_s
{
   uint8_t f1; /* Long line in a single comment, OK. */
   uint8_t f2; /* Long line in a block comment,
                * nxstyle complains.
                */
};

nxstyle: "Multiple data definitions" false alarm

nxstyle complains "Multiple data definitions" on the following line in apps/examples/module/module_main.c

static const char g_write_string[] = "Hi there, installed driver\n";

it seems it is confused with "," in the string.

_xtensa_panic clobbers the exception code

_xtensa_panic saves the exception code in EXCSAVE_1 and then calls _xtensa_context_save, which uses EXCSAVE_1 for its own purpose and thus clobbers the saved exception code.

Should the makefile warn if there isn't a valid APPDIR?

If you run the ./tools/configure.sh script without a ../apps folder or without setting APPDIR you get errors like below without any helpful reason what is going on. It took several minutes to figure it out.

nuttx$ ./tools/configure.sh olimex-stm32-e407:nsh
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
make: the '-C' option requires a non-empty string argument
Usage: make [options] [target] ...
Options:
...

Thoughts on having the Makefile check for this folder to provide reasonable warning/error messages?

Add intree board config to test the relative CUSTOM board tooling

See #594 (comment) for Context

In the past and recently changes in make files have broken the CUSTOM board tooling.

CONFIG_ARCH_BOARD_CUSTOM=y
CONFIG_ARCH_BOARD_CUSTOM_DIR="../nuttx-config"
CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH=y
CONFIG_ARCH_BOARD_CUSTOM_NAME="tvc15-pro"
CONFIG_ARCH_CHIP="stm32h7"
CONFIG_ARCH_CHIP_STM32H743ZI=y
CONFIG_ARCH_CHIP_STM32H7=y

Adding a config will insure this does not continue to happen

Hard fault in networking stack.

Running the uIP based web server on an STM32F4 with Ethernet connection, I get errors and eventually a hard fault provoked by loading multiple pages (opening multiple connections on port 80) in quick succession, e.g. by loading a web page that includes a couple of css files, a couple of js files and a couple of images.

The errors are:

tcp_datahandler: ERROR: Failed to create new I/O buffer chain

This is from iob_tryalloc failing to allocate a buffer. It is repeated multiple times per page load. More rarely I see:

tcp_datahandler: ERROR: Failed to add data to the I/O buffer chain: -12

Initially this resulted in most of the connections failing and httpd processes hanging, but after setting CONFIG_NET_TCPBACKLOG_CONNS to 8 the page almost always fully loads (connections succeed) despite the errors.

However within a minute or two of repeatedly reloading pages, I get a hard fault.

up_hardfault: PANIC!!! Hard fault: 40000000
up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 148 task: <pthread>
up_registerdump: R0: 00000000 200153e0 20010820 00000000 00000000 20012a60 00000000 ffffffff
up_registerdump: R8: ffffffff 00000000 2001bd62 00000002 000012c0 200163d8 080197eb 08012860
up_registerdump: xPSR: 00000000 PRIMASK: 00000001 CONTROL: 00000000
up_registerdump: EXC_RETURN: fffffff9
up_dumpstate: sp:     200014a8
up_dumpstate: IRQ stack:
up_dumpstate:   base: 20001500
up_dumpstate:   size: 00000800
up_stackdump: 200014a0: 20001500 08000cd7 00000001 00000000 00000002 000012c0 200163d8 080197eb
up_stackdump: 200014c0: 08012860 08021178 00000003 0800110d 080010cd 2000d8c0 2001638c 080014fd
up_stackdump: 200014e0: 00000001 080011f5 00000001 2001638c 20012a60 00000000 ffffffff 08000dc3
up_dumpstate: sp:     200163d8
up_dumpstate: User stack:
up_dumpstate:   base: 20016478
up_dumpstate:   size: 00000ffc
up_stackdump: 200163c0: 20010820 00000000 000012c0 080197eb 08012860 00000000 2000bba8 20012ab8
up_stackdump: 200163e0: 20012ab8 0800f275 20012ab8 20012a60 2001add6 2001ac70 08028030 0800e399
up_stackdump: 20016400: 2000bba8 20012ab8 2001add6 0800e4e7 2001bda4 08014087 2001bda4 08007ff9
up_stackdump: 20016420: 20015360 08019255 00000000 0000000b 2001be34 2001adb8 00000000 20015360
up_stackdump: 20016440: 20015460 20012880 2001288c 00000000 00000000 00000000 00000000 08018aa9
up_stackdump: 20016460: 00000000 00000000 00000000 00000000 00000000 00000000 000101aa 00000001

R15 is inside _net_timedwait and R14 is inside nxsem_wait.

I've attached the map.

System.map.txt

Also my config:

defconfig.txt

undefined reference to `_eramfuncs' when enabled CONFIG_ARCH_RAMFUNCS

Hi ,
undefined reference to "_framfuncs", "_sramfuncs", "_eramfuncs" when enabled CONFIG_ARCH_RAMFUNCS for SAMV71-XULT.
I can find these definitions of these variables, in armv7-r/arm_heads.S, but in other architecture, no definition could be found.
Best Rds

Remove CONFIG_CAN_PASS_STRUCTS

The configuration option CONFIG_CAN_PASS_STRUCTS was added many years ago to support an old version of the SDCC compiler. That compiler is currently used only with the Z80 and Z180 targets. The limitation of that old compiler was that it could not pass structures or unions as either inputs or outputs. For example:

#ifdef CONFIG_CAN_PASS_STRUCTS
struct mallinfo mallinfo(void);
#else
int      mallinfo(FAR struct mallinfo *info);
#endif

And even leads to violation of a few POSIX interfaces like:

#ifdef CONFIG_CAN_PASS_STRUCTS
int  sigqueue(int pid, int signo, union sigval value);
#else
int  sigqueue(int pid, int signo, FAR void *sival_ptr);
#endif

This breaks the 1st INVIOLABLES rule:

Strict POSIX compliance
-----------------------

  o Strict conformance to the portable standard OS interface as defined at
    OpenGroup.org.
  o A deeply embedded system requires some special support.  Special
    support must be minimized.
  o The portable interface must never be compromised only for the sake of
    expediency.
  o Expediency or even improved performance are not justifications for
   violation of the strict POSIX interface

Also, it appears that the current SDCC compilers have resolve this issue and so, perhaps, this is no longer a problem: z88dk/z88dk#1132

I am waiting for confirmation from the SDCC developer that the issue has been fixed.

An idea to reduce duplicate code in ./boards/.

Hi,

I noticed that there are a lot of file duplication in the ./boards/ directory. This is probably a very late point in time to try and fix this, but I am prepared to give it a go. In my PR #78, I added a tool for exposing this.

Before I start, I'd like to make it absolutely clear that I am not trying to say that this is bad or anything in those lines. I simply don't believe that duplicate code is good. It's hard to maintain and hard to stop from getting duplicated even more.

Let's take the following example:

How many stm32_autoleds.c files do we have in ./boards/?

$ find ./boards/ -type f -name stm32_autoleds.c |wc -l
49

The answer is 49 files. This is not bad, just a fact.

Now the interesting part starts. We'll list the 20 most common combinations of files that are the most common. The ./tools/listcommonpercentage.sh from PR #78 lists the following (file, common_%, file, common_%):

find ./boards/ -type f -name stm32_autoleds.c |grep -v nero |PERCENT_SIGN="" DELIM=" " xargs ./tools/listcommonpercentage.sh |sort -nk2 -nk4 |tail -20
./boards/arm/stm32/photon/src/stm32_autoleds.c 99 ./boards/arm/stm32l4/b-l475e-iot01a/src/stm32_autoleds.c 99
./boards/arm/stm32/stm3220g-eval/src/stm32_autoleds.c 99 ./boards/arm/stm32/stm3240g-eval/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32/nucleo-f103rb/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32/nucleo-f302r8/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32/nucleo-f334r8/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32/nucleo-l152re/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/b-l072z-lrwan1/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/nucleo-g071rb/src/stm32_autoleds.c 99
./boards/arm/stm32/stm32f334-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c 99
./boards/arm/stm32f0l0g0/nucleo-f091rc/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/nucleo-f072rb/src/stm32_autoleds.c 99
./boards/arm/stm32f0l0g0/nucleo-g071rb/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/b-l072z-lrwan1/src/stm32_autoleds.c 99
./boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/b-l072z-lrwan1/src/stm32_autoleds.c 99
./boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c 99 ./boards/arm/stm32f0l0g0/nucleo-g071rb/src/stm32_autoleds.c 99
./boards/arm/stm32f7/stm32f746g-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32f7/stm32f769i-disco/src/stm32_autoleds.c 99
./boards/arm/stm32h7/nucleo-h743zi/src/stm32_autoleds.c 99 ./boards/arm/stm32f7/nucleo-144/src/stm32_autoleds.c 99
./boards/arm/stm32h7/nucleo-h743zi/src/stm32_autoleds.c 99 ./boards/arm/stm32h7/stm32h747i-disco/src/stm32_autoleds.c 99
./boards/arm/stm32l4/nucleo-l496zg/src/stm32_autoleds.c 99 ./boards/arm/stm32f7/nucleo-144/src/stm32_autoleds.c 99
./boards/arm/stm32l4/stm32l4r9ai-disco/src/stm32_autoleds.c 99 ./boards/arm/stm32l4/stm32l476vg-disco/src/stm32_autoleds.c 99
./boards/arm/stm32/nucleo-f207zg/src/stm32_autoleds.c 100 ./boards/arm/stm32/nucleo-f303ze/src/stm32_autoleds.c 100
./boards/arm/stm32f0l0g0/stm32f051-discovery/src/stm32_autoleds.c 100 ./boards/arm/stm32f0l0g0/stm32f072-discovery/src/stm32_autoleds.c 100

So, the 20 most common file combinations are >= 99% copies of each other. Does it hurt? Well, only if these files have a bit of code in them. For sure they have code in them, 58 lines of it. This means that if we could get rid of the duplication, we'll save 58 * .99 * (20/2 - 1) = 516 lines of code.

https://github.com/apache/incubator-nuttx/blob/97bead5496614029e612b553daaab5856592df49/boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c#L36-L94

Let's look at a diff of a random pair:

$ diff -u ./boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c

./boards/arm/stm32f0l0g0/b-l072z-lrwan1/src/stm32_autoleds.c
--- ./boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c 2019-12-13 17:09:50.704153380 +0000
+++ ./boards/arm/stm32f0l0g0/b-l072z-lrwan1/src/stm32_autoleds.c        2019-12-13 17:09:50.704153380 +0000
@@ -1,5 +1,5 @@
 /****************************************************************************
- * boards/arm/stm32f0l0g0/nucleo-l073rz/src/stm32_autoleds.c
+ * boards/arm/stm32f0l0g0/b-l072z-lrwan1/src/stm32_autoleds.c
  *
  *   Copyright (C) 2018 Gregory Nutt. All rights reserved.
  *   Authors: Mateusz Szafoni <[email protected]>
@@ -44,11 +44,10 @@
 #include <debug.h>
 
 #include <nuttx/board.h>
+#include <arch/board/board.h>
 
 #include "stm32_gpio.h"
-#include "nucleo-l073rz.h"
-
-#include <arch/board/board.h>
+#include "b-l072z-lrwan1.h"
 
 #ifdef CONFIG_ARCH_LEDS

Actually, if you look closer, only the following 2 lines differ:

#include "nucleo-l073rz.h"
#include "b-l072z-lrwan1.h"

So if we could include a file with a common name here, which should be easy, the files will be 100% copies.

The final step will be to find a place for the (common) stm32_autoleds.c file.
I would suggest it has to live in ./boards/<somewhere>/drivers/, but we have at least 5 for this case:

$ find ./boards/arm/ -maxdepth 1 -type d -name stm32\*
./boards/arm/stm32
./boards/arm/stm32h7
./boards/arm/stm32f0l0g0
./boards/arm/stm32l4
./boards/arm/stm32f7

This makes me think that ./boards/arm/drivers/, which does not exist yet, would be the right place for it. If this is the right place, I'll have to add this directory and bind it into the whole make process, which should also not be such a problem.

I'll appreciate any feedback on this idea and I would like to add that I am prepared to continue with the implementation of this or any related idea, in order to reduce the code duplication.

Thanks & regards

nxstyle: header files that are not header files.

There is an issue with the graphics/nxglib/nxglib_fillrun.h header file (and probably others).

It is not really a header file. It is a "template" of a C file that is included with some definitions to make a complete C file. So it will NOT pass the tests for a header file.

See:

graphics/nxglib/lcd/nxglib_fillrectangle.c
graphics/nxglib/lcd/nxglib_filltrapezoid.c

It is not clear how this case should be handled. I believe we either have change the file name extension (but then it won't be checked at all) or change the extension to .c (which is misleading too).

Reference: PR #478

Cannot build NuttX with a romfs image

I cannot build NuttX with a romfs image.

CC:  stm32_romfs_initialize.c
{standard input}: Assembler messages:
{standard input}:498: Error: can't resolve `.rodata' {.rodata section} - `.Ltext0' {.text section}
{standard input}:499: Error: can't resolve `.rodata' {.rodata section} - `.Ltext0' {.text section}
{standard input}:502: Error: can't resolve `.rodata' {.rodata section} - `.Ltext0' {.text section}
{standard input}:503: Error: can't resolve `.rodata' {.rodata section} - `.Ltext0' {.text section}
/home/ysugino/incubator-nuttx/nuttx/boards/Board.mk:109: recipe for target 'stm32_romfs_initialize.o' failed
make[2]: *** [stm32_romfs_initialize.o] Error 1
make[2]: Leaving directory '/home/ysugino/incubator-nuttx/nuttx/boards/arm/stm32/stm32f4discovery/src'
Makefile:181: recipe for target 'board/libboard.a' failed
make[1]: *** [board/libboard.a] Error 2
make[1]: Leaving directory '/home/ysugino/incubator-nuttx/nuttx/arch/arm/src'
tools/Makefile.unix:465: recipe for target 'pass2' failed
make: *** [pass2] Error 2

Steps to reproduce

1. Make a configuration

$ ./tools/configure.sh stm32f4discovery:rndis

2. Make a romfs image

$ mkdir foo
$ cd foo/
$ echo bar > baz
$ genromfs -f rom.img
$ cp rom.img /PATH_TO_NUTTX_DIR/

3. Enable FS_ROMFS and STM32_ROMFS

$ make menuconfig

4. Build NuttX

$ make

Workaround

I found a following workaround.

diff --git a/boards/arm/stm32/stm32f4discovery/src/stm32_romfs_initialize.c b/boards/arm/stm32/stm32f4discovery/src/stm32_romfs_initialize.c
index 9f63db65ad..79839b84c1 100644
--- a/boards/arm/stm32/stm32f4discovery/src/stm32_romfs_initialize.c
+++ b/boards/arm/stm32/stm32f4discovery/src/stm32_romfs_initialize.c
@@ -93,7 +93,8 @@ __asm__ (
 "romfs_data_end:\n"
     ".globl   romfs_data_size\n"
 "romfs_data_size:\n"
-    ".word romfs_data_end - romfs_data_begin\n");
+    ".word romfs_data_end - romfs_data_begin\n"
+    ".text\n");

 extern const char romfs_data_begin;
 extern const char romfs_data_end;

Locking case in SMP mode

Recently I use qemu to simulate the sabre-6quad board based on the SMP defconfig .

When turn on CONFIG_DEBUG_FEATURES CONFIG_DEBUG_ERROR options and run app/testing/smp program , the nuttx system was locked.

See call stack, I found the thread1 was locked at spinlock() and thread2 was locked at enter_critial_section().

Turn off the CONFIG_DEBUG_ERROR options and the SMP program runs normally.

What could be the problem?

My defconfig is as follows:
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD="sabre-6quad"
CONFIG_ARCH_BOARD_SABRE_6QUAD=y
CONFIG_ARCH_BUTTONS=y
CONFIG_ARCH_CHIP="imx6"
CONFIG_ARCH_CHIP_IMX6=y
CONFIG_ARCH_CHIP_IMX6_6QUAD=y
CONFIG_ARCH_INTERRUPTSTACK=2048
CONFIG_ARCH_IRQBUTTONS=y
CONFIG_ARCH_LOWVECTORS=y
CONFIG_ARCH_STACKDUMP=y
CONFIG_BOARD_LOOPSPERMSEC=99369
CONFIG_BOOT_RUNFROMSDRAM=y
CONFIG_BUILTIN=y
CONFIG_DEBUG_ASSERTIONS=y
CONFIG_DEBUG_ERROR=y
CONFIG_DEBUG_FEATURES=y
CONFIG_DEBUG_FULLOPT=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_SYMBOLS=y
CONFIG_DEBUG_WARN=y
CONFIG_DEV_ZERO=y
CONFIG_FS_PROCFS=y
CONFIG_HAVE_CXX=y
CONFIG_HAVE_CXXINITIALIZE=y
CONFIG_IMX6_UART1=y
CONFIG_IMX_DDR_SIZE=1073741824
CONFIG_INTELHEX_BINARY=y
CONFIG_MAX_WDOGPARMS=2
CONFIG_NFILE_DESCRIPTORS=8
CONFIG_NFILE_STREAMS=8
CONFIG_NSH_ARCHINIT=y
CONFIG_NSH_BUILTIN_APPS=y
CONFIG_NSH_FILEIOSIZE=512
CONFIG_NSH_READLINE=y
CONFIG_PREALLOC_MQ_MSGS=4
CONFIG_PREALLOC_TIMERS=4
CONFIG_RAMLOG=y
CONFIG_RAM_SIZE=1073741824
CONFIG_RAM_START=0x10000000
CONFIG_RAM_VSTART=0x10000000
CONFIG_RAW_BINARY=y
CONFIG_RR_INTERVAL=200
CONFIG_SCHED_HPWORK=y
CONFIG_SCHED_HPWORKPRIORITY=192
CONFIG_SCHED_WAITPID=y
CONFIG_SMP=y
CONFIG_SMP_NCPUS=2
CONFIG_START_MONTH=3
CONFIG_START_YEAR=2016
CONFIG_SYMTAB_ORDEREDBYNAME=y
CONFIG_SYSTEM_NSH=y
CONFIG_SYSTEM_NSH_CXXINITIALIZE=y
CONFIG_TESTING_SMP=y
CONFIG_TESTING_SMP_NBARRIER_THREADS=4
CONFIG_UART1_SERIAL_CONSOLE=y
CONFIG_USER_ENTRYPOINT="nsh_main"

The nxstyle is generating false alarm

Hi Haitao Liu, when you have the chance, could you please verify the false alarm reported by nxstyle when handling code block delimited by { } ?

Example:

/* Bulk OUT endpoint descriptor */

{
int len = usbmsc_copy_epdesc(USBMSC_EPBULKOUT,
(FAR struct usb_epdesc_s *)buf, devinfo,
hispeed);

buf += len;
length += len;

}

The alignment of the left and right braces are correct, but nxstyle get confused because there is not an if/while/switch, etc before the brace.

See more examples here:

=== drivers/usbdev/usbmsc_desc.c =============================================
drivers/usbdev/usbmsc_desc.c:342:2: error: Bad left brace alignment
drivers/usbdev/usbmsc_desc.c:343:4: error: Bad comment alignment
drivers/usbdev/usbmsc_desc.c:344:5: error: Bad comment block alignment
drivers/usbdev/usbmsc_desc.c:345:5: error: Bad comment block alignment
drivers/usbdev/usbmsc_desc.c:346:5: error: Bad comment block alignment
drivers/usbdev/usbmsc_desc.c:368:2: error: Bad right brace alignment
drivers/usbdev/usbmsc_desc.c:373:2: error: Bad left brace alignment
drivers/usbdev/usbmsc_desc.c:374:4: error: Bad alignment
drivers/usbdev/usbmsc_desc.c:390:2: error: Bad right brace alignment
drivers/usbdev/usbmsc_desc.c:396:2: error: Bad left brace alignment
drivers/usbdev/usbmsc_desc.c:402:2: error: Bad right brace alignment
drivers/usbdev/usbmsc_desc.c:406:2: error: Bad left brace alignment
drivers/usbdev/usbmsc_desc.c:413:2: error: Bad right brace alignment

Thank you very much in advance!

SMP for Cortex-A MPcore is unstable

There were several discussions on SMP issues for Cortex-A MPcore in NuttX mailing list before.
Yesterday I tried sabre-6quad:smp configuration with QEMU, and noticed that it's unstable even
if I changed the configuration to use only 2cores instead of 4cores.

Actually, heap memory was sometimes corrupted during booting up the secondary core.
Even if it succeeded to boot, heap memory was corrupted when a new task is created.
They are very basic use-cases and should work with QEMU.

So, I think something is wrong with Cortex-A SMP implementation, because Cortex-M SMP
(e.g. Sony Spresense in dual core mode) and RISC-V SMP (K210 Maix-bit) are much more stable.

IP Clearance

All files developed at the ASF need to have an ASF header [1], 3rd party headers for the most part need to be retained [2]

1. https://www.apache.org/legal/src-headers.html#headers
2. https://www.apache.org/legal/src-headers.html#3party

possible nxstyle false alarm: "Missing space before closing C comment"

nxstyle claims "Missing space before closing C comment" on lines like the following:

      cpu  = sched_cpu_select(ALL_CPUS /* ptcb->affinity */);

in sched/sched/sched_mergepending.c.
i don't understand what it isn't happy about.

A error in include/errno.h?

This logic seems to be wrong,(&& !defined(KERNEL))seems redundant.
This error looks like copying a line of code, changing it, but forgetting to delete the extra parts.
To be honest, I often make this kind of mistakes.

#elif defined(CONFIG_BUILD_KERNEL) && !defined(__KERNEL__)
#  if defined(__KERNEL__)
   /* Kernel build.  Kernel code has direct access */

#    define __DIRECT_ERRNO_ACCESS 1

#  else
   /* User libraries for the kernel.  Only indirect access from user
    * libraries
   */

#    undef __DIRECT_ERRNO_ACCESS
#  endif
#endif