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.