[U-Boot] [PATCH] mxs_nand: Fix ECC strength for NAND flash with OOB size of 256
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de ---
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16; + + if (page_oob_size == 256) + return 18; }
return 0;
Hi Heiko,
On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16;
if (page_oob_size == 256)return 18; } return 0;
How about calculation the ECC strength dynamically? Peng Fan from Freescale send a patch doing this in December 2014 which was already reviewed by Marek: https://patchwork.ozlabs.org/patch/422756/
It is also necessary to change the calculation in mxsboot...
Best regards Jörg Krause
On Monday, April 13, 2015 at 10:39:46 AM, Jörg Krause wrote:
Hi Heiko,
On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16;
if (page_oob_size == 256)return 18; } return 0;How about calculation the ECC strength dynamically? Peng Fan from Freescale send a patch doing this in December 2014 which was already reviewed by Marek: https://patchwork.ozlabs.org/patch/422756/
It is also necessary to change the calculation in mxsboot...
Would be nice if the patch got applied, but I think there were some comments and the patch was never fixed/reposted. If Heiko wants to do it, that'd be nice.
Nice domain name btw ;-)
Best regards, Marek Vasut
Hello Marek, Joerg,
Am 13.04.2015 10:42, schrieb Marek Vasut:
On Monday, April 13, 2015 at 10:39:46 AM, Jörg Krause wrote:
Hi Heiko,
On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16;
if (page_oob_size == 256)return 18; } return 0;How about calculation the ECC strength dynamically? Peng Fan from Freescale send a patch doing this in December 2014 which was already reviewed by Marek: https://patchwork.ozlabs.org/patch/422756/
It is also necessary to change the calculation in mxsboot...
Would be nice if the patch got applied, but I think there were some comments and the patch was never fixed/reposted. If Heiko wants to do it, that'd be nice.
Hmm.. I feel, I have not much time left for fixing such things...
Joerg: You wrote on Jan. 27, 2015, 11:14 p.m.: "I was able to fix mxsboot, but I had difficulties with round_down, which is a macro definition in linux/kernel.h. I've copied the macro definition to mxsboot. I will submit the patch in a seperate mail."
Did you post such a patch? Was this the onyl problem of the patch from Peng Fan?
"I would like to see a comment or a macro for the magic number 13, which is the value for the Galois Field, just for clarification"
I have no idea what 13 means ...
Nice domain name btw ;-)
Indeed.
bye, Heiko
On Monday, April 13, 2015 at 11:01:14 AM, Heiko Schocher wrote:
Hello Marek, Joerg,
Am 13.04.2015 10:42, schrieb Marek Vasut:
On Monday, April 13, 2015 at 10:39:46 AM, Jörg Krause wrote:
Hi Heiko,
On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16;
if (page_oob_size == 256)return 18; } return 0;How about calculation the ECC strength dynamically? Peng Fan from Freescale send a patch doing this in December 2014 which was already reviewed by Marek: https://patchwork.ozlabs.org/patch/422756/
It is also necessary to change the calculation in mxsboot...
Would be nice if the patch got applied, but I think there were some comments and the patch was never fixed/reposted. If Heiko wants to do it, that'd be nice.
Hmm.. I feel, I have not much time left for fixing such things...
Joerg: You wrote on Jan. 27, 2015, 11:14 p.m.: "I was able to fix mxsboot, but I had difficulties with round_down, which is a macro definition in linux/kernel.h. I've copied the macro definition to mxsboot. I will submit the patch in a seperate mail."
Did you post such a patch? Was this the onyl problem of the patch from Peng Fan?
"I would like to see a comment or a macro for the magic number 13, which is the value for the Galois Field, just for clarification"
I have no idea what 13 means ...
Well I know what GF(13) stands for, but why this particular prime (13) is chosen in the computation, that is not clear. So a comment would really be helpful here.
Best regards,
Hi Marek, Heiko,
On Mo, 2015-04-13 at 11:01 +0200, Heiko Schocher wrote:
Hello Marek, Joerg,
Am 13.04.2015 10:42, schrieb Marek Vasut:
On Monday, April 13, 2015 at 10:39:46 AM, Jörg Krause wrote:
Hi Heiko,
On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16;
if (page_oob_size == 256)return 18; } return 0;How about calculation the ECC strength dynamically? Peng Fan from Freescale send a patch doing this in December 2014 which was already reviewed by Marek: https://patchwork.ozlabs.org/patch/422756/
It is also necessary to change the calculation in mxsboot...
Would be nice if the patch got applied, but I think there were some comments and the patch was never fixed/reposted. If Heiko wants to do it, that'd be nice.
Hmm.. I feel, I have not much time left for fixing such things...
I can re-submit the patch from Peng Fan together with my fixes for mxsboot.
Joerg: You wrote on Jan. 27, 2015, 11:14 p.m.: "I was able to fix mxsboot, but I had difficulties with round_down, which is a macro definition in linux/kernel.h. I've copied the macro definition to mxsboot. I will submit the patch in a seperate mail."
Did you post such a patch? Was this the onyl problem of the patch from Peng Fan?
No, I didn't. I waited for some comment and then I just forgot about it. The main problem with the patch from Peng Fan was that it was not consistent with mxsboot, which still has the hardcoded oobsizes. I copied the calculation to mxsboot.c, but failed to include linux/kernel.h, because mxsboot is compiled with the host compiler and u-boot with the cross-compiler. So I just copied the macro definition for round_down from kernel.h to mxsboot.c.
"I would like to see a comment or a macro for the magic number 13, which is the value for the Galois Field, just for clarification"
I have no idea what 13 means ...
This is cited from the i.MX28 Reference Manual: BCH-codes are a type of block-code, which implies that all error- correction is performed over a block of N-symbols. The BCH operation will be performed over GF (2^13 = 8192), which is the Galois Field consisting of 8191 one-bit symbols.
Nice domain name btw ;-)
Indeed.
Thanks :-)
bye, Heiko
Hello Joerg,
Am 13.04.2015 13:38, schrieb Jörg Krause:
Hi Marek, Heiko,
On Mo, 2015-04-13 at 11:01 +0200, Heiko Schocher wrote:
Hello Marek, Joerg,
Am 13.04.2015 10:42, schrieb Marek Vasut:
On Monday, April 13, 2015 at 10:39:46 AM, Jörg Krause wrote:
Hi Heiko,
On So, 2015-04-12 at 10:17 +0200, Heiko Schocher wrote:
On the i.mx6 based aristainetos2 board a Toshiba TH58NYG3S0HBAI4 is used, which has 4096 pagesize and 256b oob. The ECC strength was not correct detected by U-Boot
Signed-off-by: Heiko Schocher hs@denx.de
drivers/mtd/nand/mxs_nand.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c index 2d2b938..00bf036 100644 --- a/drivers/mtd/nand/mxs_nand.c +++ b/drivers/mtd/nand/mxs_nand.c @@ -163,6 +163,9 @@ static inline uint32_t mxs_nand_get_ecc_strength(uint32_t page_data_size,
if (page_oob_size == 224) return 16;
if (page_oob_size == 256)return 18; } return 0;How about calculation the ECC strength dynamically? Peng Fan from Freescale send a patch doing this in December 2014 which was already reviewed by Marek: https://patchwork.ozlabs.org/patch/422756/
It is also necessary to change the calculation in mxsboot...
Would be nice if the patch got applied, but I think there were some comments and the patch was never fixed/reposted. If Heiko wants to do it, that'd be nice.
Hmm.. I feel, I have not much time left for fixing such things...
I can re-submit the patch from Peng Fan together with my fixes for mxsboot.
Yes, please (and with a comment for the magic number 13 ;-)
I can test your patches then on an imx6 based board ... maybe we do not need my patch then!
Joerg: You wrote on Jan. 27, 2015, 11:14 p.m.: "I was able to fix mxsboot, but I had difficulties with round_down, which is a macro definition in linux/kernel.h. I've copied the macro definition to mxsboot. I will submit the patch in a seperate mail."
Did you post such a patch? Was this the onyl problem of the patch from Peng Fan?
No, I didn't. I waited for some comment and then I just forgot about it. The main problem with the patch from Peng Fan was that it was not consistent with mxsboot, which still has the hardcoded oobsizes. I copied the calculation to mxsboot.c, but failed to include linux/kernel.h, because mxsboot is compiled with the host compiler and u-boot with the cross-compiler. So I just copied the macro definition for round_down from kernel.h to mxsboot.c.
"I would like to see a comment or a macro for the magic number 13, which is the value for the Galois Field, just for clarification"
I have no idea what 13 means ...
This is cited from the i.MX28 Reference Manual: BCH-codes are a type of block-code, which implies that all error- correction is performed over a block of N-symbols. The BCH operation will be performed over GF (2^13 = 8192), which is the Galois Field consisting of 8191 one-bit symbols.
Thanks!
bye, Heiko
participants (3)
-
Heiko Schocher -
Jörg Krause -
Marek Vasut