20.12.2018 17:28, I wrote:
20.12.2018 16:09, Nikolai Zhubr:
NAND: nand_base: Could not find valid ONFI parameter page; aborting
ECC init failed: -22
failed to init nand chips
Some new addition: I've discovered that it fails specifically because
(without this ONFI page thing) the initialization subroutine gets for
ECC parameters size=0 strength=0 and it does not have any buit-in
defaults in the code, so then it obviously has to fail out immediately.
Ok, hardcoding size=1024 and strength=40 allowed to proceed with
installing exactly per instructions in sunxi/README.nand and after
power-cycle I've got a greeting from u-boot SPL from nand!
U-Boot SPL 2019.01-rc2 (Dec 20 2018 - 16:30:46 +0300)
CPU: 912000000Hz, AXI/AHB/APB: 3/2/2
DRAM: 1024 MiB
Trying to boot from NAND
However, nothing usefull apparenly happens after the greeting. Just
silence...
Any hints?
Thank you!
Regards,
Nikolai
Now question is, how and where do I properly set them? AFAICS for the
linux kernel, the DT file can not be used for that on sunxi yet.
Apparently "strength" can possibly be either 24 or 40, taking into
account page size 8k and BROM restrictions. Not sure about the "size"
though.
Any hints?
Thank you!
Regards,
Nikolai
This is what the new shiny u-boot is saying me right after uploaded
though fel. So it of course rejects any subsequent nand commands.
Actually, it is basically the same message as sunxi_nand driver is
throwing in the kernel, but there it still somehow proceeds even without
this parameter page...
Any hints?
Thank you,
Regards,
Nikolai
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.
