Open thestumbler opened 2 months ago
I did look into supporting larger chips and decided it was impractical. The chip you are using has a block size of 136K. This is the smallest amount that can be erased. Consequently my driver would require a contiguous buffer of 136K which is quite unrealistic on most microcontrollers.
My driver uses buffering because it is part of a family of drivers supporting multiple chip types; it also supports usage other than in a filesystem. @robert-hh has pointed out that, to support littlefs, buffering is not required. He has published this driver which is unbuffered and would make a better starting point for large devices. I believe his driver only supports a single chip rather than an array.
I suggest you investigate this approach.
Okay. That makes sense. And it clicks with one of my experiments where it failed allocating a 128 KiB memory buffer. I thought I had just screwed up the various size definitions. But based on your reply, I had them correct.
I will investigate that project as you say. I would still like to get your take on the various definitions, just for my knowledge.
This is the new Bus Pirate 5 board, and I am trying to write a simple proof of concept collection of MP modules (it has been substantially successful and easy so far). Maybe I'll give your project a quick whirl on the Bus Pirate 6 beta unit, which has about double the RAM, and see if it flies.
Thanks -Chris
By the way, Peter, I am using your project for talking to an SPI serial EEPROM. It is one that isn't officially supported, I suspect because it is so small -- the Atmel 25080 8 Kib (1024 x 8 configuration). I didn't choose this myself, but it happened to be on a small evaluation board I'm using for testing. I get the warning possible unsupported chip. Size: 1KiB
. Despite this, it seems to work just fine.
The terminology used in my code is:
1 size
The size of a single chip (not the whole array) in KiB.
sec_size
The size in bytes of the smallest erasable block (== the necessary buffer size).block_size
The block size reported to the filesystem. Size in bytes == 2**block_size.page_size
This is only relevant to non-Flash chips. EEPROMS have a small RAM buffer. This is the size in bytes of this buffer.Note that block_size
has nothing to do with the physical chip. The ioctl
reports a block size which I think once referred to the size of a sector on disk. The value is 9 by convention.
@peterhinch Here's a writeup I did mentioning this package. Which reminds me, I have a pull request I need to make for the small sized EEPROM. I'll try to do that this week. -Chris https://hackaday.com/2024/10/15/experimenting-with-micropython-on-the-bus-pirate-5/
I'm struggling to get a larger 1GB NAND flash working with the library.
I first figured out that the READ_ID command didn't follow the same rule as the code was expecting, and memory size was being scanned incorrectly. Put a temporary patch in for that (see below) and now I'm simply not able to get it to work. Similar to reports from others here who have tried adding unknown flash chips -- it seems to read and write, but it doesn't persist across a reset nor power cycle.
But before I get deeper into that, I'm struggling to match the terminology of Micron with that of the library / block driver / VFSLFS2. Specifically, Micron describes the memory organization as:
The library code manages four categories of sizes:
I'd appreciate any guidance for sorting out these seemingly different naming conventions. I've tried too many combinations of the above, all without success.
Here's the snippet where I patched the scan function to try to get started