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

Reply via email to