Hi,
Once again please remember this project is Apache NuttX and not Xiaomi OS.
The fact that your company is a major contributor and that you have
established your own local usage patterns does not mean these are the
only valid ones.
Each user has its own vision of how such a flexible system should work,
and all users count.
So please dont suggest "bandaid" solutions to me like /etc is the only
place to mount a romfs because the init script can "do things".
It is perfectly valid to mount three romfs each at /foo /bar and /baz at
boot and NuttX should allow it without telling me what's better.
And I'm sorry but nsh is a demo shell and not an init system, on my own
product there is NO WAY I want to give full shell access to my customer.
This wont happen and nsh is not even part of my production build.
FSes can be initialized in the board's _bringup routine and I dont want
a systemd/init/shell to read scripts to mount /proc and bind a littlefs
to a directory of my choosing. And _bringup is already used to init spi
and mtd. Because NuttX is a RTOS and is meant to be more lightweight and
flexible than a generic freebsd/macos/linux OS.
Patch will come, I think this is a good change for nsh, but I'm a bit
busy at work at this moment, stuck in a kind of dual-PIC18 cursed hell
with hard deadlines lol.
I also have a kind of "raid0" to aggregate two MTD with compatible
geometries into one, because reasons. It needs more tests, but it could
be useful for other users.
Sebastien
On 2/2/23 19:48, Xiang Xiao wrote:
On Fri, Feb 3, 2023 at 2:06 AM Sebastien Lorquet <sebast...@lorquet.fr>
wrote:
No, and this was exactly my problem.
The romfs should NOT be mounted by nsh.
It's an option and disabled by default.
BTW, which place do you think is better than the current one?
Mounting to /etc/ is also NOT flexible enough.
Because in a normal board the boot app is not nsh but the customer app.
You can boot other applications/services from scripts.
At the moment this romfs mount is also closely coupled to the boot
script mechanism, which is very annoying if your boot script is on a
flash device (eg littlefs) and not on a romfs.
I have decoupled this, but still not provided a pull request, that was
in fact easy and the result is cleaner than the current way it is done.
Yes, the Kconfig option makes the romfs mount couple with boot script, but
it is easy to decouple them. Patch is welcome.
You cant expect customers to follow a nsh-based design. The learning
curve for nuttx is hard enough, and if you add more constraints in apps
building it is even harder.
It depends on the developer's background. If the developer has
experience with other POSIX OS(Android, Ubuntu and macOS), all is natural.
Remember that NSH and apps are just "examples" and nuttx should work
with completely separated apps.
Of course, all we discuss so far is the user space feature, not related to
the kernel.
Thats why I think nsh should not be responsible for too much.
nsh equals init pus sh. One improvement is split init from nsh like other
OS.
Sebastien
Le 02/02/2023 à 17:47, Xiang Xiao a écrit :
The infrastructure is there, you can:
1. Enable CONFIG_NSH_ROMFSETC
2. Add your files to RCSRCS/RCRAWS in board's Makefile
Then nsh will auto mount it to /etc. sim already has a demo for this:
https://github.com/apache/nuttx/tree/master/boards/sim/sim/sim/src/etc
On Fri, Feb 3, 2023 at 12:33 AM Russell Haley <russ.ha...@gmail.com>
wrote:
On Thu, Feb 2, 2023 at 6:35 AM Alan C. Assis <acas...@gmail.com> wrote:
It should be nice to have a simple logic to let users to use ROMFS.
Currently everyone needs to duplicate it in their own code/application.
I'm thinking something like apps/romfiles/ where people just put the
files that they want to be in the ROM and it will be included
automatically, instead reinventing the wheel.
This is what I was hoping to find. I thought that since nuttx was
already
building a root filesystem there would be a simple way to include files
with the image.
Cheers,
Russ
BR,
Alan
On 2/2/23, Sebastien Lorquet <sebast...@lorquet.fr> wrote:
Hi,
Dont use boardctl for the romfs, this is too intertwined in the
mechanism used to initialize nsh, which is not suitable for
customization.
This need to be decoupled, I've done this in my own apps. I'll send it
later, maybe.
Here is the proper way to mount a romfs from your board bringup()
routines:
I am using stm32 as example, the ROM fs directory holding the file is
a
brother to board/
boarddir:
+-- romfs
+-- your files...
+-- board
+-- include
+-- src
You can do something else if you change the makefile below
First change your board/src makefile to add a dependency so that
stm32_bringup.c depends on romfs.h
.PHONY: myromfs.h #might not be required
stm32_bringup.c: myromfs.h
myromfs.h:
@echo "ROMFS"
@genromfs -v -f my.romfs -d $(BOARD_DIR)/../romfs
@xxd -i my.romfs > myromfs.h
Then do this in stm32_bringup.c:
#include "myromfs.h"
#define SECTORSIZE 64
#define NSECTORS(b) (((b)+SECTORSIZE-1)/SECTORSIZE)
#include <nuttx/fs/fs.h>
#include <nuttx/drivers/ramdisk.h>
#include <sys/mount.h>
and then in stm32_bringup(void):
ret = romdisk_register(0, // /dev/ram0
myromfs, //var in the xxd header
NSECTORS(myromfs_len),
SECTORSIZE);
ret = nx_mount("/dev/ram0", "/romfs", "romfs", MS_RDONLY, NULL);
Then you will have your files mounted in /romfs at boot.
You can do symlinks:
ret = symlink("/romfs/etc" , "/etc");
_info("Linking /etc: %d\n", ret);
Sebastien
Le 02/02/2023 à 05:59, Russell Haley a écrit :
I am mistaken. I understood that the rom image was part of the
application
on flash, but had mis-read the documentation of
boardctl(BOARDIOC_ROMDISK,
(uintptr_t)&desc); and thought that the command loaded the image into
*RAM*
(the BOARDIOC_MKRD command makes the RAM disk. oops!).
Incidentally, neither the romfs example nor my attempt to re-create
it
works in my sim:
osboxes@osboxes ~/n/nuttx (master)> ./nuttx
NuttShell (NSH) NuttX-12.0.0
nsh> romfs
ERROR: Failed to create RAM disk: Unknown error
nsh> rapp
Starting Russells App 1...
ERROR: Failed to create RAM disk: Unknown error
nsh>
I don't know how to debug this "unknown error". I guess I will try to
find
where that error message comes from and hook in GDB? I'm terrible at
this
stuff, someone needs to revoke my compiler license (tee hee).
Cheers,
Russ
On Wed, Feb 1, 2023 at 7:29 PM Xiang Xiao <xiaoxiang781...@gmail.com
wrote:
romfs is part of your image as the const string. There is no
difference
from the below manual step.
On Thu, Feb 2, 2023 at 10:00 AM Russell Haley <russ.ha...@gmail.com
wrote:
On Tue, Jan 31, 2023 at 6:16 AM Fotis Panagiotopoulos <
f.j.pa...@gmail.com
wrote:
Hello,
Indeed the "proper" way of including a script would be to store it
in
a
file system.
However, when I needed to include a single and small script and I
didn't
want to introduce a complete FS just for this, I used xxd.
xxd can convert any file to a C header file.
You can then include the header, and access the whole file as a
variable.
Here is an example:
I added this in my app Makefile:
# Setup any special pre-build context
context: header
$(Q) cd path/to/libs/json.lua/ && xxd -i json.lua >
json_lua.h
&&
echo -n "const " | cat - json_lua.h > temp && mv temp json_lua.h
And then I used the file like this:
#include "lua.h"#include "lauxlib.h"#include <string.h>
#include "json_lua.h"
static int luaopen_json(lua_State * L);
void ExtLibs_load(lua_State * L){
// json.lua#ifdef CONFIG_EXT_LIB_JSON_LUA
luaL_requiref(L, "json", luaopen_json, 1);
lua_pop(L, 1);#endif}
int luaopen_json(lua_State * L){
const char * modname = lua_tostring(L, 1);
if (strcmp(modname, "json") != 0)
return luaL_error(L, "cannot load json module");
if (luaL_loadbufferx(L, (char*)json_lua, json_lua_len,
"json",
"t") != LUA_OK)
return lua_error(L);
lua_call(L, 0, 1);
return 1;}
I hope this helps...
That is very helpful, and not just for nuttx development! Thanks
for
the
tip.
The romfs example actually uses xxd as well to convert the
filesystem
into
hex code that is also stored in a header file. If I am reading the
code
correctly, the example app loads the entire filesystem into memory,
which
isn't very efficient and not at all what I wanted. Can someone tell
me
if
that's true?
Thanks,
Russ
On Sun, Jan 29, 2023 at 7:34 AM Xiang Xiao <
xiaoxiang781...@gmail.com>
wrote:
You can use the real file system on the device, there are many
choices:
romfs, littlefs, fatfs, starmtfs and spiffs.
On Sun, Jan 29, 2023 at 12:59 PM Russell Haley <
russ.ha...@gmail.com
wrote:
On Sat, Jan 28, 2023 at 7:35 PM Xiang Xiao <
xiaoxiang781...@gmail.com>
wrote:
You can enable CONFIG_FS_HOSTFS/CONFIG_SIM_HOSTFS, put your
scripts
into
some PC folder and run mount this folder from nsh:
mount -t hostfs -o fs=/path/to/your/pc/folder. /data
While I appreciate the answer, I am using the sim as a testing
platform
and hoping to move to either an STM32F4/7 or a Sony Spresense. I
am
hoping
for a solution that is applicable to an embedded project. If I
can't
just
add files to the initial image then I will look at the romfs
example
and
maybe the next best thing?
On Sun, Jan 29, 2023 at 2:24 AM Russell Haley <
russ.ha...@gmail.com>
wrote:
Hi,
Big thanks to Xiang Xiao for pointing me to the sim:lua
configuration.
I
was unable to simply include the defconfig file that you
linked
to,
but I
was able to reconfigure for the sim:lua configuration. I've
now
got
an
app
in the examples folder that includes the Lua interpreter. Is
there
a
tutorial on how to include folders and lua scripts or extra
files
in
the
initial file system?
Much appreciated,
Russ
