examples/elf: add possibility to create romfs image

[Laczen]

Add the possibility to create a romfs image for an "external" file system. The romfs.img can directly be written to a configurable mtdblock device.

Summary

The elf loader can also be used to generate a romfs.img that contains applications. This romfs.img can be written directly to a internal mtdblock device. The example then provides a method to illustrate how to separate kernel from applications and allows recompilation and update of the romfs without a kernel update.

Impact

None, it is an extra sample configuration.

Testing

Tested on esp32_devkitc:elf. The example configuration is:

<*> ELF Loader Example
        ELF File System (External File system)  --->
[*]     Mount external file system
[ ]         Removable file system
(romfs) External file system type
(/dev/mtdblock0) Block driver device path
[ ]     Link with LIBC

After compilation the romfs.img is copied to mtdblock0 using (0x180000 is the start of mtdblock0):

esptool.py write_flash 0x180000 nuttx/apps/examples/elf/tests/romfs.img

The test is then performed as:

nsh> elf
Initial memory usage: 13908
Mounting romfs filesystem at target=/mnt/elf/romfs on /dev/mtdblock0

Memory Usage after mount:
  Before:    13908 After:    19052 Change:     5144

****************************************************************************
* Executing errno
****************************************************************************


Memory Usage after exec:
  Before:    19052 After:    22324 Change:     3272
Hello, World on stdout
Wait a bit for test completion
Hello, World on stderr
We failed to open "aflav-sautga-ay!" errno is 0

Memory Usage after program execution:
  Before:    22324 After:    22140 Change:     -184

****************************************************************************
* Executing hello
****************************************************************************


Memory Usage after exec:
  Before:    22140 After:    22324 Change:      184
Wait a bit for test completion
Getting ready to say "Hello, world"

Hello, world!
It has been said.

argc    = 1
argv    = 0x3ffe38b8
argv[0] = (0x3ffe38c0) "hello"
argv[1] = 0
Goodbye, world!

Memory Usage after program execution:
  Before:    22324 After:    22140 Change:     -184

****************************************************************************
* Executing hello++1
****************************************************************************


Memory Usage after exec:
  Before:    22140 After:    22324 Change:      184
Wait a bit for test completion
Hello, World!

Memory Usage after program execution:
  Before:    22324 After:    22140 Change:     -184

****************************************************************************
* Executing hello++2
****************************************************************************


Memory Usage after exec:
  Before:    22140 After:    22324 Change:      184
Wait a bit for test completion
main: Started.  Creating MyThingSayer
CThingSayer::CThingSayer: I am!
main: Created MyThingSayer=0x3ffe3120
main: Calling MyThingSayer->Initialize
CThingSayer::Initialize: When told, I will say 'Hello, World!'
main: Calling MyThingSayer->SayThing
CThingSayer::SayThing: I am now saying 'Hello, World!'
main: Destroying MyThingSayer
CThingSayer::~CThingSayer: I cease to be
CThingSayer::~CThingSayer: I will never say 'Hello, World!' again
main: Returning

Memory Usage after program execution:
  Before:    22324 After:    22140 Change:     -184

****************************************************************************
* Executing hello++3
****************************************************************************


Memory Usage after exec:
  Before:    22140 After:    22348 Change:      208
Wait a bit for test completion
CThingSayer::CThingSayer: I am!
main: Started.  MyThingSayer should already exist
main: Calling MyThingSayer.Initialize
CThingSayer::Initialize: When told, I will say 'Hello, World!'
main: Calling MyThingSayer.SayThing
CThingSayer::SayThing: I am now saying 'Hello, World!'
main: Returning.  MyThingSayer should be destroyed
CThingSayer::~CThingSayer: I cease to be
CThingSayer::~CThingSayer: I will never say 'Hello, World!' again

Memory Usage after program execution:
  Before:    22348 After:    22140 Change:     -208

****************************************************************************
* Executing mutex
****************************************************************************


Memory Usage after exec:
  Before:    22140 After:    22380 Change:      240
Wait a bit for test completion
Starting thread 1
Starting thread 2
Stopping threads
        Thread1 Thread2
Loops   10      10
Errors  0       0

Memory Usage after program execution:
  Before:    22380 After:    26684 Change:     4304

****************************************************************************
* Executing pthread
****************************************************************************


Memory Usage after exec:
  Before:    26684 After:    22324 Change:    -4360
Wait a bit for test completion
PARENT: started

PARENT: calling pthread_start with arg=305419896
CHILD: started with arg=305419896
CHILD: returning -2023406815
PARENT child exitted with -2023406815
PARENT returning success


Memory Usage after program execution:
  Before:    22324 After:    24412 Change:     2088

****************************************************************************
* Executing signal
****************************************************************************


Memory Usage after exec:
  Before:    24412 After:    22348 Change:    -2064
Wait a bit for test completion
Setting up signal handlers from pid=13
Old SIGUSR1 sighandler at 0
New SIGUSR1 sighandler at 0x40086480
Old SIGUSR2 sighandler at 0
New SIGUSR2 sighandler at 0x40086480
Raising SIGUSR1 from pid=13
Kill-ing SIGUSR1 from pid=13
siguser_action: Received signo=10 siginfo=0x3ffb13fc arg=0
  SIGUSR1 received
siginfo:
  si_signo  = 10
  si_code   = 0
  si_errno  = 4
  si_value  = 0
SIGUSR1 raised from pid=13
SIGUSR1 not received

Memory Usage after program execution:
  Before:    22348 After:    22172 Change:     -176

****************************************************************************
* Executing struct
****************************************************************************


Memory Usage after exec:
  Before:    22172 After:    22380 Change:      208
Wait a bit for test completion
Calling getstruct()
getstruct returned 0x40086688
  n = 42 (vs 42) PASS
  pn = 0x3ffe3290 (vs 0x3ffe3290) PASS
 *pn = 87 (vs 87) PASS
  ps = 0x40086684 (vs 0x40086684) PASS
  ps->n = 117 (vs 117) PASS
  pf = 0x40086454 (vs 0x40086454) PASS
Calling mystruct->pf()
In dummyfunc() -- PASS
Exit-ing

Memory Usage after program execution:
  Before:    22380 After:    22172 Change:     -208

****************************************************************************
* Executing task
****************************************************************************


Memory Usage after exec:
  Before:    22172 After:    22412 Change:      240
Wait a bit for test completion
Parent: Started, pid=20
Parent: Calling task_create()
Parent: Waiting for child (pid=22)
Child: execv was successful!
Child: argc=2
Child: argv[0]="child"
Child: argv[1]="Hello from your parent!"
Child: Exit-ting with status=0
Parent: Exit-ing

Memory Usage after program execution:
  Before:    22412 After:    25260 Change:     2848

Memory Usage End-of-Test:
  Before:    25260 After:    25260 Change:        0
nsh> 

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although some minor improvements could be made.

Strengths:

• Clear Summary: The summary explains the change, its purpose, and how it works.
• Impact Assessment: While concise, it addresses all the points. "None" is acceptable for most if the change is truly isolated.
• Testing: Includes host/target details and provides before and after logs demonstrating functionality.

Areas for Improvement:

• Relate to an issue: Even if this is a new feature without a prior issue, it's good practice to create an issue first to discuss the idea and get feedback before implementing it. This facilitates community involvement and avoids wasted effort. The PR can then reference the issue.
• More detail on how it works: The summary mentions using the ELF loader to generate a romfs.img. A little more detail here would be helpful. Does this involve new Kconfig options? Changes to the build system? Mentioning specific files modified would make it easier for reviewers.
• Testing - Clarity on before: The "before" logs are unclear. What was the previous behavior? Since this is a new feature, the before might simply be the absence of the feature, but it's worth explicitly stating that. Or perhaps the "before" is a system without the external romfs, and you're showing that the elf loader still works as expected for internal romfs.

Conclusion:

The PR is well-structured and provides the necessary information. Adding an associated issue and slightly expanding the technical details and "before" test explanation would strengthen it further.

[cederom]

Thank you @Laczen very nice feature!! :-)

Some trivial code formatting to be fixed (https://nuttx.apache.org/docs/latest/contributing/coding_style.html).

Would it be possible to add nuttx/documentation in this area please? :-)

[Laczen]

Thank you @Laczen very nice feature!! :-)

Some trivial code formatting to be fixed (https://nuttx.apache.org/docs/latest/contributing/coding_style.html).

Would it be possible to add nuttx/documentation in this area please? :-)

I didn't realize the coding_style was also valid for the nuttx-apps, I thought the requirements where relaxed to allow direct integration of external code. I will correct the errors.

Regarding the documentation, is it correct to add sample documentation for nuttx-apps in the NuttX/documentation? This seems very fragile and risks to get out of sync.

[cederom]

Thank you @Laczen very nice feature!! :-)
Some trivial code formatting to be fixed (https://nuttx.apache.org/docs/latest/contributing/coding_style.html).
Would it be possible to add nuttx/documentation in this area please? :-)

I didn't realize the coding_style was also valid for the nuttx-apps, I thought the requirements where relaxed to allow direct integration of external code. I will correct the errors.

The coding standard is both for NuttX and the Apps, so we have all clean, thanks :-)

Regarding the documentation, is it correct to add sample documentation for nuttx-apps in the NuttX/documentation? This seems very fragile and risks to get out of sync.

Yes, docs are in nuttx repo, also for the apps part, with smaller updates in the code coupled with the documentation updates we should be able to keep things in sync :-) Thus my question to document this nice feature I am sure there are other folks that may find it useful :-)

[acassis]

Just fix the compilation issues add Documentation