Thanks for taking the time to reply. My thinking is undoubtedly flawed - I think I assumed that carving up a 128Mbyte QSPI NOR flash into a number of partitions would allow each registered device partition to behave independently so I could do with them what I wanted. For example:
/dev/qspi0 - bootstrap and MCUboot code (i.e. raw data) /dev/qspi0 - MCUboot primary slot (also raw data) /dev/qspi1 - MCUboot secondary slot (also raw data) /dev/qspi2 - MCUboot scratch area (also raw data) /dev/qspi3 - FAT partition for USBMSD. This would be a union FS to allow log files from a different NOR flash running LittleFS to be “seen” by a host PC and uploaded, as well as a location for users to copy new firmware to, for firmware upgrades, etc. The 128Mbyte QSPI is the main boot memory and actually has to have its AT91 boot loader at address 0 - so I won’t be able to have FAT as partition 0, nor put a MBR or partition table there. So I think I am stuffed, unless there’s a way of “isolating” a partition in the way I originally conceived, so that the mount operation genuinely only looks at the partitioned space. As you can tell, this is on the fringe of my (very limited) NuttX/Posix/FAT knowledge! If this is just not possible, I will revert to plan B and use CDC/NCM with a NuttX web-server to provide a front end for the user to up and down load files. > On 29 Oct 2024, at 23:24, Tomek CEDRO <to...@cedro.info> wrote: > > That depends on what partition schema do you use. If MBR then first > 512 bytes are the partition table and the boot code (like on PC), > there is a limit of 4 partitions (that on PC was solved by makind > "extended partition" and then first 512 bytes of that partition > enabled another partitions). GPT for instance does not have this > limitation and it contains backup table at the end of device. Also you > may use MBR disk schema with no partitions that is pretty common with > some unformatted pendrives and simple USB MSC emulation on tiny MCUs > with USB device. > > Also FAT does not seem perfect solution for embedded storage because > of 1 possible data corruption on power loss and 2 memory wear leveling > because some locations are used far more often than the others (i.e. > atime that can be disabled). There are other filesystems designed with > embedded application by design :-) > > Are you sure that partition table is okay and you are formatting / > mounting the correct partition? :-) > > Tomek > > > On Tue, Oct 29, 2024 at 7:00 PM Tim Hardisty <timhardist...@gmail.com> wrote: >> >> Whilst FAT on a NOR flash may generally be seen a not such a great >> idea...please ignore that and confirm if... >> >> ...I am right in deducing that I can't simply make a FAT file system on >> (say) the third mtd partition (with 512 byte sector emulation) >> (partitions 0, 1 and 2 are "raw" data) since FAT will treat the entire >> flash devices as a "volume" and so fail to find a partition table at the >> bottom end of the flash device? If so, it no doubt explains why I can >> format a FAT FS but not mount it. >> >> I could - perhaps should - re-jig my partitions so partition 0 is used >> for FAT, rather than partition 3, but before I do that are there any FAT >> FA/NuttX gurus who can let me know if there is a way to do this (and >> save me the hassle of reworking my bootstrap and MCUboot locations etc. >> for now)? >> > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
