All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] U-Boot on Sparc leon3
@ 2015-01-23 11:16 Florian Praden
  2015-01-24 14:21 ` Simon Glass
  0 siblings, 1 reply; 2+ messages in thread
From: Florian Praden @ 2015-01-23 11:16 UTC (permalink / raw)
  To: u-boot

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [U-Boot] U-Boot on Sparc leon3
  2015-01-23 11:16 [U-Boot] U-Boot on Sparc leon3 Florian Praden
@ 2015-01-24 14:21 ` Simon Glass
  0 siblings, 0 replies; 2+ messages in thread
From: Simon Glass @ 2015-01-24 14:21 UTC (permalink / raw)
  To: u-boot

Hi Florian,

On 23 January 2015 at 04:16, Florian Praden
<florian.praden@telecom-paristech.fr> wrote:
> 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?

It looks like the compile line was needed, although I'm not sure why.
It used to say:

$(START): $(START:.o=.S)
$(CC) -D__ASSEMBLY__ $(DBGFLAGS) $(OPTFLAGS) -D__KERNEL__ \
-DCONFIG_SYS_TEXT_BASE=$(CONFIG_SYS_TEXT_BASE) -I$(TOPDIR)/include \
-fno-builtin -ffreestanding -nostdinc -isystem $(gccincdir) -pipe \
$(PLATFORM_CPPFLAGS) -Wall -Wstrict-prototypes \
-I$(TOPDIR)/board -c -o $(START) $(START:.o=.S)

I don't see anything in there that does something special with
compiler flags, but there must be some difference.

You could try comparing the compiler flags that are used with start.S
in each case. There may be some sort of difference, and then you can
add it to PLATFORM_CPPFLAGS or perhaps your arch/xxx/config.mk.

Re your second question, compilation is handled by U-Boot's standard
build system, so we should be calling the compiler manually in a
Makefile. The Makefile is there mainly to specify what should be
built.

Also when you do get it working, I'd encourage you to move to 2015.01
which is newer and has Kconfig.

Regards,
Simon

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-01-24 14:21 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-23 11:16 [U-Boot] U-Boot on Sparc leon3 Florian Praden
2015-01-24 14:21 ` Simon Glass

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.