[U-Boot] U-Boot on Sparc leon3

[Florian Praden <florian.praden@telecom-paristech.fr>]

Hi, 

I'm trying to build u-boot for a new gaisler board (gr-pci-xc5v-LX110T).

I have some trouble with the leon3/start.S and the linking process 
so I tried to build u-boot from a fresh clean GIT source with the board on 
board/gaisler/gr_xc3s_1500 which should be supported.

And I'm having the same linking problem.

I have already tried the u-boot 1.3.3 which is working on my board
(booting, but the flash is not supported).

The linking problem is the following:

On version v2013.04:

* In the relocation loop, the start.S define 2 variables which is set during the 
  link: 
=============
/* un relocated start address of monitor */
#define TEXT_START _text

/* un relocated end address of monitor */
#define DATA_END __init_end

reloc:
	set     TEXT_START,%g2
	set     DATA_END,%g3
	set     CONFIG_SYS_RELOC_MONITOR_BASE,%g4
reloc_loop:
=============

* compiling this start.S give the following relocation record
=============
RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
0000009c R_SPARC_WDISP30   cpu_init_f
000000a4 R_SPARC_HI22      _text
000000a8 R_SPARC_LO10      _text
000000ac R_SPARC_HI22      __init_end
000000b0 R_SPARC_LO10      __init_end
=============
with the following assembly code:
=============
000000a4 <reloc>:
  a4:   05 00 00 00     sethi  %hi(0), %g2
  a8:   84 10 a0 00     mov  %g2, %g2   ! 0 <_hardreset>
  ac:   07 00 00 00     sethi  %hi(0), %g3
  b0:   86 10 e0 00     mov  %g3, %g3   ! 0 <_hardreset>
  b4:   09 10 fe 38     sethi  %hi(0x43f8e000), %g4

000000b8 <reloc_loop>:
=============

For now, everythings is normal.

After the linking process, I've the following elf:

=============
000010a4 <reloc>:
    10a4:       05 00 00 03     sethi  %hi(0xc00), %g2
    10a8:       84 10 a1 3c     or  %g2, 0x13c, %g2     ! d3c <MINFRAME+0xce0>
    10ac:       07 00 00 03     sethi  %hi(0xc00), %g3
    10b0:       86 10 e1 30     or  %g3, 0x130, %g3     ! d30 <MINFRAME+0xcd4>
    10b4:       09 10 fe 38     sethi  %hi(0x43f8e000), %g4
=============
And the associated .map:

=============
.text           0x0000000000000000    0x2d2b8
                0x0000000000000000                _load_addr = .
                0x0000000000000000                _text = .
[...]
.data.init
 *(.data.init)
                0x0000000000030000                . = ALIGN (0x1000)
                0x0000000000030000                __init_end = .
                0x0000000000030000                __bss_start = .
=============

And the others symbol in this start.S are not defined correctly either.

On the v2013.01 version, I've the same intermediate file but the following  u-boot elf:

=============
000010a4 <reloc>:
    10a4:       05 00 00 00     sethi  %hi(0), %g2
    10a8:       84 10 a0 00     mov  %g2, %g2   ! 0 <_load_addr>
    10ac:       07 00 00 c0     sethi  %hi(0x30000), %g3
    10b0:       86 10 e0 00     mov  %g3, %g3   ! 30000 <__bss_start>
    10b4:       09 10 fe 38     sethi  %hi(0x43f8e000), %g4
=============

Which is what I expected.

On IRC, Marex give me the advice to check with git bisect and find the commit which (I think) break the linking process.
And It found this one:
=============================
eb33809f70e3d3a2c1fba043e56cca8fccedbe0c is the first bad commit
commit eb33809f70e3d3a2c1fba043e56cca8fccedbe0c
Author: Simon Glass <sjg@chromium.org>
Date:   Tue Mar 5 14:40:03 2013 +0000

    sparc: Fix out-of-tree building

    It isn't clear why the sparc cpu Makefile has its own compile line, but
    it does not work correctly with an out-of-tree build. Removing it fixes
    this problem. Perhaps it does not introduce others.

    Signed-off-by: Simon Glass <sjg@chromium.org>

:040000 040000 39dc0c7a3ff2feadaddeda1b7938502f30f2ed76 7e77469d3aa8550d3f712470d45ef73e46b217b8 M      arch
bisect run success
============================

Which corresponds to remove the specific makefile for sparc.


So what did i do wrong or misunderstund about the compiling u-boot process?
Why removing specific compile process for sparc?

Best, 

--
Florian.