[U-Boot] i.MX3 NAND: trying to understand OOB handling

[U-Boot] i.MX3 NAND: trying to understand OOB handling

[Philip Paeps]

I am in the process of upgrading a customer's i.MX35-based design to
state-of-the-art U-Boot.  The board previously booted from NAND using a
home-grown SPL.  Since I'm doing some heavy-lifting anyway, I decided to
try out Beno?t's patches and use U-Boot's SPL bits and they work well
for me (thanks, Beno?t!).

My NAND has 4K pages and speaks ONFI, though I now also have 2K NANDs to
test with.  I managed to hack mxc_nand.c and mxc_nand_spl.c to the point
that I can now boot successfully from 2K and 4K ONFI NANDs.  I'd like to
clean up my changes and contribute them.

That was the good news. :-)

Unfortunately, the more I look at the code (and the Linux code, and
patches on mailing lists and the datasheet), the more confused I'm
getting about the OOB handling.  In particular: where does the NFC
hide the factory bad block markers.

Using a (mostly) unmodified driver, none of the virgin chips I've looked
at have any factory bad blocks on them.  I find that hard to believe.

My NANDs have factory bad block markers in the first spare byte of the
first or the second page of every bad block.  The "or" in the previous
sentence suggests to me that I want to set NAND_BBT_SCAN2NDPAGE in
bbt_{main,mirror}_descr.options.  I probably want to make that bit
conditional on a board option.

The i.MX35 reference manual tells me that 2K and 4K NANDs are read 512
bytes at a time, so that the layout in SRAM will be:

 | 512 + 16 | 512 + 16 | 512 + 16 | 512 + 16 |
 |<------------------ 2112 ----------------->|

or

 | 512 + 26 | 512 + 26  |  [...]  | 512 + 36 |
 |<------------------ 4314 ----------------->|

(the extra spare bytes are appended to the last section)

That would put the factory bad block marker somewhere in the data
section, but depending on how you interpret the datasheet, it could be
at a number of different offsets.  Patches posted to various mailing
lists suggest that 0x7D0 is a popular assumption, but I've not managed
to encounter a convincing reasoning for that offset over any of the
other options.

To confuse matters further, send_{prog,read}_page() in mxc_nand.c does a
little dance to allegedly make the spare data contiguous.  Is this
really spare data in the case of 2K or 4K pages though?  Or is that code
actually corrupting data?  Given that Linux does the same dance, and
that it's doing the same dance both reading and programming, it "works",
but that code makes me a little uneasy.  I feel quite strongly that the
bytes we access through a pointer named "spare" are actually OOB bytes
and not secretly in the data area.

Further down in mxc_nand.c, mxc_nand_read_oob_syndrome() also interprets
the layout of the SRAM buffer, apparently so that it can get the "real"
ECC data.

Bolting on code to make 4K pages work doesn't make this any prettier, so
I'd like to take the opportunity to refactor this a bit.  Before I hack
myself into a corner though, I'd like to make sure that I understand the
mapping between the SRAM buffer and the actual NAND correctly.

I'd be grateful if others who have looked at this code could share their
understanding.

Thanks!

 - Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information

[U-Boot] i.MX3 NAND: trying to understand OOB handling

[Benoît Thébaudeau]

Hi Philip,

On Monday, April 15, 2013 10:50:06 PM, Philip Paeps wrote:
> I am in the process of upgrading a customer's i.MX35-based design to
> state-of-the-art U-Boot.  The board previously booted from NAND using a
> home-grown SPL.  Since I'm doing some heavy-lifting anyway, I decided to
> try out Beno?t's patches and use U-Boot's SPL bits and they work well
> for me (thanks, Beno?t!).
> 
> My NAND has 4K pages and speaks ONFI, though I now also have 2K NANDs to
> test with.  I managed to hack mxc_nand.c and mxc_nand_spl.c to the point
> that I can now boot successfully from 2K and 4K ONFI NANDs.  I'd like to
> clean up my changes and contribute them.
> 
> That was the good news. :-)
> 
> Unfortunately, the more I look at the code (and the Linux code, and
> patches on mailing lists and the datasheet), the more confused I'm
> getting about the OOB handling.  In particular: where does the NFC
> hide the factory bad block markers.
> 
> Using a (mostly) unmodified driver, none of the virgin chips I've looked
> at have any factory bad blocks on them.  I find that hard to believe.
> 
> My NANDs have factory bad block markers in the first spare byte of the
> first or the second page of every bad block.  The "or" in the previous
> sentence suggests to me that I want to set NAND_BBT_SCAN2NDPAGE in
> bbt_{main,mirror}_descr.options.  I probably want to make that bit
> conditional on a board option.
> 
> The i.MX35 reference manual tells me that 2K and 4K NANDs are read 512
> bytes at a time, so that the layout in SRAM will be:
> 
>  | 512 + 16 | 512 + 16 | 512 + 16 | 512 + 16 |
>  |<------------------ 2112 ----------------->|
> 
> or
> 
>  | 512 + 26 | 512 + 26  |  [...]  | 512 + 36 |
>  |<------------------ 4314 ----------------->|
> 
> (the extra spare bytes are appended to the last section)
> 
> That would put the factory bad block marker somewhere in the data
> section, but depending on how you interpret the datasheet, it could be
> at a number of different offsets.  Patches posted to various mailing
> lists suggest that 0x7D0 is a popular assumption, but I've not managed
> to encounter a convincing reasoning for that offset over any of the
> other options.
> 
> To confuse matters further, send_{prog,read}_page() in mxc_nand.c does a
> little dance to allegedly make the spare data contiguous.  Is this
> really spare data in the case of 2K or 4K pages though?  Or is that code
> actually corrupting data?  Given that Linux does the same dance, and
> that it's doing the same dance both reading and programming, it "works",
> but that code makes me a little uneasy.  I feel quite strongly that the
> bytes we access through a pointer named "spare" are actually OOB bytes
> and not secretly in the data area.
> 
> Further down in mxc_nand.c, mxc_nand_read_oob_syndrome() also interprets
> the layout of the SRAM buffer, apparently so that it can get the "real"
> ECC data.
> 
> Bolting on code to make 4K pages work doesn't make this any prettier, so
> I'd like to take the opportunity to refactor this a bit.  Before I hack
> myself into a corner though, I'd like to make sure that I understand the
> mapping between the SRAM buffer and the actual NAND correctly.
> 
> I'd be grateful if others who have looked at this code could share their
> understanding.

Wow, that's many questions.

You might want to have a look at the following threads:
http://lists.denx.de/pipermail/u-boot/2012-November/140506.html
http://archive.arm.linux.org.uk/lurker/message/20121121.092540.b9b858ad.en.html

There is also an app note by Freescale about NAND Flash bad block handling in
their Linux doc bundle (also confusing).

With the 2-kiB-paged NANDs that I use, I get some bad blocks detected with the
current code, but not for all parts.

Some light changes are required in the current OOB layout as explained in the
threads above, for both U-Boot and Linux. And those should be synchronized. But
then, there is Freescale's app note above that seems to contradict a few things.

This cleanup is also on my long TODO list, but with a low priority, so if you
come up with a solution, that's perfect.

I hope that helps.

Best regards,
Beno?t

[U-Boot] i.MX3 NAND: trying to understand OOB handling

[Philip Paeps]

On 2013-04-15 23:58:16 (+0200), Beno?t Th?baudeau <benoit.thebaudeau@advansee.com> wrote:
> On Monday, April 15, 2013 10:50:06 PM, Philip Paeps wrote:
> > Unfortunately, the more I look at the code (and the Linux code, and
> > patches on mailing lists and the datasheet), the more confused I'm
> > getting about the OOB handling.  In particular: where does the NFC
> > hide the factory bad block markers.
> >
> > [...]
> > 
> > Bolting on code to make 4K pages work doesn't make this any prettier, so
> > I'd like to take the opportunity to refactor this a bit.  Before I hack
> > myself into a corner though, I'd like to make sure that I understand the
> > mapping between the SRAM buffer and the actual NAND correctly.
> > 
> > I'd be grateful if others who have looked at this code could share their
> > understanding.
> 
> Wow, that's many questions.

Sorry for the braindump. :-)

> You might want to have a look at the following threads:
> http://lists.denx.de/pipermail/u-boot/2012-November/140506.html
> http://archive.arm.linux.org.uk/lurker/message/20121121.092540.b9b858ad.en.html
> 
> There is also an app note by Freescale about NAND Flash bad block handling in
> their Linux doc bundle (also confusing).

Thanks for the pointers.  I mentally skipped over i.MX5-related
discussions when I was digging, but now you mention it, I realise
there's probably a lot more recent context about the mxc_nand driver in
those than in the i.MX3-related discussions I've been staring at.

> With the 2-kiB-paged NANDs that I use, I get some bad blocks detected with the
> current code, but not for all parts.

I've only tested with about five of each 2K and 4K NANDs.  That's
certainly not a statistically significant number, but I would have at
least expected a couple of factory bad blocks, especially in the larger
4K MLC parts.

Another thing I've not tried, is marking some blocks as bad and then
scanning for bad blocks to see what it finds.  For that experiment to be
meaningful though, I'd want to be sure the code that marks the blocks as
bad does the right thing.

> Some light changes are required in the current OOB layout as explained in the
> threads above, for both U-Boot and Linux. And those should be synchronized. But
> then, there is Freescale's app note above that seems to contradict a few things.
> 
> This cleanup is also on my long TODO list, but with a low priority, so if you
> come up with a solution, that's perfect.

While cleanup for the sake of cleanup isn't very high on my list,
reliable operation in the face of bad blocks is near the top.  Since
it's easier to express confidence in clean code, I might as well clean
things up. :-)

> I hope that helps.

It does.  Thank you!

 - Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information

[U-Boot] i.MX3 NAND: trying to understand OOB handling

[Benoît Thébaudeau]

Hi Philip,

On Tuesday, April 16, 2013 12:49:44 AM, Philip Paeps
> Subject: Re: [U-Boot] i.MX3 NAND: trying to understand OOB handling
> 
> On 2013-04-15 23:58:16 (+0200), Beno?t Th?baudeau
> <benoit.thebaudeau@advansee.com> wrote:
> > On Monday, April 15, 2013 10:50:06 PM, Philip Paeps wrote:
> > > Unfortunately, the more I look at the code (and the Linux code, and
> > > patches on mailing lists and the datasheet), the more confused I'm
> > > getting about the OOB handling.  In particular: where does the NFC
> > > hide the factory bad block markers.
> > >
> > > [...]
> > > 
> > > Bolting on code to make 4K pages work doesn't make this any prettier, so
> > > I'd like to take the opportunity to refactor this a bit.  Before I hack
> > > myself into a corner though, I'd like to make sure that I understand the
> > > mapping between the SRAM buffer and the actual NAND correctly.
> > > 
> > > I'd be grateful if others who have looked at this code could share their
> > > understanding.
> > 
> > Wow, that's many questions.
> 
> Sorry for the braindump. :-)
> 
> > You might want to have a look at the following threads:
> > http://lists.denx.de/pipermail/u-boot/2012-November/140506.html
> > http://archive.arm.linux.org.uk/lurker/message/20121121.092540.b9b858ad.en.html
> > 
> > There is also an app note by Freescale about NAND Flash bad block handling
> > in
> > their Linux doc bundle (also confusing).
> 
> Thanks for the pointers.  I mentally skipped over i.MX5-related
> discussions when I was digging, but now you mention it, I realise
> there's probably a lot more recent context about the mxc_nand driver in
> those than in the i.MX3-related discussions I've been staring at.

Yes, these OOB topics are not i.MX5-specific.

> > With the 2-kiB-paged NANDs that I use, I get some bad blocks detected with
> > the
> > current code, but not for all parts.
> 
> I've only tested with about five of each 2K and 4K NANDs.  That's
> certainly not a statistically significant number, but I would have at
> least expected a couple of factory bad blocks, especially in the larger
> 4K MLC parts.

It's lottery. ;)

> Another thing I've not tried, is marking some blocks as bad and then
> scanning for bad blocks to see what it finds.  For that experiment to be
> meaningful though, I'd want to be sure the code that marks the blocks as
> bad does the right thing.

For what you want to test, you need to undefine CONFIG_SYS_NAND_USE_FLASH_BBT.
Otherwise, the BBT is updated with the bad block information instead of the bad
lock itself.

Best regards,
Beno?t