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

Anders Larsen alarsen at rea.de
Wed Jan 28 11:37:54 CET 2004

Markus Pietrek <maillist at fsforth.de> schreibt:
>For my target the compiler is using his internal libgcc.a:__div0 routine
>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
>code. I can't see any relevant differences in both build lines.


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:
>                              drivers/libdrivers.a(serial_ns9750.o) 

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

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


-------------- 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 

More information about the U-Boot mailing list