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

Reply via email to