2009-01-12 03:14:16     Some strange problems using BF526 NFC

Document created by Aaronwu Employee on Aug 9, 2013
Version 1Show Document
  • View in full screen mode

2009-01-12 03:14:16     Some strange problems using BF526 NFC

Marco Reppenhagen (GERMANY)

Message: 67779   


I've two strange problems using a 64M NAND-Flash (ST 512W3A2BN6) on a costummade BF526-board via inbuild NFC with the regular drivers of the uClinux (rootfstype is jffs2). Under U-Boot our board works fine - but it starts making trouble when linux start up, please take a look:


1) Very slow access to NAND-Flash


This NAND flash got a pagesize of 512Bytes(+oob), so I turned it on and wondered about the difference in "include/asm-blackfin/nand.h" -> There's something like a workaround, which prohibit using DMA-Mode (simple re-difinition of the bit, which turns on 512Byte pagemode...?). I guessed that's no problem: in U-Boot the access via PIO-Mode is fast enough and it should be under Linux, too. The driver depends on quite the same code with sparse differences.

But I failed: It's boring slow under linux? (Depend on HZ- setting; bigger values fasten boot...)


I tried jffs2-summary-stuff and common ways to speed it up (Hashing the scan-stuff, etc.), but there's no increase of performance!


After a unhasty boot-up I copied a few MByte via "DD" from and to NAND Flash using the /dev/mtd- device and it also be very slow. So my problem is shure based deeply in the system (first few layers).


2) Corrupt OOB-Area after successful mounted JFFS2


The other problem is a corrupt OOB after such a slow bootup... When everything is mounted after a few minutes   the NAND-Map is unusable under U-Boot; When I try to "nand erase" I got the following error message:


NAND 64MiB 3,3V 8-bit: MTD Erase failure: -5

Erasing at 0x200000 --  88% complete.nand_erase: attempt to erase a bad block at page 0x00001020


So I have to "nand scrub" all and everything works "fine" again.


I still use some custommade gadgets with jffs2 without any problems and Without hacking the OOB-Stuff of JFFS2: Maybe there are wrong ECC-Bytes, but the BadBlock marker was still in place and an erase was possible - NOT in this case - I'm wondering about it.


When I turn on ECC in BF-BOOT-Style, the system freezes during the mount of the rootfs at boot time. (Stays in idle(); )


After a couple of tests I found that include/arch/cputime.h points to the generic implementation of cputime.h; When I try to measure the speed of reading one Block out of NAND with "do_gettimeofday" I got a resolution of 10ms or 4ms (depends on HZ). I remember some code for ARM that gives a better resolution by accessing registers of CPU - Is such a hack available for BF526, too? This would be nice, because exact measurement help in this case.


I'm quite new to Blackfin and uClinux, so I guess my trouble depends on a wrong configuration? (.config added)


Somewhere I read that 512Byte pages are not supported by the inbuild ECC-machine? Is this correct?


I'm very thankful for any help or tips... regards: Marco






2009-01-12 07:37:13     Re: Some strange problems using BF526 NFC

Mike Frysinger (UNITED STATES)

Message: 67799   


what version of software exactly are you using ?  we've never made a release using the 2.6.26 kernel.  if you're using svn trunk, you need to be using the latest tree and not anything else.


for your time settings, you can control the source under the Blackfin customizations ... either disable generic time or use cycles as your clock source.


you arent trying to use ethernet in your system are you ?




2009-01-12 11:17:46     Re: Some strange problems using BF526 NFC

Marco Reppenhagen (GERMANY)

Message: 67814   


I will check out trunk head and try again... maybe the problem is gone. (A first look: There are no significant differences in bf5xxx_nand.c and involved other files.)


I found the reason about the nice fast U-Boot action: instead of using the "N_ND_RB" egde detection of NFC_IRQSTAT the NFC_STAT will be used and polled. Even in Linux the Status is polled (nand_wait_ready in nand_base.c), so I tried booting in this  "u-boot"-style with an amazing result: The systems comes completely up in a few sec but afterwards got lost in panic(); The IRQMASKs of the original driver disable all Masks (nothing routet to IRC) so I'm wondering about this, but it it was only a quick shot - I take a closer look at it tomorrow.


We use ethernet in our system... hmmmm... what's up with it?




2009-01-12 11:59:57     Re: Some strange problems using BF526 NFC


Message: 67815   




Ethernet and NAND on the 526 can share pins - I assume you are using the Alternate Data line for NAND? and RMII for Ethernet (Otherwise you loose NAND Chip Enable).






2009-01-12 12:08:03     Re: Some strange problems using BF526 NFC

Mike Frysinger (UNITED STATES)

Message: 67816   


hmm, shouldnt the portmux framework catch this in latest trunk ?




2009-01-13 06:03:13     Re: Some strange problems using BF526 NFC

Marco Reppenhagen (GERMANY)

Message: 67861   


We use RMII because of this pin- sharing. With my changes described above I was able to fasten up the boot and it works quite fine and very fast: The system comes up without this change in abt. 6 minutes. Of course:  The IRQstatus returns fine when reading only one byte, but after a while I recognised that the NFC_IRQSTAT register won't change the NBUSYIRQ... then a timeout terminates the wait. That works, because the Nandflash got really enough time to become ready but it's slow. After using NFC_STAT register instead (NBUSY-Bit) it speeds up: Boottime is now abt. 22 sec :-)


Now I'm looking forward to find a reason why use of CONFIG_MTD_NAND_BF5XX_HWECC in combination with CONFIG_MTD_NAND_BF5XX_BOOTROM_ECC fails (System crashes into default_idle()).


Without BOOTROM_ECC (collision with JFFS2 handling of the OOB? I have to take a closer look, it's quite new for me) I can boot over and over again... no problem until I would erase the JFFS2 Area in the NAND: Above shown error message occurs..


BTW: Thank you for fast support and don't telling me: RTFM! - That's great.




2009-01-13 06:27:40     Re: Some strange problems using BF526 NFC

Mike Frysinger (UNITED STATES)

Message: 67863   


you cannot just switch OOB layouts on the fly.  u-boot and the kernel must be using the same OOB layout and you must have programmed the flash using the active OOB layout.  when changing layouts, you also need to use `nand scrub` to reset things.


anything else is not supported.




2009-01-13 06:33:12     Re: Some strange problems using BF526 NFC

Mike Frysinger (UNITED STATES)

Message: 67866   


also, simply enabling HWECC support results in a different hardware algorithm which means the ECC values wont match in the OOB region either




2009-01-13 08:41:34     Re: Some strange problems using BF526 NFC

Marco Reppenhagen (GERMANY)

Message: 67878   


Yes I saw it: The switch is done by a #define and that causes the overload of bootrom_ecclayout with bootrom-style. There's no chance to do this on the fly.


So I have to find out, why my linux crashes on enabling the #define in the kernel config.


On my way of understanding the BOOTROM_ECC I stumble about the 24 Bytes reservation...? There are only 16 Bytes in the OOB of the nand? (512+16 Pages).  Hmmm. I'm confused where to put these 24 Bytes in a 16 Byte area?


The second heavy problem I'll be faced with would be the JFFS2 Filesystem in combination with the BOOTROM_ECC-style.


At this moment I take a look closer to the stuff because I'm not versed enough to ask smart questions ;-)


Plan "B": I use two U-Boots: One with BOOTROM_ECC to program the Flash with an U-Boot without the BOOTROM_ECC flag.




2009-01-13 11:15:11     Re: Some strange problems using BF526 NFC

Mike Frysinger (UNITED STATES)

Message: 67892   


as documented in the HRM/datasheet, booting out of NAND only works with parts that have 64bytes in the OOB page.  if you arent booting u-boot out NAND, then it makes no sense at all to use the bootrom ECC layout.




2009-01-14 05:14:27     Re: Some strange problems using BF526 NFC

Marco Reppenhagen (GERMANY)

Message: 67929   


Well, now I'm confused:


We also use a BF527 for our more powerful products and boot already from the same NAND with a 512+16 Layout...?

IMHO you can find 64Byte OOBs only in NANDs with large apges (2048 Pagesize) - In the manual I can't find anything that I have to use only these ones for NAND-Boot....


Of course: At the moment we use a hardware workaround on our BF526: We boot from an SPIdevice and wait for the 2ndSi of the BF526 with working NAND boot capabilities.


I thought that the implementation would be the same as it is used in the big brother 527, where NAND-boot works fine for us? So if I'm wrong and a new algo will be implemented, where only big-size NANDs will be boot... wow - this won't be good news ;-(


For this "NAND boot on BF526 problem" we should add another thread to the forum (I do it later) because this can cause much trouble.

In any case my primary problems are solved by the following small changes:


1) Quicker boot: Different use of register (NFC_STAT instead of NFC_IRQSTAT in bf5xx_nand_devready in bf5xx_nand.c).

( I found that nand_wait_ready polls this and after a while (when blocksized data have to be read) the NFC_IRQSTAT don't reflekt correct states - It always returns "0" so that the while slope in nand_wait_ready start running in it's long timeouts. That made my boot boring slow.)


2) BOOTROM_ECC problem is solved by using two different u-boot: One is compiled with BOOTROM_ECC flag and only used to program another u-boot without this flag into the NAND. This is less painful than suspected and works also fine.


MNY Thanks!




2009-01-14 06:16:37     Re: Some strange problems using BF526 NFC

Mike Frysinger (UNITED STATES)

Message: 67938   


sorry, you're right.  the HRM states the bootrom supports small and large page nand.  only large page nand is supported by our software however as that is the only thing we can test (it's the NAND that's on the BF548-EZKIT).  anything smaller will most likely lead to memory corruption and crashes (hmm, sounds familiar to you ? ;]).


guess i'll update the code to add some checks to panic() in any other configuration.