Thanks for all the information and suggestions. The nand information is read out right. The ECC values given are different everytime and the do not look like bit errors. We did remove the Protect and UnProtect as this ST does not support it.
When we tried to set PLL1_Mult to a low value of 16 with DDR2 at 162 Mhz, we did not get any ECC errors. We used your u-boot-nand_s3_4_fix.bin u-boot file and did see the u-boot terminal. But there were a lot of errors: nand device not found and i2c errors. The clock speeds were displayed right. We are next trying to use the emulator and flash the same UBL code. Any other suggestions are welcome. Regards Suba. --- "Allred, Daniel" <[EMAIL PROTECTED]> wrote: > The ECC generation on the DM644x happens in 512 byte > chunks. So when using a large block device, the > page read or write happens four times, so you > actually generate four ECCs, each of which is stored > in a 4-byte chunk of a 16-byte chunk of the spare > region. So after a complete page write operation, > each ECC value will be written to the spare bytes > region as part of a 16-byte write (writing the > tempSpareValue array. On a large block device, this > will happen four times. > > > > I should point out that the ECC values are Hamming > Codes and the number of bits in the code is > 2*log_2(number of bits in page operation). For 512 > byte page operations, that's 4096 bits for 2*12 = 24 > bits of ECC bits. If we supported a 2048 block page > operation, then it would still be only 28 bits > needed to do ECCs. > > > > Regarding your issue, like I stated earlier, try > modifying the code to display a lot more output > data. Like during the NAND init, have it output the > device ID, page size info, etc. and make sure that > it matches the device data sheet. Also check to see > if your device supports protect and unprotect > operations. The ST NAND device I most recently > worked with did not support those commands, so you > might want to consider commenting those out if yours > doesn't either. Also output the data read back > after the write is done (during the verify step) and > make sure it matches. When there is an ECC > mismatch, output both the values that are being > compared to see if they are totally off, or just off > by one bit (which would indicate a bad bit in that > page). The program should correct from that problem > by trying the first page of the next block, but > maybe there's a bug in my code that prevents that. > > > > Those are recommendations so maybe we can help > further. > > > > Regards, > > Daniel > > > > Daniel J. Allred > > Software Applications > > Catalog DSP / Emerging End Equipment > > ________________________________ > > From: ketan deshpande [mailto:[EMAIL PROTECTED] > Sent: Friday, April 27, 2007 7:40 AM > To: Ivan Tonchev; Allred, Daniel > Cc: Linux DaVinci; Subashini Ravindran > Subject: Re: UBL on custom board > > > > Hi All, > > We implemented the patch provided by Ivon > Tonchev. But the problem still persists. There is no > change in the way we are getting the output. > > Let me elaborate our problem and hardware a bit > more. > > We are using nand flash chip of > STMicro-NAND01G-B2B. > And for DDR we use the chip Micron-MT47H64M4. It is > 64MB DDR. > Our board is in NAND boot mode. > > The DDR timings are almost similar. The only major > change was > DDR_IBANK = 2 and > DDR_PAGESIZE = 1 in DM644x.c. > With the similar DDR value changes in GEL file some > simple codes run fine in CCS. So verification of > those values is also done. > > Coming back to NAND Chip part. It is a big block > device. > There is something we are finding very difficult to > understand in DVFlasher code. If we refer nand.c > file and function NAND_WritePage we find following > lines; > > tempSpareValue[0] = 0xFFFFFFFF; > tempSpareValue[1] = 0xFFFFFFFF; > tempSpareValue[2] = eccValue[i]; > tempSpareValue[3] = 0xFFFFFFFF; > > So that means even though we have 16 bytes of Spare > bytes at a time we are making use of only 4 bytes > for ECC. Why is that? > > > regards, > -Ketan > > > > > > ----- Original Message ---- > From: Ivan Tonchev <[EMAIL PROTECTED]> > To: "Allred, Daniel" <[EMAIL PROTECTED]> > Cc: ketan deshpande <[EMAIL PROTECTED]>; Linux > DaVinci > <[email protected]>; > Subashini Ravindran <[EMAIL PROTECTED]> > Sent: Thursday, 26 April, 2007 8:48:01 PM > Subject: Re: UBL on custom board > > Try attached patch > > Allred, Daniel wrote: > > Ivan brings up a good point. The host app and > target app (the UBL) make certain assumptions about > the memory map. These are issues that need to be > addressed in a future release, but you need to > remember that application was originally only > intended for EVM usage, particularly for customers > who weren¢t using CCS, or who were only on a Linux > box. Since the source of both the host app and the > target app are available, the necessary changes can > be made. > > > > But having said that it, it might be another issue. > Try modifying the UBL program to report back some > status on ECC values or the data seen in the > verification step (NAND_VerifyPage function). > > > > Regards, > > Daniel > > > > > > Daniel J. Allred > > Software Applications > > Catalog DSP / Emerging End Equipment > > ________________________________ > > From: Ivan Tonchev [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 26, 2007 9:55 AM > To: ketan deshpande > Cc: Allred, Daniel ; Linux DaVinci; Subashini > Ravindran > Subject: Re: UBL on custom board > > > > How much RAM do you have on your board? > > Is it < 256M? > > ketan deshpande wrote: > > Hi, > > We are trying the DVFlasher_1_12 with the custom > designed board with NAND Flash. > The NAND flash chip we are using is a big block > device.When we try to flash the UBL we get the > following messages. > > Attempting to connect to device COM1... > Press any key to end this program at any time. > > Waiting for DVEVM... > BOOTME commmand received. Returning ACK and > header... > ACK command sent. Waiting for BEGIN command... > DVEVM: BEGIN > BEGIN commmand received. Sending CRC table... > CRC table sent. Waiting for DONE... > DONE received. Sending the UART UBL file... > DONE received. UART UBL file was accepted. > UART UBL Transmitted successfully. > > DVEVM: TI UBL Version: 1.11, Flash type: > NAND > DVEVM: Booting PSP Boot Loader > DVEVM: PSPBootMode = NAND > > WARNING! The DM644x is NOT in UART boot mode! > Only continue if you are sure of what you are doing. > > Continue (Y/N) ? y > > Waiting for UBL on DVEVM... > UBL's BOOTPSP commmand received. Returning CMD and > command... > CMD value sent. > SENDUBL received. Returning ACK and header for UBL > data... > ACK command sent. Waiting for BEGIN command... > UART UBL's BEGIN commmand received. Sending the > Flash UBL code... > Flash UBL code sent. Waiting for DONE... > DONE received. All bytes of Flash UBL code > received... > DONE received. Flash UBL S-record decoded > correctly. > DVEVM: Initializing NAND flash... > DVEVM: Correct devID found > DVEVM: Writing UBL to NAND flash > DVEVM: Number of blocks needed for header > and data: 0x00000001 > DVEVM: Attempting to start in block number > 0x00000001. > DVEVM: Unprotecting blocks 0x00000001 > through 0x00000001. > DVEVM: Erasing blocks 0x00000001 through > 0x00000001. > DVEVM: Writing header... > DVEVM: NAND ECC failure! > DVEVM: Starting UART Boot... > DVEVM: BOOTPSP > > Waiting for UBL on DVEVM... > UBL's BOOTPSP commmand received. Returning CMD and > command... > CMD value sent. > SENDUBL received. Returning ACK and header for UBL > data... > ACK command sent. Waiting for BEGIN command... > UART UBL's BEGIN commmand received. Sending the > Flash UBL code... > > > The above mentioned sequence keeps on repeating. > What could be the problem?? > > regards, > -Ketan > > > > ________________________________ > > SHOUT IT OUT! Tell everyone, from anywhere, that > you're online on Yahoo! Messenger > <http://us.rd.yahoo.com/mail/in/ymessenger/*http:/messenger.yahoo.com/addpresence.php> > > > > > > > > > > > ________________________________ > > > > > > > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > > > # By default UBL is hardcoded to run on boards with > 256 > # or above megabytes of RAM > # > # This patch relaxes hardcoded constraints for > boards > # with 64MB (or above) megabytes of ram > # > # Signed-off-by: Ivan Tonchev <[EMAIL PROTECTED] > # > diff -urp dvflasher-256mb/ubl/include/ubl.h > dvflasher-64mb/ubl/include/ubl.h > --- dvflasher-256mb/ubl/include/ubl.h 2007-03-21 > 21:28:17.000000000 +0200 > +++ dvflasher-64mb/ubl/include/ubl.h 2007-04-21 > 16:34:36.000000000 +0300 > @@ -59,11 +59,15 @@ > #define UBL_IMAGE_SIZE (0x00003800) > > > > // Define maximum downloadable image size > > -#define MAX_IMAGE_SIZE (0x02000000) > > +#define MAX_IMAGE_SIZE (0x00800000) > > > > /* Set details of RAM */ > > #define RAM_START_ADDR (0x80000000) > > +#ifndef APMP > > #define RAM_END_ADDR (0x8FFFFFFF) > > +#else > > +#define RAM_END_ADDR (0x83FFFFFF) > > +#endif > > > > typedef struct { > > Uint32 magicNum; /* Expected magic number */ > > diff -urp dvflasher-256mb/ubl/src/ubl_davinci.lds > dvflasher-64mb/ubl/src/ubl_davinci.lds > --- dvflasher-256mb/ubl/src/ubl_davinci.lds > 2007-02-01 22:02:50.000000000 +0200 > +++ dvflasher-64mb/ubl/src/ubl_davinci.lds > 2007-04-21 16:30:56.000000000 +0300 > @@ -69,15 +69,15 @@ SECTIONS { > > > > __topstack = 0xC000 - 0x4; > > > > - /* 128 MB of DDR2 */ > > + /* 64 MB of DDR2 */ > > . = 0x80000000; > > .ddrram : > > { > > *(.ddrram) > > } > > > > - /* 128 MB of DDR2 */ > > - . = 0x88000000; > > + /* 32 MB of DDR2 */ > > + . = 0x82000000; > > .ddrram2 : > > { > > *(.ddrram2) > > > > > > ________________________________ > > SHOUT IT OUT! Tell everyone, from anywhere, that > you're online on Yahoo! Messenger > <http://us.rd.yahoo.com/mail/in/ymessenger/*http:/messenger.yahoo.com/addpresence.php> > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
