Hi there,
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.
