[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Michal Suchanek]

Hello,

when using a hardfloat toolchain linking u-boot fails.

LD      u-boot
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o)
uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file
/usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(bpabi.o)
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o)
uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file
/usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_divdi3.o)
ld.bfd: error: /usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o)
uses VFP register arguments, u-boot does not
ld.bfd: failed to merge target specific data of file
/usr/lib/gcc/arm-linux-gnueabihf/4.9/libgcc.a(_udivdi3.o)
Makefile:1065: recipe for target 'u-boot' failed
make: *** [u-boot] Error 1

Removing the softfloat option fixes the issue:

--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -16,7 +16,7 @@ endif
 LDFLAGS_FINAL += --gc-sections
 PLATFORM_RELFLAGS += -ffunction-sections -fdata-sections \
                     -fno-common -ffixed-r9
-PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \
+PLATFORM_RELFLAGS += \
       $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,))

 # Support generic board on ARM

Did u-boot start using floating point calculations?
Or are these objects superfluous?
Or neither of that but addition of the softfloat option sometime last
year just needlessly breaks builds?

Thanks

Michal

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Tom Rini]

On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote:

> Hello,
> 
> when using a hardfloat toolchain linking u-boot fails.

What version of U-Boot are you building?  There's a few rc releases that
fail with hardfp-only because a few things leaked in with 64bit math.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150104/627943d0/attachment.pgp>

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Michal Suchanek]

On 5 January 2015 at 02:28, Tom Rini <trini@ti.com> wrote:
> On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote:
>
>> Hello,
>>
>> when using a hardfloat toolchain linking u-boot fails.
>
> What version of U-Boot are you building?  There's a few rc releases that
> fail with hardfp-only because a few things leaked in with 64bit math.


I am building master (or what you get by cloning git) with some extra
patches for sunxi support.

Maybe I should check if some of the sunxi patches cause the failure.

Thanks

Michal

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[B.R. Oake]

On 05/01/15 01:28, Tom Rini wrote:
> On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote:
>> when using a hardfloat toolchain linking u-boot fails.
> 
> What version of U-Boot are you building?  There's a few rc releases that
> fail with hardfp-only because a few things leaked in with 64bit math.

Hi Tom,

I also encountered this problem
( http://lists.denx.de/pipermail/u-boot/2015-January/200123.html )
and found it was indeed when 64-bit maths operations were included.
To be exact, it was this division of a long long in
drivers/video/videomodes.c:

     mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);

which was part of this commit in Hans' sunxi video series:

0cd5efe videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function

and which was linked into the u-boot binary in a later commit:

e7872f3 sunxi: video: Use video-mode/-timing from videomodes
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
[...]
-obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
+obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o

Thanks,
B.R. Oake.

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Hans de Goede]

Hi,

On 05-01-15 11:46, B.R. Oake wrote:
> On 05/01/15 01:28, Tom Rini wrote:
>> On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote:
>>> when using a hardfloat toolchain linking u-boot fails.
>>
>> What version of U-Boot are you building?  There's a few rc releases that
>> fail with hardfp-only because a few things leaked in with 64bit math.
>
> Hi Tom,
>
> I also encountered this problem
> ( http://lists.denx.de/pipermail/u-boot/2015-January/200123.html )
> and found it was indeed when 64-bit maths operations were included.
> To be exact, it was this division of a long long in
> drivers/video/videomodes.c:
>
>       mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);
>
> which was part of this commit in Hans' sunxi video series:
>
> 0cd5efe videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function
>
> and which was linked into the u-boot binary in a later commit:
>
> e7872f3 sunxi: video: Use video-mode/-timing from videomodes
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> [...]
> -obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
> +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o

Ah, ok, thanks for figuring that out, so this only happens to people
following my sunxi-wip branch, because that commit is not upstream yet.

So I guess I will need to fix this somehow without using 64 bit math,
any suggestions?

Regards,

Hans

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Michael Trimarchi]

Hi

On Mon, Jan 5, 2015 at 11:51 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 05-01-15 11:46, B.R. Oake wrote:
>>
>> On 05/01/15 01:28, Tom Rini wrote:
>>>
>>> On Sun, Jan 04, 2015 at 11:23:29PM +0100, Michal Suchanek wrote:
>>>>
>>>> when using a hardfloat toolchain linking u-boot fails.
>>>
>>>
>>> What version of U-Boot are you building?  There's a few rc releases that
>>> fail with hardfp-only because a few things leaked in with 64bit math.
>>
>>
>> Hi Tom,
>>
>> I also encountered this problem
>> ( http://lists.denx.de/pipermail/u-boot/2015-January/200123.html )
>> and found it was indeed when 64-bit maths operations were included.
>> To be exact, it was this division of a long long in
>> drivers/video/videomodes.c:
>>
>>       mode->pixclock = 1000000000000LL /
>> EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);
>>
>> which was part of this commit in Hans' sunxi video series:
>>
>> 0cd5efe videomodes: Add video_edid_dtd_to_ctfb_res_modes helper function
>>
>> and which was linked into the u-boot binary in a later commit:
>>
>> e7872f3 sunxi: video: Use video-mode/-timing from videomodes
>> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
>> [...]
>> -obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
>> +obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o videomodes.o
>
>
> Ah, ok, thanks for figuring that out, so this only happens to people
> following my sunxi-wip branch, because that commit is not upstream yet.
>
> So I guess I will need to fix this somehow without using 64 bit math,
> any suggestions?

do_div?

Michael

>
> Regards,
>
> Hans
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[B.R. Oake]

On 05/01/15 10:51, Hans de Goede wrote:
> Ah, ok, thanks for figuring that out, so this only happens to people
> following my sunxi-wip branch, because that commit is not upstream yet.
> 
> So I guess I will need to fix this somehow without using 64 bit math,
> any suggestions?

EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is
10,000 times a uint16, so one way of avoiding 64-bit arithmetic would
be to cancel out the 10,000 before the division:

--- a/drivers/video/videomodes.c	2015-01-05 10:18:58.745985034 +0000
+++ b/drivers/video/videomodes.c	2015-01-05 12:15:27.484150964 +0000
@@ -411,7 +411,8 @@
 	mode->refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) /
 			(h_total * v_total);

-	mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);
+	mode->pixclock = 100000000L /
+                         (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 10000);
 	mode->pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) /
 				1000;


I still wonder though whether a nicer way would be for the configs to be
refactored so that -msoft-float was not set on platforms where it wasn't
appropriate.

Cheers,
B.R.

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Tom Rini]

On Mon, Jan 05, 2015 at 12:24:13PM +0000, B.R. Oake wrote:
> On 05/01/15 10:51, Hans de Goede wrote:
> > Ah, ok, thanks for figuring that out, so this only happens to people
> > following my sunxi-wip branch, because that commit is not upstream yet.
> > 
> > So I guess I will need to fix this somehow without using 64 bit math,
> > any suggestions?
> 
> EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is
> 10,000 times a uint16, so one way of avoiding 64-bit arithmetic would
> be to cancel out the 10,000 before the division:

Good idea!

[snip]
> I still wonder though whether a nicer way would be for the configs to be
> refactored so that -msoft-float was not set on platforms where it wasn't
> appropriate.

We've gone over this before (so there's discussions in the archive) but
in sum, no, we don't want to get into doing floating point.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150105/ff06cc40/attachment.pgp>

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[Hans de Goede]

Hi,

On 05-01-15 13:24, B.R. Oake wrote:
> On 05/01/15 10:51, Hans de Goede wrote:
>> Ah, ok, thanks for figuring that out, so this only happens to people
>> following my sunxi-wip branch, because that commit is not upstream yet.
>>
>> So I guess I will need to fix this somehow without using 64 bit math,
>> any suggestions?
>
> EDID_DETAILED_TIMING_PIXEL_CLOCK() always returns a uint32 that is
> 10,000 times a uint16, so one way of avoiding 64-bit arithmetic would
> be to cancel out the 10,000 before the division:
>
> --- a/drivers/video/videomodes.c	2015-01-05 10:18:58.745985034 +0000
> +++ b/drivers/video/videomodes.c	2015-01-05 12:15:27.484150964 +0000
> @@ -411,7 +411,8 @@
>   	mode->refresh = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) /
>   			(h_total * v_total);
>
> -	mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);
> +	mode->pixclock = 100000000L /
> +                         (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 10000);
>   	mode->pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) /
>   				1000;
>
>
> I still wonder though whether a nicer way would be for the configs to be
> refactored so that -msoft-float was not set on platforms where it wasn't
> appropriate.

Ah I did not realize that the EDID_DETAILED_TIMING_PIXEL_CLOCK did * 10000,
that indeed makes things easier, I've done this instead (somewhat cleaner) :

-   mode->pixclock = 1000000000000LL / EDID_DETAILED_TIMING_PIXEL_CLOCK(*t);
-   mode->pixclock_khz = (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) + 500) /
-                           1000;
+ mode->pixclock_khz = EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) / 1000;
+ mode->pixclock = 1000000000L / mode->pixclock_khz;

I've squashed this fix into my personal tree, sunxi-wip branch, so people
building from there should not longer see those compile errors, and I'll
preserve the fix when the patches move to u-boot-sunxi/next :)

Regards,

Hans

[U-Boot] Cannot compile arm u-boot with hardfloat toolchain

[B.R. Oake]

On 05/01/15 13:37, Tom Rini wrote:
> On Mon, Jan 05, 2015 at 12:24:13PM +0000, B.R. Oake wrote:
>> I still wonder though whether a nicer way would be for the configs to be
>> refactored so that -msoft-float was not set on platforms where it wasn't
>> appropriate.
> 
> We've gone over this before (so there's discussions in the archive) but
> in sum, no, we don't want to get into doing floating point.

Hi Tom,

OK, I'll look for those discussions for more background.  Just in case
there's any misunderstanding, though, I wasn't advocating using floating
point, I just meant that U-Boot code might want to perform operations
such as long long integer division, which will invoke a libgcc function
such as __udivdi3(), and for the linking to succeed we need to ensure
that U-Boot and libgcc are using the same ABI.  On a fully hard-float
system, removing the -msoft-float compilation option seems a good way of
achieving that.

Thanks,
B.R.