[Buildroot] Building ARM with Soft-float

[Buildroot] Building ARM with Soft-float

[Ulf Samuelsson]

Tried the Integrator-926ejs default.
=>	This works:

Modify to use: "generic-arm" instead of "arm926ejs".

[Buildroot] Building ARM with Soft-float

[Ulf Samuelsson]

fre 2007-09-28 klockan 10:56 +0200 skrev Ulf Samuelsson:
> Tried the Integrator-926ejs default.
> =>	This works:
> 

Beeing trying the ARM integrator softfloat the whole day.

Vanilla configuration works.
generic-arm, instead of arm926ejs works

oabi, instead of eabi, generates a new problem
which was not present a week ago.
The C compiler seems to be built with EABI...

My configuration is as follows
> grep ABI .config
BR2_ARM_OABI=y
# BR2_ARM_EABI is not set
> grep ABI toolchain_build_arm_nofpu/uClibc-0.9.29/.config
CONFIG_ARM_OABI=y
# CONFIG_ARM_EABI is not set
> grep abi .config
BR2_GNU_TARGET_SUFFIX="uclibc-linux-gnueabi"

I compile the file a.c:  

> cat a.c
#ifdef  __ARM_EABI__
#warning "EABI"
#endif
> ./arm-uclibc-linux-gnueabi-gcc a.c
a.c:2:2: warning: #warning "EABI"

Why is this?

This results in a failure, since
uClibc/include/bits/sysnum.h is generated from 
<kernel-header>/asm/arch/unistd.h
and if __ARM_EABI__ is set, then 
the Syscall numbers are wrong, and the 
_NR_syscall definition is not (base+113)
as it was one week ago
#define _NR_syscall  (<base>+113)
instead it is
#define _NR_syscall  _NR_syscall

so the build of syscalls.c in uClibc fails.

I can't see anything in the toolset which configures
the ABI for the compiler.



BR
Ulf Samuelsson



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

[Buildroot] Building ARM with Soft-float

[Bernhard Fischer]

On Fri, Sep 28, 2007 at 10:56:52AM +0200, Ulf Samuelsson wrote:
>Tried the Integrator-926ejs default.
>=>	This works:
>
>Modify to use: "generic-arm" instead of "arm926ejs".

Ulf, what are you referring to (you didn't follow-up on another mail)?
My sample integrator926t_defconfig or something else?

I'm certainly not using generic-arm with the 926t.. look at the
abovementioned config file in target/device/ARM/

[Buildroot] Building ARM with Soft-float

[Bernhard Fischer]

On Fri, Sep 28, 2007 at 06:28:08PM +0200, Ulf Samuelsson wrote:
>fre 2007-09-28 klockan 10:56 +0200 skrev Ulf Samuelsson:
>> Tried the Integrator-926ejs default.
>> =>	This works:
>> 
>
>Beeing trying the ARM integrator softfloat the whole day.
>
>Vanilla configuration works.
>generic-arm, instead of arm926ejs works
>
>oabi, instead of eabi, generates a new problem
>which was not present a week ago.
>The C compiler seems to be built with EABI...

double-check, triple-check your BR2_GNU_TARGET_SUFFIX

And i'm not doing OABI ;)
>
>My configuration is as follows
>> grep ABI .config
>BR2_ARM_OABI=y
># BR2_ARM_EABI is not set
>> grep ABI toolchain_build_arm_nofpu/uClibc-0.9.29/.config
>CONFIG_ARM_OABI=y
># CONFIG_ARM_EABI is not set
>> grep abi .config
>BR2_GNU_TARGET_SUFFIX="uclibc-linux-gnueabi"

yea, that'd be it. Everything is fine.
>
>I compile the file a.c:  
>
>> cat a.c
>#ifdef  __ARM_EABI__
>#warning "EABI"
>#endif
>> ./arm-uclibc-linux-gnueabi-gcc a.c
>a.c:2:2: warning: #warning "EABI"
>
>Why is this?

See above
>
>This results in a failure, since
>uClibc/include/bits/sysnum.h is generated from 
><kernel-header>/asm/arch/unistd.h
>and if __ARM_EABI__ is set, then 
>the Syscall numbers are wrong, and the 
>_NR_syscall definition is not (base+113)
>as it was one week ago
>#define _NR_syscall  (<base>+113)
>instead it is
>#define _NR_syscall  _NR_syscall
>
>so the build of syscalls.c in uClibc fails.
>
>I can't see anything in the toolset which configures
>the ABI for the compiler.

Please look more carefully (see above)

[Buildroot] Building ARM with Soft-float

[Ulf Samuelsson]

fre 2007-09-28 klockan 18:29 +0200 skrev Bernhard Fischer:
> On Fri, Sep 28, 2007 at 10:56:52AM +0200, Ulf Samuelsson wrote:
> >Tried the Integrator-926ejs default.
> >=>	This works:
> >
> >Modify to use: "generic-arm" instead of "arm926ejs".
> 

Bloody useless "evolution" mail program which will send a mail 
directly if you happen to press the CTRL-Return combination...

Was not intended to be sent in this shape...
/ulf


> Ulf, what are you referring to (you didn't follow-up on another mail)?
> My sample integrator926t_defconfig or something else?
> 
> I'm certainly not using generic-arm with the 926t.. look at the
> abovementioned config file in target/device/ARM/

[Buildroot] Building ARM with Soft-float

[Ulf Samuelsson]

fre 2007-09-28 klockan 19:01 +0200 skrev Bernhard Fischer:
> On Fri, Sep 28, 2007 at 06:28:08PM +0200, Ulf Samuelsson wrote:
> >fre 2007-09-28 klockan 10:56 +0200 skrev Ulf Samuelsson:
> >> Tried the Integrator-926ejs default.
> >> =>	This works:
> >> 
> >
> >Beeing trying the ARM integrator softfloat the whole day.
> >
> >Vanilla configuration works.
> >generic-arm, instead of arm926ejs works
> >
> >oabi, instead of eabi, generates a new problem
> >which was not present a week ago.
> >The C compiler seems to be built with EABI...
> 
> double-check, triple-check your BR2_GNU_TARGET_SUFFIX
> 
> And i'm not doing OABI ;)
> >
> >My configuration is as follows
> >> grep ABI .config
> >BR2_ARM_OABI=y
> ># BR2_ARM_EABI is not set
> >> grep ABI toolchain_build_arm_nofpu/uClibc-0.9.29/.config
> >CONFIG_ARM_OABI=y
> ># CONFIG_ARM_EABI is not set
> >> grep abi .config
> >BR2_GNU_TARGET_SUFFIX="uclibc-linux-gnueabi"
> 
> yea, that'd be it. Everything is fine.
> >


You mean the gcc look at its invocation name to determine
what it should do.
Seems stupid to me.
What happens if you just call it arm-linux-gcc or even gcc?

BTW; there are a lot of warning messages about
calling the tools

<arch>-linux-uclibc-<tool>.

Should they not be called <arch>-uclibc-linux-<tool>?

BR
Ulf Samuelsson


 

[Buildroot] Building ARM with Soft-float

[Bernhard Fischer]

On Fri, Sep 28, 2007 at 11:08:13PM +0200, Ulf Samuelsson wrote:
>fre 2007-09-28 klockan 19:01 +0200 skrev Bernhard Fischer:
>> On Fri, Sep 28, 2007 at 06:28:08PM +0200, Ulf Samuelsson wrote:
>> >fre 2007-09-28 klockan 10:56 +0200 skrev Ulf Samuelsson:
>> >> Tried the Integrator-926ejs default.
>> >> =>	This works:
>> >> 
>> >
>> >Beeing trying the ARM integrator softfloat the whole day.

>> >oabi, instead of eabi, generates a new problem
>> >which was not present a week ago.
>> >The C compiler seems to be built with EABI...

>> >BR2_GNU_TARGET_SUFFIX="uclibc-linux-gnueabi"

>You mean the gcc look at its invocation name to determine
>what it should do.

No notion of the invocation name there.

http://gcc.gnu.org/install/

>Seems stupid to me.

Well, it isn't :P
If you disagree, http://gcc.gnu.org/bugs.html

>What happens if you just call it arm-linux-gcc or even gcc?

You can call it however you like. The drivers follow a somewhat stricter
layout but are hidden from users anyway.
>
>BTW; there are a lot of warning messages about
>calling the tools

I don't understand this.

><arch>-linux-uclibc-<tool>.
>
>Should they not be called <arch>-uclibc-linux-<tool>?

I don't think so. Look at your staging_dir/usr/bin/*

[Buildroot] Buildroot filesystem files' ownership

[Leonid]

Hi:

Buildroot documentation claims that entire filesystem can be created
without root priviliges and this is true. However as a result all files
in filesystem, residing in TARGET_DIR (even device nodes) belongs to
USER, not to root. While trying to NFS into such filesystem, it doesn't
work (no console output). I have expected that files which must belong
to root will be "massaged" by fakeroot but this doesn't happen at least
for TARGET_DIR.

When I change ownership of all files in the filesystem to root

sudo chown -Rf root.root .

NFS is working fine. Questions:

1) May be filesystem in the TARGET_DIR is not supposed to be used as
real target FS - one must use .ext, .jffs2,... images? Where I get
filesystem for NFS then?

2) What files in the filesystem MUST belong to root - I suspect my
changing all of them to root is overkill.

Thanks,

Leonid. 

[Buildroot] Buildroot filesystem files' ownership

[Bernhard Fischer]

On Fri, Sep 28, 2007 at 04:24:40PM -0700, Leonid wrote:
>Hi:
>
>Buildroot documentation claims that entire filesystem can be created
>without root priviliges and this is true. However as a result all files
>in filesystem, residing in TARGET_DIR (even device nodes) belongs to
>USER, not to root. While trying to NFS into such filesystem, it doesn't
>work (no console output). I have expected that files which must belong
>to root will be "massaged" by fakeroot but this doesn't happen at least
>for TARGET_DIR.
>
>When I change ownership of all files in the filesystem to root

When you do this, you can no longer build as a user.
>
>sudo chown -Rf root.root .
>
>NFS is working fine. Questions:
>
>1) May be filesystem in the TARGET_DIR is not supposed to be used as
>real target FS - one must use .ext, .jffs2,... images? Where I get
>filesystem for NFS then?

Select either of the target filesystem outputs (e.g. tar) unpack that to
your preferred nfs root and use that copy. I don't remember offhand if
nfs has an option to make all exported files owned 0.0, check the
manpage.

>
>2) What files in the filesystem MUST belong to root - I suspect my
>changing all of them to root is overkill.

the device-nodes should probably initially be owned by root

HTH,