On Thu, Dec 20, 2018 at 03:44:19AM +0300, Nikolai Zhubr wrote: > Hello all, > > I'm trying to get NAND working on an a20-olinuxino-micro board and it does > not quite work for me yet. I know the support of NAND storage supposed to be > somewhat incomplete or unstable at the moment, but actually I'd like to just > properly install a reasonably new u-boot (with ethernet support) to NAND so > as to avoid having the opaque boot0 and boot1, and I've read such > configuration was proven possible, although on some cubie device, not > olinuxino.
There's README.nand in mainline u-boot's board/sunxi directory. Make sure that your board's configuration has CONFIG_NAND=y. This will trigger building of spl/sunxi-spl-with-ecc.bin > > Currently, I've got 2 ways of installing u-boot with subsequent successfull > OS boot from network: > > 1. Mainline U-boot on a micro-sd card. All is working fine, except I'd > prefer to avoid any removable parts and wiggling junctures as much as > possible. > > 2. Mainline U-boot without SPL stored into a special partition on NAND > memory, which is only accessible when booted some outdated debian image with > 3.x kernel by means of some severely non-standard Allwinner drivers. This is > not only inconvenient to setup/modify/access, but sometimes booting just > randomly fails somewhere between boot0 and boot1. Retrying after several > seconds (after plugging off the power) usually helps. Also, I've found that > some time-critical application works more reliably wrt performance when > booted from sd-card as compared to this NAND-boot0-boot1-uboot scenario, > although uboot is the same and the kernel and all userspace is the same. I > suspect boot0/boot1 does some unwanted (and unnecessary) hardware tweaking > which then negatively affects performance. > > So, using various instructions and patches floating around, I've enabled > "Support for NAND on Allwinner SoCs" in my kernel (4.14), added &nfc to dts, > prepared mtd-utils, attempted to load sunxi_nand. > > [ 67.072646] nand: Could not find valid ONFI parameter page; aborting > [ 67.079082] nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7 > [ 67.085509] nand: Hynix NAND 4GiB 3,3V 8-bit > [ 67.089777] nand: 4096 MiB, MLC, erase size: 2048 KiB, page size: 8192, > OOB size: 640 > [ 67.100973] Bad block table not found for chip 0 > [ 67.108481] Bad block table not found for chip 0 > [ 67.113126] Scanning device for bad blocks > [ 67.147285] Bad eraseblock 16 at 0x0000021fe000 > .... (repeated a lot) > > Then I had to use a hack in nand_erase_nand() in order to workaround the > eraseblocks flood. My next findings are the following: > > nanddump seem to dump something, but the actual data in first 200Mb does not > contain anything recognizable (32Kb@0 and 32Kb@2M look like filled with > random bytes, the rest looks like uninitialized or random bytes). > > flash_erase does something, but it does not fix the "Bad eraseblock..." > flood however. > > nandwrite and subsequent nanddump of e.g. u-boot-sunxi-with-spl.bin shows > that apparently something got stored, because the read data matches > perfectly the source. > > Now leaving alone preparation of u-boot for NAND, I see two problems > already: > > 1. Initializing bad block table fails, also after flash_erase, probably > indicating something goes wrong; > > 2. Reading original (bootable Debian) NAND contents does not give any > recognizable strings but random garbage. > > This feels like maybe physically some access takes place, but the "encoding" > is somehow wrong. I've seen some mentions of ECC_STRENGTH setting, but I'm > rather unsure how to deal with it. > > Maybe it could be of some help that I have the debug serial output from > CT_Nandboot utility, see below. > > Any hints? > > > Thank you! > > Regards, > Nikolai > > -------------------------------------------------------------------- > CT_Nandboot output (trimmed): > [SCAN_DBG] ==============Nand Architecture Parameter============== > [SCAN_DBG] Nand Chip ID: 0xda94d7ad 0xffffffff > [SCAN_DBG] Nand Chip Count: 0x1 > [SCAN_DBG] Nand Chip Connect: 0x1 > [SCAN_DBG] Nand Rb Connect Mode: 0x1 > [SCAN_DBG] Sector Count Of Page: 0x10 > [SCAN_DBG] Page Count Of Block: 0x100 > [SCAN_DBG] Block Count Of Die: 0x800 > [SCAN_DBG] Plane Count Of Die: 0x2 > [SCAN_DBG] Die Count Of Chip: 0x1 > [SCAN_DBG] Bank Count Of Chip: 0x1 > [SCAN_DBG] Optional Operation: 0x1188 > [SCAN_DBG] Access Frequence: 0x1e > [SCAN_DBG] ECC Mode: 0x3 > [SCAN_DBG] Read Retry Type: 0x10604 > [SCAN_DBG] DDR Type: 0x0 > [SCAN_DBG] ======================================================= > > [SCAN_DBG] ==============Optional Operaion Parameter============== > [SCAN_DBG] MultiPlaneReadCmd: 0x60, 0x60 > [SCAN_DBG] MultiPlaneWriteCmd: 0x11, 0x81 > [SCAN_DBG] MultiPlaneCopyReadCmd: 0x60, 0x60, 0x35 > [SCAN_DBG] MultiPlaneCopyWriteCmd: 0x85, 0x11, 0x81 > [SCAN_DBG] MultiPlaneStatusCmd: 0x70 > [SCAN_DBG] InterBnk0StatusCmd: 0xf1 > [SCAN_DBG] InterBnk1StatusCmd: 0xf2 > [SCAN_DBG] BadBlockFlagPosition: 0x2 > [SCAN_DBG] MultiPlaneBlockOffset: 0x1 > [SCAN_DBG] ======================================================= > NHW : nand hw scan ok > check nand version start. > Current nand driver version is 0x000000ff 0x00000000 0x00000002 0x00000012 > Succeed in getting flash info. > -------------------------------------------------------------------- > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
