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
>>
>>
