January 5, 2021

EBAZ4205 Bitcoin miner board - NAND flash

The Zynq-XC7Z010 is interfaced to a Winbond W29N01HVS flash chip.

This is a 1 Gbit flash chip (128M byte). It is described as an ONFI interface, where "ONFI" is Open Nand Flash Interface.

It has 1024 erasable blocks of 128K.
Each block has 64 pages of 2112 byes.
A page is 2048 bytes of data and 64 bytes of "spare data".

Devices may ship with invalid blocks (which are marked).

Entire pages must be erased. The datasheet says "programming a single bit more than once without first erasing is not supported". It also says that partial page programming is allowed up to 4 times before an erase is required. Based on the error message I see in U-Boot when I try a "saveenv", namely 

Invalid bus 0 (err=-1)
the driver "drivers/spi/spi-uclass.c" is being used by U-Boot for NAND flash.

U-boot and nand

There is a command "nand info" that gives: 
nand info
Device 0: nand0, sector size 128 KiB
  Page size       2048 b
  OOB size          64 b
  Erase size    131072 b
  subpagesize      512 b
  options     0x       0
  bbt options 0x   20000
And the "nand" command can tell you about bad blocks: 
nand bad
Device 0 bad blocks:
  07f60000
  07f80000
  07fa0000
  07fc0000
  07fe0000
There is even "nand dump" along with read, write, and erase.

Note that it is possible to get an image into ram and then write the whole thing into flash. Now there is a way to get software into the EBAZ4205. However I am not messing with that until I know the flash layout and where U-Boot lives in particular as I don't want to erase or corrupt U-Boot and make my board a brick for a while. But for reference, the scheme would go like this: 

nand info
nand device nand0	// not really necessary on our board
nand erase  

// Download the image to a location DDR(DDR addr) using tftp and then perform write to nand from
// that DDR address as shown below.

nand write   

// The nand programming is now done, but to ensure that it was written successfully
// just read the written data back and compare it to what was written.

nand read   
cmp

NAND dump

The U-Boot "nand dump" command was making me crazy for a while, but with some experimenting, I figure out how it works. The mystery is all about the offset. The offset is a byte offset and U-Boot thinks it is a hex number whether or not it has a "0x" prefix.

Knowing that, the next thing is that U-boot always truncates back to the start of whatever page (and pages are 2048 bytes in size) and shows you the entire page.
So, all of these give the same result (they dump page 0). 

nand dump 0
nand dump 500
nand dump 0x500
nand dump 7ff
nand dump 0x7ff
If you want to see the next page, use: 
nand dump 800
nand dump 0x800
Now the observant reader may have realized that with a fast serial connection, and a bit of programming, it would be possible to dump the entire NAND memory and get it into a file for examination. I wrote a program not long ago to do just that, but used the U-Boot md command in that case.
Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org