Alan - the reasoning was explained earlier in this conversation, but I will summarize once I have it 100% working with multiple partitions, USBMSD, MCUboot etc.
As an aside I will take a look at other QSPI drivers as they may have the same problem as I found with the write status flag (not surprisingly my GD55 driver is based on existing code!). > On 31 Oct 2024, at 18:49, Alan C. Assis <acas...@gmail.com> wrote: > > Hi Tim, > > It would be nice if you can write down the steps you took, if you have a > blog to document it. > > Why do you need a partition with LittleFS and another with FAT with USB > Mass Storage? > > Do you want to copy the file from computer to board to firmware update or > just to copy logs and other files from the board? > > Maybe you could consider using USBMTP because it is more reliable, but I > think we are still missing a userspace part of it. > I think Xiang Xiao said they will provide it someday, but since nobody ever > tried to use it or requested it, it never arrived :-) > > BR, > > Alan > > On Thu, Oct 31, 2024 at 3:28 PM Tim Hardisty <timhardist...@gmail.com> > wrote: > >> I have got this working - the only problem I had was a bug in the QSPI >> NOR flash driver (GigaDevice GD55 series) I am writing in parallel to >> allow for what I want. >> >> I missed something in the datasheet whereby if you send >256 bytes in a >> single write sequence, it will overwrite the first 256 bytes with the >> later data. The checking of the write-in-progress status bit was outside >> the sector programming loop. Doh! >> >> For completeness, and to answer the points made: >> >> * I need to use existing POSIX/NuttX functionality >> * I want FAT on a section of my NOR flash. It will get few writes >> (100's perhaps) for the life of the product and is the perfect fit >> here to allow USBMTD >> * mtd_partition is, as I understand it, just creating character >> drivers at various offsets in the flash. >> * MCUboot - in NuttX at least - wants primary and secondary slots >> configured as /dev/xxx character drivers - hence me using partitions >> * I can create 1, 2, 4 such partitions with no problem, and use >> character driver methods to read/write to them >> * LittleFS does also format on such a partition and works fine >> * mkfatfs (now!) creates a FAT file system on my chosen partition >> >> Happy days! >> >> On 30/10/2024 19:43, Tomek CEDRO wrote: >>> 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
