feat(spi_nand_flash): Add linux target support

[RathiSonika]

Change description

Below is the implementation architecture of the spi_nand_flash component.

graph TD
    A[Application] --> B[FATFS]
    B --> C[Dhara Library]
    C --> Hardware_Path[Hardware Path]
    C --> Linux_Path[Linux Path]
    subgraph Hardware_Path [Hardware Path]
        HP1[NAND Flash Layer]
        HP1 --> HP2[SPI NAND Flash Driver]
        HP2 --> HP3["SPI Driver (ESP-IDF)"]
        HP3 --> HP4[Hardware via SPI]
    end
    subgraph Linux_Path [Linux Path]
        LP1[NAND Flash Layer]
        LP1 --> LP2[NAND Emulation Layer]
        LP2 --> LP3[Memory Mapped File]
    end

Loading

This PR adds support for the Linux target, following the Linux path shown in the diagram above. The files nand_impl_linux.c and nand_linux_mmap_emul.c have been added to implement the NAND emulation layer and memory-mapped file handling which is used to emulate NAND Flash.

Additionally, host_tests have been included to verify that all tests function correctly on the Linux platform.

[igrr]

If I understand correctly, NAND flash is emulated by the "storage" partition in the emulated SPI flash.

If yes, this raises a couple of questions.

First, emulated SPI flash size is currently limited to 4 MB (espressif/esp-idf#14894). So it seems we can only emulate very tiny NAND flash, if we rely on esp_partition calls. This looks like a limitation.

Second, hard-coded usage of the "storage" partition doesn't seem to be documented. How should the user of this library find out that the spi_nand_flash component is using the "storage" partition, so that they avoid using "storage" themselves?

I also wonder if you have considered any alternative designs while working on this feature. For example, storing NAND flash contents in a separate file — which wouldn't be impacted by the above limitations. What are the reasons why you have chosen this particular design over the alternatives?

By the way, I would also suggest including such information in the PR description. A few sentences with an overview of the design or implementation, and some reasons why it was chosen, can help reviewers a lot.

[RathiSonika]

Thank you for your comments @igrr.
The previous design prioritised direct integration with ESP-IDF's partition system to ensure better compatibility with existing storage mechanisms, which is why the "storage" partition was originally used. However, hard-coded usage of the "storage" partition is not good way and also having spi_nand_flash depend on esp_partition is not the correct approach—it should be the other way around. To address this, the design has been updated to use a separate memory-mapped file for storing NAND flash contents.

Regarding PR documentation, Agreed! Adding a design rationale in the PR description will help reviewers better understand the approach. I’ll make sure to include it moving forward.

Additionally, I have updated the README.md file to include documentation for these changes.
PTAL. Thank you!

[pacucha42]

First round of the final review done. Thanks for revamping the previous design, now all generally LGTM, except for the dependencies: please, try to resolve the FatFS separation, as there should be no relation of any file system to this component. Consider placing all the FatFS specific code (diskio, examples) into IDF, and add the dependency on spi_nand_flash there (similar to esp_littlfs model). Thanks

[pacucha42]

Why do we need dependency on FatFS?

[RathiSonika]

This dependency is primarily required for the diskio layer implementation. However, I have now made it private to this component, preventing other components from inheriting it directly.

[pacucha42]

FatFS is unrelated to this component, imo. See previous comment

[pacucha42]

Dtto. This update should be internal to the FatFS code (please, check CMake for possible forking)

[pacucha42]

FatFS deps, see previous comments