[U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udiv0

[U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udiv0

[Markus Pietrek]

Hi folks,

I'm currently porting U-Boot 1.0.0 to a NetSilicon NS9750 (ARM926EJS core). 
This port is partly derived from board/omap1610inn. The compiler is 
gcc-3.3.2, taken from the uClibc toolchain.

For my target the compiler is using his internal libgcc.a:__div0 routine which 
of course fails (it's an SWI instruction). But compiling U-Boot for an 
smdk2410 platform with the same compiler uses the correct U-Boot's own __div0 
code. I can't see any relevant differences in both build lines.

Can anyone help me? And is it really necessary to include libgcc.a?

The build line for the NS9750:
========================
UNDEF_SYM=`arm-linux-objdump -x board/ns9750dev/libns9750dev.a 
cpu/arm926ejs/libarm926ejs.a lib_arm/libarm.a fs/jffs2/libjffs2.a 
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a 
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a 
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a |sed  -n -e 
's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
        arm-linux-ld -Bstatic -T 
/targets/ewp/LxMOD/build/apps/u-boot-1.0.0/board/ns9750dev/u-boot.lds -Ttext 
0x00F80000  $UNDEF_SYM cpu/arm926ejs/start.o \
                --start-group board/ns9750dev/libns9750dev.a 
cpu/arm926ejs/libarm926ejs.a lib_arm/libarm.a fs/jffs2/libjffs2.a 
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a 
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a 
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a -L 
/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2 -lgcc --end-group 
\
                -Map u-boot.map -o u-boot
========================

The relevant entry in u-boot.map for __div0:


===========================
/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2/libgcc.a(_udivsi3.o)
                              drivers/libdrivers.a(serial_ns9750.o) 
(__udivsi3)
/
Compilation
============================


The build line for SMDK2410

=======================-
UNDEF_SYM=`arm-linux-objdump -x board/smdk2410/libsmdk2410.a 
cpu/arm920t/libarm920t.a lib_arm/libarm.a fs/jffs2/libjffs2.a 
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a 
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a 
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a |sed  -n -e 
's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
        arm-linux-ld -Bstatic -T 
/targets/ewp/LxMOD/build/apps/u-boot.smdk/board/smdk2410/u-boot.lds -Ttext 
0x33F80000  $UNDEF_SYM cpu/arm920t/start.o \
                --start-group board/smdk2410/libsmdk2410.a 
cpu/arm920t/libarm920t.a lib_arm/libarm.a fs/jffs2/libjffs2.a 
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a 
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a 
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a -L 
/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2 -lgcc --end-group 
\
                -Map u-boot.map -o u-boot
===================

The relevant entry in u-boot.map for __div0:

====================
lib_arm/libarm.a(_udivsi3.o)  cpu/arm920t/libarm920t.a(speed.o) (__udivsi3)

-- 
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221

[U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udi

[Anders Larsen]

Markus Pietrek <maillist@fsforth.de> schreibt:
>For my target the compiler is using his internal libgcc.a:__div0 routine
>which 
>of course fails (it's an SWI instruction). But compiling U-Boot for an 
>smdk2410 platform with the same compiler uses the correct U-Boot's own
>__div0 
>code. I can't see any relevant differences in both build lines.

Hi,

your compiler wasn't built for a stand-alone target, otherwise
it would have included a full implementation of __div0, __udivsi3 etc.
However, there might be an easy solution to your problem, see below.
>
>Can anyone help me? And is it really necessary to include libgcc.a?
>
>The build line for the NS9750:
>========================
>/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2/libgcc.a(_udivsi3.o)
>                              drivers/libdrivers.a(serial_ns9750.o) 
>(__udivsi3)

>The build line for SMDK2410
>========================
>lib_arm/libarm.a(_udivsi3.o)  cpu/arm920t/libarm920t.a(speed.o)
>(__udivsi3)

The reason for the difference is the link order:
For SMDK2410, __udivsi3 is needed by a module linked before libarm.a
(in this case, cpu/arm920t/speed.c), whereas for NS9750 no module
before or in libarm.a needs it; drivers/libdrivers.a is linked after
libarm.a, so the linker won't go back to get __udivsi3 there and falls
back to using libgcc.a, which is linked last.

One solution could be to change the link order (link libarm.a last);
another (dirty) solution to add some code to your board-specific code
that needs __udivsi3.
I'd prefer the former, of course.

Please try the attached quick patch and let us know if it solves the
problem (or if it breaks thing). Caveat - I haven't tried it myself
yet!

Cheers
 Anders

-------------- next part --------------
A non-text attachment was scrubbed...
Name: link-order.patch
Type: application/octet-stream
Size: 622 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20040128/f1764a3e/attachment.obj 

[U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udi

[Wolfgang Denk]

In message <fc.004c4e48002071d73b9aca009ccdb13f.207378@rea.de> you wrote:
> 
> your compiler wasn't built for a stand-alone target, otherwise

can you please explain what you mean with this statement? It's rather
cryptic for me. I never built GCC "for a stand-alone target", and yet
I always was able to use it without problems including for U-Boot.

> The reason for the difference is the link order:

This is most definitely NOT the reason.

> One solution could be to change the link order (link libarm.a last);

This makes no sense to me.

If you look carefully at the link statement you might notice that all
the libraries are  enclosed  by  a  "--start-group  ...  --end-group"
sequence.

Reading TFM:

     The specified archives are searched repeatedly until no new
     undefined references are created.  Normally, an archive is
     searched only once in the order that it is specified on the
     command line.  If a symbol in that archive is needed to resolve an
     undefined symbol referred to by an object in an archive that
     appears later on the command line, the linker would not be able to
     resolve that reference.  By grouping the archives, they all be
     searched repeatedly until all possible references are resolved.


Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 17 - 19,  Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The evolution of the human race will not be accomplished in  the  ten
thousand  years  of  tame  animals,  but in the million years of wild
animals, because man is and will always be a wild animal.
                                              - Charles Galton Darwin

[U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udi

[Markus Pietrek]

Hello,

> your compiler wasn't built for a stand-alone target, otherwise
> it would have included a full implementation of __div0, __udivsi3 etc.
> However, there might be an easy solution to your problem, see below.

There is a full set already available in the gcc? But anyway, it makes not 
much sense using two different gcc compilers. One for the bootloader, one for 
applications. And with which one has the linux kernel to be compiled?


> The reason for the difference is the link order:
> For SMDK2410, __udivsi3 is needed by a module linked before libarm.a
> (in this case, cpu/arm920t/speed.c), whereas for NS9750 no module
> before or in libarm.a needs it; drivers/libdrivers.a is linked after
> libarm.a, so the linker won't go back to get __udivsi3 there and falls
> back to using libgcc.a, which is linked last.

Yes, of course. Now I see it. I'm needing the non-power 2 division only in the 
serial driver for calculation the baudrate divisior. And libdrivers has been 
after libarm :-( 

> Please try the attached quick patch and let us know if it solves the
> problem (or if it breaks thing). Caveat - I haven't tried it myself
> yet!

Thank you, it works fine. Therefore, in the near future a new board and CPU 
will be supported by U-Boot :-)

Bye,

-- 
Markus Pietrek
Kueferstrasse 8, D-79206 Breisach, Germany
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145,  FAX +49 (7667) 908 221

[U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udi

[Robert Schwebel]

Markus, 

On Thu, Jan 29, 2004 at 09:37:25AM +0100, Markus Pietrek wrote:
> There is a full set already available in the gcc? But anyway, it makes
> not much sense using two different gcc compilers. One for the
> bootloader, one for applications. And with which one has the linux
> kernel to be compiled?

It looks like I have fixed the problems with softfloat support in
gcc-3.3.2 in PTXdist; they first came up when I tried to compile U-Boot
and the linker claimed that libgcc wouldn't have softfloat support
included. If you want to give it a try, download a snapshot from 

	http://www.pengutronix.de/software/ptxdist/ptxdist-20040201-1.tgz

and try it out with 

	make toolchain-arm-linux-3.3.2_config
	make world

> Thank you, it works fine. Therefore, in the near future a new board
> and CPU will be supported by U-Boot :-)

The Atmel one? Which board are you working with? 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstra?e 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4