[HELP] romfs on esp32

[Laczen]

Description

I am trying to mount a romfs filesystem at a specific location in flash. I am using the romfs sample.

I have placed the testdir.img at a specific location in flash (0x200000) and modified desc.image:

desc.image = (FAR uint8_t *)0x200000;

However when mounting the romfs filesystem this causes a User Exception, so I guess I cannot just do it like this.

What would be the correct way to mount a romfs filesystem at a specific location in flash ?

Verification

• I have verified before submitting the report.

[acassis]

@lupyuen did you try something like this in the past?

[lupyuen]

Hi @Laczen: For my RISC-V and Arm64 Ports of NuttX, I mount the ROM FS like this...
https://lupyuen.org/articles/avaota.html#mount-the-romfs

  struct boardioc_romdisk_s desc;
  desc.minor    = RAMDISK_DEVICE_MINOR;
  desc.nsectors = NSECTORS((ssize_t)__ramdisk_size);
  desc.sectsize = SECTORSIZE;
  desc.image    = __ramdisk_start;
  int ret = boardctl(BOARDIOC_ROMDISK, (uintptr_t)&desc);

__ramdisk points to a Memory Region defined in the Linker Script:
https://lupyuen.org/articles/avaota.html#linker-script

/* Linker Script: We added the RAM Disk (16 MB) */
MEMORY {
  dram (rwx)    : ORIGIN = 0x40800000, LENGTH = 2M
  pgram (rwx)   : ORIGIN = 0x40A00000, LENGTH = 4M    /* w/ cache */
  ramdisk (rwx) : ORIGIN = 0x40E00000, LENGTH = 16M   /* w/ cache */
}

/* We'll reference these in our code */
__ramdisk_start = ORIGIN(ramdisk);
__ramdisk_size  = LENGTH(ramdisk);
__ramdisk_end   = ORIGIN(ramdisk) + LENGTH(ramdisk);

And I copied the ROM FS, from the NuttX Image into the above Memory Region:
https://lupyuen.org/articles/avaota.html#copy-the-romfs

Would this work for ESP32?

[Laczen]

@lupyuen thanks for the reply.

For the esp32 the linker scripts are a mystery for me.

Maybe @tmedici or @eren-terzioglu know how to reserve a flash region for the romdisk in the linker script and how to access it. It would be great to allow updates (e.g. python mounted in /usr/local/lib) while not modifying the os.

[tmedicci]

@lupyuen thanks for the reply.

For the esp32 the linker scripts are a mystery for me.

Maybe @tmedici or @eren-terzioglu know how to reserve a flash region for the romdisk in the linker script and how to access it. It would be great to allow updates (e.g. python mounted in /usr/local/lib) while not modifying the os.

Well, there are two scenarios to solve this problem. First: the experiment you did about ROMFS didn't work because ROMFS is expected to be embedded in the firmware: when you fix a location in flash and try to write there directly, the firmware knows nothing about that address.

So, insisting on ROMFS, the first alternative is handling it the way @lupyuen proposed: you would need to modify flat_memory.ld and esp32_sections.ld, creating another memory section dedicated to the romdisk and deaing manually with the addresses in such a way that the virtual address of it corresponds to a known location on flash that you'd write directly. Sounds complicated, but it's possible.

But...

This isn't the best approach. There are a couple of examples that uses part of the flash directly. This is known as "SPI flash support". Check esp32-devkitc:spiflash: it creates a 1MiB SPI flash MTD driver at 0x180000 and mounts it with the SmartFS filesystem (by default). This isn't part of the firmware: it uses part of the SPI flash chip as if it were an external chip. Read and write operations are implemented like a MTD-based device. On top of that, we have a file system. Now you can read and write to the flash directly at the 0x180000 address. You can select the ESP32_SPIFLASH_SPIFFS and use tools like these to manipulate the content externally, or easier, just unselect any of the filesystems and the device will be mounted as a MTD-based block driver at /dev/mtdblock. Then, you can format it as a FAT device and mount it on NuttX. When read from flash and mounted on your PC, it'd already be formatted as the known FAT filesystem and you can edit it externally and reflash it again at the same location ;)

Please let me know if it works for you. Also, if you find this helpful, we'd be happy if you can help enhancing our documentation with such a guide.

[Laczen]

@tmedicci thanks for your reply.

I had chosen romfs because from the documentation this seemed to be the simplest, it is explicitly read-only and should support xip. I will have a look at option 2.

Thanks again.

[Laczen]

@tmedicci (and others if interested) it is also possible to mount a romfs system directly on a mtd device.

I created a mtd device /dev/mtdblock0 starting at 0x200000 and wrote a generated romfs file directly to 0x200000. This can be mounted using:

mount -t romfs -o MS_RDONLY /dev/mtdblock0 /mnt/romfs

It is then possible to use /mnt/romfs to access the files in the romfs filesystem. This is a great solution for allowing updates to a romfs without updating the kernel.

[acassis]

@Laczen maybe it could become a Guide here: https://nuttx.apache.org/docs/latest/guides/index.html

How are you updating the romfs without updating the kernel? Do you just flash a new version at that 0x200000 position?

[Laczen]

@Laczen maybe it could become a Guide here: https://nuttx.apache.org/docs/latest/guides/index.html

I need to further test this to see if there are limitations to this approach.

How are you updating the romfs without updating the kernel? Do you just flash a new version at that 0x200000 position?

Yes, the romfs is just a binary image (that in present nuttx examples is inserted as a "const" array in the kernel). Regenerating the romfs and flashing at the correct location is all that is needed.

[acassis]

That is really cool approach! Maybe using it with progmem you can have create OTA apps update

[Laczen]

That is really cool approach! Maybe using it with progmem you can have create OTA apps update

That is my ultimate goal, I reckon that if modules (see examples/module) can be added to a romfs so can other apps.

[Laczen]

@acassis I can confirm that this method also works with the elf example. NuttX is so cool :-).

I will look into making an example (e.g. hello_world) to show the method.

[acassis]

@Laczen cool! If you get some inspiration please create a Guide showing how to do an Application update using this ROMFS approach with ELF support