I will babble on because I am feeling chatty today.
Let me explain more about the role of apps/tools/mkromfsimg.sh in the KERNEL build.
In the kernel build, there are not tasks. There are only processes and all code lives in its own, private address space.
One consequence of that is that task_create() and friends cannot be used in the KERNEL build mode. Instead, all processes are loaded into a virtual address space from an ELF or NxFLAT file in the file system.
You have probably seen logic like this and wonder what was going on:
#ifdef CONFIG_BUILD_KERNEL
int main(int argc, FAR char *argv[])
#else
int hello_main(int argc, char *argv[])
#endif
In the FLAT and PROTECTED build mode all applications are built into a single BLOB, every symbol must have a unique name to avoid collitions.
In the KERNEL build mode, all applications are built at separated linked programs in the file system. The entry point to ALL programs is the function main().
There is also some strange magic in all of the Makefiles to build each application differently in the KERNEL build.
When you build the apps/ programs in FLAT or PROTECTED modes, all of the object files are put into an archive apps/libapps.a which is, eventually, copied to nuttx/libs and the BLOB is created by linking with lib/libapps.a.
But when you build the apps/ programs in the KERNEL mode, the directory apps/bin is created. Each source file is compiled, but the object files are not added to an archive. Instead, the object files are linked into a separate compiled and linked program. The program is then installed at apps/bin.
When the apps/ kernel build is complete, all of the programs have been installed in apps/bin. That is where apps/tools/mkromfsimg.sh file comes into to play. It takes all of the programs in apps/bin and creates a ROMFS file system image containing all of the applications. That ROMFS file system image is built into the kernel.
At run time, when the kernel boots, it will mount that ROMFS file system at /bin. In the FLAT build mode, the OS boot logic calls task_create() to start the task you have configured with CONFIG_USER_ENTRYPOINT. But in the KERNEL build, something different happens. CONFIG_USER_ENTRYPOINT is not used. Instead, CONFIG_INIT_FILEPATH is used. This will be the name of the program to stared in /bin to bring up the system.
Look at the logic in nuttx/sched/init/os_bringup.c:
#elif defined(CONFIG_INIT_FILEPATH)
static inline void os_do_appstart(void)
{
int ret;
#ifdef CONFIG_BOARD_INITIALIZE
/* Perform any last-minute, board-specific initialization, if so
* configured.
*/
board_initialize();
#endif
/* Start the application initialization program from a program in a
* mounted file system. Presumably the file system was mounted as part
* of the board_initialize() operation.
*/
sinfo("Starting init task: %s\n", CONFIG_USER_INITPATH);
ret = exec(CONFIG_USER_INITPATH, NULL, CONFIG_INIT_SYMTAB,
CONFIG_INIT_NEXPORTS);
ASSERT(ret >= 0);
}
Where exec() is an internal, more primitive function that is the base for the POSIX standard functions execv() and friends.
This is probably worth turning into a Wiki page.