mtd/gpmi : add BBT support
Subsystems (2)
PATCH 1/1 mtd/gpmi : add BBT support
add the BBT support to the gpmi nand driver.
--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
drivers/mtd/nand/gpmi-nand/gpmi-nand.c +1 -0
@@ -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 ;
Signature · 1 line
1.7.0.4
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 11 lines · Huang Shijie
add the BBT support to the gpmi nand driver.
Signed-off-by Huang Shijie <[email protected]>--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)drivers/mtd/nand/gpmi-nand/gpmi-nand.c +0
-0
drivers/mtd/nand/gpmi-nand/gpmi-nand.c static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this) · line 1496
Quoted 4 lines
drivers/mtd/nand/gpmi-nand/gpmi-nand.c +1
-0@@ -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?
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
? 2012?01?30? 17:46, Wolfram Sang ??:
Quoted 7 lines · Huang Shijie
Quoted 6 lines
add the BBT support to the gpmi nand driver.
Signed-off-by Huang Shijie <[email protected]>--- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
Quoted 12 lines
drivers/mtd/nand/gpmi-nand/gpmi-nand.c static int __devinit gpmi_nfc_init(struct gpmi_nand_data *this) · line 1496
Quoted 9 lines
drivers/mtd/nand/gpmi-nand/gpmi-nand.c +1
-0@@ -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 1/1 mtd/gpmi : add BBT support
Quoted 7 lines
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
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 9 lines
Quoted 8 lines
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?
Quoted 3 lines
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.
Quoted 1 line
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
Quoted 7 lines
regressions, we shouldn't make this default as well, come to think of it.
Regards,
Wolfram
PATCH 1/1 mtd/gpmi : add BBT support
CCing Marek, he can say more about the U-Boot side probably...
Quoted 3 lines
Quoted 1 line
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).
Quoted 4 lines
Quoted 1 line
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?
Quoted 3 lines
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
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 1 line
CCing Marek, he can say more about the U-Boot side probably...
Thanks!
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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 ;-)
Quoted 3 lines
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.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 4 lines
Thanks,
Wolfram
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 4 lines
Quoted 1 line
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.
Quoted 4 lines
Quoted 1 line
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.
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
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 :)
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
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 1/1 mtd/gpmi : add BBT support
Quoted 2 lines
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.
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
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.
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 10 lines
Quoted 1 line
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.
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 3 lines
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 1/1 mtd/gpmi : add BBT support
In reply to Wolfram Sanghi,
Quoted 10 lines
CCing Marek, he can say more about the U-Boot side probably...
Quoted 3 lines
Quoted 1 line
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 1/1 mtd/gpmi : add BBT support
Quoted 2 lines
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
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
hi,
Quoted 1 line
I'd make it board specific rather than a module parameter like most
ok. I make it board specific.
thanks
Huang Shijie
Quoted 2 lines
other drivers seem to do.
PATCH 1/1 mtd/gpmi : add BBT support
In reply to Wolfram SangQuoted 9 lines
Quoted 2 lines
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 1/1 mtd/gpmi : add BBT support
Quoted 4 lines
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
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 7 lines
Quoted 4 lines
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.
Quoted 4 lines
Regards,
Wolfram
PATCH 1/1 mtd/gpmi : add BBT support
In reply to Huang ShijieQuoted 11 lines
Quoted 9 lines
Quoted 7 lines
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 ;-)
Quoted 1 line
Could you show me some more detail cases?
Type "help" in the command prompt and look for "nand" ;-)
Quoted 8 lines
Quoted 4 lines
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_OOBmakes the BBT written to the NAND with the ECC enabled.Quoted 1 line
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.
Quoted 10 lines
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
Quoted 16 lines
Br
Huang ShijieQuoted 6 lines
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
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 3 lines
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...
Signature · 9 lines
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>
PATCH 1/1 mtd/gpmi : add BBT support
Quoted 5 lines
Quoted 2 lines
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_OOBoption 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.