Hi Daniel,
Also, when printing out Ecc error, we print also the tempSpareValue which is always 0xFFFFFFFF while the eccvalue[i] has some value (masked as 0x0FFF0FFF). After flashing the code thro' CCS, the Nand_Init passes and the ECC error occurs on reading the magic number. If flashing the code with DVFlasher, the write fails with the same 0xFFFFFFFF for tempSpareValue. Reg Suba --- "Allred, Daniel" <[EMAIL PROTECTED]> wrote: > Suba, > > I'm a little confused as to what method you are > using to flash the NAND device via CCS. Also just > so I'm clear, the problem statement is as follows: > > You have a 64MB custom board based on the DM644x, > which is having problems when flashing and booting > from the NAND device. The device cannot be flashed > via the DVFlasher program even after modifications > to the init values in the file dm644x.c, but it can > be flashed via a CCS program which uses a particular > GEL file for initialization. But even in the case > where flashing via CCS succeeds, booting into U-boot > still has issues with the NAND device. > > Is that a correct assessment? If so, then that > would indicate either some issue with the UBL > initialization or a hardware issue. I would be > interested in seeing all the boot messages and also > in seeing your dm644x.c file. > > Regards, > Daniel > > Daniel J. Allred > Software Applications > Catalog DSP / Emerging End Equipment > > -----Original Message----- > From: Subashini Balaraman > [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 02, 2007 1:34 AM > To: Ivan Tonchev > Cc: Allred, Daniel; ketan deshpande; Linux DaVinci > Subject: Re: UBL on custom board > > > > Hello Ivan, > > The nand chip is a NAND01GR3B2BZA6E ST Micro part. > > It has a 8-bit bus width and the AEMIF is configured > as 8-bit. The register BOOTCFG reads as 0x1F. > > Also, I use the same nand.c, nandcopy.c from the > emulator and write the UBL code and u-boot code to > the > corresponding blocks 1 and 6. Then the Nand_ReadPage > comes out without errors and prints the correct > magic > number. > > But when running without the emulator, the code > gives NAND ECC failure even the first time when > trying > to the magic number for u-boot from block 6. > > The same code works differently from the emulator > and from ROM bootmode. There is some initialization > that is done thro' the emulator that I am missing in > the UBL. Of course, even with the emulator code, > after > flashing succesfully the u-boot and after calling > Nand_Copy, if I jump to application start address > 0x81080000, the u-boot comes up, but with the ecc > error hot on my trail: > > NAND:nand_read_ecc: Attempt read beyond end of > device > 100000 4000 0 > > I have tried to modify the DDR timings and also > tried to use the same code in the gel file to the > UBL's dm644x.c code. > > Regards > Suba. > > > --- Ivan Tonchev <[EMAIL PROTECTED]> wrote: > > > Hi Suba, > > > > How is your BOOTCFG register configured? > > > > Is it configured for 8 or 16bit AEMIF? > > Is your NAND flash 8 or 16 bit? > > > > DaVinci RBL uses it for booting the UBL from NAND > > and in turn, UBL uses > > it to reinitialize NAND. > > > > See ubl/src/nand.c: > > > > // Setting the nand_width = 0(8 bit NAND) or > > 1(16 bit NAND). AEMIF > > CS2 bus Width > > // is given by the BOOTCFG(bit no.5) > > width = ( ( (SYSTEM->BOOTCFG) & 0x20) >> 5); > > gNandInfo.busWidth = > (width)?BUS_16BIT:BUS_8BIT; > > > > Ivan > > > > Subashini Balaraman wrote: > > > 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 > > > > > > > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam > protection around > http://mail.yahoo.com > __________________________________________________ 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
