[Buildroot] USE_BX=n on armv4 generate bx instruction

["|~۞~| demoniark |~۞~| " <demoniark@gmail.com>]

Thanks for your answer, and sorry for the late reply but I ran through a
lot of compiling during the last days to understand exactly what is h
appening.
I'm now using the buildroot version that do you recommended to me. Without
any changes the result is not the one I expected...

On my last try I wrote a quick patch[0] and pasted it in
buildroot-2014.02-rc1/package/uclibc/
0.9.33.2/uclibc-0999-thumb-interwork-for-armv4.patch.
I changed buildroot BR2_TARGET_OPTIMIZATION="-pipe" for
BR2_TARGET_OPTIMIZATION="-pipe -mno-thumb-interwork -marm
-D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=fa526 -msoft-float"
and set uclibc flag UCLIBC_EXTRA_CFLAGS="-march=armv4 -mtune=fa526"

The results are close to those expected. I ran some  tools to check 'bx'
and 'thumbs' instructions (arm-linux-objdump -S,  readelf -d):
% grep 'bx\|Disassembly' *.asm
busybox.asm:Disassembly of section .text:
busybox.asm:   81764:    e12fff13     bx    r3
busybox.asm:   81770:    e12fff1e     bx    lr
[...]
libc.asm:Disassembly of section .text:
libc.asm:   42484:    e12fff1e     bx    lr
libc.asm:   424c4:    e12fff1e     bx    lr
libc.asm:   42970:    e12fff1e     bx    lr
libc.asm:   42d90:    e12fff1e     bx    lr
(full output[1])

I think this is not the right way to proceed, but it allowed me to see the
different options to pass to the toolchain/CFLAGS wich make the system
operational.
So when my nas4220 boots on this generated kernel and root filesystem
everythink seems to be ok (except drivers but that's another story).
    Welcome to Buildroot
    nas login: root
    Password:
    # uname -a
    Linux nas 3.12.10 #1 Tue Mar 4 01:04:41 UTC 2014 armv4l GNU/Linux
    # busybox | head -1
    BusyBox v1.22.1 (2014-03-03 21:10:48 UTC) multi-call binary.
    #

From what I understand here buildroot does not pass  '-mno-thumb-interwork'
option to gcc when compiling for armv4 cpu. I tried to wrote a patch for
builroot but without success. I assume that uclibc needs to be patched to
because buildroot CFLAGS doesn't seem to affect uclibc CFLAGS.

Is the approach correct? Does anyone has a clue on how to proceed?

Thanks in advance.

Here are my config files:
uclibc:
https://paste.ydct.org/?6e6c16ca059e6f1f#xXIFmMsmGE1T4Q+ym2fxKx2m+JmVJeqqLOhf2Mkb9JU=
kernel:
https://paste.ydct.org/?5f6bc06098ca8cef#wzu7HLm1pwhEFTmfkJPCq+bAgD7qO/vIalSH+C+5/Co=
busybox:
https://paste.ydct.org/?8d240d1975706482#P4783MWLYaI1jAAmBYdhyDrfrP9QNqJRl4OsxEscpa0=
buildroot:
https://paste.ydct.org/?d028b977eaae5c8c#tW5YeRIj1WWfonL7UNIdV9JJcXiN1aPdCqt9S1d3Jd4=

[0] http <http://paste.debian.net/hidden/5e5c72f6/>
://paste.debian.net/hidden/5e5c72f6/<http://paste.debian.net/hidden/5e5c72f6/>
[1] http://paste.debian.net/hidden/1f9230ae/


2014-02-14 8:42 GMT+00:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Dear |~?~| demoniark |~?~|,
>
> On Fri, 14 Feb 2014 00:02:18 +0100, |~?~| demoniark |~?~| wrote:
> > I'm tring to self compile a system for my ib-nas-4220-b which embed a
> fa526
> > cpu.
> > I'm using buildroot v2013.11 with compiling kernel 3.12.
> > My configs files are here:
> > buildroot config:
> >
> https://paste.ydct.org/?d7d79d21da6e34dc#cIrSeqbdDpbAvA3d55DoH36Eb417bDysMEjmtaYaaZU=
> > busybox config:
> >
> https://paste.ydct.org/?a1a61121ae4be30f#cBDY3H89/m4owEwtCO0Mv6nI0WFhScBuwJ92V/zyOPE=
> > kernel config:
> >
> https://paste.ydct.org/?a3035f3c2a153083#w7dWY4LuBgoSMXDWn7alrIuueR1x+Gc75Rt6nlZLS2I=
> > uclibc config:
> >
> https://paste.ydct.org/?91bbe608fe4be481#JRt/Zd/1I5VOmyYldmUK+2L1fxM0sSHDbplmZxGXPxM=
> > When I try to boot my kernel with internet found filesystem, the nas
> boots.
> > When the nas boot with the filesystem compiled with buildroot I get:
> > [    4.630000] init (1): undefined instruction: pc=b6f0df40
> > [    4.640000] Code: e5803180 e5802188 e580c18c e8bd4038 (e12fff1e)
> > [    4.650000] Kernel panic - not syncing: Attempted to kill init!
> > exitcode=0x00000004
> > [    4.650000]
> > [    4.650000] CPU: 0 PID: 1 Comm: init Not tainted 3.12.1 #2
> > [    4.650000] Backtrace:
> > [    4.650000] [<c001119c>] (dump_backtrace+0x0/0x10c) from [<c001153c>]
> > (show_stack+0x18/0x1c)
> > [    4.650000]  r6:c7825be0 r5:c0c78de0 r4:c072c728 r3:00000204
> > [    4.650000] [<c0011524>] (show_stack+0x0/0x1c) from [<c05a3880>]
> > (dump_stack+0x20/0x28)
> > [    4.650000] [<c05a3860>] (dump_stack+0x0/0x28) from [<c059f8e0>]
> > (panic+0x80/0x1d4)
> > [    4.650000] [<c059f860>] (panic+0x0/0x1d4) from [<c001bf94>]
> > (do_exit+0x388/0x75c)
> > [    4.650000]  r3:c7829c40 r2:c7825cd0 r1:00000004 r0:c065552f
> > [    4.650000]  r7:c0c78e10
> > [    4.650000] [<c001bc0c>] (do_exit+0x0/0x75c) from [<c001c428>]
> > (do_group_exit+0x88/0xc4)
> > [    4.650000]  r7:c7829c40
> > [    4.650000] [<c001c3a0>] (do_group_exit+0x0/0xc4) from [<c0026018>]
> > (get_signal_to_deliver+0x40c/0x458)
> > [    4.650000]  r4:c7826000 r3:80000013
> > [    4.650000] [<c0025c0c>] (get_signal_to_deliver+0x0/0x458) from
> > [<c059f3c4>] (do_signal+0xa0/0x3c0)
> > [    4.650000] [<c059f324>] (do_signal+0x0/0x3c0) from [<c0010f28>]
> > (do_work_pending+0x64/0xbc)
> > [    4.650000] [<c0010ec4>] (do_work_pending+0x0/0xbc) from [<c000e9dc>]
> > (work_pending+0xc/0x20)
> > [    4.650000]  r6:ffffffff r5:60000010 r4:b6f0df40 r3:c7825be0
> > With objdump fautly code e12fff1e appears to be the assembly 'bx'
> > instruction. However, due to arm.com (
> >
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0204j/Cihfddaf.html#Cihiiajh
> > ),
> > I suppose that this instruction is not implemented in my farraday 526
> > processor (an old armv4).
> > In reference of this patch:
> >
> http://git.buildroot.net/buildroot/commit/?id=9474421da36d8602f56b84b150e4cf4c78e788b3
> > [*
> > Fix uClibc USE_BX logic, it was always on, this would break the new
> > FA526/626 support and broke StrongARM since it's a v4 core.] I understood
> > it was corrected.
> > So my question is next: what i'm doing wrong/missing?
>
> Thanks a lot for your very detailed report, great to see people
> reporting precise bugs, with all the details (configuration files,
> Buildroot version, things that are happening, and the beginning of an
> analysis).
>
> Would you mind retrying with 2014.02-rc1, which has been recently
> released? It might be possible that the commit
>
> http://git.buildroot.net/buildroot/commit/arch/Config.in.arm?id=d3539dd53bf9e37538fd4d8b89783a11fded119f
> ,
> which has been merged after 2013.11, is fixing the problem you're
> reporting.
>
> If not, then please get back to us again, and I'll have a look.
>
> Thanks again for your report!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140305/65fef6b6/attachment.html>