[U-Boot] Trouble with U-Boot on our EVM-based hardware

Fri Feb 11 11:35:12 CET 2011

Hi there,

First of all I am new with xldr/uboot, but not new with OMAP3(EVM). Maybe this isn't the correct address, so please be kind with me, if not.

Our hardware is based on the OMAP3EVM board, but with some changes.

I got trouble with U-Boot, which "forget" configuration in the gd->bd->bi_dram[0].start and .size.

Starting OS Bootloader from MMC by jumping to 0x80008000...
U-Boot 2010.06 (Feb 11 2011 - 10:09:18)

OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz
OMAP3 EVM board + LPDDR/NAND
I2C:   ready
DRAM:  0 Bytes
NAND:  256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
Die ID #415e000400000000040365fb16003015
Hit any key to stop autoboot:  0
OMAP3_EVM

In cpu/arm_cortexa8/omap3/sdrc.c in function dram_init() this struct is set:

    gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
    gd->bd->bi_dram[0].size = size0;
    gd->bd->bi_dram[1].start = PHYS_SDRAM_1 + get_sdr_cs_offset(CS1);
    gd->bd->bi_dram[1].size = size1;

Sadly if I printf the gd->bd->bi_dram[0].start after this lines I got zero. So later with "DRAM: " (see bold log) he also can't get the values.

Later If I want to start the kernel, the kernel is checked (and this common functions of lib/arm/bootm.c will store additional informations in this gd-struct, which also get lost.

reading uImage

3143676 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 80000000 ...
   Image Name:   Angstrom/2.6.32/omap3evm
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    3143612 Bytes = 3 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

I don't get a starting kernel.

If I change the struct definition in include/asm_arm/u-boot.h to volatile (for size/start/bi_dram), it works. My printf directly after the set in dram_init is ok, and he also know now, that we are using 256 MB Ram.

At first I used the branch git://arago-project.org/git/projects/u-boot-omap3.git;protocol=git  with revision 7683ca6af43c17cf8214e9a241cd63c0001a59b1 (labeled as OMAPPSP_03.00.01.06 from 19.10.2010)

Now I use the current head revision from Arago-project (0231dc91cd52760fa5cf4209e37c7adb06305da7) from 19 Jan 2011. Same result. Also I tried the beagle variante as defined with SRC_URI_beagleboard in u-boot_git.bb in the current openembedded release (from git://www.denx.de/git/u-boot.git;protocol=git  with revision ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55 and a lot of patch files). Nothing changes.

If I change more variables in other structs to volatile (global_data.h / setup.h), I got even the kernel to "start". U-boot call the address, where he puts the kernel, but the kernel ends in a tiny loop, I can see it via jtag (want to have a 0x20 in R2). I don't get additional logger outputs like decompressing kernel or something which can help me. Maybe my kernel needs also some changes for our platform, but I can't change something more to volatile, which is only a quick ugly workaround to understand a little bit more.

My ram settings are all correct - yes really, the hardware is ok (WinCE runs perfectly, and I use the same SDRC-registers). I can use the whole 0x8000 0000 range. I can read the xldr/uboot/kernel from sdcard to memory, can transport it from memory to flash and omap can start from flash - so the ram generally is ok. But the *important* struct gd here does something really weird.

The struct is created in lib_arm/board.c:

    /* Pointer is writable since we allocated a register for it */
    gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t));
    /* compiler optimization barrier needed for GCC >= 3.4 */
    __asm__ __volatile__("": : :"memory");

    memset ((void*)gd, 0, sizeof (gd_t));
    gd->bd = (bd_t*)((char*)gd - sizeof(bd_t));
    memset (gd->bd, 0, sizeof (bd_t));

The position of gd is originally 0x80E3FFE0, but I also try different locations, i.e. 0x8F000000.

With JTAG I can see that he clear this position to zero (memset!), but no effect with the gd->bd->bi_dram[0].start. I set a jtag breakpoint to read/write this address, and got no call for write. Only a break on reading this zero.

Maybe our compiler does something really weird:

arm-angstrom-linux-gnueabi-gcc (GCC) 4.5.3 20110110 (prerelease)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I also tried to change the compiler flags (from optimisation -Os to -O0 or -O1), but no change.

I also found a chatlog http://www.beagleboard.org/irclogs/index.php?date=2010-11-22 where the user "dent_" (scroll to end) has the same problem. He try an older gcc (which I am try at next), but what is the reason here?

What is going on here? Can somebody help me understanding this?

Best regards,

  David.

_______________________________________________
David Schade, Software-Engineer, M. Eng.
DResearch Digital Media Systems GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515932 - 231
Fax: +49 (30) 515932 - 77
mailto: schade at dresearch.de
http://www.dresearch.de
Amtsgericht: Berlin Charlottenburg, HRB:54412
Ust.-IDNr. DE169013825; WEEE Reg.-Nr. DE 85995642
Geschäftsführer: Dr. M. Weber, W. Mögle