NAND on Davinci boards
Hi all,
I have seen an incompatibility between the NAND driver in u-boot for the davinci boards and the linux driver (kernel 2.6.38, mainline).
I think it is not related to the specific board I use. In any case, I am using the ea20 board (OMAP-L138 based, in u-boot mainline), and I have added NAND support setting for the driver:
#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#define CONFIG_SYS_NAND_USE_FLASH_BBT
This is done in the linux driver, too. Both drivers are using ECC in Hardware, the number of bits for ECC is set to 4, the OOB is set first, and the oob layout is the same.
The NAND driver under u-boot works flawless. The kernel is stored on NAND (the board boots from a SPI-Flash), and everything seems correct.
The same thing under linux. In Linux I am able to set up a root filesystem with UBIfs, everything ok. Problems arises when u-boot tries to access to data written from Linux and viceversa. It seems to me that the management of ECC is different in u-boot and in kernel.
If I write under Linux a kernel Image in a NAND partition, after a reset I am not able to read that partition from u-boot.
Setting MTDDEBUG and a couple of printf, I see that nand_do_read_ops() report an error:
if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;This is the output of my board:
nboot aKernel
Loading from nand0, offset 0x0
Bad block table found at page 262080, version 0x01 Bad block table found at page 262016, version 0x01 Returning error 4 0
nand_bbt: ECC error while reading bad block table
nand_read_bbt: Bad block at 0x000002220000
nand_read_bbt: Bad block at 0x00000b120000
nand_read_bbt: Bad block at 0x00001f100000 nand_isbad_bbt(): bbt info for offs 0x00000000: (block 0) 0x00 Returning error 8 4
NAND read from offset 0 failed -74
** Read error
Checking the two drivers, it seems to me that they are doing different things. However, I do not know which one is correct. I would think that the driver in u-boot is old and must be synchronized with the Linux's driver, but after checking how u-boot gets the ecc's error from Hardware it seems to me it is correct.
Has anyone seen the same issue or have proposal, which driver should be modified ?
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
Quoted 8 lines · Stefano Babic
Hi all,
I have seen an incompatibility between the NAND driver in u-boot for the davinci boards and the linux driver (kernel 2.6.38, mainline).
I think it is not related to the specific board I use. In any case, I am using the ea20 board (OMAP-L138 based, in u-boot mainline), and I have added NAND support setting for the driver:
I'm using da830evm (OMAP-L137) with more or less up-to-date U-Boot, but quite old 2.6.18+ kernel from Montavista.
Quoted 3 lines
#define
CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#defineCONFIG_SYS_NAND_USE_FLASH_BBT
I don't have BBT enabled.
Quoted 5 lines
This is done in the linux driver, too. Both drivers are using ECC in Hardware, the number of bits for ECC is set to 4, the OOB is set first, and the oob layout is the same.
Quoted 7 lines
The NAND driver under u-boot works flawless. The kernel is stored on NAND (the board boots from a SPI-Flash), and everything seems correct.
The same thing under linux. In Linux I am able to set up a root filesystem with UBIfs, everything ok. Problems arises when u-boot tries to access to data written from Linux and viceversa. It seems to me that the management of ECC is different in u-boot and in kernel.
I almost always update my NAND kernel image from within Linux. U-Boot reads this with no errors and can reboot the system correctly.
Quoted 26 lines
If I write under Linux a kernel Image in a NAND partition, after a reset I am not able to read that partition from u-boot.
Setting MTDDEBUG and a couple of printf, I see thatnand_do_read_ops()report an error:if (mtd->ecc_stats.failed - stats.failed) return -EBADMSG;This is the output of my board:
nboot aKernel
Loading from nand0, offset
0x0
Bad block table found at page 262080, version0x01Bad block table found at page 262016, version0x01Returning error 4 0
nand_bbt: ECC error while reading bad block table
nand_read_bbt: Bad block at0x000002220000
nand_read_bbt: Bad block at0x00000b120000
nand_read_bbt: Bad block at0x00001f100000nand_isbad_bbt(): bbt info for offs0x00000000: (block 0)0x00Returning error 8 4
NAND read from offset 0 failed -74
** Read error
Quoted 8 lines
Checking the two drivers, it seems to me that they are doing different things. However, I do not know which one is correct. I would think that the driver in u-boot is old and must be synchronized with the Linux's driver, but after checking how u-boot gets the ecc's error from Hardware it seems to me it is correct.
Has anyone seen the same issue or have proposal, which driver should be modified ?
Neither ;)
I think the U-Boot NAND driver for davinci has always been setup to be compatible with the TI & Montavista Kernels. What I'm not sure about is if those Kernels are compatible with mainline Linux and in particular the very latest mainline kernels. In fact I'm not sure if it is compatible with the very latest TI Kernels.
Have you tried "nand dump" of a Linux programmed Kernel and compared it with "nand dump" of a U-Boot programmed Kernel? You would be able to see identical data in each case, but you will be able to compare the differences in the OOB. You only need to look at the first page to see if the OOB data or position of the OOB data differs.
You errors all seem to be in the BBT handling. I don't use BBT here.
Nick.
On 03/16/2011 11:01 AM, Nick Thompson wrote:
Hi Nick,
Quoted 8 lines
I'm using da830evm (OMAP-L137) with more or less up-to-date U-Boot, but quite old 2.6.18+ kernel from Montavista.
Quoted 3 lines
#define
CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#defineCONFIG_SYS_NAND_USE_FLASH_BBTI don't have BBT enabled.
Thanks, I have tried to disable it. No improvement, I got always ECC errors.
Quoted 5 lines
Neither ;)
I think the U-Boot NAND driver for davinci has always been setup to be compatible with the TI & Montavista Kernels.
This is probably the problem. I cannot check the montavista sources (I do not use them, but it seems that the old source.mvista.com went offline), but if u-boot sticks to mvista kernel is surely not aligned to the kernel mainline.
Quoted 4 lines
What I'm not sure about is if
those Kernels are compatible with mainline Linux and in particular the very latest mainline kernels. In fact I'm not sure if it is compatible with the very latest TI Kernels.
I think I can answer: no. I checked PSP_3.20 from Texas, and even on the arago project. TI went from their 2.x version of PSP tools to 3.x from mvista kernel to mainline kernel, and probably at that point u-boot and kernel were not anymore compatible. I have not seen patches in drivers/mtd/davinci_nand.c related to make it suitable for newer kernels.
Quoted 3 lines
Have you tried "nand dump" of a Linux programmed Kernel and compared it with "nand dump" of a U-Boot programmed Kernel?
I have tried now to get the first page (=2048 bytes) from both and I have compared byte-per-byte. They are identical, inclusive the oob part.
Quoted 4 lines
You would be able to see
identical data in each case, but you will be able to compare the differences in the OOB. You only need to look at the first page to see if the OOB data or position of the OOB data differs.
No differences at all. For both, I get in the oob:
OOB:
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00However, u-boot complain about it:
nand read kernel_addr_r 0 800
NAND read: device 0 offset 0x0, size 0x800
Getting too many errors
Getting too many errors
Getting too many errors
Getting too many errors
2048 bytes read: OK
Quoted 2 lines
You errors all seem to be in the BBT handling. I don't use BBT here.
Rather it is not enough - already tried to disable, same errors. It seems I can exclude errors by writing or reading raw data from the NAND. It seems the problem is related to a different interpretation of ECC results.
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
Quoted 31 lines · Stefano Babic
On 03/16/2011 11:01 AM, Nick Thompson wrote:
Hi Nick,
Quoted 8 lines
I'm using da830evm (OMAP-L137) with more or less up-to-date U-Boot, but quite old 2.6.18+ kernel from Montavista.
Quoted 3 lines
#define
CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
#defineCONFIG_SYS_NAND_USE_FLASH_BBTI don't have BBT enabled.
Thanks, I have tried to disable it. No improvement, I got always ECC errors.
Quoted 5 lines
Neither ;)
I think the U-Boot NAND driver for davinci has always been setup to be compatible with the TI & Montavista Kernels.
This is probably the problem. I cannot check the montavista sources (I do not use them, but it seems that the old source.mvista.com went offline), but if u-boot sticks to mvista kernel is surely not aligned to the kernel mainline.
Quoted 4 lines
What I'm not sure about is if
those Kernels are compatible with mainline Linux and in particular the very latest mainline kernels. In fact I'm not sure if it is compatible with the very latest TI Kernels.
Quoted 5 lines
I think I can answer: no. I checked PSP_3.20 from Texas, and even on the arago project. TI went from their 2.x version of PSP tools to 3.x from mvista kernel to mainline kernel, and probably at that point u-boot and kernel were not anymore compatible. I have not seen patches in
drivers/mtd/davinci_nand.crelated to make it suitable for newer kernels.
You may be correct, but maybe you have another problem first...
Quoted 16 lines
Quoted 4 lines
Have you tried "nand dump" of a Linux programmed Kernel and compared it with "nand dump" of a U-Boot programmed Kernel?
I have tried now to get the first page (=2048 bytes) from both and I have compared byte-per-byte. They are identical, inclusive the oob part.
Quoted 4 lines
You would be able to see
identical data in each case, but you will be able to compare the differences in the OOB. You only need to look at the first page to see if the OOB data or position of the OOB data differs.No differences at all. For both, I get in the oob:
OOB:
Quoted 8 lines
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00Is this really from the OOB for the first _kernel_ page. It looks wrong.
I see:
Quoted 1 line
nand dump
0x100000
<snip>
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff
9a ea 40 97 85 bc 5f f5
2e 15 91 c2 c6 93 14 c0
03 e3 b6 4c 35 40 2d 8f
7e 74 10 13 59 47 cf 09
24 10 6a 0a 8b e2 f1 b0The part after all the ff's is the ECC. IIRC a zero ECC implies all the data in the page is zero also. That would be an odd start to a Kernel image.
Can you confirm what it is you dumped?
Quoted 14 lines
However, u-boot complain about it:
nand read
kernel_addr_r0 800NAND read: device 0 offset
0x0, size0x800
Getting too many errors
Getting too many errors
Getting too many errors
Getting too many errors
2048 bytes read: OKQuoted 1 line
Quoted 9 lines
Quoted 1 line
You errors all seem to be in the BBT handling. I don't use BBT here.
Rather it is not enough - already tried to disable, same errors. It seems I can exclude errors by writing or reading raw data from the NAND. It seems the problem is related to a different interpretation of ECC results.
Stefano
Nick.
Quoted 1 line · Nick Thompson
You may be correct, but maybe you have another problem first...
Yes, you are right...
Quoted 25 lines
Quoted 16 lines
Quoted 4 lines
Have you tried "nand dump" of a Linux programmed Kernel and compared it with "nand dump" of a U-Boot programmed Kernel?
I have tried now to get the first page (=2048 bytes) from both and I have compared byte-per-byte. They are identical, inclusive the oob part.
Quoted 4 lines
You would be able to see
identical data in each case, but you will be able to compare the differences in the OOB. You only need to look at the first page to see if the OOB data or position of the OOB data differs.No differences at all. For both, I get in the oob:
OOB:
Quoted 8 lines
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Quoted 1 line
Is this really from the OOB for the first _kernel_ page. It looks wrong.
Yes. this is when I write the kernel from linux.
Quoted 14 lines
I see:
Quoted 1 line
nand dump
0x100000<snip>
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 9a ea 40 97 85 bc 5f f5 2e 15 91 c2 c6 93 14 c0 03 e3 b6 4c 35 40 2d 8f 7e 74 10 13 59 47 cf 09 24 10 6a 0a 8b e2 f1 b0
Quoted 5 lines
The part after all the ff's is the ECC. IIRC a zero ECC implies all the data in the page is zero also. That would be an odd start to a Kernel image.
Can you confirm what it is you dumped?
Yes. This
However, when I write the kernel with u-boot, I get:
OOB:
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff a7 af c5 ed 87 86 2f 1c f9 31 10 92 4a 34 5a 7d 91 cf e0 fd b6 3f 4b ae ca 63 86 9c 2d 91 d2 6c 95 73 1b 4b e0 09 ed a3
It looks like Linux has not written the ECCs at all....
Stefano
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
Stefano,
Quoted 2 lines · Stefano Babic
It looks like Linux has not written the ECCs at all....
So I'll leave you to look into that problem.
You could still be correct about Kernel compatibilities, though I hope not. I'm encouraged that the zeros where in the "correct" place, but the ECC nibbles could be still be packed differently.
Good luck,
Nick.
Hi Stefano,
Quoted 8 lines · Stefano Babic
Hi all,
I have seen an incompatibility between the NAND driver in u-boot for the davinci boards and the linux driver (kernel 2.6.38, mainline).
I think it is not related to the specific board I use. In any case, I am using the ea20 board (OMAP-L138 based, in u-boot mainline), and I have added NAND support setting for the driver:
I've noticed some problems with u-boot and 2.6.38 writing to NAND also, here on a da850evm.
I'm reasonably sure that I had a working combination at some point. I'm in the process of investigating also.
I hope we can combine our efforts -- please keep me on the CC here.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
Quoted 2 lines · Ben Gardiner
Hi Stefano,
Hi Ben,
Quoted 1 line
I hope we can combine our efforts -- please keep me on the CC here.
Sure. I will inform you about my progresses (if any...).
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
Quoted 1 line · Stefano Babic
Sure. I will inform you about my progresses (if any...).
Solved. It was a misunderstanding about how to set up the NAND driver in linux. I think the usage of the "id" field in the platform device can confuse, as it did for me. I thought the id was used only as index for multiple devices, but the driver takes it as chipselect, even if the value of the chip select itself could be derived from the resource structure.
And then, the value of the chip select is used by the driver to enable the ECC, and as I passed the wrong chip select, the hw ecc was disabled. Even if I could correctly write/read the NAND under Linux.
I have checked the two drivers and I went to the conclusion that they are fully compatible. They do exactly the same things and in the same sequence, no problem at all.
My problem was caused by the fact I have set up the device platform with "id = 1", and this is translate by the driver as chip select = 3. However, on my board chip select 2 is used ;-(
Ben, I have already tested writing from linux, and u-boot can now read the partition correctly. I think there is no incompatibility problem with the mainline kernel.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de =====================================================================
Hi Stefano,
Quoted 4 lines · Stefano Babic
[...]
Ben, I have already tested writing from linux, and u-boot can now read the partition correctly. I think there is no incompatibility problem with the mainline kernel.
Thanks. I guess that eliminates quite a few possible causes on my end. The current most likely candidate is between the keyboard and the chair.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca