* Can ID the NAND chip, but every erase block is bad?
@ 2010-01-02 5:05 Bill Gatliff
2010-01-02 10:03 ` David Woodhouse
0 siblings, 1 reply; 6+ messages in thread
From: Bill Gatliff @ 2010-01-02 5:05 UTC (permalink / raw)
To: linux-mtd
Guys:
I have a platform with an ancient Linux kernel that I'm updating, and
I'm having some problems. The platform has a Freescale MPC5200, a
Samsung K9 NAND flash chip, and it all works fine under 2.6.20, I'm
trying to bring it up to 2.6.32.
Simply put, when I register the gen_nand device for this chip under
2.6.32, it successfully identifies the chip but then says that every
single eraseblock in the chip is bad. When I reboot to the 2.6.20
kernel, I don't get any complaints there. I see the same problem both
with and without CONFIG_MTD_NAND_ECC_SMC.
Anyone have any ideas on where I should look for the problem? Thanks!
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can ID the NAND chip, but every erase block is bad?
2010-01-02 5:05 Can ID the NAND chip, but every erase block is bad? Bill Gatliff
@ 2010-01-02 10:03 ` David Woodhouse
2010-01-03 13:58 ` Bill Gatliff
2010-01-04 19:48 ` Bill Gatliff
0 siblings, 2 replies; 6+ messages in thread
From: David Woodhouse @ 2010-01-02 10:03 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-mtd
On Fri, 2010-01-01 at 23:05 -0600, Bill Gatliff wrote:
>
> I have a platform with an ancient Linux kernel that I'm updating, and
> I'm having some problems. The platform has a Freescale MPC5200, a
> Samsung K9 NAND flash chip, and it all works fine under 2.6.20, I'm
> trying to bring it up to 2.6.32.
>
> Simply put, when I register the gen_nand device for this chip under
> 2.6.32, it successfully identifies the chip but then says that every
> single eraseblock in the chip is bad. When I reboot to the 2.6.20
> kernel, I don't get any complaints there. I see the same problem both
> with and without CONFIG_MTD_NAND_ECC_SMC.
>
> Anyone have any ideas on where I should look for the problem? Thanks!
Take a closer look at how bad blocks were detected under 2.6.20.
A virgin chip will use a certain byte in the spare area of each
eraseblock to mark that block as bad. But often we reclaim those bytes
and transcribe the information into a bad block table elsewhere on the
flash.
Booting a kernel which ignores the bad block table and looks for the bad
block markers in the original location will have fairly much the effect
you describe.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can ID the NAND chip, but every erase block is bad?
2010-01-02 10:03 ` David Woodhouse
@ 2010-01-03 13:58 ` Bill Gatliff
2010-01-03 15:44 ` Darwin Rambo
2010-01-03 15:55 ` David Woodhouse
2010-01-04 19:48 ` Bill Gatliff
1 sibling, 2 replies; 6+ messages in thread
From: Bill Gatliff @ 2010-01-03 13:58 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
David Woodhouse wrote:
> Take a closer look at how bad blocks were detected under 2.6.20.
>
> A virgin chip will use a certain byte in the spare area of each
> eraseblock to mark that block as bad. But often we reclaim those bytes
> and transcribe the information into a bad block table elsewhere on the
> flash.
>
> Booting a kernel which ignores the bad block table and looks for the bad
> block markers in the original location will have fairly much the effect
> you describe.
>
Ok, I'll take a look into that code.
Is there any way to instruct MTD to discard any previous bad block
information, and reconstruct the bad block table from scratch?
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Can ID the NAND chip, but every erase block is bad?
2010-01-03 13:58 ` Bill Gatliff
@ 2010-01-03 15:44 ` Darwin Rambo
2010-01-03 15:55 ` David Woodhouse
1 sibling, 0 replies; 6+ messages in thread
From: Darwin Rambo @ 2010-01-03 15:44 UTC (permalink / raw)
To: Bill Gatliff, David Woodhouse; +Cc: linux-mtd@lists.infradead.org
> Is there any way to instruct MTD to discard any previous bad block
> information, and reconstruct the bad block table from scratch?
You can use the config option that leaves the bad block markers alone in the oob
and have linux quickly build the bad block table in RAM on bootup instead of flash.
I think that it's risky to corrupt the bad block markers in the oob of the bad
block itself since a single accidental erasure can lose _all_ the bad block markers
in one fell swoop and they can't be reconstructed without detailed knowledge of the
factory testing algorithms and environmental test parameters. You could possibly
have redundant blocks for bad block tables in flash to handle this. If you need more
space for strong bch/reed solomon ecc bytes, you can truncate the 8 byte cleanmarker
down to a byte or two using a custom oob layout map, and the multi-byte ecc can skip
over the bad block marker.
Darwin
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can ID the NAND chip, but every erase block is bad?
2010-01-03 13:58 ` Bill Gatliff
2010-01-03 15:44 ` Darwin Rambo
@ 2010-01-03 15:55 ` David Woodhouse
1 sibling, 0 replies; 6+ messages in thread
From: David Woodhouse @ 2010-01-03 15:55 UTC (permalink / raw)
To: Bill Gatliff; +Cc: linux-mtd
On Sun, 2010-01-03 at 07:58 -0600, Bill Gatliff wrote:
>
>
> Ok, I'll take a look into that code.
>
> Is there any way to instruct MTD to discard any previous bad block
> information, and reconstruct the bad block table from scratch?
In general, it's not possible to reconstruct the bad block table from
scratch. Don't lose the previous bad block table. That's why we
generally write two copies of it...
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can ID the NAND chip, but every erase block is bad?
2010-01-02 10:03 ` David Woodhouse
2010-01-03 13:58 ` Bill Gatliff
@ 2010-01-04 19:48 ` Bill Gatliff
1 sibling, 0 replies; 6+ messages in thread
From: Bill Gatliff @ 2010-01-04 19:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
David Woodhouse wrote:
> Take a closer look at how bad blocks were detected under 2.6.20.
>
Found the problem.
I hacked the code to show me the bytes as they were being read from the
flash, and they were significantly different with my 2.6.32 kernel---
all zeros, in fact. That led me to a bug in my cmd_ctrl code: I was
bailing out if the command was CMD_NONE, before writing anything to the
flash. That causes some important bytes to get dropped, apparently. :)
Thanks!
b.g.
--
Bill Gatliff
Embedded systems training and consulting
http://billgatliff.com
bgat@billgatliff.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-01-04 19:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-02 5:05 Can ID the NAND chip, but every erase block is bad? Bill Gatliff
2010-01-02 10:03 ` David Woodhouse
2010-01-03 13:58 ` Bill Gatliff
2010-01-03 15:44 ` Darwin Rambo
2010-01-03 15:55 ` David Woodhouse
2010-01-04 19:48 ` Bill Gatliff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).