dlbeer / dhara

NAND flash translation layer for low-memory systems
Other
409 stars 120 forks source link

Can dhara be used for NOR flash? #17

Closed FreddieChopin closed 2 years ago

FreddieChopin commented 3 years ago

This is a question, not an issue report (;

Can dhara be used with no issues on a typical serial NOR flash? I have no experience with NAND and just basic knowledge about this technology, but I understand that the differences would basically boil down to these:

I understand that first point makes it impossible to check for read errors and to mark pages as "bad" - both of these are probably not needed, assuming that dhara checks for data consistency (for example to recover after power failure) in some other way. For such a memory I would therefore implement dhara_nand_is_bad() to always return "block is perfectly OK" with no checks, and dhara_nand_mark_bad() to be a no-op (or even an assertion, as this should never be called anyway).

Is this a good or a bad idea to use dhara on such chip? Or maybe it just needs some special handling somewhere?

Side question, assuming that I could use it. In most (all?) NOR flashes you can program individual bytes of a page in separate operations with no issues. I guess that setting log2_page_size to 1 is not such a great idea, but how low can this be set and is there a "sweet spot"? Could I set it just to the typical 256/512 bytes, or maybe a better option would be to set it higher or lower?

Thanks in advance!

dlbeer commented 3 years ago

On Fri, Jan 29, 2021 at 10:12:56AM -0800, Freddie Chopin wrote:

This is a question, not an issue report (;

Can dhara be used with no issues on a typical serial NOR flash? I have no experience with NAND and just basic knowledge about this technology, but I understand that the differences would basically boil down to these:

  • NOR has no ECC, as it generally doesn't need it, it also has no OOB, if some cells become damaged, then the chip is most likely dead anyway,
  • serial NOR is much smaller (like a few MB usually),
  • the size of erasable block is smaller (usually 4 kB - 64 kB),
  • the size of programmable block is smaller (256/512 B).

Hi Freddie,

Yes, that's correct.

I understand that first point makes it impossible to check for read errors and to mark pages as "bad" - both of these are probably not needed, assuming that dhara checks for data consistency (for example to recover after power failure) in some other way. For such a memory I would therefore implement dhara_nand_is_bad() to always return "block is perfectly OK" with no checks, and dhara_nand_mark_bad() to be a no-op (or even an assertion, as this should never be called anyway).

That'd be a sensible implementation.

Is this a good or a bad idea to use dhara on such chip? Or maybe it just needs some special handling somewhere?

You won't benefit from bad-block recovery or erase-block management, but it might possibly help with wear levelling. If you would otherwise be rewriting the same block many times over, you may wear out the block and render the chip unusable sooner.

Side question, assuming that I could use it. In most (all?) NOR flashes you can program individual bytes of a page in separate operations with no issues. I guess that setting log2_page_size to 1 is not such a great idea, but how low can this be set and is there a "sweet spot"? Could I set it just to the typical 256/512 bytes, or maybe a better option would be to set it higher or lower?

Either way, you will have two pages per checkpoint (due to the small page size) with one page containing metadata and one page containing your actual data.

If you will often write things that are smaller than 256 bytes, you might want to go with the smaller size.

Note that 256 bytes is the smallest possible usable page size (unless you want to modify the height of the internal radix tree).

Cheers, Daniel

-- Daniel Beer dlbeer@gmail.com http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B