Bad Data CRC on loading of DM365 uImage kernel

Tim,

I can think of two possible causes:

1. Either the uImage itself is not correctly created. You can use the default uImage given by TI DVSDK to eliminate this point.

2. It might be TFTP that is causing the problem. We have seen TFTP server running on windows PC at times gives such problems. The problem comes because the data transferred over TFTP is not bit-to-bit correct. Can you try TFTP server running on say linux to eliminate this issue as well?

Regards,

Anshuman

Anshuman:

Yes, I have been doing this on both points.  I built the DM365 kernel as well as use what came with the PSP binary releases and some result on both.   I have been using the tftp that comes with Linux.  Below is the result from the DM365 using tftp:

DM365 EVM :>boot

BOOTP broadcast 1

*** Unhandled DHCP Option in OFFER/ACK: 26

*** Unhandled DHCP Option in OFFER/ACK: 26

DHCP client bound to address 192.168.2.4

TFTP from server 192.168.2.3; our IP address is 192.168.2.4

Filename 'uImage_dm365'.

Load address: 0x80700000

Loading: #################################################################

#################################################################

##########

done

Bytes transferred = 2049992 (1f47c8 hex)

TFTP from server 192.168.2.3; our IP address is 192.168.2.4

Filename 'uImage_dm365'.

Load address: 0x80700000

Loading: #################################################################

#################################################################

##########

done

Bytes transferred = 2049992 (1f47c8 hex)

## Booting kernel from Legacy Image at 80700000 ...

Image Name: Linux-2.6.18_pro500-davinci_evm-

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 2049928 Bytes = 2 MB

Load Address: 80008000

Entry Point: 80008000

Verifying Checksum ... Bad Data CRC

ERROR: can't get kernel image!

and below is the result when I use tftp fo rthe DM6467 board - just swapped out the boards using the same Linux machine and using tftp:

Booting PSP Boot Loader

Starting NAND Copy

Booting Application @ 0x81080000

U-Boot 1.2.0 (Dec 13 2007 - 14:52:18)

I2C: ready

DRAM: 256 MB

unknown vendor=0 Flash: 0 kB

NAND: 128 MiB

In: serial

Out: serial

Err: serial

ARM Clock :- 297MHz

DDR Clock :- 297MHz

Hit any key to stop autoboot: 0

TFTP from server 192.168.2.3; our IP address is 192.168.2.20

Filename 'uImageEVM6467'.

Load address: 0x80700000

Loading: #################################################################

#################################################################

#################################################################

#################################################################

#####################

done

Bytes transferred = 1434100 (15e1f4 hex)

## Booting image at 80700000 ...

Image Name: Linux-2.6.10_mvl401-davinci_evm-

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 1434036 Bytes = 1.4 MB

Load Address: 80008000

Entry Point: 80008000

Verifying Checksum ... OK

OK

Starting kernel ...

Uncompressing Linux................................................................................................. done, booting the kernel.

Linux version 2.6.10_mvl401-davinci_evm-PSP_01_30_00_082 (root@localhost.localdomain) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.104.0600975 2006-07-06)) #1 9CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ)

CPU0: D VIVT write-back cache

Is there any issues with using the DM365 Rev E board?  Do you have a Rev E board?  I could send you the uImage file that I am using for the DM365 board that I have.  Do you have a board that you can try this out with to see if you can get it to work on your board?  It is 2 Mbytes in size which is small enough to email.

Thanks,

Tim

Tim,

This is some interesting information. I did not realize that you mentioned Rev E board. I dont have a Rev E board, but i can try to find out one. I dont expect any problem with a different revision, but still a good thing to check. Meanwhile, have you tried with any other EVM revision say Rev C? I have tested and have TFTP working on multiple custom boards as well as Rev C EVM.

I can try my own uImage to test it on Rev E EVM if i can get one. If that works, then i will ask for your uImage. BTW, you have already tried the uImage that comes with TI released PSP package. Isnt it?

Have you made any changes to uBoot at all? Can you share your bootArgs also?

Another suggestion would be to just connect your PC back-to-back to your EVM and run TFTP server on you PC.

Regards,

Anshuman

Tim,

Another post on similar lines is listed here http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/99/t/7865.aspx

I think it is solved by just reinstalling the stuff on other machine. Hope this helps.

Regards,

Anshuman

Hey Anshuman:

Yes, I just tried with a working board (rev A) that I received today that was a known working board and it still does not work on my machine.  I have tried using the uImage that I created with a make, a uImage that comes directly out of the binary images from the PSP directory, and one that is a working one that was sent via email that goes with a known working board and neither of them work.

See my bootargs that I am using below:

bootdelay=4
baudrate=115200
ethaddr=00:0e:99:02:cd:a2
setboot=setenv bootargs $(bootargs) video=dm36x:output=$(videostd)
nfsdir=/home/user/workdir_davinci/filesys
bootargs_nfs_dhcp=setenv bootargs console=ttyS0,115200n8 noinitrd ip=dhcp root=/dev/nfs rw nfsroot=$(serverip):$(nfsdir),nolock mem=116M video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=ntsc dm365_imp.oper_mode=0 davinci_capture.device_type=4
bootcmd_nfs_dhcp_tftp=run bootargs_nfs_dhcp;dhcp;tftp;bootm $(ramaddr)
bootcmd=run bootcmd_nfs_dhcp_tftp
ramaddr=0x80700000
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 1.3.4 (May 22 2009 - 11:25:39)
bootfile=uImageDM365
filesize=1F762C
fileaddr=80700000
gatewayip=192.168.2.1
netmask=255.255.255.0
ipaddr=192.168.2.5
serverip=192.168.2.3
dnsip=192.168.2.1

As for u-boot and UBL, I am using what comes out of the binary directory of the PSP.  I now have tried 2 DM365 EVM boards (1 a rev E brand new out of the box and another a known working rev A board) and neither of them work - fail with a bad CRC check. 

I have tried 3 different tftp sites (2 from separate Linux VMWare images and 1 form a PC with a tftp server running).  None of the DM365 EVMs work using a built uImage, uImage from the PSP directory, and known uImage that goes with the rev A board that I received.  However I have tried a DM6467 EVM board on all 3 of these tftp sites and all 3 worked with no issues.  So the tftp site works with no problems with my DM6467 EVM, but can't get it to work at all with 2 DM365 EVMs - 1 brand new out of the box and another a known working EVM from one our TI internal folks back at the factory.  Do you have any idea what is going on?  This is extremely frustrating!

Thanks,
Tim

Hi Tim,

I have a Rev E board as well, and I just verified that it is able to boot-up linux well using the UBL included here: http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r35/board-utils/board-utils-davinci.tar.gz and U-Boot here: http://arago-project.org/files/releases/davinci-psp_3.x.0.0-r35/images/dm365-evm/u-boot-dm365-evm.bin

If using these binaries doesn't help as well, we need to debug into what is the cause of the issue - DDR or tftp.

To eliminate DDR as the cause, can you boot into U-Boot, connect to the EVM using CCS and use the raw binary download that CCS provides for ARM to download the uImage at 0x8070'0000. After the download completes, use bootm command to boot from 0x8070'0000. I have tried this before with CCSv3.3

Thanks,

Sekhar

Hello Sekhar:

I have tried loading UBL and U-Boot using what is provided with the PSP into the board and have done this twice to make sure I have done this correctly with no issues using CCS3.3.  The known working board (rev A) already had this installed and I just tried to tftp uImage to it, but it failed with a data CRC check. 

Are you saying to try this again using CCS3.3 with the files that you provided? 

I'm unclear what you mean in your last sentence above.  By booting into U-Boot, I assume you mean just bring up the console window and hit enter before the time-out so I can enter u-boot commands and then once I have a prompt to go in using CCS and download a raw binary (by this do you mean the uImage file using CCS and place this at memory location 0x80700000) and then go back to the console window and enter "bootm 0x80700000"?  Please advise.

Thanks,
Tim

Hi Tim,

Tim Simerly said:

I have tried loading UBL and U-Boot using what is provided with the PSP into the board and have done this twice to make sure I have done this correctly with no issues using CCS3.3.  The known working board (rev A) already had this installed and I just tried to tftp uImage to it, but it failed with a data CRC check. 

Are you saying to try this again using CCS3.3 with the files that you provided? 

 If you already flashed the exact same binaries I provided earlier by some means (CCS, serial flash etc), then no need to try again.

Tim Simerly said:

I'm unclear what you mean in your last sentence above.  By booting into U-Boot, I assume you mean just bring up the console window and hit enter before the time-out so I can enter u-boot commands and then once I have a prompt to go in using CCS and download a raw binary (by this do you mean the uImage file using CCS and place this at memory location 0x80700000) and then go back to the console window and enter "bootm 0x80700000"?  Please advise.

Yes, this is to determine who is the culprit - the external RAM on the board or tftp download.

Thanks,

Sekhar

Hey Sekhar:

I tried this and after downloading the uImage file into DDR (0x80700000) using CCS3.3 and then going into u-boot and typing

bootm 0x80700000

it boots fine with no bad CRC check.  I then followed this with a tftp download of the uImage file using u-boot and then went into memory using CCS and wrote the memory contents to a file and noticed that there was a block of 192 0's in the image starting at an offset of 0x4F4 from the beginning of memory.  For some reason, the data that gets downloaded into memory gets corrupted by a block of 192 0's and repeats every 0x5BC. I can also see this same problem by doing a tftp download and then using CCS to look into memory and see these blocks of 0's spread throughout memory by using the memory window of CCS.

I use this same tftp server with my DM6467 EVM and no problem.  Only when I use my DM365 EVM does this happen.  Does this mean that there is something wrong with the u-boot file that is associated with the tftp download?  I have tried 2 different VMWare images with tftp servers enable as well as using this same PC and setting it up to run a tftp server using Windows XP and no problems with my DM6467 EVM, but fails under all 3 cases with my DM365 EVM.  And it does this for both DM365 EVMs - 1 brand new out-of-the-box and another a known working board from one of our guys back in the factory - so the boards most likely are ok.  I also tried using another PC and set it up to run a tftp server and the same issue - works with my DM6467 EVM but not with either of my DM365 EVMs. 

Do you have any idea as to what to try next to isolate this?   Memory is getting corrupted from the tftp download which is why it is failing with a bad data CRC.  Do you have any other u-boot (.bin) files that you can send me to try another u-boot image that works since the one I am using now is failing on the tftp download?  Is there anything particular that could go wrong with burning the u-boot image in using CCS3.3?

Thanks,
Tim

Hey Sekhar:

Also I went ahead and wrote the uImage file into my nand FLASH on the DM365 EVM board, and it boots up ok with a good CRC check but it fails with using NFS with the message below:

Loading from NAND 1GiB 3,3V 8-bit, offset 0x400000

Image Name: Linux-2.6.18_pro500-davinci_evm-

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 2049928 Bytes = 2 MB

Load Address: 80008000

Entry Point: 80008000

## Booting kernel from Legacy Image at 80700000 ...

Image Name: Linux-2.6.18_pro500-davinci_evm-

Image Type: ARM Linux Kernel Image (uncompressed)

Data Size: 2049928 Bytes = 2 MB

Load Address: 80008000

Entry Point: 80008000

Verifying Checksum ... OK

Loading Kernel Image ... OK

OK

Starting kernel ...

Uncompressing Linux......................................................................................................................................... done, booting the kernel.

Linux version 2.6.18_pro500-davinci_evm-arm_v5t_le (a0850430@gtlnxlsf01.gt.design.ti.com) (gcc version 4.2.0 20070126 (prerelease) (MontaVista 4.2.0-3.0.0.0702771 2007-03-10)) #1 PREEMPT Fri May 22 12:07:46 EDT 2009

CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177

Machine: DaVinci DM365 EVM

Memory policy: ECC disabled, Data cache writeback

DaVinci DM0365 variant 0x0

PLL0: fixedrate: 24000000, commonrate: 121500000, vpssrate: 243000000

PLL0: vencrate_sd: 27000000, ddrrate: 243000000 mmcsdrate: 121500000

PLL1: armrate: 297000000, voicerate: 20482758, vencrate_hd: 74250000

CPU0: D VIVT write-back cache

CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets

CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets

Built 1 zonelists. Total pages: 29696

Kernel command line: console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=192.168.2.4:/home/user/workdir646x/filesys mem=116M video=davincifb:vid0=OFF:vid1=OFF:osd0=720x576x16,4050K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=ntsc dm365_imp.oper_mode4PID hash table entries: 512 (order: 9, 2048 bytes)

Clock event device timer0_0 configured with caps set: 07

Console: colour dummy device 80x30

Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)

Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)

Memory: 116MB = 116MB total

Memory: 113152KB available (3529K code, 712K data, 204K init)

Security Framework v1.0.0 initialized

Capability LSM initialized

Mount-cache hash table entries: 512

CPU: Testing write buffer coherency: ok

NET: Registered protocol family 16

MUX: initialized SPI0_SCLK

MUX: initialized SPI0_SDO)

MUX: initialized SPI0_SDI

MUX: initialized SPI0_SDENA0

DaVinci: 104 gpio irqs

MUX: initialized GPIO20

MUX: initialized I2C_SCL

DM365 IPIPE initialized in Continuous mode

Generic PHY: Registered new driver

ch0 default output "COMPOSITE", mode "NTSC"

VPBE Encoder Initialized

LogicPD encoder initialized

Avnetlcd encoder initialized

dm365_afew_hw_init

SCSI subsystem initialized

usbcore: registered new driver usbfs

usbcore: registered new driver hub

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 4096 (order: 2, 16384 bytes)

TCP bind hash table entries: 2048 (order: 1, 8192 bytes)

TCP: Hash tables configured (established 4096 bind 2048)

TCP reno registered

VFS: Disk quotas dquot_6.5.1

Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

squashfs: version 3.1 (2006/08/19) Phillip Lougher

JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.

yaffs May 22 2009 12:04:06 Installing.

SGI XFS with no debug enabled

Initializing Cryptographic API

io scheduler noop registered

io scheduler anticipatory registered (default)

davincifb davincifb.0: dm_osd0_fb: Initial window configuration is invalid.

davincifb davincifb.0: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 4050KB

davincifb davincifb.0: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 1020KB

davincifb davincifb.0: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB

davincifb davincifb.0: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 1020KB

DAVINCI-WDT: DaVinci Watchdog Timer: heartbeat 60 sec

facedetect major#: 253, minor# 0

facedetect driver registered

imp serializer initialized

davinci_previewer initialized

davinci_resizer initialized

Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled

serial8250.0: ttyS0 at MMIO map 0x1c20000 mem 0xfbc20000 (irq = 40) is a 16550A

serial8250.0: ttyS1 at MMIO map 0x1d06000 mem 0xfbd06000 (irq = 41) is a 16550A

RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize

Davinci EMAC MII Bus: probed

MAC address is 00:0e:99:02:c9:48

TI DaVinci EMAC Linux version updated 4.0

netconsole: not configured, aborting

Linux video capture interface: v2.00

vpfe_init

starting ccdc_reset...<7>

End of ccdc_reset...<5>vpfe_probe

vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = MT9T001

vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = MT9P031

TVP514X : nummber of channels = 1

vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = TVP514X

Trying to register davinci display video device.

layer=c09e8600,layer->video_dev=c09e8760

Trying to register davinci display video device.

layer=c09e8400,layer->video_dev=c09e8560

davinci_init:DaVinci V4L2 Display Driver V1.0 loaded

vpfe ccdc capture vpfe ccdc capture.1: vpif_register_decoder: decoder = TVP7002

af major#: 250, minor# 0

AF Driver initialized

aew major#: 249, minor# 0

AEW Driver initialized

i2c /dev entries driver

nand_davinci nand_davinci.0: Using 4-bit hardware ECC

NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit)

2 NAND chips detected

Creating 5 MTD partitions on "nand_davinci.0":

0x00000000-0x003c0000 : "bootloader"

0x003c0000-0x00400000 : "params"

0x00400000-0x00800000 : "kernel"

0x00800000-0x20800000 : "filesystem1"

0x20800000-0x80000000 : "filesystem2"

nand_davinci nand_davinci.0: hardware revision: 2.3

dm_spi.0: davinci SPI Controller driver at 0xc781e000 (irq = 42) use_dma=0

Initializing USB Mass Storage driver...

usbcore: registered new driver usb-storage

USB Mass Storage support registered.

usbcore: registered new driver usbhid

drivers/usb/input/hid-core.c: v2.6:USB HID core driver

musb_hdrc: version 6.0, cppi-dma, host, debug=0

MUX: initialized GPIO33

musb_hdrc musb_hdrc: No DMA interrupt line

musb_hdrc: USB Host mode controller at c7874000 using DMA, IRQ 12

musb_hdrc musb_hdrc: MUSB HDRC host driver

musb_hdrc musb_hdrc: new USB bus registered, assigned bus number 1

usb usb1: configuration #1 chosen from 1 choice

hub 1-0:1.0: USB hub found

hub 1-0:1.0: 1 port detected

mice: PS/2 mouse device common for all mice

davinci-mmc davinci-mmc.0: Supporting 4-bit mode

davinci-mmc davinci-mmc.0: Using DMA mode

Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).

ASoC version 0.13.1

AIC3X Audio Codec 0.2

asoc: aic3x <-> davinci-i2s mapping ok

ALSA device list:

#0: DaVinci DM365 EVM (aic3x)

IPv4 over IPv4 tunneling driver

TCP bic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

Time: timer0_1 clocksource has been installed.

Clock event device timer0_0 configured with caps set: 08

Switched to high resolution mode on CPU 0

Sending DHCP requests .., OK

IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.3

IP-Config: Complete:

device=eth0, addr=192.168.2.3, mask=255.255.255.0, gw=192.168.2.1,

host=192.168.2.3, domain=Belkin, nis-domain=(none),

bootserver=0.0.0.0, rootserver=192.168.2.4, rootpath=

Looking up port of RPC 100003/2 on 192.168.2.4

Looking up port of RPC 100005/1 on 192.168.2.4

nfs: server 192.168.2.4 not responding, timed out

VFS: Unable to mount root fs via NFS, trying floppy.

VFS: Cannot open root device "nfs" or unknown-block(2,0)

Please append a correct "root=" boot option

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)

Any idea as to what may be the problem with using NFS with the DM365 EVM?  I have no issues with using the DM6467 EVM with NFS.

Thanks,
Tim

Hi Tim,

I haven't seen any reports of NFS not working on DM365 before. Can you make sure the NFS is accessible by trying this from another host on the network?

mount -t nfs 192.168.2.4:/home/user/workdir646x/filesys /mnt/

If this works from another host, we need to boot using a ramdisk and check if the DM365 is able to ping 192.168.2.4 successfully.

Thanks,

Sekhar

Hi Tim,

Thanks for debugging this.

The only way forward here is to use wireshark or an equivalent network sniffer on the TFTP host and see what could be wrong with the transfers.

Looking at the data my guess is that your host ethernet card is unable to handle MTU sized packets. Note that I am still suspecting the host only because I haven't seen this problem on my setup nor see widespread complaints regarding this issue.

The 0x5BC in your analysis corresponds to 1468 which is what seems to be presented as block size option to the server:

Tim,

Tim Simerly said:

Also I went ahead and wrote the uImage file into my nand FLASH on the DM365 EVM board, and it boots up ok with a good CRC check but it fails with using NFS with the message below:

How did you write uImage on NAND? Generally, we use TFTP to get uImage on DDR and then use uBoot "nanr write" command to program it on NAND. Is this how you are also doing this? If yes, then you should have faced the same problem when the uImage is written to NAND?

Regards,

Anshuman

Hey Sekhar & Anshuman:

We finally got this resolved.  It had to do with the MTU packet size in the u-boot image being set to 1468.  I was using a value of 1300 on my PC.  To fix this, I did the following:

In the u-boot srouce code directory, I changed the file (net/tftp.c) in the u-boot source directory from:

#define TFTP_MTU_BLOCKSIZE 1468
static unsigned short TftpBlkSize=TFTP_BLOCK_SIZE;
static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE;

to:

#define TFTP_MTU_BLOCKSIZE 1024
static unsigned short TftpBlkSize=TFTP_BLOCK_SIZE;
static unsigned short TftpBlkSizeOption=TFTP_MTU_BLOCKSIZE;

and then rebuilt u-boot using the following:

Hi Everyone..

  I m booting my dm355evm through Sd card utility tool,

i m unable to boot kernel image from nand,

im getting following error

plz do the needful.

              SD Main Menu:
                 -------------
                 1 - Erase Flash
                 2 - Install Image
                 3 - Boot
                 4 - Others
        

                 WARNING!! This will erase the ENTIRE FLASH
                 Do you wish to continue (y/n):
 > y
    Erasing block 0x00000001 through 0x00000FFB.
Nand Erase completed.
DONE



                 SD Main Menu:
                 -------------
                 1 - Erase Flash
                 2 - Install Image
                 3 - Boot
                 4 - Others
        

                 WARNING!! This will write the Bootloader,Kernel,Ramfs in Nand
                 Do you wish to continue (y/n):
 > ysdcard_init
*data0=0xA1ACED00 0000920 sdcard_read sdc_src=0x00001000 dst=0x80001284 len=0x00000200 dst + len=0x80001484 .............
flasher_data=0x000F4E00   
*data0=0x00010000 c=0x000FCE00 dst=0x80001284 len=0x00000200 dst + len=0x80001484 .............
check_pattern_123         
check_pattern
sdcard_install
 * Flashing UBL
*data0=0xEE190F31 c=0x00104E00 dst=0x80001488 len=0x00007800 dst + len=0x80008C88 .............
Writing header data to Block 00000001, Offset 00020000
Writing header data to Block 00000002, Offset 00040000
Writing header data to Block 00000003, Offset 00060000
Writing header data to Block 00000004, Offset 00080000
Writing header data to Block 00000005, Offset 000A0000
Writing header data to Block 00000006, Offset 000C0000
Writing header data to Block 00000007, Offset 000E0000
Writing header data to Block 00000008, Offset 00100000
Writing header data to Block 00000009, Offset 00120000
Writing header data to Block 0000000A, Offset 00140000
Writing header data to Block 0000000B, Offset 00160000
Writing header data to Block 0000000C, Offset 00180000
Writing header data to Block 0000000D, Offset 001A0000
Writing header data to Block 0000000E, Offset 001C0000
Writing header data to Block 0000000F, Offset 001E0000
Writing header data to Block 00000010, Offset 00200000
Writing header data to Block 00000011, Offset 00220000
Writing header data to Block 00000012, Offset 00240000
Writing header data to Block 00000013, Offset 00260000
Writing header data to Block 00000014, Offset 00280000
Writing header data to Block 00000015, Offset 002A0000
Writing header data to Block 00000016, Offset 002C0000
Writing header data to Block 00000017, Offset 002E0000
Writing header data to Block 00000018, Offset 00300000
 * Flashing u-boot
*data0=0xEA000012 c=0x00114E00 dst=0x81080000 len=0x00028000 dst + len=0x810A8000 .............
Assuming GNU UBL UBL_GNU_ENTRY=0x00000100
Writing header data to Block 00000019, Offset 00320000
Writing header data to Block 0000001B, Offset 00360000
Writing header data to Block 0000001D, Offset 003A0000
Writing header data to Block 0000001F, Offset 003E0000
Writing header data to Block 00000021, Offset 00420000
Writing header data to Block 00000023, Offset 00460000
Writing header data to Block 00000025, Offset 004A0000
 * Flashing kernel
*data0=0x56190527 c=0x00154E00 dst=0x80700000 len=0x00300000 dst + len=0x80A00000 .............
nand_write dst_nand=0x00500000 block_idx=0x00000028 len=0x00300000
 * Flashing Root FS         
*data0=0x00000000 c=0x004F4E00 dst=0x82000000 len=0x00400000 dst + len=0x82400000 .............
nand_write dst_nand=0x00800000 block_idx=0x00000040 len=0x00400000
DONE                        



                 SD Main Menu:
                 -------------
                 1 - Erase Flash
                 2 - Install Image
                 3 - Boot
                 4 - Others
sdcard_init
MMCSD_MMCRSP67=0x00000920 nand_boot....
src=0x00320800
nand_read block_idx=0x00000019 page_idx=0x00000001 len=0x00028000
block=0000001A



U-Boot 2009.03 (Jun 21 2010 - 15:13:07)

I2C:   ready
DRAM:  128 MB
NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
No NAND device found!!!
512 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
ARM Clock :- 216MHz
DDR Clock :- 171MHz
Hit any key to stop autoboot:  0

Loading from NAND 512MiB 3,3V 8-bit, offset 0x1000000
** Unknown image type
Wrong Image Format for bootm command
ERROR: can't get kernel image!
DM355 EVM > setenv bootcmd 'nboot 0x80700000 0 0x500000;bootm'
DM355 EVM > boot

Loading from NAND 512MiB 3,3V 8-bit, offset 0x500000
NAND read from offset 500000 failed -74
** Read error
## Booting kernel from LeSD Main Menu:
                 -------------
                 1 - Erase Flash
                 2 - Install Image
                 3 - Boot
                 4 - Others
        

                 WARNING!! This will erase the ENTIRE FLASH
                 Do you wish to continue (y/n):
 > y
    Erasing block 0x00000001 through 0x00000FFB.
Nand Erase completed.
DONE




                 SD Main Menu:
                 -------------
                 1 - Erase Flash
                 2 - Install Image
                 3 - Boot
                 4 - Others
        

                 WARNING!! This will write the Bootloader,Kernel,Ramfs in Nand
                 Do you wish to continue (y/n):
 > ysdcard_init
*data0=0xA1ACED00 0000920 sdcard_read sdc_src=0x00001000 dst=0x80001284 len=0x00000200 dst + len=0x80001484 .............
flasher_data=0x000F4E00   
*data0=0x00010000 c=0x000FCE00 dst=0x80001284 len=0x00000200 dst + len=0x80001484 .............
check_pattern_123         
check_pattern
sdcard_install
 * Flashing UBL
*data0=0xEE190F31 c=0x00104E00 dst=0x80001488 len=0x00007800 dst + len=0x80008C88 .............
Writing header data to Block 00000001, Offset 00020000
Writing header data to Block 00000002, Offset 00040000
Writing header data to Block 00000003, Offset 00060000
Writing header data to Block 00000004, Offset 00080000
Writing header data to Block 00000005, Offset 000A0000
Writing header data to Block 00000006, Offset 000C0000
Writing header data to Block 00000007, Offset 000E0000
Writing header data to Block 00000008, Offset 00100000
Writing header data to Block 00000009, Offset 00120000
Writing header data to Block 0000000A, Offset 00140000
Writing header data to Block 0000000B, Offset 00160000
Writing header data to Block 0000000C, Offset 00180000
Writing header data to Block 0000000D, Offset 001A0000
Writing header data to Block 0000000E, Offset 001C0000
Writing header data to Block 0000000F, Offset 001E0000
Writing header data to Block 00000010, Offset 00200000
Writing header data to Block 00000011, Offset 00220000
Writing header data to Block 00000012, Offset 00240000
Writing header data to Block 00000013, Offset 00260000
Writing header data to Block 00000014, Offset 00280000
Writing header data to Block 00000015, Offset 002A0000
Writing header data to Block 00000016, Offset 002C0000
Writing header data to Block 00000017, Offset 002E0000
Writing header data to Block 00000018, Offset 00300000
 * Flashing u-boot
*data0=0xEA000012 c=0x00114E00 dst=0x81080000 len=0x00028000 dst + len=0x810A8000 .............
Assuming GNU UBL UBL_GNU_ENTRY=0x00000100
Writing header data to Block 00000019, Offset 00320000
Writing header data to Block 0000001B, Offset 00360000
Writing header data to Block 0000001D, Offset 003A0000
Writing header data to Block 0000001F, Offset 003E0000
Writing header data to Block 00000021, Offset 00420000
Writing header data to Block 00000023, Offset 00460000
Writing header data to Block 00000025, Offset 004A0000
 * Flashing kernel
*data0=0x56190527 c=0x00154E00 dst=0x80700000 len=0x00300000 dst + len=0x80A00000 .............
nand_write dst_nand=0x00500000 block_idx=0x00000028 len=0x00300000
 * Flashing Root FS         
*data0=0x00000000 c=0x004F4E00 dst=0x82000000 len=0x00400000 dst + len=0x82400000 .............
nand_write dst_nand=0x00800000 block_idx=0x00000040 len=0x00400000
DONE                        


                 SD Main Menu:
                 -------------
                 1 - Erase Flash
                 2 - Install Image
                 3 - Boot
                 4 - Others
sdcard_init
MMCSD_MMCRSP67=0x00000920 nand_boot....
src=0x00320800
nand_read block_idx=0x00000019 page_idx=0x00000001 len=0x00028000
block=0000001A



U-Boot 2009.03 (Jun 21 2010 - 15:13:07)

I2C:   ready
DRAM:  128 MB
NAND:  NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V 8-bit)
Bad block table found at page 262080, version 0x01
Bad block table found at page 262016, version 0x01
No NAND device found!!!
512 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
ARM Clock :- 216MHz
DDR Clock :- 171MHz
Hit any key to stop autoboot:  0

Loading from NAND 512MiB 3,3V 8-bit, offset 0x1000000
** Unknown image type
Wrong Image Format for bootm command
ERROR: can't get kernel image!
DM355 EVM > setenv bootcmd 'nboot 0x80700000 0 0x500000;bootm'
DM355 EVM > boot

Loading from NAND 512MiB 3,3V 8-bit, offset 0x500000
NAND read from offset 500000 failed -74
** Read error
## Booting kernel from Legacy Image at 80700000 ...
   Image Name:   Linux-2.6.32-rc2-davinci1hht_v3.
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2018872 Bytes =  1.9 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
DM355 EVM >gacy Image at 80700000 ...
   Image Name:   Linux-2.6.32-rc2-davinci1hht_v3.
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2018872 Bytes =  1.9 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
DM355 EVM >

i hv changed sdboot_flash_cfg.h also

#define BLOCK 512
#define KB 1024
#define MB 0x100000

// locatins in RAM

#define UBOOT_ADDR    (void*)0x81080000
#define KERNEL_ADDR    (void*)0x80700000 // uImage
//#define KERNEL_ADDR    (void*)0x80008000 // Image, ready to run
#define ROOTFS_ADDR    (void*)0x82000000


// locations in NAND flash

#define KERNEL_FLASH 0x500000//modified STR (0x500000 to 0x560000(3MB))
#define ROOTFS_FLASH 0x800000//starting of Root file system
// 0x3e0000 - uboot env

#define UBL_CCS_ENTRY 0x20    // CCS UBL ublDM355-nand.bin
#define UBL_CCS_MAGIC 0xE59F0124    // CCS UBL ublDM355-nand.bin first word
#define UBL_GNU_ENTRY 0x100    // gcc UBL from DM35x_FlashAndBootUtils_1_10
#define UBL_GNU_MAGIC 0XEE190F31    // gcc UBL from DM35x_FlashAndBootUtils_1_10 first word

// sizes

#define SDBOOT_SIZE (30*KB) // like UBL
#define UBL_SIZE (30*KB) // max UBL size is 30 KB
//#define UBL_ENTRY UBL_GNU_ENTRY
#define UBL_ENTRY UBL_CCS_ENTRY
#define UBOOT_SIZE (160*KB)
#define KERNEL_SIZE (3*MB)
#define ROOTFS_SIZE (4*MB)

// location on SD card

#define RBL_RECORD_SDC    (8*BLOCK) // gap between MBR and FAT
#define SDBOOT_SDC    BLOCK
#define TEST_SDC    0x008000
#define UBL_SDC     0x010000
#define UBOOT_SDC    0x020000
#define KERNEL_SDC    0x060000
#define ROOTFS_SDC    0x400000

#define MAGIC_NUMBER_VALID          (0xA1ACED00)

Regards,

S.Titus.