Just for the sake of convenience had the chips swapped by the phone repair guy in the ground floor of the office. Technically I can do it, but he did a much more professional job and didn’t burn the LCD or send components flying everywhere.
HiZ> nand -h
usage:
nand [info|gc|scan|stress] [-i <count>] [-n <sectors>] [-y] [-h]
Show FTL info and status: nand info
Force a full garbage collection pass: nand gc
Read-only surface scan (verify all sectors readable): nand scan
Destructive write/GC/verify stress test (4 cycles): nand stress -i 4
Stress test without the confirmation prompt: nand stress -y
Added a nand command to stress test the new chips/drivers.
HiZ> nand info
NAND Flash Information:
Manufacturer: GigaDevice
Page size: 2048 bytes
Block size: 131072 bytes
Pages per block: 64
Total blocks: 1024
Total capacity: 131072 KB
Manufacturer: GigaDevice
FTL sectors used: 5975 / 47824
Journal size: 6006 pages
Utilization: 12%
Gigadevice NAND is working. Device info.
HiZ> nand gc
Forcing garbage collection...
Garbage collection OK: 2 steps, journal 6006 -> 6005 pages
forcing garbage collection.
HiZ> nand stress -i 4
Stress test DESTROYS all data on the NAND flash and file system.
Run 'format' afterwards to restore the file system.
Continue? y/n> y
Stress test: 4 cycles over 64 sectors of 2048 bytes
Cycle 0: gc 1 steps, 0 write err, 0 read err, 0 mismatch
Cycle 1: gc 1 steps, 0 write err, 0 read err, 0 mismatch
Cycle 2: gc 1 steps, 0 write err, 0 read err, 0 mismatch
Cycle 3: gc 1 steps, 0 write err, 0 read err, 0 mismatch
Stress test complete:
Write errors: 0
Read errors: 0
Data mismatches:0
RESULT: PASS - garbage collection preserved all data
File system was overwritten. Run 'format' before using storage.
Stress testing device.
GigaDevice chip works. Zetta does not.
Fake chip?
HiZ> nand raw
Raw READ ID (cold): 70 41 70 41
Raw READ ID (after reset): 70 41 70 41
I spent some time grinding on the Zetta chip and eventually did the simplest low level read ID. And, well, the chip is not reporting the correct ID. We should get 0xBA 0X71, and instead we get 0x70 0x41. If I hard code that ID we can get access to the chip info, but not to read/write.
It is indeed the right marking. I’m going to talk to SZLCSC about it because these are not cheap chips at the moment.
Out of curiosity, can you force a page to be marked bad (for testing purposes) by writing the 0x00 (0x0000) in the first bytes of the first / last page(s) defect area for a given block?
I ask because, historically, I’ve found it quite difficult to create media with “bad” blocks. Even when able to pretend the blocks are bad, the device behavior is often very different for actually marginal media vs. a test label … sometimes causing excessive timeouts, and less commonly, hanging the storage device (where a power cycle was needed).
For NAND, it’s also useful if you can perform raw read of the block (with ECC portion given to you directly). Double-bonus if you can you also write the blocks raw, followed by reading them with the hardware doing the ECC correction.
If so, you can have your favorite LLM write up an ECC-corruptor test (write normal, read back raw with ECC, flip some bits, write it raw, read back ECC-corrected). This ensures at least basic behaviour under various ECC recovery modes is tested
(Can you tell I don’t trust storage devices?
)
HiZ> nand raw
Raw READ ID (cold): BA 71 BA 71
Raw READ ID (after reset): BA 71 BA 71
HiZ>
Well, well. This new chip has the correct ID, but I need to remove some hacks from the driver to see if it actually works.
i dont comment much anymore since i got shamed with the spam side comments, tis fine. But I honestly enjoyed the version 8 of buspirate where you had the sd card availability to export or switch things out. I know its a pain in the butt in some aspect for performance, but it was a very convenient. I have had similar supply issues with sourcing for regular spi flash chips, and now the rapsberry pi people are locking down memory because 3rd party sellers are desoldering ram from the 1gb versions and putting bootleg version ram on the boards. If i must say it sounds like anthorpic/openai is not only partial to buying books and burning them (link for henry who likes the deets - https://www.washingtonpost.com/technology/2026/01/27/anthropic-ai-scan-destroy-books/) - I wonder and I joke if they are actually sourcing all the ram to just burn it too. That and if you find a good supplier in Thailand (because there are some good companies there let me know)- I need a small considerate and decent 3rd party supplier that tells you how much they are taking off the top and can show the paper work trail for the nand/spi/you name it.
The massive difference in quality of the chip marking, coupled with the different IDs, strongly suggests that SZLCSC had some fake chips. I don’t know if they’re an innocent victim, but … they’re not even admitting that this was a problem, never mind apologizing or explaining how they are preventing it in the future.
It might make me add a pre-use validation step for inventory received from them, and not rely on samples as representative of stock. ![]()



