Yup thats what I mentioned before :-) On OS there are mount options
that may improve efficiency and storage lifetime like noatime (no
access time update), nomtime (no modify time update).. not sure if
these are available on NuttX but may be worth considering :-)
Tomek
On Fri, Nov 1, 2024 at 4:12 PM Xiang Xiao <xiaoxiang781...@gmail.com> wrote:
>
> it mayn't work as you expect. FatFS updates some fixed location very
> frequently, your flash device may stop working after you make ten thousand
> changes.
>
> On Fri, Nov 1, 2024 at 8:06 PM Tim hardisty <timhardist...@gmail.com> wrote:
>
> > I am successfully creating a FAT FS on a QSPI NOR flash - the problem
> > was an error in the flash driver when 512 byte sector emulation was
> > being used. I do this in my bringup code:
> > struct qspi_dev_s *qspi_flashmem;
> >
> > qspi_flashmem = sam_qspi_initialize(0);
> > ...
> > mtd_qspi = gd55_initialize(qspi_flashmem, 0);
> > ...
> > mtd_qspi0 = mtd_partition(mtd_qspi, 0, QSPI0_SIZE);...
> > ...
> > ret = register_mtddriver("/dev/qspi0", mtd_qspi0, 0744, NULL);
> > ...
> > mtd_qspi1 = mtd_partition(mtd_qspi, QSPI0_SIZE, QSPI1_SIZE);
> > ...
> > ret = register_mtddriver("/dev/qspi1", mtd_qspi1, 0755, NULL);
> > ret = nx_mount("/dev/qspi1", "/mnt/qspi1lfs", "littlefs", 0, "autoformat");
> > etc.
> >
> > The GD55 driver is using 512 byte simulation, but s512_initialize()
> > works just as well.
> >
> > I can then use mkfatfs to create a FAT FS and mount it and all is good.
> >
> > mkfats fs is not available to use in bringup code as I understand it
> > otherwise I would mount the FS in my bringup too.
> >
> > On 01/11/2024 02:07, Xiang Xiao wrote:
> > > On Wed, Oct 30, 2024 at 2:00 AM 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?
> > >
> > > The partition is different from the file system. A file system can mount
> > on
> > > either a block/mtd device, or a partition. FAT can work only with the
> > block
> > > device, so you can't mount FAT on a flash(mtd) device, only the special
> > > designed file system(e.g. littlefs, smartfs, spiffs) can work with mtd
> > > device directly. The traditional block based file system need FTL(flash
> > > translation layer) to work with mtd device, so you can try dhara if you
> > > really want to use FAT on flash device:
> > > https://github.com/apache/nuttx/blob/master/drivers/mtd/dhara.c
> > >
> > > If so, it no doubt explains why I can
> > >> format a FAT FS but not mount it.
> > >>
> > >>
> > > Which command do you use to format the device or partition?
> > >
> > > 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)?
> > >
> > > You can format the device with GPT/MBR partition by:
> > > https://github.com/apache/nuttx-apps/tree/master/fsutils/mkgpt
> > > https://github.com/apache/nuttx-apps/tree/master/fsutils/mkmbr
> > > But, the raw flash device normally doesn't use GPT/MBR partition, instead
> > > hardcode the partition in the code directly since CPU normally could run
> > > firmware directly on flash devices which normally define a proprietary
> > > partition scheme. For this case, you can use PTABLE/TXTABLE:
> > > https://github.com/apache/nuttx/blob/master/fs/partition/fs_ptable.c
> > > https://github.com/apache/nuttx/blob/master/fs/partition/fs_txtable.c
> > >
> >
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
