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
