[U-Boot] Nand dump and nand bad block disagree
Hi,
I have an omap3 based board with a micron 4Gbit large page nand attached. when using software ecc, everything is fine.
When using hardware ecc, ecc is ok (ie u-boot and ROM bootloader agree), but bad block detection is broken.
Here is an OOB dump OOB: ff 44 bb 1e ba 45 87 f7 f7 88 38 c7 d2 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
According to the code in drivers/mtd/nand_base.c, bad block checking is done by reading OOB data at a particular position. For large page, this is at NAND_LARGE_BADBLOCK_POS which is zero.
In the above OOB data, oob[0] is 0xff, so there is no reason for this block to be considered as bad. How can I sort this ?
Jean-Philippe François
On 02/28/2012 08:34 AM, jean-philippe francois wrote:
Hi,
I have an omap3 based board with a micron 4Gbit large page nand attached. when using software ecc, everything is fine.
When using hardware ecc, ecc is ok (ie u-boot and ROM bootloader agree), but bad block detection is broken.
Here is an OOB dump OOB: ff 44 bb 1e ba 45 87 f7 f7 88 38 c7 d2 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
According to the code in drivers/mtd/nand_base.c, bad block checking is done by reading OOB data at a particular position. For large page, this is at NAND_LARGE_BADBLOCK_POS which is zero.
In the above OOB data, oob[0] is 0xff, so there is no reason for this block to be considered as bad. How can I sort this ?
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
Also please mention which version of U-Boot you're using. Top of tree currently has broken nand dump (fixed with the latest nand pull request).
-Scott
Le 29 février 2012 00:40, Scott Wood scottwood@freescale.com a écrit :
On 02/28/2012 08:34 AM, jean-philippe francois wrote:
Hi,
I have an omap3 based board with a micron 4Gbit large page nand attached. when using software ecc, everything is fine.
When using hardware ecc, ecc is ok (ie u-boot and ROM bootloader agree), but bad block detection is broken.
Here is an OOB dump OOB: ff 44 bb 1e ba 45 87 f7 f7 88 38 c7 d2 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
According to the code in drivers/mtd/nand_base.c, bad block checking is done by reading OOB data at a particular position. For large page, this is at NAND_LARGE_BADBLOCK_POS which is zero.
In the above OOB data, oob[0] is 0xff, so there is no reason for this block to be considered as bad. How can I sort this ?
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
It is an 8 bit nand. The badblock patern can be redefined by the controller driver to be different from the one in nand_base.c ? Do you have an example of this ?
Also please mention which version of U-Boot you're using. Top of tree currently has broken nand dump (fixed with the latest nand pull request).
I am using a pretty ancient version (2009.11) because it is the version provided with Ti DVSDK.
On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote:
Le 29 février 2012 00:40, Scott Wood scottwood@freescale.com a écrit :
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
It is an 8 bit nand. The badblock patern can be redefined by the controller driver to be different from the one in nand_base.c ? Do you have an example of this ?
look at the Blackfin nand driver (in u-boot and linux). we have to override the badblock layout because our on-chip boot rom expects something other than what linux uses. -mike
On 02/29/2012 01:06 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote:
Le 29 février 2012 00:40, Scott Wood scottwood@freescale.com a écrit :
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
It is an 8 bit nand. The badblock patern can be redefined by the controller driver to be different from the one in nand_base.c ? Do you have an example of this ?
look at the Blackfin nand driver (in u-boot and linux). we have to override the badblock layout because our on-chip boot rom expects something other than what linux uses.
But be careful when doing this -- it really should match what manufacturers will write.
If it's an 8-bit NAND, I don't see why it would be looking for anything but the first byte by default. Overriding should not be necessary.
-Scott
On Wednesday 29 February 2012 14:09:44 Scott Wood wrote:
On 02/29/2012 01:06 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote:
Le 29 février 2012 00:40, Scott Wood a écrit :
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
It is an 8 bit nand. The badblock patern can be redefined by the controller driver to be different from the one in nand_base.c ? Do you have an example of this ?
look at the Blackfin nand driver (in u-boot and linux). we have to override the badblock layout because our on-chip boot rom expects something other than what linux uses.
But be careful when doing this -- it really should match what manufacturers will write.
yep
on the Blackfin side, nothing to be done now. the rom team didn't consult with the linux team before implementing things, and these roms are fixed in the processor, and they can't change now without breaking backwards compat.
If it's an 8-bit NAND, I don't see why it would be looking for anything but the first byte by default. Overriding should not be necessary.
you can see the Blackfin OOB layout used here if you have a passing interest: http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:bootrom#nand_consid... -mike
On 02/29/2012 04:34 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 14:09:44 Scott Wood wrote:
On 02/29/2012 01:06 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote:
Le 29 février 2012 00:40, Scott Wood a écrit :
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
It is an 8 bit nand. The badblock patern can be redefined by the controller driver to be different from the one in nand_base.c ? Do you have an example of this ?
look at the Blackfin nand driver (in u-boot and linux). we have to override the badblock layout because our on-chip boot rom expects something other than what linux uses.
But be careful when doing this -- it really should match what manufacturers will write.
yep
on the Blackfin side, nothing to be done now. the rom team didn't consult with the linux team before implementing things, and these roms are fixed in the processor, and they can't change now without breaking backwards compat.
Do you migrate the bad block markers to the new location prior to using a chip?
-Scott
On Wednesday 29 February 2012 17:37:32 Scott Wood wrote:
On 02/29/2012 04:34 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 14:09:44 Scott Wood wrote:
On 02/29/2012 01:06 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 04:02:39 jean-philippe francois wrote:
Le 29 février 2012 00:40, Scott Wood a écrit :
Is this a 16-bit NAND? If so, the first two bytes have to be 0xffff, unless the controller driver defines the bad block pattern differently.
It is an 8 bit nand. The badblock patern can be redefined by the controller driver to be different from the one in nand_base.c ? Do you have an example of this ?
look at the Blackfin nand driver (in u-boot and linux). we have to override the badblock layout because our on-chip boot rom expects something other than what linux uses.
But be careful when doing this -- it really should match what manufacturers will write.
yep
on the Blackfin side, nothing to be done now. the rom team didn't consult with the linux team before implementing things, and these roms are fixed in the processor, and they can't change now without breaking backwards compat.
Do you migrate the bad block markers to the new location prior to using a chip?
we leave that as an "exercise for the user" ;)
this OOB layout is only used when the processor is booting directly from NAND, so the layout already has to be adjusted in order for it to boot at all. if you aren't booting from NAND, we recommend to customers to stick with the standard OOB layout. so there isn't really a point in time where we could add code to automatically migrate layouts. -mike
On 02/29/2012 04:54 PM, Mike Frysinger wrote:
On Wednesday 29 February 2012 17:37:32 Scott Wood wrote:
Do you migrate the bad block markers to the new location prior to using a chip?
we leave that as an "exercise for the user" ;)
this OOB layout is only used when the processor is booting directly from NAND, so the layout already has to be adjusted in order for it to boot at all. if you aren't booting from NAND, we recommend to customers to stick with the standard OOB layout. so there isn't really a point in time where we could add code to automatically migrate layouts.
OK. I guess it depends how you prepare the bootable image -- if you prepare a NAND boot by first booting U-Boot from something else, it would still be a U-Boot issue. If you write the image from something that isn't U-Boot, obviously the migration has to happen in that other entity.
We'll be getting into a similar situation on FSL eLBC with the hack to support 4K NAND. I plan to have U-Boot do the migration if it doesn't see a special marker that asserts the migration has already happened. This will be needed even when not booting from NAND. Booting from NAND with this hack would be an additional headache, and probably just not safely possible with a lot of 4K NAND chips that want 4-bit ECC which eLBC doesn't support.
-Scott
On 02/29/2012 03:02 AM, jean-philippe francois wrote:
Le 29 février 2012 00:40, Scott Wood scottwood@freescale.com a écrit :
Also please mention which version of U-Boot you're using. Top of tree currently has broken nand dump (fixed with the latest nand pull request).
I am using a pretty ancient version (2009.11) because it is the version provided with Ti DVSDK.
You may want to check whether current upstream U-Boot runs on your hardware.
Otherwise, ask TI for support with their SDK.
-Scott
participants (3)
-
jean-philippe francois -
Mike Frysinger -
Scott Wood