[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[adam hussein]

I've been building the at91rm9200ek configuration of buildroot to get a toolchain I can use to build u-boot with some board specific configuration.

This is an ARM920T core chip with ARMv4T architecture??- later ARM9 series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)

When gcc is built, or perhaps specifically libgcc only, it seems the selection of 920t/v4 architecture gets lost and v5 is used instead.
This means that when I use it to build u-boot, I find it has the __udivsi3 function using the illegal (to v4) instruction CLZ (count leading zeros).

The easiest workaround for me is to specify arm7tdmi and be done with it, but I'd like to try contributing a proper fix if possible.

It turns out that this issue has been around for some time:

e.g. 2006: http://www.mail-archive.com/oe at handhelds.org/msg02024.html
e.g. 2007: http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/3139
e.g. 2007: http://web.archive.org/web/20070815094037/http://bugs.busybox.net/view.php?id=1406 (referred to in previous link)

and then the last link has this patch:
http://web.archive.org/web/20070815094037/http://bugs.busybox.net/file_download.php?file_id=1059&type=bug

...which seems not to have made it into the main repo, and no longer applies correctly; all the locations have changed.


So, here follows an up-to-date version of it. I hope someone finds it useful and avoids repeating all my 'digging about'.

And many thanks to 'bjdooks' for the original.


----

diff -ruN buildroot-2013.08.1-orig/arch/Config.in.arm buildroot-2013.08.1/arch/Config.in.arm
--- buildroot-2013.08.1-orig/arch/Config.in.arm??? 2013-09-17 12:42:07.000000000 +0100
+++ buildroot-2013.08.1/arch/Config.in.arm??? 2013-09-25 15:42:16.923369027 +0100
@@ -117,6 +117,24 @@
???? bool "iwmmxt"
?endchoice

+# what we pass to the --with-cpu= option to gcc
+config BR2_ARM_gcc_cpu
+??? string
+??? default arm610????????? if BR2_arm610
+??? default arm710????????? if BR2_arm710
+??? default arm720t???????? if BR2_arm720t
+??? default arm920t???????? if BR2_arm920t
+??? default arm922t???????? if BR2_arm922t
+??? default arm926t???????? if BR2_arm926t
+??? default arm1136jf-s???? if BR2_arm1136jf_s
+??? default arm1176Jz-s???? if BR2_arm1176jz_s
+??? default arm1176jfz-s??? if BR2_arm1176jzf_s
+??? default strongarm110??? if BR2_sa110
+??? default strongarm1100?? if BR2_sa1100
+??? default xscale????????? if BR2_xscale
+??? default iwmmxt????????? if BR2_iwmmxt
+
+
?config BR2_arm1136jf_s
???? bool
???? default BR2_arm1136jf_s_r0 || BR2_arm1136jf_s_r1
diff -ruN buildroot-2013.08.1-orig/package/gcc/gcc.mk buildroot-2013.08.1/package/gcc/gcc.mk
--- buildroot-2013.08.1-orig/package/gcc/gcc.mk??? 2013-09-17 12:42:07.000000000 +0100
+++ buildroot-2013.08.1/package/gcc/gcc.mk??? 2013-09-25 15:49:01.605600268 +0100
@@ -159,6 +160,13 @@
?ifneq ($(call qstrip,$(BR2_GCC_TARGET_ABI)),)
?HOST_GCC_COMMON_CONF_OPT += --with-abi=$(BR2_GCC_TARGET_ABI)
?endif
+
+ifeq ($(BR2_arm),y)
+ifeq ($(BR2_generic_arm),)
+HOST_GCC_COMMON_CONF_OPT += --with-cpu=$(BR2_ARM_gcc_cpu)
+endif
+endif
+
?# GCC doesn't support --with-cpu for bfin
?ifeq ($(BR2_bfin),)
?ifneq ($(call qstrip,$(BR2_GCC_TARGET_CPU)),)??? ??

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Thomas Petazzoni]

Hello,

On Thu, 26 Sep 2013 08:34:53 -0700 (PDT), adam hussein\(!\) wrote:
> I've been building the at91rm9200ek configuration of buildroot to get
> a toolchain I can use to build u-boot with some board specific
> configuration.
> 
> This is an ARM920T core chip with ARMv4T architecture??- later ARM9
> series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)
> 
> When gcc is built, or perhaps specifically libgcc only, it seems the
> selection of 920t/v4 architecture gets lost and v5 is used instead.
> This means that when I use it to build u-boot, I find it has the
> __udivsi3 function using the illegal (to v4) instruction CLZ (count
> leading zeros).
> 
> The easiest workaround for me is to specify arm7tdmi and be done with
> it, but I'd like to try contributing a proper fix if possible.
> 
> It turns out that this issue has been around for some time:
> 
> e.g. 2006: http://www.mail-archive.com/oe at handhelds.org/msg02024.html
> e.g. 2007:
> http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/3139 e.g.
> 2007:
> http://web.archive.org/web/20070815094037/http://bugs.busybox.net/view.php?id=1406
> (referred to in previous link)
> 
> and then the last link has this patch:
> http://web.archive.org/web/20070815094037/http://bugs.busybox.net/file_download.php?file_id=1059&type=bug
> 
> ...which seems not to have made it into the main repo, and no longer
> applies correctly; all the locations have changed.
> 
> 
> So, here follows an up-to-date version of it. I hope someone finds it
> useful and avoids repeating all my 'digging about'.
> 
> And many thanks to 'bjdooks' for the original.

Interesting. First, thanks for the investigation.

When you select BR2_arm920t as the ARM processor, we are already
passing --with-arch=armv4t to the gcc configure. So, gcc should already
avoid the use of CLZ, since ARMv4T does not support it.

Have you investigated why passing the --with-cpu argument is also
needed, in addition to --with-arch?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Yann E. MORIN]

Thomas, Adam, All,

On 2013-09-26 17:54 +0200, Thomas Petazzoni spake thusly:
> Hello,
> 
> On Thu, 26 Sep 2013 08:34:53 -0700 (PDT), adam hussein\(!\) wrote:
> > I've been building the at91rm9200ek configuration of buildroot to get
> > a toolchain I can use to build u-boot with some board specific
> > configuration.
> > 
> > This is an ARM920T core chip with ARMv4T architecture??- later ARM9
> > series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)
> > 
> > When gcc is built, or perhaps specifically libgcc only, it seems the
> > selection of 920t/v4 architecture gets lost and v5 is used instead.
> > This means that when I use it to build u-boot, I find it has the
> > __udivsi3 function using the illegal (to v4) instruction CLZ (count
> > leading zeros).
> > 
> > The easiest workaround for me is to specify arm7tdmi and be done with
> > it, but I'd like to try contributing a proper fix if possible.
> > 
> > It turns out that this issue has been around for some time:
> > 
> > e.g. 2006: http://www.mail-archive.com/oe at handhelds.org/msg02024.html
> > e.g. 2007:
> > http://permalink.gmane.org/gmane.comp.lib.uclibc.buildroot/3139 e.g.
> > 2007:
> > http://web.archive.org/web/20070815094037/http://bugs.busybox.net/view.php?id=1406
> > (referred to in previous link)
> > 
> > and then the last link has this patch:
> > http://web.archive.org/web/20070815094037/http://bugs.busybox.net/file_download.php?file_id=1059&type=bug
> > 
> > ...which seems not to have made it into the main repo, and no longer
> > applies correctly; all the locations have changed.
> > 
> > 
> > So, here follows an up-to-date version of it. I hope someone finds it
> > useful and avoids repeating all my 'digging about'.
> > 
> > And many thanks to 'bjdooks' for the original.
> 
> Interesting. First, thanks for the investigation.
> 
> When you select BR2_arm920t as the ARM processor, we are already
> passing --with-arch=armv4t to the gcc configure. So, gcc should already
> avoid the use of CLZ, since ARMv4T does not support it.
> 
> Have you investigated why passing the --with-cpu argument is also
> needed, in addition to --with-arch?

In crosstool-Ng, we have this:
    http://crosstool-ng.org/hg/crosstool-ng/annotate/98b7806295cc/patches/gcc/4.4.5/210-arm-unbreak-armv4t.patch#l1

For gcc, if --with-cpu is not specified, then it defaults to
TARGET_CPU_arm10tdmi which is an armv5 (as far as I understand it).

The patch above downgrades the default CPU to an armv4t. Maybe worth a
try. That, or passing --with-cpu=... as suggested by Adam.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 Thomas> Interesting. First, thanks for the investigation.

 Thomas> When you select BR2_arm920t as the ARM processor, we are
 Thomas> already passing --with-arch=armv4t to the gcc configure. So,
 Thomas> gcc should already avoid the use of CLZ, since ARMv4T does not
 Thomas> support it.

It indeed sounds quite strange, as I've run buildroot rootfs'es on the
mini2440 (which is arm920t) back in 2011 at least.

I don't have access to that hardware anymore though.

-- 
Bye, Peter Korsgaard

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Thu, 26 Sep 2013 19:52:21 +0200, Yann E. MORIN wrote:

> In crosstool-Ng, we have this:
>     http://crosstool-ng.org/hg/crosstool-ng/annotate/98b7806295cc/patches/gcc/4.4.5/210-arm-unbreak-armv4t.patch#l1
> 
> For gcc, if --with-cpu is not specified, then it defaults to
> TARGET_CPU_arm10tdmi which is an armv5 (as far as I understand it).

So even when --with-arch=armv7a, gcc will use --with-cpu=arm10tdmi? I'm
not sure to understand what will be the effect of having
--with-arch=armv7a and --with-cpu=arm10tdmi.

> The patch above downgrades the default CPU to an armv4t. Maybe worth a
> try. That, or passing --with-cpu=... as suggested by Adam.

Ok.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[adam hussein]

>In crosstool-Ng, we have this:
>? ? http://crosstool-ng.org/hg/crosstool-ng/annotate/98b7806295cc/patches/gcc/4.4.5/210-arm-unbreak-armv4t.patch#l1
>
>For gcc, if --with-cpu is not specified, then it defaults to
>TARGET_CPU_arm10tdmi which is an armv5 (as far as I understand it).
>
>The patch above downgrades the default CPU to an armv4t. Maybe worth a
>try. That, or passing --with-cpu=... as suggested by Adam.

Hi,

I have got a similar patch in:
??? package/gcc/4.7.3/830-arm_unbreak_armv4t.patch
...to edit SUBTARGET_CPU_DEFAULT to use arm9tdmi instead of the arm5t arm10tdmi 
core.

The file affected, gcc/config/arm/linux-eabi.h, has no equivalent to set the architecture to arm4t as default.
I wonder if libgcc has no translation from the cpu/core to the architecture.

Following back from the __udivsi3 libgcc function...

My exception was at:
??? 20127a2c:??? e16f3f10 ??? clz??? r3, r0

which is in:
??? 20127a10 <__udivsi3>:

u-boot.map states:
???? .text????????? 0x20127a10????? 0x20c /opt/arm-2009q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_udivsi3.o)

then in ../buildroot-2013.08.1/output/build/host-gcc-final-4.7.3/build/arm-buildroot-linux-uclibcgnueabi/libgcc/_udivsi3.dep 
??? _udivsi3.o: ../../../libgcc/config/arm/lib1funcs.S _udivsi3.vis \
???????????????????? ../../../libgcc/config/arm/ieee754-df.S \
???????????????????? ../../../libgcc/config/arm/ieee754-sf.S \
???????????????????? ../../../libgcc/config/arm/bpabi.S

The assembler code at the start:

??? 20127a10 <__udivsi3>:
??? 20127a10:??? e2512001 ??? subs??? r2, r1, #1??? ; 0x1
??? 20127a14:??? 012fff1e ??? bxeq??? lr
??? 20127a18:??? 3a000074 ??? bcc??? 20127bf0 <__udivsi3+0x1e0>
??? 20127a1c:??? e1500001 ??? cmp??? r0, r1
??? 20127a20:??? 9a00006b ??? bls??? 20127bd4 <__udivsi3+0x1c4>
??? 20127a24:??? e1110002 ??? tst??? r1, r2
????20127a28:??? 0a00006c ??? beq??? 20127be0 <__udivsi3+0x1d0>

matches an available version(within "#else /* ARM version/Thumb-2.? */")
This then uses the macro ARM_DIV_BODY, which sure enough gives the CLZ containing options.

??? .macro ARM_DIV_BODY dividend, divisor, result, curbit
??? 
??? #if __ARM_ARCH__ >= 5 && ! defined (__OPTIMIZE_SIZE__)
??? 
??? #if defined (__thumb2__)
??????????? clz???? \curbit, \dividend
??????????? clz???? \result, \divisor
??? ...
??? #else
??????????? clz???? \curbit, \dividend
??????????? clz???? \result, \divisor
??? ...
??? #endif
??? 
??? #else /* __ARM_ARCH__ < 5 || defined (__OPTIMIZE_SIZE__) */
??? #if __ARM_ARCH__ >= 5
??? 
??????????? clz???? \curbit, \divisor
??????????? clz???? \result, \dividend
??? ...
??? #else /* __ARM_ARCH__ < 5 */
??? ...

So, we clearly have __ARM_ARCH__ >= 5.
The value of this is defined at the beginning of the same file, in the absense of any of:
??? __ARM_ARCH_2__,
??? __ARM_ARCH_3__,
??? __ARM_ARCH_3M__,
??? __ARM_ARCH_4__ or
??? __ARM_ARCH_4T__
..being defined.

I notice with a 'grep -r "__ARM_ARCH_" *" that 'libffi' does something similar.
But, I can't find where this is set. 
Or rather, I don't think it is set in one piece.
The file:
??? gcc/config/arm/arm-cores.def
..seems to be a bridge from 'arm9tdmi', specifying '4T', presumably to append make up __ARM_ARCH_4T__

But the construction of this I unfortunately cannot find.

Any of this jog a memory?

Cheers,
Adam

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Thomas Petazzoni]

Dear adam hussein\(!\),

On Thu, 26 Sep 2013 08:34:53 -0700 (PDT), adam hussein\(!\) wrote:

> I've been building the at91rm9200ek configuration of buildroot to get a toolchain I can use to build u-boot with some board specific configuration.
> 
> This is an ARM920T core chip with ARMv4T architecture??- later ARM9 series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)
> 
> When gcc is built, or perhaps specifically libgcc only, it seems the selection of 920t/v4 architecture gets lost and v5 is used instead.
> This means that when I use it to build u-boot, I find it has the __udivsi3 function using the illegal (to v4) instruction CLZ (count leading zeros).
> 
> The easiest workaround for me is to specify arm7tdmi and be done with it, but I'd like to try contributing a proper fix if possible.

Can you try the attached patch? Ideally, it would be nice if you could
try it with two configurations:

 * With the internal toolchain backend
 * With the Sourcery CodeBench 2013.05 external toolchain

and run it on real hardware.

Thanks a lot for your testing!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arch-use-BR2_GCC_TARGET_CPU-on-ARM.patch
Type: text/x-patch
Size: 1391 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20131102/3a0545f1/attachment.bin>

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Thomas Petazzoni]

Adam,

Did you had the opportunity to test the proposed patch?

On Sat, 2 Nov 2013 16:39:06 +0100, Thomas Petazzoni wrote:
> Dear adam hussein\(!\),
> 
> On Thu, 26 Sep 2013 08:34:53 -0700 (PDT), adam hussein\(!\) wrote:
> 
> > I've been building the at91rm9200ek configuration of buildroot to get a toolchain I can use to build u-boot with some board specific configuration.
> > 
> > This is an ARM920T core chip with ARMv4T architecture??- later ARM9 series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)
> > 
> > When gcc is built, or perhaps specifically libgcc only, it seems the selection of 920t/v4 architecture gets lost and v5 is used instead.
> > This means that when I use it to build u-boot, I find it has the __udivsi3 function using the illegal (to v4) instruction CLZ (count leading zeros).
> > 
> > The easiest workaround for me is to specify arm7tdmi and be done with it, but I'd like to try contributing a proper fix if possible.
> 
> Can you try the attached patch? Ideally, it would be nice if you could
> try it with two configurations:
> 
>  * With the internal toolchain backend
>  * With the Sourcery CodeBench 2013.05 external toolchain
> 
> and run it on real hardware.
> 
> Thanks a lot for your testing!
> 
> Thomas



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[adam hussein]

Hi Thomas,

Sorry for going quiet for so long; a lot of change going on here.

Thanks for the patch; much tidier!

I'm
 not in a position to work on this board now, the project taking a 
different direction altogether; however, I have found time for a sneaky 
test of the patch using the internal toolchain, and it seems fine.

The objdump showing that udivsi3 no longer has CLZ instructions.

arm-buildroot-linux-uclibcgnueabi-objdump -d u-boot | grep "20126c1c:" -A 10
20126c1c:??? e2512001 ??? subs??? r2, r1, #1
20126c20:??? 012fff1e ??? bxeq??? lr
20126c24:??? 3a000036 ??? bcc??? 20126d04 <__udivsi3+0xe8>
20126c28:??? e1500001 ??? cmp??? r0, r1
20126c2c:??? 9a000022 ??? bls??? 20126cbc <__udivsi3+0xa0>
20126c30:??? e1110002 ??? tst??? r1, r2
20126c34:??? 0a000023 ??? beq??? 20126cc8 <__udivsi3+0xac>
20126c38:??? e311020e ??? tst??? r1, #-536870912??? ; 0xe0000000
20126c3c:??? 01a01181 ??? lsleq??? r1, r1, #3
20126c40:??? 03a03008 ??? moveq??? r3, #8
20126c44:??? 13a03001 ??? movne??? r3, #1

Selecting Sourcery CodeBench 2013.05 external toolchain had the buildroot make attempt end with:

? LD????? vmlinux
? SYSMAP? System.map
? SYSMAP? .tmp_System.map
? OBJCOPY arch/arm/boot/Image
? Kernel: arch/arm/boot/Image is ready
? AS????? arch/arm/boot/compressed/head.o
arch/arm/boot/compressed/head.S: Assembler messages:
arch/arm/boot/compressed/head.S:936: Error: selected processor does not support ARM mode `clz r5,r4'

And using it for u-boot gave me:

arm-none-linux-gnueabi-objdump -d u-boot | grep "20126bc0:" -A 10
20126bc0:??? e2512001 ??? subs??? r2, r1, #1
20126bc4:??? 012fff1e ??? bxeq??? lr
20126bc8:??? 3a000074 ??? bcc??? 20126da0 <__udivsi3+0x1e0>
20126bcc:??? e1500001 ??? cmp??? r0, r1
20126bd0:??? 9a00006b ??? bls??? 20126d84 <__udivsi3+0x1c4>
20126bd4:??? e1110002 ??? tst??? r1, r2
20126bd8:??? 0a00006c ??? beq??? 20126d90 <__udivsi3+0x1d0>
20126bdc:??? e16f3f10 ??? clz??? r3, r0
20126be0:??? e16f2f11 ??? clz??? r2, r1


I hope this tells you what you wanted to know, in spite of not being able to run on the hardware.


Adam





----- Original Message -----
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: adam hussein(!) <kryme76@yahoo.com>; "buildroot at busybox.net" <buildroot@busybox.net>
Sent: Thursday, November 7, 2013 7:31 PM
Subject: Re: [Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

Adam,

Did you had the opportunity to test the proposed patch?


On Sat, 2 Nov 2013 16:39:06 +0100, Thomas Petazzoni wrote:
> Dear adam hussein\(!\),
> 
> On Thu, 26 Sep 2013 08:34:53 -0700 (PDT), adam hussein\(!\) wrote:
> 
> > I've been building the at91rm9200ek configuration of buildroot to get a toolchain I can use to build u-boot with some board specific configuration.
> > 
> > This is an ARM920T core chip with ARMv4T architecture??- later ARM9 series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)
> > 
> > When gcc is built, or perhaps specifically libgcc only, it seems the selection of 920t/v4 architecture gets lost and v5 is used instead.
> > This means that when I use it to build u-boot, I find it has the __udivsi3 function using the illegal (to v4) instruction CLZ (count leading zeros).
> > 
> > The easiest workaround for me is to specify arm7tdmi and be done with it, but I'd like to try contributing a proper fix if possible.
> 
> Can you try the attached patch? Ideally, it would be nice if you could
> try it with two configurations:
> 
>? * With the internal toolchain backend
>? * With the Sourcery CodeBench 2013.05 external toolchain
> 
> and run it on real hardware.
> 
> Thanks a lot for your testing!
> 
> Thomas



-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Thomas Petazzoni]

Adam,

On Thu, 21 Nov 2013 06:56:10 -0800 (PST), adam hussein\(!\) wrote:

> Sorry for going quiet for so long; a lot of change going on here.

No problem.

> I'm
>  not in a position to work on this board now, the project taking a 
> different direction altogether; however, I have found time for a
> sneaky test of the patch using the internal toolchain, and it seems
> fine.
> 
> The objdump showing that udivsi3 no longer has CLZ instructions.
> 
> arm-buildroot-linux-uclibcgnueabi-objdump -d u-boot | grep
> "20126c1c:" -A 10 20126c1c:??? e2512001 ??? subs??? r2, r1, #1
> 20126c20:??? 012fff1e ??? bxeq??? lr
> 20126c24:??? 3a000036 ??? bcc??? 20126d04 <__udivsi3+0xe8>
> 20126c28:??? e1500001 ??? cmp??? r0, r1
> 20126c2c:??? 9a000022 ??? bls??? 20126cbc <__udivsi3+0xa0>
> 20126c30:??? e1110002 ??? tst??? r1, r2
> 20126c34:??? 0a000023 ??? beq??? 20126cc8 <__udivsi3+0xac>
> 20126c38:??? e311020e ??? tst??? r1, #-536870912??? ; 0xe0000000
> 20126c3c:??? 01a01181 ??? lsleq??? r1, r1, #3
> 20126c40:??? 03a03008 ??? moveq??? r3, #8
> 20126c44:??? 13a03001 ??? movne??? r3, #1

Ok, so that's with a Buildroot internal toolchain. Can you also try to
build the kernel with this toolchain to see if it's affected or not by
the below problem?

> Selecting Sourcery CodeBench 2013.05 external toolchain had the
> buildroot make attempt end with:
> 
> ? LD????? vmlinux
> ? SYSMAP? System.map
> ? SYSMAP? .tmp_System.map
> ? OBJCOPY arch/arm/boot/Image
> ? Kernel: arch/arm/boot/Image is ready
> ? AS????? arch/arm/boot/compressed/head.o
> arch/arm/boot/compressed/head.S: Assembler messages:
> arch/arm/boot/compressed/head.S:936: Error: selected processor does
> not support ARM mode `clz r5,r4'

Ok. I think this is a kernel bug actually. The head.S file is special
in that it contains instructions for ARMv5+, which an ARMv4t assembler
will not accept. But it should, because the code guarantees that the
ARMv5+ instructions will not be executed on ARMv4.

In order to ask the assembler to accept these instructions, the
following commit was made back in 2008:

  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/Makefile?id=80cec14a83ad0ad109d822b3f3482a379bc481ba

However, it was reverted recently:

  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/Makefile?id=da94a829305f1c217cfdf6771cb1faca0917e3b9

I am not sure how this last commit doesn't break your situation.

It would be interesting if you could confirm whether the kernel builds
or not with the Buildroot internal toolchain.

> And using it for u-boot gave me:
> 
> arm-none-linux-gnueabi-objdump -d u-boot | grep "20126bc0:" -A 10
> 20126bc0:??? e2512001 ??? subs??? r2, r1, #1
> 20126bc4:??? 012fff1e ??? bxeq??? lr
> 20126bc8:??? 3a000074 ??? bcc??? 20126da0 <__udivsi3+0x1e0>
> 20126bcc:??? e1500001 ??? cmp??? r0, r1
> 20126bd0:??? 9a00006b ??? bls??? 20126d84 <__udivsi3+0x1c4>
> 20126bd4:??? e1110002 ??? tst??? r1, r2
> 20126bd8:??? 0a00006c ??? beq??? 20126d90 <__udivsi3+0x1d0>
> 20126bdc:??? e16f3f10 ??? clz??? r3, r0
> 20126be0:??? e16f2f11 ??? clz??? r2, r1

So in other words, you mean that this wouldn't work on the target
platform. Hum, weird. Is this a part of U-Boot implemented in assembly,
or something compiled from C ?

Can you give me the relevant informations to allow me to build the
kernel image and U-Boot image myself? Kernel version and configuration
file, U-Boot version and configuration, etc.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[adam hussein]

Hi Thomas,


>Ok, so that's with a Buildroot internal toolchain. Can you also try to
>build the kernel with this toolchain to see if it's affected or not by
>the below problem?

It was fine, just didn't think to mention it as was an exception of the Sourcery toolchain.

>Ok. I think this is a kernel bug actually. The head.S file is special
>in that it contains instructions for ARMv5+, which an ARMv4t assembler
>will not accept. But it should, because the code guarantees that the
>ARMv5+ instructions will not be executed on ARMv4.
>
>In order to ask the assembler to accept these instructions, the
>following commit was made back in 2008:
>
>? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/Makefile?id=80cec14a83ad0ad109d822b3f3482a379bc481ba
>
>However, it was reverted recently:
>
>? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/Makefile?id=da94a829305f1c217cfdf6771cb1faca0917e3b9
>
>I am not sure how this last commit doesn't break your situation.

Interesting stuff. It's building 2.6.38.6, which benefits only from the first commit.

>It would be interesting if you could confirm whether the kernel builds
>or not with the Buildroot internal toolchain.

As above, it built fine.

>> 20126bdc:??? e16f3f10 ??? clz??? r3, r0
>> 20126be0:??? e16f2f11 ??? clz??? r2, r1

>So in other words, you mean that this wouldn't work on the target
>platform. Hum, weird. Is this a part of U-Boot implemented in assembly,
>or something compiled from C ?

Yes indeed. My belief is that _udivsi3 was pulled in with CLZs intact from the libgcc built and distributed with the Sourcery toolchain, rather than rebuilding a 4T arch version for the occasion.
To be honest, I'm not sure if something like --sysroot can redirect this; I've never thought about it before.

>Can you give me the relevant informations to allow me to build the
>kernel image and U-Boot image myself? Kernel version and configuration
>file, U-Boot version and configuration, etc.

Sure. Didn't get far off making for the dev board it was based on, aside from memory tweaks to u-boot.
I'm building the buildroot-2013.08.1 archive with 'make at91rm9200df_defconfig'.
The u-boot clone is at commit 46ef4faed18196472eb95216b2f74c1397ecf024 from http://git.denx.de/u-boot.git.
Then:
??? export PATH=$PATH:/data/at91rm9200/buildroot-2013.08.1/output/host/usr/bin/
??? export CROSS_COMPILE=arm-buildroot-linux-uclibcgnueabi-
??? make at91rm9200dvc_ram_config
??? make
or:
??? export PATH=$PATH:/data/at91rm9200/buildroot-2013.08.1-thomas2/output/host/opt/ext-toolchain/bin/
accordingly.

I used JTAG to pin-point that CLZ was the cause of failure, rather than myself!

Good luck,
Adam

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Thomas Petazzoni]

Adam,

On Thu, 21 Nov 2013 08:07:17 -0800 (PST), adam hussein\(!\) wrote:

> >Ok, so that's with a Buildroot internal toolchain. Can you also try to
> >build the kernel with this toolchain to see if it's affected or not by
> >the below problem?
> 
> It was fine, just didn't think to mention it as was an exception of the Sourcery toolchain.

Ok, thanks for the confirmation!

> >In order to ask the assembler to accept these instructions, the
> >following commit was made back in 2008:
> >
> >? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/Makefile?id=80cec14a83ad0ad109d822b3f3482a379bc481ba
> >
> >However, it was reverted recently:
> >
> >? http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/compressed/Makefile?id=da94a829305f1c217cfdf6771cb1faca0917e3b9
> >
> >I am not sure how this last commit doesn't break your situation.
> 
> Interesting stuff. It's building 2.6.38.6, which benefits only from the first commit.

Ah, interesting.

> >So in other words, you mean that this wouldn't work on the target
> >platform. Hum, weird. Is this a part of U-Boot implemented in assembly,
> >or something compiled from C ?
> 
> Yes indeed. My belief is that _udivsi3 was pulled in with CLZs intact from the libgcc built and distributed with the Sourcery toolchain, rather than rebuilding a 4T arch version for the occasion.
> To be honest, I'm not sure if something like --sysroot can redirect this; I've never thought about it before.

The Sourcery toolchain has 3 sysroot: ARMv4, ARMv5, and ARMv7 Thumb2.
So if the proper -march=armv4t option is passed, it uses the ARMv4
sysroot.

> Sure. Didn't get far off making for the dev board it was based on, aside from memory tweaks to u-boot.
> I'm building the buildroot-2013.08.1 archive with 'make at91rm9200df_defconfig'.
> The u-boot clone is at commit 46ef4faed18196472eb95216b2f74c1397ecf024 from http://git.denx.de/u-boot.git.
> Then:
> ??? export PATH=$PATH:/data/at91rm9200/buildroot-2013.08.1/output/host/usr/bin/
> ??? export CROSS_COMPILE=arm-buildroot-linux-uclibcgnueabi-
> ??? make at91rm9200dvc_ram_config
> ??? make
> or:
> ??? export PATH=$PATH:/data/at91rm9200/buildroot-2013.08.1-thomas2/output/host/opt/ext-toolchain/bin/
> accordingly.

This is wrong. For external toolchains, you should *NOT* use the
compiler in host/opt/ext-toolchain/bin, but instead the compiler in
output/host/usr/bin. We create a toolchain wrapper which ensures that
the proper compiler flags are used. If you don't use this toolchain
wrapper, then it cannot work.

Have you been building both the kernel and u-boot outside of Buildroot?
Why not instruct Buildroot to build them instead?

Can you retry the external toolchain case, by using the compiler in
output/host/usr/bin instead?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] libgcc erroneously built as armv5 for arm920t(armv4t)

[Yann E. MORIN]

On 2013-11-02 16:39 +0100, Thomas Petazzoni spake thusly:
> Dear adam hussein\(!\),
> 
> On Thu, 26 Sep 2013 08:34:53 -0700 (PDT), adam hussein\(!\) wrote:
> 
> > I've been building the at91rm9200ek configuration of buildroot to get a toolchain I can use to build u-boot with some board specific configuration.
> > 
> > This is an ARM920T core chip with ARMv4T architecture??- later ARM9 series have ARMv5TE architecture (http://en.wikipedia.org/wiki/ARM9)
> > 
> > When gcc is built, or perhaps specifically libgcc only, it seems the selection of 920t/v4 architecture gets lost and v5 is used instead.
> > This means that when I use it to build u-boot, I find it has the __udivsi3 function using the illegal (to v4) instruction CLZ (count leading zeros).
> > 
> > The easiest workaround for me is to specify arm7tdmi and be done with it, but I'd like to try contributing a proper fix if possible.
> 
> Can you try the attached patch? Ideally, it would be nice if you could
> try it with two configurations:
> 
>  * With the internal toolchain backend
>  * With the Sourcery CodeBench 2013.05 external toolchain
> 
> and run it on real hardware.
> 
> Thanks a lot for your testing!
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

> From d3dca38af037a96fe45f94a303775c4f29b022b4 Mon Sep 17 00:00:00 2001
> From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Date: Sat, 2 Nov 2013 16:32:48 +0100
> Subject: [PATCH] arch: use BR2_GCC_TARGET_CPU on ARM
> 
> Currently, the ARM Config.in logic specifies values for
> --with-arch/-march and --with-tune/-mtune, but not for
> --with-cpu/-mcpu. However, this causes problems on ARMv4, because
> specifying --with-arch=armv4t isn't enough to make gcc generate ARMv4
> code: one should also pass --with-cpu=<some ARMv4 CPU>.
> 
> Moreover, since Buildroot is generally designed to generate code
> specifically for the configured target, it makes sense to give our own
> --with-cpu/-mcpu value instead of relying on the default value used by
> gcc, and only do small optimizations with -mtune.
> 
> Reported-by: Adam Hussein <kryme76@yahoo.com>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

> ---
>  arch/Config.in.arm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/Config.in.arm b/arch/Config.in.arm
> index c0fabb7..dd58744 100644
> --- a/arch/Config.in.arm
> +++ b/arch/Config.in.arm
> @@ -341,7 +341,7 @@ config BR2_ENDIAN
>  	default "LITTLE" if BR2_arm
>  	default "BIG"	 if BR2_armeb
>  
> -config BR2_GCC_TARGET_TUNE
> +config BR2_GCC_TARGET_CPU
>  	default "arm7tdmi"	if BR2_arm7tdmi
>  	default "arm7tdmi"	if BR2_arm720t
>  	default "arm7tdmi"	if BR2_arm740t
> -- 
> 1.8.1.2
> 

> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'