tmedicci commented on issue #16099: URL: https://github.com/apache/nuttx/issues/16099#issuecomment-2769338704
> [@lupyuen](https://github.com/lupyuen) thanks for the reply. > > For the esp32 the linker scripts are a mystery for me. > > Maybe [@tmedici](https://github.com/tmedici) or [@eren-terzioglu](https://github.com/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`](https://github.com/apache/incubator-nuttx/blob/84f2fe05c121e4667edd4d8885922906ec079846/boards/xtensa/esp32/common/scripts/flat_memory.ld) and [`esp32_sections.ld`](https://github.com/apache/incubator-nuttx/blob/b89ad74660537a17ec59b8efe8a6ea494e172e5e/boards/xtensa/esp32/common/scripts/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`](https://nuttx.apache.org/docs/latest/platforms/xtensa/esp32/boards/esp32-devkitc/index.html#spiflash): it creates a [1MiB](https://github.com/apache/incubator-nuttx/blob/1c6b603eec8b450cdef7e79facbe79d68da87dcd/arch/xtensa/src/esp32/Kconfig#L1920) SPI flash MTD driver at [`0x180000`](https://github.com/apache/incubator-nuttx/blob/1c6b603eec8b450cdef7e79facbe79d68da87dcd/arch/xtensa/src/esp32/Kconfig#L1913) and mounts it with the [`SmartFS`](https://github.com/apache/incubator-nuttx/blob/3f4151525d47f3869d9ce4d04d03482380f5ae17/boards/xtensa/esp32/common/Kconfig#L24) 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`](https://github.com/apache/incubator-nuttx/blob/3f4151525d47f3869d9ce4d04d03482380f5ae17/boards/xtensa/esp32/common/Kconfig#L49) and use tools like [these](https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/storage/spiffs.html#tools) 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](https://github.com/apache/nuttx/pull/16098) at `/dev/mtdblock`. Then, you can format it as a [FAT device and mount it on NuttX](https://github.com/apache/incubator-nuttx/blob/149d6481295daf4e92c84a1f50cd5598ee96e464/Documentation/applications/nsh/commands.rst#L859). 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
