[PATCH] mtd/gpmi : add BBT support

[PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

add the BBT support to the gpmi nand driver.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 493ec2f..4fbb341 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1493,6 +1493,7 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
 	chip->ecc.mode		= NAND_ECC_HW;
 	chip->ecc.size		= 1;
 	chip->ecc.layout	= &gpmi_hw_ecclayout;
+	chip->bbt_options	= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
 
 	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
 	this->bch_geometry.payload_size = 1024;
-- 
1.7.0.4

[PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

add the BBT support to the gpmi nand driver.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 493ec2f..4fbb341 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1493,6 +1493,7 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
 	chip->ecc.mode		= NAND_ECC_HW;
 	chip->ecc.size		= 1;
 	chip->ecc.layout	= &gpmi_hw_ecclayout;
+	chip->bbt_options	= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
 
 	/* Allocate a temporary DMA buffer for reading ID in the nand_scan() */
 	this->bch_geometry.payload_size = 1024;
-- 
1.7.0.4

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Mon, Jan 30, 2012 at 12:36:14PM +0800, Huang Shijie wrote:
> add the BBT support to the gpmi nand driver.
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 493ec2f..4fbb341 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1493,6 +1493,7 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
>  	chip->ecc.mode		= NAND_ECC_HW;
>  	chip->ecc.size		= 1;
>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
> +	chip->bbt_options	= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;

You are making this default. Is there a bootloader which supports that
on MXS?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

On Mon, Jan 30, 2012 at 12:36:14PM +0800, Huang Shijie wrote:
> add the BBT support to the gpmi nand driver.
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> index 493ec2f..4fbb341 100644
> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
> @@ -1493,6 +1493,7 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
>  	chip->ecc.mode		= NAND_ECC_HW;
>  	chip->ecc.size		= 1;
>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
> +	chip->bbt_options	= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;

You are making this default. Is there a bootloader which supports that
on MXS?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120130/93dba91b/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

于 2012年01月30日 17:46, Wolfram Sang 写道:
> On Mon, Jan 30, 2012 at 12:36:14PM +0800, Huang Shijie wrote:
>> add the BBT support to the gpmi nand driver.
>> Signed-off-by: Huang Shijie <b32955@freescale.com>
>> ---
>>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> index 493ec2f..4fbb341 100644
>> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> @@ -1493,6 +1493,7 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
>>  	chip->ecc.mode		= NAND_ECC_HW;
>>  	chip->ecc.size		= 1;
>>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
>> +	chip->bbt_options	= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
> You are making this default. Is there a bootloader which supports that
> on MXS?
>
The bootloader usually is burned on /dev/mtd0, while the BBT is placed
at the end
of the NAND chip.

I tested the NAND boot mode too.

What's your concern?

Huang Shijie

[PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

? 2012?01?30? 17:46, Wolfram Sang ??:
> On Mon, Jan 30, 2012 at 12:36:14PM +0800, Huang Shijie wrote:
>> add the BBT support to the gpmi nand driver.
>> Signed-off-by: Huang Shijie <b32955@freescale.com>
>> ---
>>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c |    1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> index 493ec2f..4fbb341 100644
>> --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
>> @@ -1493,6 +1493,7 @@ static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this)
>>  	chip->ecc.mode		= NAND_ECC_HW;
>>  	chip->ecc.size		= 1;
>>  	chip->ecc.layout	= &gpmi_hw_ecclayout;
>> +	chip->bbt_options	= NAND_BBT_USE_FLASH | NAND_BBT_NO_OOB;
> You are making this default. Is there a bootloader which supports that
> on MXS?
>
The bootloader usually is burned on /dev/mtd0, while the BBT is placed
at the end
of the NAND chip.

I tested the NAND boot mode too.

What's your concern?

Huang Shijie

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

> The bootloader usually is burned on /dev/mtd0, while the BBT is placed
> at the end
> of the NAND chip.
> 
> I tested the NAND boot mode too.
> 
> What's your concern?

Bootloaders may also need to write to NAND. So, they need to share the
same bad block information with the kernel. Currently, I am not aware of
a bootloader for mxs which support BBT without OOB. Unless this has
changed meanwhile, we shouldn't make this default, because they can't
share the same information then. To be on the safe side regardings
regressions, we shouldn't make this default as well, come to think of
it.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

> The bootloader usually is burned on /dev/mtd0, while the BBT is placed
> at the end
> of the NAND chip.
> 
> I tested the NAND boot mode too.
> 
> What's your concern?

Bootloaders may also need to write to NAND. So, they need to share the
same bad block information with the kernel. Currently, I am not aware of
a bootloader for mxs which support BBT without OOB. Unless this has
changed meanwhile, we shouldn't make this default, because they can't
share the same information then. To be on the safe side regardings
regressions, we shouldn't make this default as well, come to think of
it.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120130/6d726d4e/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

>> The bootloader usually is burned on /dev/mtd0, while the BBT is placed
>> at the end
>> of the NAND chip.
>>
>> I tested the NAND boot mode too.
>>
>> What's your concern?
> Bootloaders may also need to write to NAND. So, they need to share the
Do you mean the uboot may write something to the NAND?
Could you show me some more detail cases?

> same bad block information with the kernel. Currently, I am not aware of
> a bootloader for mxs which support BBT without OOB. Unless this has
> changed meanwhile, we shouldn't make this default, because they can't
The NAND_BBT_NO_OOB makes the BBT written to the NAND with the ECC enabled.
> share the same information then. To be on the safe side regardings
The kobs-ng which burns the bootloader to the NAND will also burn the
whole BBT
to the NAND too.

So I think the bootloader and the kernel share the same BBT information.

But if the bootloader can make some block bad, the BBT information
becomes different.
Does the bootloader have the feature to make some block bad?


Br
Huang Shijie




> regressions, we shouldn't make this default as well, come to think of
> it.
>
> Regards,
>
>    Wolfram
>

[PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

>> The bootloader usually is burned on /dev/mtd0, while the BBT is placed
>> at the end
>> of the NAND chip.
>>
>> I tested the NAND boot mode too.
>>
>> What's your concern?
> Bootloaders may also need to write to NAND. So, they need to share the
Do you mean the uboot may write something to the NAND?
Could you show me some more detail cases?

> same bad block information with the kernel. Currently, I am not aware of
> a bootloader for mxs which support BBT without OOB. Unless this has
> changed meanwhile, we shouldn't make this default, because they can't
The NAND_BBT_NO_OOB makes the BBT written to the NAND with the ECC enabled.
> share the same information then. To be on the safe side regardings
The kobs-ng which burns the bootloader to the NAND will also burn the
whole BBT
to the NAND too.

So I think the bootloader and the kernel share the same BBT information.

But if the bootloader can make some block bad, the BBT information
becomes different.
Does the bootloader have the feature to make some block bad?


Br
Huang Shijie




> regressions, we shouldn't make this default as well, come to think of
> it.
>
> Regards,
>
>    Wolfram
>

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]

CCing Marek, he can say more about the U-Boot side probably...

> > Bootloaders may also need to write to NAND. So, they need to share the
> Do you mean the uboot may write something to the NAND?
> Could you show me some more detail cases?

U-Boot has NAND support in mainline, for barebox it is work-in-progress.
Both can and do write to NAND (kernel, rootfs), because both have
established procedures to do so (and maybe don't want to rely on
third-party tools like kobs-ng).

> > share the same information then. To be on the safe side regardings
> The kobs-ng which burns the bootloader to the NAND will also burn the
> whole BBT
> to the NAND too.

Did it always do that? Or is a newer version needed?

> But if the bootloader can make some block bad, the BBT information
> becomes different.
> Does the bootloader have the feature to make some block bad?

Sure. If you are able to write NAND, you should be able to mark blocks
bad, too :)

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

CCing Marek, he can say more about the U-Boot side probably...

> > Bootloaders may also need to write to NAND. So, they need to share the
> Do you mean the uboot may write something to the NAND?
> Could you show me some more detail cases?

U-Boot has NAND support in mainline, for barebox it is work-in-progress.
Both can and do write to NAND (kernel, rootfs), because both have
established procedures to do so (and maybe don't want to rely on
third-party tools like kobs-ng).

> > share the same information then. To be on the safe side regardings
> The kobs-ng which burns the bootloader to the NAND will also burn the
> whole BBT
> to the NAND too.

Did it always do that? Or is a newer version needed?

> But if the bootloader can make some block bad, the BBT information
> becomes different.
> Does the bootloader have the feature to make some block bad?

Sure. If you are able to write NAND, you should be able to mark blocks
bad, too :)

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120130/99632de8/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> CCing Marek, he can say more about the U-Boot side probably...

Thanks!

> 
> > > Bootloaders may also need to write to NAND. So, they need to share the
> > 
> > Do you mean the uboot may write something to the NAND?
> > Could you show me some more detail cases?
> 
> U-Boot has NAND support in mainline, for barebox it is work-in-progress.

Why don't you rather start hacking on u-boot instead of chasing behind it all 
the time ;-)

> Both can and do write to NAND (kernel, rootfs), because both have
> established procedures to do so (and maybe don't want to rely on
> third-party tools like kobs-ng).

I think the FSL U-Boot can write stuff to NAND too. You can give that a shot 
too.
> 
> > > share the same information then. To be on the safe side regardings
> > 
> > The kobs-ng which burns the bootloader to the NAND will also burn the
> > whole BBT
> > to the NAND too.
> 
> Did it always do that? Or is a newer version needed?

I can't comment on this one, I never used it. I rather got NAND working 
properly.

> 
> > But if the bootloader can make some block bad, the BBT information
> > becomes different.
> > Does the bootloader have the feature to make some block bad?
> 
> Sure. If you are able to write NAND, you should be able to mark blocks
> bad, too :)

Not really, but you prefer to do so ;-)

Thanks!

M
> 
> Thanks,
> 
>    Wolfram

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> CCing Marek, he can say more about the U-Boot side probably...

Thanks!

> 
> > > Bootloaders may also need to write to NAND. So, they need to share the
> > 
> > Do you mean the uboot may write something to the NAND?
> > Could you show me some more detail cases?
> 
> U-Boot has NAND support in mainline, for barebox it is work-in-progress.

Why don't you rather start hacking on u-boot instead of chasing behind it all 
the time ;-)

> Both can and do write to NAND (kernel, rootfs), because both have
> established procedures to do so (and maybe don't want to rely on
> third-party tools like kobs-ng).

I think the FSL U-Boot can write stuff to NAND too. You can give that a shot 
too.
> 
> > > share the same information then. To be on the safe side regardings
> > 
> > The kobs-ng which burns the bootloader to the NAND will also burn the
> > whole BBT
> > to the NAND too.
> 
> Did it always do that? Or is a newer version needed?

I can't comment on this one, I never used it. I rather got NAND working 
properly.

> 
> > But if the bootloader can make some block bad, the BBT information
> > becomes different.
> > Does the bootloader have the feature to make some block bad?
> 
> Sure. If you are able to write NAND, you should be able to mark blocks
> bad, too :)

Not really, but you prefer to do so ;-)

Thanks!

M
> 
> Thanks,
> 
>    Wolfram

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

> > U-Boot has NAND support in mainline, for barebox it is work-in-progress.
> 
> Why don't you rather start hacking on u-boot instead of chasing behind it all 
> the time ;-)

"chasing all the time behind it" is plain wrong, you should know that. I
also fed back the DMA fix I found. Besides, this is off-topic.

> > Did it always do that? Or is a newer version needed?
> 
> I can't comment on this one, I never used it. I rather got NAND working 
> properly.

Me neither. But if so, we have another regression candidate.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

> > U-Boot has NAND support in mainline, for barebox it is work-in-progress.
> 
> Why don't you rather start hacking on u-boot instead of chasing behind it all 
> the time ;-)

"chasing all the time behind it" is plain wrong, you should know that. I
also fed back the DMA fix I found. Besides, this is off-topic.

> > Did it always do that? Or is a newer version needed?
> 
> I can't comment on this one, I never used it. I rather got NAND working 
> properly.

Me neither. But if so, we have another regression candidate.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120130/c92e28fb/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > > U-Boot has NAND support in mainline, for barebox it is
> > > work-in-progress.
> > 
> > Why don't you rather start hacking on u-boot instead of chasing behind it
> > all the time ;-)
> 
> "chasing all the time behind it" is plain wrong, you should know that. I
> also fed back the DMA fix I found. Besides, this is off-topic.

Hehe, just torturing you guys a bit :)
> 
> > > Did it always do that? Or is a newer version needed?
> > 
> > I can't comment on this one, I never used it. I rather got NAND working
> > properly.
> 
> Me neither. But if so, we have another regression candidate.

What regression candidate ? The version of NAND driver in u-boot should be close 
to what's in mainline Linux kernel.

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > > U-Boot has NAND support in mainline, for barebox it is
> > > work-in-progress.
> > 
> > Why don't you rather start hacking on u-boot instead of chasing behind it
> > all the time ;-)
> 
> "chasing all the time behind it" is plain wrong, you should know that. I
> also fed back the DMA fix I found. Besides, this is off-topic.

Hehe, just torturing you guys a bit :)
> 
> > > Did it always do that? Or is a newer version needed?
> > 
> > I can't comment on this one, I never used it. I rather got NAND working
> > properly.
> 
> Me neither. But if so, we have another regression candidate.

What regression candidate ? The version of NAND driver in u-boot should be close 
to what's in mainline Linux kernel.

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1018 bytes --]


> Hehe, just torturing you guys a bit :)

And the gain of that is? The only outcome I currently see is that I feel
less motivated to put you on CC next time.

> > > > Did it always do that? Or is a newer version needed?
> > > 
> > > I can't comment on this one, I never used it. I rather got NAND working
> > > properly.
> > 
> > Me neither. But if so, we have another regression candidate.
> 
> What regression candidate ? The version of NAND driver in u-boot should be close 
> to what's in mainline Linux kernel.

I am not talking about U-Boot here. I was wondering if somebody who uses
the FSL deployment method would need to update kobs-ng, so a proper BBT
gets written. If so, people missing the need to update would see a
regression. Which is another reason to not make BBT usage default. But I
maybe wrong here. Huang will tell.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

> Hehe, just torturing you guys a bit :)

And the gain of that is? The only outcome I currently see is that I feel
less motivated to put you on CC next time.

> > > > Did it always do that? Or is a newer version needed?
> > > 
> > > I can't comment on this one, I never used it. I rather got NAND working
> > > properly.
> > 
> > Me neither. But if so, we have another regression candidate.
> 
> What regression candidate ? The version of NAND driver in u-boot should be close 
> to what's in mainline Linux kernel.

I am not talking about U-Boot here. I was wondering if somebody who uses
the FSL deployment method would need to update kobs-ng, so a proper BBT
gets written. If so, people missing the need to update would see a
regression. Which is another reason to not make BBT usage default. But I
maybe wrong here. Huang will tell.

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120130/d8152c1a/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > Hehe, just torturing you guys a bit :)
> 
> And the gain of that is? The only outcome I currently see is that I feel
> less motivated to put you on CC next time.
> 
> > > > > Did it always do that? Or is a newer version needed?
> > > > 
> > > > I can't comment on this one, I never used it. I rather got NAND
> > > > working properly.
> > > 
> > > Me neither. But if so, we have another regression candidate.
> > 
> > What regression candidate ? The version of NAND driver in u-boot should
> > be close to what's in mainline Linux kernel.
> 
> I am not talking about U-Boot here. I was wondering if somebody who uses
> the FSL deployment method would need to update kobs-ng, so a proper BBT
> gets written.

... if someone actually still uses kobs-ng.

> If so, people missing the need to update would see a
> regression. Which is another reason to not make BBT usage default. But I
> maybe wrong here. Huang will tell.

Yes, either him or Fabio. This is a good point actually.

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > Hehe, just torturing you guys a bit :)
> 
> And the gain of that is? The only outcome I currently see is that I feel
> less motivated to put you on CC next time.
> 
> > > > > Did it always do that? Or is a newer version needed?
> > > > 
> > > > I can't comment on this one, I never used it. I rather got NAND
> > > > working properly.
> > > 
> > > Me neither. But if so, we have another regression candidate.
> > 
> > What regression candidate ? The version of NAND driver in u-boot should
> > be close to what's in mainline Linux kernel.
> 
> I am not talking about U-Boot here. I was wondering if somebody who uses
> the FSL deployment method would need to update kobs-ng, so a proper BBT
> gets written.

... if someone actually still uses kobs-ng.

> If so, people missing the need to update would see a
> regression. Which is another reason to not make BBT usage default. But I
> maybe wrong here. Huang will tell.

Yes, either him or Fabio. This is a good point actually.

Re: [PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

hi,
> CCing Marek, he can say more about the U-Boot side probably...
>
>>> Bootloaders may also need to write to NAND. So, they need to share the
>> Do you mean the uboot may write something to the NAND?
>> Could you show me some more detail cases?
> U-Boot has NAND support in mainline, for barebox it is work-in-progress.
> Both can and do write to NAND (kernel, rootfs), because both have
> established procedures to do so (and maybe don't want to rely on
> third-party tools like kobs-ng).
>
ok.

What's about to add a module_param() to enable/disable the BBT for GPMI?
What's your suggestion?


Br
Huang Shijie

[PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

hi,
> CCing Marek, he can say more about the U-Boot side probably...
>
>>> Bootloaders may also need to write to NAND. So, they need to share the
>> Do you mean the uboot may write something to the NAND?
>> Could you show me some more detail cases?
> U-Boot has NAND support in mainline, for barebox it is work-in-progress.
> Both can and do write to NAND (kernel, rootfs), because both have
> established procedures to do so (and maybe don't want to rely on
> third-party tools like kobs-ng).
>
ok.

What's about to add a module_param() to enable/disable the BBT for GPMI?
What's your suggestion?


Br
Huang Shijie

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 385 bytes --]

> What's about to add a module_param() to enable/disable the BBT for GPMI?
> What's your suggestion?

I'd make it board specific rather than a module parameter like most
other drivers seem to do.

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

> What's about to add a module_param() to enable/disable the BBT for GPMI?
> What's your suggestion?

I'd make it board specific rather than a module parameter like most
other drivers seem to do.

Thanks,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120131/02747958/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

hi,
> I'd make it board specific rather than a module parameter like most
ok. I make it board specific.


thanks

Huang Shijie
> other drivers seem to do.
>

[PATCH] mtd/gpmi : add BBT support

[Huang Shijie]

hi,
> I'd make it board specific rather than a module parameter like most
ok. I make it board specific.


thanks

Huang Shijie
> other drivers seem to do.
>

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > What's about to add a module_param() to enable/disable the BBT for GPMI?
> > What's your suggestion?
> 
> I'd make it board specific rather than a module parameter like most
> other drivers seem to do.
> 
> Thanks,
> 
>    Wolfram

Actually it's not board specific. You can run various bootloaders or various 
bootstrap tools on any of those boards. Though pdata seems ok for the default 
case, maybe we should have a simple way to override this?

M

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > What's about to add a module_param() to enable/disable the BBT for GPMI?
> > What's your suggestion?
> 
> I'd make it board specific rather than a module parameter like most
> other drivers seem to do.
> 
> Thanks,
> 
>    Wolfram

Actually it's not board specific. You can run various bootloaders or various 
bootstrap tools on any of those boards. Though pdata seems ok for the default 
case, maybe we should have a simple way to override this?

M

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]


> Actually it's not board specific. You can run various bootloaders or various 
> bootstrap tools on any of those boards. Though pdata seems ok for the default 
> case, maybe we should have a simple way to override this?

You mean you want to switch to/drop the BBT if you want to? On MX23,
this can be easily a very dangerous thing to do. What's the use case?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

> Actually it's not board specific. You can run various bootloaders or various 
> bootstrap tools on any of those boards. Though pdata seems ok for the default 
> case, maybe we should have a simple way to override this?

You mean you want to switch to/drop the BBT if you want to? On MX23,
this can be easily a very dangerous thing to do. What's the use case?

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120131/2e6defcf/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > Actually it's not board specific. You can run various bootloaders or
> > various bootstrap tools on any of those boards. Though pdata seems ok
> > for the default case, maybe we should have a simple way to override
> > this?
> 
> You mean you want to switch to/drop the BBT if you want to? On MX23,
> this can be easily a very dangerous thing to do. What's the use case?

Tools that don't support writing the BBT properly.

> 
> Regards,
> 
>    Wolfram

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > Actually it's not board specific. You can run various bootloaders or
> > various bootstrap tools on any of those boards. Though pdata seems ok
> > for the default case, maybe we should have a simple way to override
> > this?
> 
> You mean you want to switch to/drop the BBT if you want to? On MX23,
> this can be easily a very dangerous thing to do. What's the use case?

Tools that don't support writing the BBT properly.

> 
> Regards,
> 
>    Wolfram

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> >> The bootloader usually is burned on /dev/mtd0, while the BBT is placed
> >> at the end
> >> of the NAND chip.
> >> 
> >> I tested the NAND boot mode too.
> >> 
> >> What's your concern?
> > 
> > Bootloaders may also need to write to NAND. So, they need to share the
> 
> Do you mean the uboot may write something to the NAND?

Yes it can, mainline for certain and ... surprisingly even the one provided by 
freescale ;-)

> Could you show me some more detail cases?

Type "help" in the command prompt and look for "nand" ;-)
> 
> > same bad block information with the kernel. Currently, I am not aware of
> > a bootloader for mxs which support BBT without OOB. Unless this has
> > changed meanwhile, we shouldn't make this default, because they can't
> 
> The NAND_BBT_NO_OOB makes the BBT written to the NAND with the ECC enabled.
> 
> > share the same information then. To be on the safe side regardings

The mainline incarnation of this should be able to work with the BBT just fine. 
You can give it a go, mx28evk (the freescale kit) is supported.
> 
> The kobs-ng which burns the bootloader to the NAND will also burn the
> whole BBT
> to the NAND too.
> 
> So I think the bootloader and the kernel share the same BBT information.
> 
> But if the bootloader can make some block bad, the BBT information
> becomes different.
> Does the bootloader have the feature to make some block bad?

Sure

M
> 
> 
> Br
> Huang Shijie
> 
> > regressions, we shouldn't make this default as well, come to think of
> > it.
> > 
> > Regards,
> > 
> >    Wolfram
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> >> The bootloader usually is burned on /dev/mtd0, while the BBT is placed
> >> at the end
> >> of the NAND chip.
> >> 
> >> I tested the NAND boot mode too.
> >> 
> >> What's your concern?
> > 
> > Bootloaders may also need to write to NAND. So, they need to share the
> 
> Do you mean the uboot may write something to the NAND?

Yes it can, mainline for certain and ... surprisingly even the one provided by 
freescale ;-)

> Could you show me some more detail cases?

Type "help" in the command prompt and look for "nand" ;-)
> 
> > same bad block information with the kernel. Currently, I am not aware of
> > a bootloader for mxs which support BBT without OOB. Unless this has
> > changed meanwhile, we shouldn't make this default, because they can't
> 
> The NAND_BBT_NO_OOB makes the BBT written to the NAND with the ECC enabled.
> 
> > share the same information then. To be on the safe side regardings

The mainline incarnation of this should be able to work with the BBT just fine. 
You can give it a go, mx28evk (the freescale kit) is supported.
> 
> The kobs-ng which burns the bootloader to the NAND will also burn the
> whole BBT
> to the NAND too.
> 
> So I think the bootloader and the kernel share the same BBT information.
> 
> But if the bootloader can make some block bad, the BBT information
> becomes different.
> Does the bootloader have the feature to make some block bad?

Sure

M
> 
> 
> Br
> Huang Shijie
> 
> > regressions, we shouldn't make this default as well, come to think of
> > it.
> > 
> > Regards,
> > 
> >    Wolfram
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]


> The mainline incarnation of this should be able to work with the BBT just fine. 
> You can give it a go, mx28evk (the freescale kit) is supported.

Did you test? I can't find any NO_OOB option in the code. Not that you
lose the BBTs...

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCH] mtd/gpmi : add BBT support

[Wolfram Sang]

> The mainline incarnation of this should be able to work with the BBT just fine. 
> You can give it a go, mx28evk (the freescale kit) is supported.

Did you test? I can't find any NO_OOB option in the code. Not that you
lose the BBTs...

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120130/f91c6ea1/attachment.sig>

Re: [PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > The mainline incarnation of this should be able to work with the BBT just
> > fine. You can give it a go, mx28evk (the freescale kit) is supported.
> 
> Did you test? I can't find any NO_OOB option in the code. Not that you
> lose the BBTs...

I didn't. Let's also Cc Fabio here, I think he can comment on the FSL part of 
stuff better than me.

Btw. aren't we duplicating stuff here? The mx28 has some builtin badblock 
protection.

[PATCH] mtd/gpmi : add BBT support

[Marek Vasut]

> > The mainline incarnation of this should be able to work with the BBT just
> > fine. You can give it a go, mx28evk (the freescale kit) is supported.
> 
> Did you test? I can't find any NO_OOB option in the code. Not that you
> lose the BBTs...

I didn't. Let's also Cc Fabio here, I think he can comment on the FSL part of 
stuff better than me.

Btw. aren't we duplicating stuff here? The mx28 has some builtin badblock 
protection.