Hi, We are executing following steps:
1. Boot system using SD card 2. On UBOOT_SD prompt, we are writing 512 Bytes of data (any value) to NAND (after erasing) using NAND driver hacked from "NAND Programmer" 3. After writing, we read back data 4. We can see that data and ECC are matching with the written data and ECC 5. EMIF gives same error i.e. ECC_STATE bit of NANDFSR register is set It is seen that same NAND Driver code from "NAND Programmer" project is working successfully using JTAG emulator. As I am writing 512 Bytes I guess this should not have any difference if NAND is of 2KB or 4KB. Any thoughts why EMIF see error (more than four) even though data and ECC read are correct? Regards, Jitendra Jain -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, February 02, 2009 12:00 PM To: [email protected]; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query Hi Steven, Thanks for your response. Your understanding is somewhat deviating. Let me rephrase it again. a) Yes I boot from SD using hacked u-boot. Description of hacked u-boot: 1) I added support of SD driver in u-boot to make board boot from SD 2) I created file called "cmd_burn_ubl.c" in //u-boot/common This file is the exact copy of NAND programmer with only modification is instead of reading UBL_NAND and UBOOT_NAND binaries from file I/O operations; it reads UBL_NAND and UBOOT_NAND from SD Pls note for burning UBL_NAND and UBOOT_NAND using hacked u-boot, NAND write and read functions are called from common/cmd_burn_ubl.c b) Write NAND using hacked u-boot and I am making note of data as well as syndrome written c) Read data and syndrome from NAND using hacked u-boot. d) Data and syndrome matches (from b and c) but NANDECCFindAndCorrectError function indicates errors So my query is when I use NAND programmer with JTAG, it can successfully burn UBL and U-Boot but when I use same NAND Programmer in u-boot it gives me errors as mentioned above. Also I did check the things as suggested by you. a) Check the declaration of status. In an earlier version it was declared an Uint8, but it was used as Uint16. Jitendra] --> in my case it was declared as Uint8 and I tried with Uint16, but this did not help. b) Towards the bottom of the routine, there is a if/else block of code which is setting addOffset from the NANDERRADDn registers and corrValue from the NANDERRVALn registers. Make sure that the right bits are being checked in the NANDERRVALn registers. The relative bit positions should be the same between the two sets of registers. Jitendra] --> corrState is set to 1 and hence it returns with failure much before I reach the bottom of the routine. corrState = (volatile Uint32)(CSL_EMIF_0_REGS->NANDFSR & 0xF00)>>8; if(corrState == 1) { return E_FAIL; } Regards, Jitendra -----Original Message----- From: Gorwood, Steve [mailto:[email protected]] Sent: Friday, January 30, 2009 7:12 PM To: Jain, Jitendra [PROTOOL/RTC/IN]; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query That error indicates that it found more than 4 errors and therefore could not do the correction. So my understanding is: a) Write NAND using NAND Programmer, making note of data and ECC syndrome for future comparison b) Read back NAND using NAND Programmer routines, verify that no errors in NANDECCFindAndCorrectError. c) Boot from SD card using hacked u-boot with modified NAND routines d) Read NAND using hacked u-boot and both data and syndromes are the same as noted in step a above; but NANDECCFindAndCorrectError function indicates errors. Is this correct? If so, and the data read and the ecc syndromes are the same; then somewhere the hacked routines are having a problem. Here are a couple of things to check that were problems in earlier versions of the code that might not have been corrected in the version of the NANDECCFindAndCorrectError routine that you started with: a) Check the declaration of status. In an earlier version it was declared an Uint8, but it was used as Uint16. b) Towards the bottom of the routine, there is a if/else block of code which is setting addOffset from the NANDERRADDn registers and corrValue from the NANDERRVALn registers. Make sure that the right bits are being checked in the NANDERRVALn registers. The relative bit positions should be the same between the two sets of registers. Regards, Steven Gorwood -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Friday, January 30, 2009 5:27 AM To: Gorwood, Steve; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query Hi, I did verified data by writing and reading back using u-boot with NAND programmer support by booting from SD card. Data as well as syndrome matches after reading. But still I am getting error in NANDECCFindAndCorrectError function. In NANDFSR register bits (8:11), ECC_STATE is set to 1 which says "Errors cannot be corrected" Any clue what could be the cause for this error and how to solve it Regards, Jitendra -----Original Message----- From: Gorwood, Steve [mailto:[email protected]] Sent: Tuesday, January 27, 2009 9:48 PM To: Jain, Jitendra [PROTOOL/RTC/IN]; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query It is possible that there is a timing issue. I recently found a timing issue in the ubl. I had to modify the NANDWaitRdy() routine by adding a pause as shown below: /* Wait for the status to be ready Polling for the pad_wait_i(bit 0) of NANDFSR */ Uint8 NANDWaitRdy() { volatile Uint32 cnt; Uint32 status; Uint32 i; cnt = NAND_TIMEOUT; do { status = (CSL_EMIF_0_REGS->NANDFSR & 1); cnt--; } while((cnt>0) && !status); if(cnt == 0) return E_FAIL; /*Insert pause */ for (i=0; i<0x500; i++) cnt++; return E_PASS; } Until I made this change, the first byte in each 512 byte sector was occasionally misread. This was corrected by the ECC and would have normally been invisable to the user. I don't think that this is your problem; since your boot works when programmed by the NAND_Programmer. My suspicion is that you will find the ECC is being written to a different address between the two programmers. Regards, Steven Gorwood -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, January 27, 2009 2:15 AM To: Gorwood, Steve; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query Hi Steven, Yes, your understanding is quite correct. By means of nand layout, I guess you are referring figure: 11-4 and 11-5 of sprufb3.pdf. I have gone through PDF and NAND programmer code. Code is writing data and syndromes as explained. As per code, irrespective of NAND is of 512, 2048 or 4196 page size, data is stored: 1. 512 bytes of data 2. 6 bytes - 0xFF 3. 10 bytes - syndrome This matches with what sprufb3.pdf says. I guess RBL should be able to read properly. As you suggested, I'll dump data being written and read using NAND programmer and using u-boot. (PS: as NAND is auto incrementing address, I am not able to print the address but able to read the data and data being written in sequence.) Btw, do you suspect there could be timing issue? As I have ported NAND programmer code, I really don't doubt the functionality. Code is developed and working successfully with TI's CCS compiler but as I am now integrating with the U-Boot I am using GCC complier. I have found lot of for loops being used to provide some delay between operations. Also, there is a function "waitloop" in NAND programmer code which is also used in code for same purpose. Regards, Jitendra -----Original Message----- From: Gorwood, Steve [mailto:[email protected]] Sent: Monday, January 26, 2009 9:30 PM To: Jain, Jitendra [PROTOOL/RTC/IN]; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query OK. To summarize my understanding: a) If you program NAND with NAND programmer hacked to identify 4K device, but only write to 1st 2K of each page, then boot proceeds without problems. b) If you program NAND with u-boot hacked to use NAND programmer driver code, then boot fails ECC read. Is this correct? I suspect that the u-boot is writing the ECC data into a different address than the RBL is reading it from. The NAND layout is documented in the ARM reference guide. I would program the NAND using the NAND programmer, then read back the data using the read routine used by the NAND programmer (paying attention to the address and contents used in the spare byte area). I would then program the NAND using u-boot, then read it back using the NAND programmer read routine and compare the address and contents of the spare byte area. I suspect that you will find that the contents are different. Regards, Steven Gorwood -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Saturday, January 24, 2009 5:04 AM To: Gorwood, Steve; [email protected] Cc: [email protected] Subject: RE: dm355:ecc query Hi, Let me rephrase the query: Background: 1. We are using a custom board using DM355 and NAND - MT29F16G08DAA having 4096 page size 2. SD card is carrying binaries for: a. UBL_SD - RBL will fetch from SD Card and load UBOOT_SD in SD BOOT Mode b. UBOOT _SD - UBL_SD will load in SD BOOT Mode, will support burning UBL_NAND and UBOOT_NAND in NAND c. UBL_NAND - in NAND Mode, will load from NAND by RBL d. UBOOT_NAND - in NAND Mode, will load from NAND by UBL_NAND 3. We are burning UBL_NAND, UBOOT_NAND in NAND from UBOOT_SD's command prompt Case-1 (Using JTAG programmer and NAND_programmer.pjt): NAND_Programmer.pjt is hacked to support NAND with 4K page size. Due to modification, NAND_programmer.pjt detects NAND with page size of 4K but treats it same way as if NAND is having Page size equal to 2K. Result: we are able to burn UBL_NAND and UBOOT_NAND. In NAND boot mode, UBL_NAND and UBOOT_NAND works as expected. Case-2 (Using SD boot and UBL_SD/UBOOT_SD): UBOOT_SD is having support of writing UBL_NAND and UBOOT_NAND from SD to NAND. We have ported NAND driver part of NAND_programmer.pjt to burn UBL_NAND and UBOOT_NAND. Result: we are unable to burn UBL_NAND and UBOOT_NAND. Using ported NAND driver of NAND_programmer.pjt, we are failing at very first step of checking bad block. ECC_STATE of NAND FSR register is found 1 for entire NAND which means errors cannot be corrected. However, blocks are not bad. Hope above clarifies the issue. Any help/suggestion is appreciated. Regards, Jitendra ________________________________________ From: Gorwood, Steve [mailto:[email protected]] Sent: Friday, January 23, 2009 9:04 PM To: Jon Povey; Jain, Jitendra [PROTOOL/RTC/IN] Cc: [email protected] Subject: RE: dm355:ecc query The existing DM355 does not support NAND devices with 4K page sizes. As an unrecognized device, the identification should default to assuming a 2K page size with 64 pages/block. I would assume that the UBL was not read correctly due to the page layout. I am surprised, though, that this did not result in a fall back to an SD boot Regards, Steven Gorwood ________________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Jon Povey Sent: Friday, January 23, 2009 4:19 AM To: [email protected] Cc: [email protected] Subject: RE: dm355:ecc query This may be an issue with the RBL not detecting your NAND chip, if I remember correctly DM355 does not support 4KB page devices at the moment, although it is not very clear and may support some devices, or I have a vague memory that for some 4KB devices it reads them as if they were 2KB page devices, so you can put "hand-crafted" data in the early blocks enough to get UBL loading. I also seem to remember some talk of a new revision of DM355 that could support more recent NAND devices. Maybe someone from TI could comment. I have not been looking into this recently and my memory is flaky. -- Jon Povey, Design Engineer [email protected] | +44(0)1280 825983 ________________________________________ From: [email protected] [mailto:[email protected]] Sent: 23 January 2009 09:12 To: Jon Povey; [email protected]; [email protected] Subject: RE: dm355:ecc query Hi Jon, Actually we are facing a strange problem. I am using MT29F16G08DAA nand chip with page size: 4096 I have written UBL descriptor in block 1, page 0 and UBL in block 2, page 0. When I change boot mode to NAND, I do not see any message on console and as board is not falling back to SD mode, I suspect RBL found valid magic number. But I don't understand why it can't load UBL. On my head I suspect two possibilities a) ECC errors while copying UBL from NAND b) RBL is unable to find UBL (maybe information given in UBL descriptor is taken incorrectly by RBL) I do not have JTAG with me. Regards, Jitendra Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
