[U-Boot-Users] MIPS (purple) compilation problems.

[U-Boot-Users] MIPS (purple) compilation problems.

[Ronen Shitrit]

Hi

I'm trying to port the U-Boot to Marvell board with MIPS (rm7000)
I am using a cross compiler mips64-elf.
I'm trying to compile the purpule_config and I have some compilation 
problems,
when I'm using the cpu/mips/config  flag -mabicalls I get a lot of warnings:
      c1: warning: -G is incompatible with PIC code which is the default
       .........
and an LD error:
      mips64-elf-ld: common/main.o: linking PIC files with non-PIC files
      Bad value: failed to merge target specific data of file common/main.o

When I remove the -mabicalls flag, the compilation pass, and the LD fail 
again on different error:
        mips64-elf-ld: target elf32-tradbigmips not found

The LD is looking for elf32-tradbigmips because in the LD script we 
define the output file to be: elf32-tradbigmips

why do we use this definition and not elf32-bigmips??  and what is the 
difference between these two??
and why when I install my cross compiler I don't have support for this 
output format??

so I changed it the output format to elf32-bigmips then I'm getting this 
LD error:
            : undefined reference to `_GLOBAL_OFFSET_TABLE_'

I know it is because I don't have this define in the linker script, and 
I guess the elf32-tradbigmips has this definition.
What should I do??

Thanks

-- 
Ronen Shitrit

M.S.I.L
D.N. Misgav  20184
Tel:   +972-4-9951000
Fax:   +972-4-9951001
Email: mailto: ronen.shitrit at il.marvell.com
_____________________________________________________________
This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for the use of the individual 
or entity named above. If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, distribution 
or copying of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by 
telephone, or by e-mail and delete the message from your computer.

[U-Boot-Users] MIPS (purple) compilation problems.

[Ronen Shitrit]

Hi

I'm trying to port the U-Boot to Marvell board with MIPS (rm7000)
I see that after relocating to the DRAM the disassembly of the u-boot 
shows me
that we jump back to the flash:
start.S:                                            dis:
la     t9,board_init_r                    lui     t9,0xbfc1
                                                  addiu     t9,20140
j      t9                                        jr     t9

I see that I get the same problem when I jump to printf etc.
maybe it is because I don't compile the code as PIC? Is there any 
special compilation flag I should use?
Can someone please send me a disassembly of the U-Boot for any of the 
MIPS board (purple, incaip or dbaux100).

Is there any special handle for relocating of the MIPS that is different 
from the PPC, that I should take under consideration???

Thanks Ronen

Ronen Shitrit wrote:

> Hi
>
> I'm trying to port the U-Boot to Marvell board with MIPS (rm7000)
> I am using a cross compiler mips64-elf.
> I'm trying to compile the purpule_config and I have some compilation 
> problems,
> when I'm using the cpu/mips/config  flag -mabicalls I get a lot of 
> warnings:
>      c1: warning: -G is incompatible with PIC code which is the default
>       .........
> and an LD error:
>      mips64-elf-ld: common/main.o: linking PIC files with non-PIC files
>      Bad value: failed to merge target specific data of file 
> common/main.o
>
> When I remove the -mabicalls flag, the compilation pass, and the LD 
> fail again on different error:
>        mips64-elf-ld: target elf32-tradbigmips not found
>
> The LD is looking for elf32-tradbigmips because in the LD script we 
> define the output file to be: elf32-tradbigmips
>
> why do we use this definition and not elf32-bigmips??  and what is the 
> difference between these two??
> and why when I install my cross compiler I don't have support for this 
> output format??
>
> so I changed it the output format to elf32-bigmips then I'm getting 
> this LD error:
>            : undefined reference to `_GLOBAL_OFFSET_TABLE_'
>
> I know it is because I don't have this define in the linker script, 
> and I guess the elf32-tradbigmips has this definition.
> What should I do??
>
> Thanks
>

-- 
Ronen Shitrit

M.S.I.L
D.N. Misgav  20184
Tel:   +972-4-9951000
Fax:   +972-4-9951001
Email: mailto: ronen.shitrit at il.marvell.com
_____________________________________________________________
This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for the use of the individual 
or entity named above. If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, distribution 
or copying of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by 
telephone, or by e-mail and delete the message from your computer.

[U-Boot-Users] MIPS (purple) compilation problems.

[Wolfgang Denk]

In message <4057256E.3080604@il.marvell.com> you wrote:
> 
> I'm trying to port the U-Boot to Marvell board with MIPS (rm7000)

In your Subject: you write: MIPS  (purple)  compilation  problems.  I
cannot see any relation to the Infineon Purple board here??

> I see that after relocating to the DRAM the disassembly of the u-boot 
> shows me
> that we jump back to the flash:

What did you disassemble? The code in RAM?

> start.S:                                            dis:
> la     t9,board_init_r                    lui     t9,0xbfc1
>                                                   addiu     t9,20140
> j      t9                                        jr     t9

This cannot work. This is what I see for the "purple" board:

...
        move    a0, a1
 564:   00a02021        move    a0,a1
        la      t9, board_init_r
 568:   8f990000        lw      t9,0(gp)
        j       t9
 56c:   03200008        jr      t9
        move    a1, a2          /* delay slot                   */
 570:   00c02821        move    a1,a2


> I see that I get the same problem when I jump to printf etc.
> maybe it is because I don't compile the code as PIC? Is there any 

If you meddle with the compiler options you better know EXACTLY  what
you are doing.

> special compilation flag I should use?

Use the flags as they are defined in U-Boot. This is what  works  for
me.

> Can someone please send me a disassembly of the U-Boot for any of the 
> MIPS board (purple, incaip or dbaux100).

See above.

> Is there any special handle for relocating of the MIPS that is different 
> from the PPC, that I should take under consideration???

There are differences, but your problem  is  not  caused  by  any  of
these. You use bad compiler options and/or misconfigured tools.

> >      c1: warning: -G is incompatible with PIC code which is the default
> >       .........
> > and an LD error:
> >      mips64-elf-ld: common/main.o: linking PIC files with non-PIC files

I don't understand why you don't follow the clear hints the  compiler
is giving: "incompatible with PIC code which is the default". If your
compiler is configured such that PIC is the default, and this default
is  causing incompatibilities, I would try to find out which compiler
option can be used NOT to generate PIC. ["-fno-pic" comes to mind.]


Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The software required `Windows 95 or better', so I installed Linux.

[U-Boot-Users] MIPS (purple) compilation problems.

[Ronen Shitrit]

Hi

Thanks for your help.

The code I disassemble below is the u-boot image.
Believe me I tried all the flags that you can think about - but non of 
it gave me a "clean" u-boot image.

As I understand the code must be PIC, other wise when we will relocate 
to the DRAM in the next function
call we will jump back to the Flash, cause  the compiler might use 
absolute jump and not a relative branch/jump.
any way I found how to overcome the below problem and now the compiler 
generate the same code as you have,
I use gcc -membedded-pic and  ld --relocatable , but this option doesn't 
work well with my elf compiler(as it is mentioned
in the man), and it cause some other problems.
Can you please send me a short description how did you built your cross 
compiler.

Thanks Ronen


Wolfgang Denk wrote:

>In message <4057256E.3080604@il.marvell.com> you wrote:
>  
>
>>I'm trying to port the U-Boot to Marvell board with MIPS (rm7000)
>>    
>>
>
>In your Subject: you write: MIPS  (purple)  compilation  problems.  I
>cannot see any relation to the Infineon Purple board here??
>
>  
>
>>I see that after relocating to the DRAM the disassembly of the u-boot 
>>shows me
>>that we jump back to the flash:
>>    
>>
>
>What did you disassemble? The code in RAM?
>
>  
>
>>start.S:                                            dis:
>>la     t9,board_init_r                    lui     t9,0xbfc1
>>                                                  addiu     t9,20140
>>j      t9                                        jr     t9
>>    
>>
>
>This cannot work. This is what I see for the "purple" board:
>
>...
>        move    a0, a1
> 564:   00a02021        move    a0,a1
>        la      t9, board_init_r
> 568:   8f990000        lw      t9,0(gp)
>        j       t9
> 56c:   03200008        jr      t9
>        move    a1, a2          /* delay slot                   */
> 570:   00c02821        move    a1,a2
>
>
>  
>
>>I see that I get the same problem when I jump to printf etc.
>>maybe it is because I don't compile the code as PIC? Is there any 
>>    
>>
>
>If you meddle with the compiler options you better know EXACTLY  what
>you are doing.
>
>  
>
>>special compilation flag I should use?
>>    
>>
>
>Use the flags as they are defined in U-Boot. This is what  works  for
>me.
>
>  
>
>>Can someone please send me a disassembly of the U-Boot for any of the 
>>MIPS board (purple, incaip or dbaux100).
>>    
>>
>
>See above.
>
>  
>
>>Is there any special handle for relocating of the MIPS that is different 
>>from the PPC, that I should take under consideration???
>>    
>>
>
>There are differences, but your problem  is  not  caused  by  any  of
>these. You use bad compiler options and/or misconfigured tools.
>
>  
>
>>>     c1: warning: -G is incompatible with PIC code which is the default
>>>      .........
>>>and an LD error:
>>>     mips64-elf-ld: common/main.o: linking PIC files with non-PIC files
>>>      
>>>
>
>I don't understand why you don't follow the clear hints the  compiler
>is giving: "incompatible with PIC code which is the default". If your
>compiler is configured such that PIC is the default, and this default
>is  causing incompatibilities, I would try to find out which compiler
>option can be used NOT to generate PIC. ["-fno-pic" comes to mind.]
>
>
>Wolfgang Denk
>
>  
>

-- 
Ronen Shitrit

M.S.I.L
D.N. Misgav  20184
Tel:   +972-4-9951000
Fax:   +972-4-9951001
Email: mailto: ronen.shitrit at il.marvell.com
_____________________________________________________________
This message may contain confidential, proprietary or legally privileged 
information. The information is intended only for the use of the individual 
or entity named above. If the reader of this message is not the intended 
recipient, you are hereby notified that any dissemination, distribution 
or copying of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by 
telephone, or by e-mail and delete the message from your computer.

[U-Boot-Users] MIPS (purple) compilation problems.

[Wolfgang Denk]

In message <4058536D.7020400@il.marvell.com> you wrote:
> 
> The code I disassemble below is the u-boot image.

Yes, that much was clear. My question was: is this the image  on  the
disk  of  your  development  host,  or in flash on your target system
before relocation, or in RAM on your target system after relocation?

> As I understand the code must be PIC, other wise when we will relocate 

No. The code must be relocatable, but not PIC.

> to the DRAM in the next function
> call we will jump back to the Flash, cause  the compiler might use 

It will not, because we relocate it.

Please note that to relocate code means more than just copying it  to
a different address.

> absolute jump and not a relative branch/jump.

This is why we relocate the code.

> Can you please send me a short description how did you built your cross 
> compiler.

See http://www.denx.de/twiki/bin/view/DULG/ELDKRebuildingComponents#Section_3.7.3.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Wagner's music is better than it sounds."               - Mark Twain