it's ok to use fatfs on flas in this particular case.
On Sat, Nov 2, 2024 at 12:43 AM Tim Hardisty <timhardist...@gmail.com>
wrote:
> I will only be making a few 100 changes over the life of the product. It’s
> a holding area for a new firmware image to be written via USBMSD by the
> user and used by MCUboot to write out (raw) to the main boot flash. Ideally
> I would like a “FAT translator” that allows (say) a LittleFS partition to
> be seen as FAT via USB but I don’t think such a thing exists.
>
> Obviously FAT is useless on flash for more “normal” things, which is why I
> have a 32MByte NOR flash running LittleFS for syslog and userlogs. In the
> limit I may just use a FAT formatted RAMdisk for the upgrade staging, but
> it depends on how much RAM my app ends up needing.
>
> > On 1 Nov 2024, at 15:12, 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
> >>>
> >>
>
>
