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