* [U-Boot] Nand dump and nand bad block disagree
@ 2012-02-28 14:34 jean-philippe francois
2012-02-28 23:40 ` Scott Wood
0 siblings, 1 reply; 10+ messages in thread
From: jean-philippe francois @ 2012-02-28 14:34 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-28 14:34 [U-Boot] Nand dump and nand bad block disagree jean-philippe francois
@ 2012-02-28 23:40 ` Scott Wood
2012-02-29 9:02 ` jean-philippe francois
0 siblings, 1 reply; 10+ messages in thread
From: Scott Wood @ 2012-02-28 23:40 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-28 23:40 ` Scott Wood
@ 2012-02-29 9:02 ` jean-philippe francois
2012-02-29 19:06 ` Mike Frysinger
2012-02-29 19:11 ` Scott Wood
0 siblings, 2 replies; 10+ messages in thread
From: jean-philippe francois @ 2012-02-29 9:02 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 9:02 ` jean-philippe francois
@ 2012-02-29 19:06 ` Mike Frysinger
2012-02-29 19:09 ` Scott Wood
2012-02-29 19:11 ` Scott Wood
1 sibling, 1 reply; 10+ messages in thread
From: Mike Frysinger @ 2012-02-29 19:06 UTC (permalink / raw)
To: u-boot
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120229/68d76c6d/attachment.pgp>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 19:06 ` Mike Frysinger
@ 2012-02-29 19:09 ` Scott Wood
2012-02-29 22:34 ` Mike Frysinger
0 siblings, 1 reply; 10+ messages in thread
From: Scott Wood @ 2012-02-29 19:09 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 19:09 ` Scott Wood
@ 2012-02-29 22:34 ` Mike Frysinger
2012-02-29 22:37 ` Scott Wood
0 siblings, 1 reply; 10+ messages in thread
From: Mike Frysinger @ 2012-02-29 22:34 UTC (permalink / raw)
To: u-boot
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_considerations
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120229/fe07a7da/attachment.pgp>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 22:34 ` Mike Frysinger
@ 2012-02-29 22:37 ` Scott Wood
2012-02-29 22:54 ` Mike Frysinger
0 siblings, 1 reply; 10+ messages in thread
From: Scott Wood @ 2012-02-29 22:37 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 22:37 ` Scott Wood
@ 2012-02-29 22:54 ` Mike Frysinger
2012-02-29 23:14 ` Scott Wood
0 siblings, 1 reply; 10+ messages in thread
From: Mike Frysinger @ 2012-02-29 22:54 UTC (permalink / raw)
To: u-boot
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120229/950cd5a4/attachment.pgp>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 22:54 ` Mike Frysinger
@ 2012-02-29 23:14 ` Scott Wood
0 siblings, 0 replies; 10+ messages in thread
From: Scott Wood @ 2012-02-29 23:14 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Nand dump and nand bad block disagree
2012-02-29 9:02 ` jean-philippe francois
2012-02-29 19:06 ` Mike Frysinger
@ 2012-02-29 19:11 ` Scott Wood
1 sibling, 0 replies; 10+ messages in thread
From: Scott Wood @ 2012-02-29 19:11 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-02-29 23:14 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-28 14:34 [U-Boot] Nand dump and nand bad block disagree jean-philippe francois
2012-02-28 23:40 ` Scott Wood
2012-02-29 9:02 ` jean-philippe francois
2012-02-29 19:06 ` Mike Frysinger
2012-02-29 19:09 ` Scott Wood
2012-02-29 22:34 ` Mike Frysinger
2012-02-29 22:37 ` Scott Wood
2012-02-29 22:54 ` Mike Frysinger
2012-02-29 23:14 ` Scott Wood
2012-02-29 19:11 ` Scott Wood
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox