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

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

[Schade, David]

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

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

[Schade, David]

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

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

[Albert ARIBAUD]

Hi David,

Le 14/02/2011 11:59, Schade, David a ?crit :

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

>> 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.

This mailing list only deals with the mainline U-boot code base 
available at denx.de, and you're not using this, apparently. Maybe for 
support about the variants you use you can find specific forums or 
support channels?

Amicalement,
-- 
Albert.

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

[Schade, David]

Hi Albert,

Thank you for your reply.

I also tried the U-Boot version for beagleboard, which comdes from 
git://www.denx.de/git/u-boot.git;protocol=git with revision ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55 and a lot of patch files.

Is this not the mainline? With this source (and my changes, but the problem is in common code) I also get my problem, and the data stored to gd/bd_t is lost unless it is volatile.

Who is responsible for this part of code, who can help me with this problem in the common code? Maybe this maintainer:
Manikandan Pillai <mani.pillai@ti.com>
omap3_evm	ARM CORTEX-A8 (OMAP3xx SoC)
(file MAINTAINERS)


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

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

[Albert ARIBAUD]

Hi David,

Le 16/02/2011 16:15, Schade, David a ?crit :
> Hi Albert,
>
> Thank you for your reply.
>
> I also tried the U-Boot version for beagleboard, which comdes from
> git://www.denx.de/git/u-boot.git;protocol=git with revision
> ca6e1c136ddb720c3bb2cc043b99f7f06bc46c55 and a lot of patch files.

Hmmm.

ca6e1c13... is quite away from the current master branch tip. I suggest 
you use the master branch (of the most appropriate git repo for your 
board, mainline, ARM or OMAP).

Also, where does this "lot of patch files" come from? All the official 
code is in the u-boot git repositories, and nowhere else.

> Is this not the mainline? With this source (and my changes, but
> the problem is in common code) I also get my problem, and the data
> stored to gd/bd_t is lost unless it is volatile.

Just because the issue appears in common code does not mean the cause is 
there too.

> Who is responsible for this part of code, who can help me with this
> problem in the common code? Maybe this maintainer:
> Manikandan Pillai<mani.pillai@ti.com>
> omap3_evm	ARM CORTEX-A8 (OMAP3xx SoC)
> (file MAINTAINERS)

This is the board maintainer. If you suspect common code, there is no 
reason to involve a specific board maintainer.

The best course of action is to send your patches to the list just like 
any others but with an added "[RFC]" tag in the subject lines.

> Best regards,
>    David.

Amicalement,
-- 
Albert.