u-boot not loading entire image into SDRAM

Forum: Bootloader
Rob 
I have a SKY2440 development board with 256M NAND (K9F2G08). I am using
u-boot 1.1.6 that was pre-installed in NOR and DNW 0.49.

When I attempt to simply download to RAM and run (option 7) to address
0x30000000 it will work fine with images less than 512K. When I download a
larger image 1,566,716 bytes in size, u-boot reports "RECEIVED FILE SIZE:
1566726 (765KB/S, 2S)". When it attempts to run it will sometimes display
the error message "invalid instruction" or "data abort" with a register
dump, or no error message at all, and then resets the CPU. This image
downloads and runs fine on a mini2440 board.

When I examine the memory I find that the memory contents starting at
address 0x30080000 are unchanged which suggests that not all of the image
was downloaded. If I manually modify the contents of memory at this address
the memory appears to work fine. I can also perform a memory test in this
region of memory with no errors, so the hardware seems okay. I tried
another version of u-boot (1.3.2-mini2440) from NAND with the same results.

The board is relatively new and came with WinCE installed. I have scrubbed
the NAND and ran creatbbt.

Perhaps there is an environment variable for u-boot I am missing or
something having erased it from the NAND?

U-Boot 1.1.6 (Mar 18 2010 - 15:47:48)

#####   Boot for Nor Flash Main Menu  #####
[1] Download u-boot or STEPLDR.nb1 or other bootloader to Nand Flash
[2] Download Eboot to Nand Flash
[3] Download Linux Kernel to Nand Flash
[5] Download CRAMFS image to Nand Flash
[6] Download YAFFS image to Nand Flash
[7] Download Program (uCOS-II or Sky2440_Test) to SDRAM and Run it
[8] Boot the system
[9] Format the Nand Flash
[0] Set the boot parameters
[a] Download User Program (eg: uCOS-II or Sky2440_Test)
[b] Download LOGO Picture (.bin) to Nand  Flash 
[l] Set LCD Parameters 
[o] Download u-boot to Nor Flash
[r] Reboot u-boot
[t] Test Linux Image (zImage)
[q] quit from menu

Enter your selection: 7

USB host is connected. Waiting a download.

Now, Downloading [ADDRESS:30000000h,TOTAL:1566726]

RECEIVED FILE SIZE: 1566726 (765KB/S, 2S)

## Starting application at 0x30000000 ...

At this point it hung and required a reset.

Examining the memory shows the contents are correct up to address
0x3007ffff when compared to the file, but from there on is incorrect. This
indicates that only the first 512k was saved to SDRAM.

Sky> md 0x3007ffe0 0x40

3007ffe0: e1a06001 e24b1024 e8910003 e3a02000    .`..$.K...... ..
3007fff0: e3a035ff e2833603 eb00ee94 e1a03000    .5...6.......0..
30080000: ffffffff ffffffff ffffffff ffffffff    ................
30080010: ffffffff ffffffff ffffffff ffffffff    ................
30080020: ffffffff ffffffff ffffffff ffffffff    ................
30080030: ffffffff ffffffff ffffffff ffffffff    ................
30080040: ffffffff ffffffff ffffffff ffffffff    ................

Sky> bdinfo

arch_number = 0x000000A8
env_t       = 0x00000000
boot_params = 0x30000100
DRAM bank   = 0x00000000
-> start    = 0x30000000
-> size     = 0x04000000
ethaddr     = 0A:1B:2C:3D:4E:5F
ip_addr     = 192.168.1.6
baudrate    = 115200 bps

Any ideas would be appreciated?

Regards,
Rob

Rob 
Update:

I have downloaded supervivi-128M to NAND then used it to download the image
and all works well. It's just u-boot that won't download an image greater
than 512K.

Regards,
Rob

davef 
> It's just u-boot that won't download an image greater than 512K.

I have used u-boot to download kernels around 2M and JFFS2 root filesystem
of up to 60M on a 64M mini2440.

What format are you using for the root filesystem?

davef 
http://processors.wiki.ti.com/index.php/Put_YAFFS_Image_to_Flash

Maybe, a "long-shot":

"For devices with 512b block NAND the HW ECC support must be disabled in
the kernel for YAFFS to work properly. For information on disabling HW ECC
support please the the Disabling NAND HW ECC support page".

Rob 
Thanks for the replies.

There is no filesystem, and no linux, just a bootloader. I am trying to
download via the bootloader (u-boot) to SDRAM, so the NAND isn't really an
issue either at this point (except perhaps for any settings that might be
stored there that u-boot requires). And just to be clear, the image I am
trying to download is RT-Thread. U-boot won't load anything bigger than
512K, supervivi works fine.

Rob

davef 
I think I now understand what you are trying to do. I recalled something to
do with u-boot and magic numbers.  Google turned this up.

From:
http://www.denx.de/wiki/DULG/UBootImages

********** 
5.13. U-Boot Image Formats

U-Boot operates on "image" files which can be basically anything, preceeded
by a special header; see the definitions in include/image.h for details;
basically, the header defines the following image properties:

    Target Operating System (Provisions for OpenBSD, NetBSD, FreeBSD,
4.4BSD, Linux, SVR4, Esix, Solaris, Irix, SCO, Dell, NCR, LynxOS, pSOS,
QNX, RTEMS, U-Boot, ARTOS, Unity OS, Integrity; Currently supported: Linux,
NetBSD, VxWorks, QNX, RTEMS, ARTOS, Unity OS, Integrity).

    Target CPU Architecture (Provisions for Alpha, ARM, AVR32, BlackFin,
IA64, M68K, Microblaze, MIPS, MIPS64, NIOS, NIOS2, Power Architecture®, IBM
S390, SuperH, Sparc, Sparc 64 Bit, Intel x86; Currently supported: ARM,
AVR32, BlackFin, M68K, Microblaze, MIPS, MIPS64, NIOS, NIOS2, Power
Architecture®, SuperH, Sparc, Sparc 64 Bit, Intel x86).

    Compression Type (Provisions for uncompressed, gzip, bzip2, lzo;
Currently supported: uncompressed, gzip, bzip2, lzo).

    Load Address

    Entry Point

    Image Name

    Image Timestamp

The header is marked by a special Magic Number, and both the header and the
data portions of the image are secured against corruption by CRC32
checksums.
******* 

Good luck.  Please report back as I had looked at RT-thread a year ago, but
did not proceed.

davef

Rob 
Thanks for that Dave, however it raises more questions than it answers.

DNW only adds 10 bytes to the file size (address (4 bytes), size (4 bytes),
data, checksum (2 bytes). The image that does load correctly via u-boot
does not contain this 64 byte header discussed at the link you posted
above, nor does it start with the magic number. So why does it load
correctly? What is supposed to add this header to the image?

As for RT-Thread, it looks promising although it could be a little more
mature for an open source project that has been in existance for 6+ years.
It's biggest problem is the lack of english documentaion. I like it for
it's simplicity and small footprint but does everything I need it to do.

Regards,
Rob

Rob 
After further reading I see there is a file called mkimage which adds the
u-boot image header. This is file is nowhere to be found in my toolchain,
nor can I find it on the mini2440 or Sky2440 CDs. So why does it work okay
for some images without this header? Why does u-boot come pre-installed on
mini/sky2440 without the mkimage file on the CD?

It would seem u-boot is more trouble than it is worth.I think I'll stick
with supervivi.

Rob

davef 
Both good questions.  For the last one, maybe because they are not
providing a complete build environment??

Rob 
Hi Dave,

Regardless of build environment, there are many images provided on the CD,
non of which seem to have the u-boot header as described at the denx site.
The bootloader u-boot comes pre-installed on the mini/sky2440 boards. As
far as I know nobody seems to have any problem loading these images using
this bootloader. There seems to be some piece of this puzzle missing. Do
they provide a modified version of u-boot that does not require the header?
Or does u-boot have a default behaviour in the absence of such a header?

In any case, most people seem to be able to use u-boot to load the 2M linux
images, 30M WinCE images and even the 50M Qtopia images without the header.
So the question - why I can't load an image larger than 512K with u-boot
remains.

Regards,
Rob

davef 
Have you tried the u-boot mailing list?