how about creating a while disk at memory offset? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Wed, Oct 30, 2024, 11:58 Tim Hardisty <timhardist...@gmail.com> wrote: > 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 > >
