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 <davinci-linux-open-source@linux.davincidsp.com>; 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 Davinci-linux-open-source@linux.davincidsp.com 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>
_______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
