[U-Boot] Trouble with U-Boot on our EVM-based hardware
Schade, David
schade at DResearch.de
Mon Feb 14 11:59:40 CET 2011
Hello again,
Now we are using the angstrom-2008.1.conf file of OpenEmbedded, which includes:
ANGSTROM_GCC_VERSION ?= "4.3.3"
The U-Boot compiled by this GCC without any source changes (with volatile) works perfect, we got
DRAM: 256 MB
....
## Booting kernel from Legacy Image at 80000000 ...
Image Name: Linux-2.6.32
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3201292 Bytes = 3.1 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Using machid 0x5ff from environment
Starting kernel ...
Then the kernel is silent, so we can search for problems of our kernel. The first hintof
http://processors.wiki.ti.com/index.php/Kernel_-_Common_Problems_Booting_Linux
which sets the correct debug uart (in our case CONFIG_OMAP_LL_DEBUG_UART3=y) didn't help yet. But we can now have a look to this.
But back to the first problem - has anybody any tipps, what is going on here with the invalid gcc optimisation?
The compiler itself is build by our host system:
cat /proc/version
Linux version 2.6.35-22-generic-pae (buildd at rothera) (gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu4) ) #33-Ubuntu SMP Sun Sep 19 22:14:14 UTC 2010
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.10
DISTRIB_CODENAME=maverick
DISTRIB_DESCRIPTION="Ubuntu 10.10"
cat /etc/debian_version
squeeze/sid
It is a server (ssh) installation without any windowmanager.
Maybe this system build an invalid cross compiler arm-linux-angstrom-gnueabi-gcc in version 4.5.
Can anyone help?
Best regards,
David.
> -----Ursprüngliche Nachricht-----
> Von: Schade, David
> Gesendet: Freitag, 11. Februar 2011 11:35
> An: 'u-boot at lists.denx.de'
> Betreff: Trouble with U-Boot on our EVM-based hardware
>
> 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
More information about the U-Boot
mailing list