We tried to write the UBL and u-boot with the emulator. With this there were no errors during a write or a read.
But again, we see the message Initializing NAND flash... After that even the first UBL magic number validation (in Block1, page0) fails though we could read it with the JTAG. We also tried to jump to application start from the emulator. U-Boot started well, but we still get this error: NAND:nand_read_ecc: Attempt read beyond end of device 100000 4000 0 And the nand was not accessible from u-boot. We use the same code as the ubl for flashing, and verifying the nand with the emulator. Even the code in the gel file and the dm644x.c are the same. Thanks in advance... Regards Suba. > > > 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
