Also, when I reduced my PLL1_Mult to 16 (for some
219MHz ARM operation) while keeping the PLL2_Mult at
22 (for 162MHz DDR2), I did get DVFlasher to read the
magic number for u-boot and could get u-boot prompt,
but with the same ECC error:
nand_read_ecc: Attempt read beyond end of device
100000 4000 0
After this error, the nand device is not accessible
from u-boot.
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
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
