Hi all,
I have been struggling with a nasty problem the last couple of months. I'll try to give the short version here. :-) Custom MCF5208 platform, very similar to M5208EVB. SDR instead of DDR and a larger NOR flash (starting on adress 0). FLASH is a Macronix device, MX29LV640MTTC-90G. We have been running a 2.4.27-uc1 kernel for quite a long time with no problems. A JFFS2 file system is used in one flash partition. I downloaded the 20070130 release of uClinux-dist, and the 20061214 prebuilt toolchain and installed on a virtual RH Enterprise machine. No problem with building the kernel image. Everything works perfectly. When I enabled the JFFS2 and fixed the m520x.c to match our board, I could successfully mount an "old 2.4.27" partition and get access to the files. When I tried copying a bunch of files from /bin to the JFFS2 partition the problem started. Sporadic CRC errors started to appear on the console output (I think I wrote something about this in August). A lot of testing led me to think it was because of the buffer write feature added in cfi_cmdset_0002.c. When forcing word write, everything seemed to work, when changing back the errors started to show up. I then added some code in the write buffer function, which performed an actual verify of the written words (in the buffer write function). Sure enough, I could see verify errors, BUT no CRC error from JFFS2 functions! I then changed the busy check algorithm to data polling instead and stress tested the file system very hard. Worked perfectly. Next test was to restore cfi_cmdset_0002.c back to stock shape. I then added code to blink a LED when the dq6 toggle algorithm was finished and a verify error was noted. I measured on this LED simultaneous with the RDY/BY signal on the flash. On my scope I could easily see that it appeared as the dq6 stopped toggling BEFORE the busy signal flagged not busy!! I then added code to store a couple of the previous reads of the databus, and also a couple of reads AFTER dq6 stopped toggling. I was startled when I noticed that after dq6 stopped toggle, it started to toggle again! We were strongly suspecting the FLASH memory acting weird with the toggle bits. In then disabled the 520x flash mapping driver, and used the generic uClinux ROM/RAM filesystem support and made a fresh build of the kernel. After loading this on our board, I measured on the CE and OE on the FLASH, and could note sporadic accesses to the FLASH (not very frequently, but occasionly). I believe this should not be possible since we load the entire image in RAM, once loaded the flash is no longer in the game. This would certainly explain the illusion of dq6 toggle stop if this happened in between the two map_read calls in cfi_cmdset_0002. I then put back the m520x driver, and modified the function that check dq6 toggle by adding a spin_lock_irqsave/irqrestore around the two reads. Worked perfectly. No more errors. None of our own applications are running during all of these tests, just a "clean" kernel with minimal functionality. This weekend I tested the 20071107 patch. After some tweaking I had a working kernel, without the mentioned spurios FLASH accesses. The JFFS2 system worked like a charm. I measured with my scope on CE/OE on the 2.4.27 kernel, no access after kernel was loaded, on the 2.6.19 there are spurios accesses, in the 2.6.23 the accesses are gone. Especially I note accesses when accessing files in the root file system (located in RAM). The accesses I see seems to be just one single bus cycle now and then, not a burst of reads or anything. I acutally don't have clue where to find the code responsible for accessing data in the adress range for the FLASH. I feel a little bit uncomfortable by just accepting that the 2.6.23 works. Unfortunately I have no experience in kernel debugging using a BDM-pod. I only have the USB version shipped with the M5208EVB. Well, well...so much for a short version. :-) Any ideas very welcome. Best regards, Martin
_______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
