On Wed, Apr 11, 2012 at 9:22 PM, Scott Wood scottwood@freescale.com wrote:
On 04/11/2012 07:14 PM, Rafael Beims wrote:
Hello Scott, On Wed, Apr 11, 2012 at 6:54 PM, Scott Wood <scottwood@freescale.com <mailto:scottwood@freescale.**com scottwood@freescale.com>> wrote:
On 04/11/2012 04:28 PM, Rafael Beims wrote:
Hello, I work with several MPC83xx boards in our company, and a while ago we were informed that the NAND chip we used was being discontinued. Theonly options for a replacement were the newer 4k page ones. Specifically, we are using now the Micron 29F8G08ABABA (8 gigabit).
I was sweeping the repositories and this list's archives and I'm with the impression that these chips are not supported yet. I saw some patches sent hacking the driver to allow for the use of 4k pages. Additionally, I'm worried about the use of the 4 bit ECC lib (BCH), as it seems to me that the fsl_elbc_nand driver is not prepared to use a software ECC config. Maybe I'm wrong, but it seems that the driver always uses the 1 bit HW ECC that's present in freescale's controller. Because of this, I would like to ask for an overall status of these things. What can I expect to be working? What are the main areas ofconcern? If there is no complete implementation yet (as I saw some patches being rejected / not merged yet), what is currently missing? What is the area where most work is needed?
The main thing that is missing from the current patches is migrating bad block markers on first use, and checking that this has happened before using the hack. See the discussion on the Linux version of these patches. I was hoping to take care of this earlier this year, but other tasks have intruded.
Does this have to do with the fact that the oob size is different in the bigger page NAND's (sorry if my question seems dumb, but I'm not very familiar with the NAND drivers and the software use. Until now the NAND part was just plug and play :) )
The hack involves changing the flash layout from "4096 main 128 spare" to "2048 main 64 spare 2048 main 64 spare". This means that the factory bad block marker is now in an area we use for main data. We need to move it to where it belongs in the new layout before doing anything else with the chip.
And as you note, many 4K-page NAND chips require 4-bit ECC whichmeans the driver will need to be updated to support software ECC (this should be fairly straightforward, except maybe the decision of when to do this).
-Scott
I will have a look at the driver and try to do the modifications to support SW ECC. As I understand the fsl_elbc_nand driver is in sync with the linux kernel, and in this case the patches should be implemented and sent to the kernel first?
Ordinarily yes, but in this case it might be better to start with U-Boot. We'll likely do the bad block migration in U-Boot, whereas Linux will just check that it's been done via some sort of marker. And the ECC stuff doesn't make much sense until we have the 4K support (I haven't heard of a 2K chip that needs 4-bit ECC).
-Scott
OK, I will have a look at it. I was just wondering, is there a tree somewhere that contains the patches for the 4k hack applied?
I saw that a version 2 of the patch was sent by Shengzhou Liu in December 12, 2011, but I cannot find these patches applied in the main git:// git.denx.de/u-boot-nand-flash.git.
I think that has something to do with the fact that the patches were not accepted in the way that they were presented, but I would like to know what's the procedure to start working from there to a possible solution. I even tried to apply the patches to the current tree, without success. I could manually apply them, but this code is not mine and if I manually applied it, it would appear as mine.
Thanks for the support so far, Rafael