Ugh, mobiles, sorry :-) I meant whole disk at some offset of memory.. and by disk I mean just the "partition" (or whatever you name it) you want to use as the filesystem storage not necessarily the whole disk with partitions (not sure why you want to use partitions) :-)
I do not know the details but if I had a single memory that would be shared among different task including having some filesystem I would just try to create a filesystem at selected memory region (without partitions) :-) Quick search shows that it should be possible to use LittleFS directly on a predefined part of memory region. No need to use partitions. You should be even able to create many filesystems in different parts of memory if you need more "partitions". https://devzone.nordicsemi.com/f/nordic-q-a/94606/memory-allocation-for-littlefs-and-running-out-of-space You can say that part of memory is a disk image to be mounted as filesystem (in a computer nomenclature). You may want to map that part of memory to a /dev/mem0 and then mount /dev/mem0 in /mnt/storage0. On FreeBSD for instance I can use any file as disk image with mdconfig utility that maps the file to /dev/mdN device and then I can use that device just as an ordinary disk. Another example is RAMFS that enables given amount of RAM to be mounted as directory to store files with superior access speed as compared to hard disk. Embedded system should not even need to create such bloat.. maybe no mapping is even necessary just provide address and size and use littlefs over there :-) Hope that helps somehow :-P Tomek On Wed, Oct 30, 2024 at 7:37 PM Tim Hardisty <timhardist...@gmail.com> wrote: > > A typo maybe? What do you mean by a “while” disk, please? > > > On 30 Oct 2024, at 18:33, Tomek CEDRO <to...@cedro.info> wrote: > > > > 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 > >> > >> > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
