[U-Boot] toolchain problems when building iMX6 mx6qsabreauto (and another bootloader tool)
Hello everyone,
I've got a copy of mainline uboot. Here's the last log message in it;
git log --name-status HEAD^..HEAD
commit d19ad726bcd5d9106f7ba9c750462fcc369f1020 Author: Tom Rini trini@ti.com Date: Mon Nov 25 16:49:32 2013 -0500
Prepare v2014.01-rc1
Signed-off-by: Tom Rini trini@ti.com
M Makefile
And well, I'm having trouble building images for the sabreauto board. Here are the steps I follow,
make distclean make mx6qsabreauto_config make
And this is the error I get;
make[1]: Leaving directory `/home/abraham/SPACE/temp_uboot/arch/arm/cpu' /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-gcc -E -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x17800000 -I/home/abraham/SPACE/temp_uboot/include -I/home/abraham/SPACE/temp_uboot/arch/arm/include -fno-builtin -ffreestanding -nostdinc -isystem /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -include /home/abraham/SPACE/temp_uboot/include/u-boot/u-boot.lds.h -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - </home/abraham/SPACE/temp_uboot/arch/arm/cpu/u-boot.lds >u-boot.lds cd /home/abraham/SPACE/temp_uboot && /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd -pie -T u-boot.lds --gc-sections -Bstatic -Ttext 0x17800000 arch/arm/cpu/armv7/start.o --start-group arch/arm/cpu/armv7/built-in.o arch/arm/cpu/armv7/mx6/built-in.o arch/arm/cpu/built-in.o arch/arm/imx-common/built-in.o arch/arm/lib/built-in.o board/freescale/common/built-in.o board/freescale/mx6qsabreauto/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/input/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o drivers/mtd/nand/built-in.o drivers/mtd/onenand/built-in.o drivers/mtd/spi/built-in.o drivers/mtd/ubi/built-in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built-in.o drivers/power/battery/built-in.o drivers/power/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o fs/built-in.o lib/built-in.o lib/libfdt/built-in.o net/built-in.o post/built-in.o test/built-in.o --end-group /home/abraham/SPACE/temp_uboot/arch/arm/lib/eabi_compat.o -L /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2 -lgcc -Map u-boot.map -o u-boot /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: error: /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(bpabi.o) /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: error: /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_divdi3.o) /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: error: /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o) make: *** [u-boot] Error 1
Now, what bothers me is NOT the error, but how I resolved it. In the above run, I've been using linaro's cross-compiler. If I switch over to using the toolchain from Mentor Graphics (code-sorcery free version), the build compiles without issues (I can even boot the resulting image on a board!).
Here are details of the cross-compilers I've been using,
From Linaro;
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-gcc --version arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.07-1 - Linaro GCC 2013.07) 4.8.2 20130624 (prerelease) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
From MentorGraphics;
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-SourceryCodeBenchLite-arm/bin/arm-none-linux-gnueabi-gcc --version arm-none-linux-gnueabi-gcc (Sourcery CodeBench Lite 2013.05-24) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is the second time I've had issues because of the toolchain. The last time was because the utility omap4boot wouldn't work unless it was built from MentorGraphics toolchain. Using Linaro's version, it would build successfully, but the resulting image wouldn't run.
Has anyone else on this mailing list had trouble when using Linaro's toolchain? Any theories on why it's not working as intended?
Really puzzled, Abraham V.
Hi Abraham,
On 28/11/2013 05:22, Abraham V. wrote:
test/built-in.o --end-group /home/abraham/SPACE/temp_uboot/arch/arm/lib/eabi_compat.o -L /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2 -lgcc -Map u-boot.map -o u-boot /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd: error: /home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not
The most evident cause here is that you use a -hf toolchain with support for hard float point. U-Boot does not support it: there is no need of it.
This is the reason why it works using Mentor's toolchain. Even if you use the Linaro's supplied with Ubuntu, it works.
Best regards, Stefano Babic
Thanks Stefano,
I didn't notice that difference until you pointed it out. Till now, I was under the assumption that both toolchains were (feature-wise) identical. And I *almost* sent a complaint letter to Linaro about this too ... Guess, I've got more to learn than I anticipated.
Sincerely, Abraham V.
On Thu, Nov 28, 2013 at 12:52 PM, Stefano Babic sbabic@denx.de wrote:
Hi Abraham,
On 28/11/2013 05:22, Abraham V. wrote:
test/built-in.o --end-group /home/abraham/SPACE/temp_uboot/arch/arm/lib/eabi_compat.o -L
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2
-lgcc -Map u-boot.map -o u-boot
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/arm-linux-gnueabihf-ld.bfd:
error:
/home/abraham/SPACE/BISQUARE/source/uboot_update/gcc-linaro-arm/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(bpabi.o)
uses VFP register arguments, u-boot does not
The most evident cause here is that you use a -hf toolchain with support for hard float point. U-Boot does not support it: there is no need of it.
This is the reason why it works using Mentor's toolchain. Even if you use the Linaro's supplied with Ubuntu, it works.
Best regards, Stefano Babic
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
Dear "Abraham V.",
In message CANiE1qo9fDOkeVjq89W3cEoxRyic9d_DO71vv9BRtg7bnJ-jnQ@mail.gmail.com you wrote:
I didn't notice that difference until you pointed it out. Till now, I was under the assumption that both toolchains were (feature-wise) identical. And I *almost* sent a complaint letter to Linaro about this too ... Guess, I've got more to learn than I anticipated.
I think feature-wise both configurations are probably identical; but for more general usability the -hf configuration should also include a non-hf version of the libgcc library, so that building with "-msoft-float" actually works.
Alternatively, you can always use USE_PRIVATE_LIBGCC=yes on the make command line to use U-Boot's builtin libgcc code.
Best regards,
Wolfgang Denk
2013/11/29 Wolfgang Denk wd@denx.de:
Dear "Abraham V.",
In message CANiE1qo9fDOkeVjq89W3cEoxRyic9d_DO71vv9BRtg7bnJ-jnQ@mail.gmail.com you wrote:
I didn't notice that difference until you pointed it out. Till now, I was under the assumption that both toolchains were (feature-wise) identical. And I *almost* sent a complaint letter to Linaro about this too ... Guess, I've got more to learn than I anticipated.
I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc.
I think feature-wise both configurations are probably identical; but for more general usability the -hf configuration should also include a non-hf version of the libgcc library, so that building with "-msoft-float" actually works.
Will try this one.
greets -- Christian Gmeiner, MSc
Dear Christian Gmeiner,
In message CAH9NwWeb6s+3s4O25D7Cifob9Y3_7jmHoSjO6o78FijQuWZMwg@mail.gmail.com you wrote:
I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc.
Maybe Linaro started using a hard-float configuration only recently?
Best regards,
Wolfgang Denk
On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk wd@denx.de wrote:
Dear Christian Gmeiner,
In message CAH9NwWeb6s+3s4O25D7Cifob9Y3_7jmHoSjO6o78FijQuWZMwg@mail.gmail.com you wrote:
I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc.
Maybe Linaro started using a hard-float configuration only recently?
For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10
toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease)
762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aubert@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200
mx6: compute PLL PFD frequencies rather than using defines
Signed-off-by: Pierre Aubert p.aubert@staubli.com CC: Stefano Babic sbabic@denx.de
:040000 040000 c3dba1387015304c14486872c9776d008d9a3b03 1f16de9cee07af71e12f1a746dcd962c9eb84bb0 M arch
git bisect log git bisect start # good: [183acb700378a8cfc5d50a01a65de93fb2c24586] Prepare v2013.10 git bisect good 183acb700378a8cfc5d50a01a65de93fb2c24586 # bad: [d19ad726bcd5d9106f7ba9c750462fcc369f1020] Prepare v2014.01-rc1 git bisect bad d19ad726bcd5d9106f7ba9c750462fcc369f1020 # good: [65ba7add0d609bbd035b8d42fafdaf428ac24751] time: add weak annotation to timer_read_counter declaration git bisect good 65ba7add0d609bbd035b8d42fafdaf428ac24751 # bad: [c3ebb8c38a5da5e40da2786c5d850d1f6555ff95] Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx git bisect bad c3ebb8c38a5da5e40da2786c5d850d1f6555ff95 # bad: [3285d4ca197928a048d3dda86751b5d26e6e0e86] Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' git bisect bad 3285d4ca197928a048d3dda86751b5d26e6e0e86 # good: [552998e5f7655ba8fd3acff400012bd651edff06] TI:armv7: Change CONFIG_SYS_SPL_ARGS_ADDR to a higher address git bisect good 552998e5f7655ba8fd3acff400012bd651edff06 # bad: [195d130da1c2705f96571b7265312bdfa8a83fee] Revert "configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards" git bisect bad 195d130da1c2705f96571b7265312bdfa8a83fee # bad: [4867b634b7c0e5ede258b4998fa4b2710e7daacf] ARM: mx5: Enable L2 cache git bisect bad 4867b634b7c0e5ede258b4998fa4b2710e7daacf # bad: [0c5e26678b18e136c1514bf769a16060ae1b5ff8] udoo: Add initial support for mx6q udoo board git bisect bad 0c5e26678b18e136c1514bf769a16060ae1b5ff8 # bad: [6654f33c9b520bd4073c7f82a13044e79bc14898] ARM: mxs: tools: Use mkimage for BootStream generation git bisect bad 6654f33c9b520bd4073c7f82a13044e79bc14898 # bad: [762a88ccf8540948fbf8c31b40a29d1e0684a25b] mx6: compute PLL PFD frequencies rather than using defines git bisect bad 762a88ccf8540948fbf8c31b40a29d1e0684a25b # first bad commit: [762a88ccf8540948fbf8c31b40a29d1e0684a25b] mx6: compute PLL PFD frequencies rather than using defines
using USE_PRIVATE_LIBGCC=yes causes another error..
arch/arm/cpu/armv7/mx6/built-in.o: In function `mxc_get_pll_pfd': /opt/github/u-boot/arch/arm/cpu/armv7/mx6/clock.c:126: undefined reference to `__aeabi_uldivmod' /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: BFD (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 2.23.2.20130610 Linaro 2013.10-4 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-linaro-2.23.2-2013.10-4/bfd/elf32-arm.c:7687 /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the linker script /opt/gcc/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation make: *** [u-boot] Error 1
Regards,
Robert Nelson robertcnelson@gmail.com writes:
On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk wd@denx.de wrote:
Dear Christian Gmeiner,
In message CAH9NwWeb6s+3s4O25D7Cifob9Y3_7jmHoSjO6o78FijQuWZMwg@mail.gmail.com you wrote:
I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc.
Maybe Linaro started using a hard-float configuration only recently?
For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10
toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease)
762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aubert@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200
mx6: compute PLL PFD frequencies rather than using defines
That commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff.
Try this patch:
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 873d9d0..752b3c8 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -5,6 +5,7 @@ */
#include <common.h> +#include <div64.h> #include <asm/io.h> #include <asm/errno.h> #include <asm/arch/imx-regs.h> @@ -123,8 +124,8 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) return 0; }
- return (freq * 18) / ((div & ANATOP_PFD_FRAC_MASK(pfd_num)) >> - ANATOP_PFD_FRAC_SHIFT(pfd_num)); + return lldiv(freq * 18, (div & ANATOP_PFD_FRAC_MASK(pfd_num)) >> + ANATOP_PFD_FRAC_SHIFT(pfd_num)); }
static u32 get_mcu_main_clk(void)
On Wed, Dec 4, 2013 at 9:35 AM, Måns Rullgård mans@mansr.com wrote:
Robert Nelson robertcnelson@gmail.com writes:
On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk wd@denx.de wrote:
Dear Christian Gmeiner,
In message CAH9NwWeb6s+3s4O25D7Cifob9Y3_7jmHoSjO6o78FijQuWZMwg@mail.gmail.com you wrote:
I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc.
Maybe Linaro started using a hard-float configuration only recently?
For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10
toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease)
762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aubert@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200
mx6: compute PLL PFD frequencies rather than using definesThat commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff.
Try this patch:
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 873d9d0..752b3c8 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -5,6 +5,7 @@ */
#include <common.h> +#include <div64.h> #include <asm/io.h> #include <asm/errno.h> #include <asm/arch/imx-regs.h> @@ -123,8 +124,8 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) return 0; }
return (freq * 18) / ((div & ANATOP_PFD_FRAC_MASK(pfd_num)) >>ANATOP_PFD_FRAC_SHIFT(pfd_num));
return lldiv(freq * 18, (div & ANATOP_PFD_FRAC_MASK(pfd_num)) >>ANATOP_PFD_FRAC_SHIFT(pfd_num));}
static u32 get_mcu_main_clk(void)
Thanks Måns!
That fixed it...
Regards,
Dear Måns Rullgård ,
On Wed, Dec 4, 2013 at 9:35 AM, Måns Rullgård <[hidden email]> wrote:
mx6: compute PLL PFD frequencies rather than using definesThat commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff.
Thank you for the fix. I missed the 64 bits division.
Best regards
-- View this message in context: http://u-boot.10912.n7.nabble.com/toolchain-problems-when-building-iMX6-mx6q... Sent from the U-Boot mailing list archive at Nabble.com.
2013/12/4 Måns Rullgård mans@mansr.com:
Robert Nelson robertcnelson@gmail.com writes:
On Fri, Nov 29, 2013 at 4:28 PM, Wolfgang Denk wd@denx.de wrote:
Dear Christian Gmeiner,
In message CAH9NwWeb6s+3s4O25D7Cifob9Y3_7jmHoSjO6o78FijQuWZMwg@mail.gmail.com you wrote:
I am running into the same problem. Me wonders which patch/change triggers this problem. I am using the same toolchain since I started to work with u-boot and it fails with the latest rc.
Maybe Linaro started using a hard-float configuration only recently?
For what it's worth, i just ran a git bisect on this issue today, as this compiler worked fine with v2013.10
toolchain: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.8-2013.10 - Linaro GCC 2013.10) 4.8.2 20131014 (prerelease)
762a88ccf8540948fbf8c31b40a29d1e0684a25b is the first bad commit commit 762a88ccf8540948fbf8c31b40a29d1e0684a25b Author: Pierre Aubert p.aubert@staubli.com Date: Thu Sep 19 17:48:59 2013 +0200
mx6: compute PLL PFD frequencies rather than using definesThat commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff.
Try this patch:
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index 873d9d0..752b3c8 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -5,6 +5,7 @@ */
#include <common.h> +#include <div64.h> #include <asm/io.h> #include <asm/errno.h> #include <asm/arch/imx-regs.h> @@ -123,8 +124,8 @@ static u32 mxc_get_pll_pfd(enum pll_clocks pll, int pfd_num) return 0; }
return (freq * 18) / ((div & ANATOP_PFD_FRAC_MASK(pfd_num)) >>ANATOP_PFD_FRAC_SHIFT(pfd_num));
return lldiv(freq * 18, (div & ANATOP_PFD_FRAC_MASK(pfd_num)) >>ANATOP_PFD_FRAC_SHIFT(pfd_num));}
static u32 get_mcu_main_clk(void)
--
works here too... can we get this patch into git asap?
thanks -- Christian Gmeiner, MSc
Hi Måns,
On 04/12/2013 16:35, Måns Rullgård wrote:
mx6: compute PLL PFD frequencies rather than using definesThat commit introduces a 64-bit division without using the lldiv() function, which pulls in previously unused libgcc stuff.
Try this patch:
As it was proofed that your patch fixes the issue, can you send aagain the patch using git send-email and adding your Signed-off-by for merging into the release ?
Thanks, Stefano Babic
On Fri, Nov 29, 2013 at 07:27:29AM +0100, Wolfgang Denk wrote:
Dear "Abraham V.",
In message CANiE1qo9fDOkeVjq89W3cEoxRyic9d_DO71vv9BRtg7bnJ-jnQ@mail.gmail.com you wrote:
I didn't notice that difference until you pointed it out. Till now, I was under the assumption that both toolchains were (feature-wise) identical. And I *almost* sent a complaint letter to Linaro about this too ... Guess, I've got more to learn than I anticipated.
I think feature-wise both configurations are probably identical; but for more general usability the -hf configuration should also include a non-hf version of the libgcc library, so that building with "-msoft-float" actually works.
Alternatively, you can always use USE_PRIVATE_LIBGCC=yes on the make command line to use U-Boot's builtin libgcc code.
Well, herp-a-derp. This is the jffs2 problem as well, which boils down to a now 64bit division that needs to be lldiv(). Single board build-tested now for that, testing the rest before posting.
participants (8)
-
Abraham V. -
Christian Gmeiner -
Måns Rullgård -
Pierre Aubert -
Robert Nelson -
Stefano Babic -
Tom Rini -
Wolfgang Denk