mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
Subsystems (3)
PATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so we end up with various failures or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state already before sending commands to NAND. This behaviour was observed in barebox and kernel, so I assume it affects U-Boot as well. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side.
---
Only compile tested. Test case was to repeatedly reboot into a simple userspace on a UBI volume. Either the bootloader failed to find its data or the kernel could not mount the UBI volume once in a while. (Yes, the kernel could not mount the UBI although it was itself loaded correctly from NAND. So, it is some set-up issue.) This was nasty to debug, so I thought I let you know...
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mtd/nand/mxs_nand.c +3 -0
@@ -1058,6 +1058,8 @@ int mxs_nand_init(struct mxs_nand_info *info) {struct mxs_gpmi_regs *gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE ; +struct mxs_bch_regs *bch_regs = + (struct mxs_bch_regs *)MXS_BCH_BASE ;int i =0 , j; info->desc = malloc(sizeof(struct mxs_dma_desc *) *
@@ -1081,6 +1083,7 @@ int mxs_nand_init(struct mxs_nand_info *info)/* Reset the GPMI block. */ mxs_reset_block (&gpmi_regs->hw_gpmi_ctrl0_reg); +mxs_reset_block (&bch_regs->hw_bch_ctrl_reg);/* * Choose NAND mode, set IRQ polarity, disable write protection and
Signature · 1 line
1.7.10.4
PATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
Quoted 42 lines · Wolfram Sang
It could happen (1 out of 100 times) that NAND did not start up correctly after
warm rebooting, so we end up with various failures or DMA timed out due to a
stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state
already before sending commands to NAND. This behaviour was observed in barebox
and kernel, so I assume it affects U-Boot as well. I chose to keep the extra
reset for BCH when changing the flash layout to be on the safe side.Signed-off-by Wolfram Sang <[email protected]>---
Only compile tested. Test case was to repeatedly reboot into a simple userspace
on a UBI volume. Either the bootloader failed to find its data or the kernel
could not mount the UBI volume once in a while. (Yes, the kernel could not mount the UBI although it was itself loaded correctly from NAND. So, it is some
set-up issue.) This was nasty to debug, so I thought I let you know...drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)drivers/mtd/nand/mxs_nand.c +2
-0@@ -1058,6 +1058,8 @@ int mxs_nand_init(struct mxs_nand_info *info) {struct mxs_gpmi_regs *gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE ; +struct mxs_bch_regs *bch_regs = + (struct mxs_bch_regs *)MXS_BCH_BASE ;int i =0 , j; info->desc = malloc(sizeof(struct mxs_dma_desc *) *
drivers/mtd/nand/mxs_nand.c int mxs_nand_init(struct mxs_nand_info *info) · line 1087
Quoted 5 lines
drivers/mtd/nand/mxs_nand.c +1
-0@@ -1081,6 +1083,7 @@ int mxs_nand_init(struct mxs_nand_info *info)/* Reset the GPMI block. */ mxs_reset_block (&gpmi_regs->hw_gpmi_ctrl0_reg); +mxs_reset_block (&bch_regs->hw_bch_ctrl_reg);
A comment here why this is need would be nice.
Quoted 10 lines
drivers/mtd/nand/mxs_nand.c +0
-1/* * Choose NAND mode, set IRQ polarity, disable write protection and -- 1.7.10.4
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: otavio at ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Fabio Estevam
reviewerPATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
In reply to Wolfram SangHi Wolfram,
Quoted 14 lines · Wolfram Sang
drivers/mtd/nand/mxs_nand.c +2
-0@@ -1058,6 +1058,8 @@ int mxs_nand_init(struct mxs_nand_info *info) {struct mxs_gpmi_regs *gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE ; +struct mxs_bch_regs *bch_regs = + (struct mxs_bch_regs *)MXS_BCH_BASE ;int i =0 , j; info->desc = malloc(sizeof(struct mxs_dma_desc *) *
drivers/mtd/nand/mxs_nand.c int mxs_nand_init(struct mxs_nand_info *info) · line 1086
Quoted 4 lines
drivers/mtd/nand/mxs_nand.c +1
-0@@ -1081,6 +1083,7 @@ int mxs_nand_init(struct mxs_nand_info *info)/* Reset the GPMI block. */ mxs_reset_block (&gpmi_regs->hw_gpmi_ctrl0_reg); +mxs_reset_block (&bch_regs->hw_bch_ctrl_reg);
In your kernel patch you only do the reset for mx23, but here you do it for mx28.
Which one is correct?
Regards,
Fabio Estevam
PATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
Quoted 19 lines · Fabio Estevam
Hi Wolfram,
Quoted 15 lines · Wolfram Sang
drivers/mtd/nand/mxs_nand.c +2
-0@@ -1058,6 +1058,8 @@ int mxs_nand_init(struct mxs_nand_info *info) {struct mxs_gpmi_regs *gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE ; +struct mxs_bch_regs *bch_regs = + (struct mxs_bch_regs *)MXS_BCH_BASE ;int i =0 , j; info->desc = malloc(sizeof(struct mxs_dma_desc *) *@@ -1081,6 +1083,7 @@ int mxs_nand_init(struct mxs_nand_info *info)
Quoted 8 lines
drivers/mtd/nand/mxs_nand.c int mxs_nand_init(struct mxs_nand_info *info) · line 1086
Quoted 3 lines
drivers/mtd/nand/mxs_nand.c +1
-0/* Reset the GPMI block. */ mxs_reset_block (&gpmi_regs->hw_gpmi_ctrl0_reg); +mxs_reset_block (&bch_regs->hw_bch_ctrl_reg);In your kernel patch you only do the reset for mx23, but here you do it for mx28.
Which one is correct?
Both patches are correct. Check the kernel code again, please, especially the function arguments.
Signature · 9 lines
Pengutronix e.K. | Wolfram Sang | Industrial Linux Solutions | http://www.pengutronix.de/ | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121206/1b443d87/attachment.pgp>
Fabio Estevam
reviewerPATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
Quoted 2 lines · Wolfram Sang
Both patches are correct. Check the kernel code again, please, especially the function arguments.
Ok, all is clear after reading the comments of the kernel gpmi_reset_block function.
Regards,
Fabio Estevam
PATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
In reply to Wolfram SangDear Wolfram Sang,
Quoted 10 lines
It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so we end up with various failures or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state already before sending commands to NAND. This behaviour was observed in barebox and kernel, so I assume it affects U-Boot as well. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side.
Signed-off-by Wolfram Sang <[email protected]>
[...]
Good, thanks. Ccing Scott to pick this up.
Best regards,
Marek Vasut
PATCH 1/1 mtd: nand: mxs: reset BCH earlier, too, to avoid NAND startup problems
In reply to Wolfram SangQuoted 14 lines · Wolfram Sang
It could happen (1 out of 100 times) that NAND did not start up correctly after
warm rebooting, so we end up with various failures or DMA timed out due to a
stalled BCH. When resetting BCH together with GPMI, the issue could not be
observed anymore (after 10000+ reboots). We probably need the consistent state
already before sending commands to NAND. This behaviour was observed in barebox
and kernel, so I assume it affects U-Boot as well. I chose to keep the extra
reset for BCH when changing the flash layout to be on the safe side.
Quoted 2 lines
Signed-off-by Wolfram Sang <[email protected]>---
Applied to u-boot-nand-flash
-Scott