As I said before, most features I talk about is disabled by default. Nobody
forbids you to use an alternative approach.
On Fri, Feb 3, 2023 at 6:40 AM Alan C. Assis wrote:
> Hi Sebastien,
>
> Please once again, don't start a frame war, we need people to
> contribute to NuttX, to make our loved p
I've put my source code here in case anyone wants to try it:
https://github.com/RussellHaley/nuttx-russ-app-1
Thanks for the help everyone!
Russ
On Fri, Feb 3, 2023 at 2:31 AM Russell Haley wrote:
> Hmmm... So far I've tried the romfs example, adding the mkrd command as
> well as the suggestio
Hmmm... So far I've tried the romfs example, adding the mkrd command as
well as the suggestion by Sebastien but everything returns an error. Is
everyone sure that romfs works with the sim:nsh example code?
rapp_main_1.c
static int open_romdisk_2(void)
{
int ret = 0;
ret = romdisk_register(0, // /d
Hi Sebastien,
Please once again, don't start a frame war, we need people to
contribute to NuttX, to make our loved project great, not to destroy
it.
That said, I want to say a famous phrase from Linus Torvalds:
"Doers decide!"
If you want to decide how ROMFS should work, please do it.
It is an
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
On Thu, Feb 2, 2023 at 1:49 PM Xiang Xiao wrote:
> On Fri, Feb 3, 2023 at 2:06 AM Sebastien Lorquet
> wrote:
>
> > 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.
> >
On Fri, Feb 3, 2023 at 2:06 AM Sebastien Lorquet
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.
>
No, and this was exactly my problem.
The romfs should NOT be mounted by nsh.
Mounting to /etc/ is also NOT flexible enough.
Because in a normal board the boot app is not nsh but the customer app.
At the moment this romfs mount is also closely coupled to the boot
script mechanism, which is ve
Then, they should run the mount or whatever they want from rcS like how
Unix did. Actually, don't invert the wheel again, just follow how Unix is
done.
On Fri, Feb 3, 2023 at 1:27 AM Alan C. Assis wrote:
> I think if it was generic but with some CONFIG_ROMFS_MNTPOINT it could
> be usable for all
I think if it was generic but with some CONFIG_ROMFS_MNTPOINT it could
be usable for all customer environment and preferences.
Well, there still some cases that could be covered: ie. a user app
that needs files mounted at two or more places inside the root file
system.
On 2/2/23, Sebastien Lorque
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
On Thu, Feb 2, 2023 at 6:35 AM Alan C. Assis 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
IMHO this is too dependent on customer environment and preferences.
But it would be nice to be an official out-of-tree board skeleton to
show people how to organize it. libopencm3 has a demo project that is
very helpful.
Because it's always the first step when you use nuttx on real hardware
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 rei
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 bringu
Hi Russel,
If all you need is to copy some file.lua to your board, then an
alternative is using TMPFS and transfer the file using zmodem.
Few day ago I created a video tutorial about it:
https://www.youtube.com/watch?v=Ne3SZZrwL9c
BR,
Alan
On 2/2/23, Russell Haley wrote:
> I am mistaken. I u
You need to prepare /dev/ram1 with the mkrd command.
On Thu, Feb 2, 2023 at 2:29 PM Russell Haley wrote:
> On Wed, Feb 1, 2023 at 9:23 PM Xiang Xiao
> wrote:
>
> > You can debug sim nuttx with your favorite PC debugger just like a normal
> > host program.
> > Of course, please ensure the debug
On Wed, Feb 1, 2023 at 9:23 PM Xiang Xiao wrote:
> You can debug sim nuttx with your favorite PC debugger just like a normal
> host program.
> Of course, please ensure the debug system is
> generated(CONFIG_DEBUG_SYMBOLS=y).
>
I was able to set up KDevelop to run nuttx in the debugger, but the c
You can debug sim nuttx with your favorite PC debugger just like a normal
host program.
Of course, please ensure the debug system is
generated(CONFIG_DEBUG_SYMBOLS=y).
On Thu, Feb 2, 2023 at 1:00 PM Russell Haley wrote:
> I am mistaken. I understood that the rom image was part of the application
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, ne
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 wrote:
> On Tue, Jan 31, 2023 at 6:16 AM Fotis Panagiotopoulos >
> wrote:
>
> > Hello,
> >
> > Indeed the "proper" way of including a script would be
On Tue, Jan 31, 2023 at 6:16 AM Fotis Panagiotopoulos
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
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 he
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 wrote:
> On Sat, Jan 28, 2023 at 7:35 PM Xiang Xiao
> wrote:
>
> > You can enable CONFIG_FS_HOSTFS/CONFIG_SIM_HOSTFS, put your scri
On Sat, Jan 28, 2023 at 7:35 PM Xiang Xiao
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 testi
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
On Sun, Jan 29, 2023 at 2:24 AM Russell Haley wrote:
> Hi,
>
> Big thanks to Xiang Xiao for pointing me to the sim:lua
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
tu
27 matches
Mail list logo
