Patchwork [1/2] nand: nand_bbt: Export nand_update_bbt

login
register
mail settings
Submitter Fabio Estevam
Date July 28, 2012, 10:29 p.m.
Message ID <1343514565-8983-2-git-send-email-festevam@gmail.com>
Download mbox | patch
Permalink /patch/173893/
State New
Headers show

Comments

Fabio Estevam - July 28, 2012, 10:29 p.m.
From: Fabio Estevam <fabio.estevam@freescale.com>

When building MTD_NAND_GPMI_NAND as module, the following error shows up:

ERROR: "nand_update_bbt" [drivers/mtd/nand/gpmi-nand/gpmi_nand.ko] undefined!

Export nand_update_bbt to fix it.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 drivers/mtd/nand/nand_bbt.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)
Artem Bityutskiy - Aug. 23, 2012, 3:08 p.m.
On Sat, 2012-07-28 at 19:29 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> When building MTD_NAND_GPMI_NAND as module, the following error shows up:
> 
> ERROR: "nand_update_bbt" [drivers/mtd/nand/gpmi-nand/gpmi_nand.ko] undefined!
> 
> Export nand_update_bbt to fix it.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

Why this driver redefined ->block_markbad() at all, it is not supposed
to do this. We should fix the driver instead.
Huang Shijie - Aug. 23, 2012, 3:36 p.m.
On Thu, Aug 23, 2012 at 11:08 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Sat, 2012-07-28 at 19:29 -0300, Fabio Estevam wrote:
>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>
>> When building MTD_NAND_GPMI_NAND as module, the following error shows up:
>>
>> ERROR: "nand_update_bbt" [drivers/mtd/nand/gpmi-nand/gpmi_nand.ko] undefined!
>>
>> Export nand_update_bbt to fix it
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>
> Why this driver redefined ->block_markbad() at all, it is not supposed
For hardware reason, in mx23, the bad block mark is stored in the
first byte of the nand page;
in mx28/mx50/mx6q, the bad block mark is stored in the first byte of the OOB.

That's why the driver redefined the ->block_markbad().

Is there any need to build the gpmi nand as a module?

Best Regards
Huang Shijie

> to do this. We should fix the driver instead.
>
> --
> Best Regards,
> Artem Bityutskiy
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
Artem Bityutskiy - Aug. 27, 2012, 3:25 p.m.
On Thu, 2012-08-23 at 11:36 -0400, Huang Shijie wrote:
> > Why this driver redefined ->block_markbad() at all, it is not supposed
> For hardware reason, in mx23, the bad block mark is stored in the
> first byte of the nand page;
> in mx28/mx50/mx6q, the bad block mark is stored in the first byte of the OOB.
> 
> That's why the driver redefined the ->block_markbad().

OK. Would you please tell about the driver some more, I am particularly
interested how th mx23 case works.

* So the bad block marker is the first byte of the eraseblock set to 0? 
* What if the user data stars with zero? Or you hide the first NAND page
  from the user?
* Can you point me to the code where you check if the eraseblock is bad
  or not at the initialization time (sorry, I could find myself,
  by trying to save time).
Huang Shijie - Aug. 28, 2012, 2:19 a.m.
于 2012年08月27日 23:25, Artem Bityutskiy 写道:
> On Thu, 2012-08-23 at 11:36 -0400, Huang Shijie wrote:
>>> Why this driver redefined ->block_markbad() at all, it is not supposed
>> For hardware reason, in mx23, the bad block mark is stored in the
>> first byte of the nand page;
>> in mx28/mx50/mx6q, the bad block mark is stored in the first byte of the OOB.
>>
>> That's why the driver redefined the ->block_markbad().
> OK. Would you please tell about the driver some more, I am particularly
> interested how th mx23 case works.
>
> * So the bad block marker is the first byte of the eraseblock set to 0?
yes.

> * What if the user data stars with zero? Or you hide the first NAND page
>    from the user?

Please see the picture in the common_nfc_set_geometry().
It's a real nand page layout.
The `M` is metadata, it's about 10 byte len.
The bad block marker is stored in the metadata, not the the
  `data` section which save the user's data.

We do not hide the first NAND page.

> * Can you point me to the code where you check if the eraseblock is bad
>    or not at the initialization time (sorry, I could find myself,
>    by trying to save time).
>
Please see the mx23_boot_init().

When mx23 reads a new nand chip in the first time, it will scan all
the nand chip. If it finds a bad block, it will call the 
nand->block_markbad() which
is just the gpmi_block_markbad(). the gpmi_block_markbad() will mark the 
first byte
of the nand page to 0 (the mx23 does not support the `swap` feature). So 
NAND boot mode,
the ROM of mx23 will check the first byte of the NAND page, if it finds 
a 0, it knows that
this is a bad block.

thanks
Huang Shijie
Artem Bityutskiy - Aug. 28, 2012, 1:02 p.m.
On Sat, 2012-07-28 at 19:29 -0300, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> When building MTD_NAND_GPMI_NAND as module, the following error shows up:
> 
> ERROR: "nand_update_bbt" [drivers/mtd/nand/gpmi-nand/gpmi_nand.ko] undefined!
> 
> Export nand_update_bbt to fix it.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>

Pushed both to l2-mtd.git, thanks!

Patch

diff --git a/drivers/mtd/nand/nand_bbt.c b/drivers/mtd/nand/nand_bbt.c
index 2d1d2fa..f4b6417 100644
--- a/drivers/mtd/nand/nand_bbt.c
+++ b/drivers/mtd/nand/nand_bbt.c
@@ -1403,3 +1403,4 @@  int nand_isbad_bbt(struct mtd_info *mtd, loff_t offs, int allowbbt)
 
 EXPORT_SYMBOL(nand_scan_bbt);
 EXPORT_SYMBOL(nand_default_bbt);
+EXPORT_SYMBOL(nand_update_bbt);