This is just some notes as I try to parse this model. Maybe you (or others) will find some of it useful. Initially, this is focused on the simplest use model (single block read / write).
NOTE: I have NOT gone through the source code yet … this is strictly a mental model of how to access/use a multi-plane SPI NAND chip.
Memory Layout
See, generally, Figure 7 on page 11.
Cache Register - most recently read block from NANDData Register - used to write to the NAND (+)Cache Register and Data Register sizes are one block (each)- Each plane has its own
Cache Register and Data Register
Sequential blocks are on alternating planes. (Even blocks on one plane, Odd blocks on the other.) For two-planes such as this chip, the plane corresponds to the least significant bit of the block address. For four-plane chips, the two least significant bits of the block would indicate the plane.
Reading Data from NAND
Generally, reading the data from the NAND is a multi-step process. A PAGE READ command reads data from a given block address into the corresponding plane’s Cache Register. Completion status must be checked via the GET FEATURES command. No changes needed to support multi-plane for this part.
Once the data is in the Cache Register, any amount of those bytes can be read using a READ FROM CACHE commmand. Because each plane has its own Cache Register, these commands now include an indication of which plane’s Cache Register to read from.
Writing Data to NAND
Generally, writing data to the NAND is also a multi-step process. First set of commands place data into a Cache Register via PROGRAM LOAD command. Because each plane has its own Cache Register, these commands now include an indication of which plane’s Cache Register to write to.
Once the block’s data is in the plane’s Cache Register, it is written to the NAND via a PROGRAM EXECUTE command. The block address is explicitly provided, which implicitly indicates the plane.
Single code path … problem?
The number of planes for a given device does not appear to be exposed via the Parameter Page? (See page 26 / Table 4). Theoretically, this could make it difficult to seamlessly support both single and multi-plane devices.
HOWEVER … the plane bits are simply overloading four dummy bits that were previously unused. If testing confirms that the single-plane chip ignores the four dummy bits, and that the two-plane chip ignores the three dummy bits, then support for up to 16-plane devices (2^4) can be implemented with a single, common code path as follows:
ALWAYS replace the four dummy bits with the low four bits of the block address.
- A single-plane chip will ignore those dummy bits
- A two-plane chip will ignore the top three bits, and use the least significant bit to select the plane
- A four-plane chip will ignore the top two bits, and use the two least significant bits to select the plane
- etc.
Summary
Any commands that previously implicitly acted on either a Cache Register or Data Register, and which did not already provide a target block address, must now including bit(s) to indicate which plane’s register(s) that the command is targeting.
The most obvious examples are the READ FROM CACHE command and PROGRAM LOAD commands.
| Command |
OpCode |
Page |
Figure |
READ FROM CACHE |
03 or 0B |
18 |
13 |
PROGRAM LOAD |
02 |
29 |
20 |
Conclusion
This seems like it should be a fairly low-overhead change. Some testing should be done of both the single-plane and multi-plane chips, to ensure they ignore the dummy bits that are not relevant to their specific layout.
(+) and also used to allow multi-sector reads to be more performant, but that is unlikely to be used in BP5(?)
P.S. - Given the simplicity of the model used by BP5, none of the benefits of multi-plane NAND are expected (at least initially).
You can also write me for a free board if you’re interested in working on the new features.
