[gentoo-embedded] Embedded linux toolchain question

[gentoo-embedded] Embedded linux toolchain question

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everybody,

I initially posted this to a fellow dev who quite rightly pointed me in
the direction of this list.  I was hoping someone here might be able to
tell me if what I'm trying to achieve is feasible or not.

I've got some existing code for tying python to some system libraries,
and I was hoping to port it onto an embedded device, specifically an
ipod.  I've managed to source myself three old ipods (one 3rd Gen
and two 4th gen).  I've got ipodlinux happily running on one of them,
installed python, rebuilt the kernel using ipodlinux's pre-packaged
toolchain (which they seem to call arm-uclinux-elf/arm-elf).

I went to build the system libraries I needed and noticed the toolchain
didn't seem able to support shared objects, and hence the python
C-extension modules probably wouldn't compile either.  Attempting to
compile python natively also failed, so building the extension right in
to python looks difficult.

So, I started investigating building the toolchain on Gentoo using
crossdev.  So far I've successfully built arm-elf, but ipodlinux seems
to mention uclinux a lot and I haven't been able to build an
arm-unknown-uclinux target successfully.  Also, there seemed to be a few
posts about the gentoo arm-elf toolchain not supporting elf2flt (which
seemed necessary to reuse any existing ipodlinux applications).  I'm
also not certain if the arm-elf toolchain built on gentoo will let me
build shared objects or not.

That seems to leave me with the following options:

1. Try rebuilding everything using arm-elf on gentoo.
2. Try to build python using the binary-packaged toolchain.
3. Try to rewrite my code in C directly and statically link the system
libraries.

I was hoping someone here might be able to clear up some of the
confusion surrounding the right targets to use, and offer an opinion on
which option seems like the best one to pursue?

Thanks very much,

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHlnYvu7rWomwgFXoRArYPAKCBqh7v+FWKCqHIov/3qjKBvsEe0QCeJbGR
tdG/X8ITar2/OSUrGiBs/dQ=
=U9N8
-----END PGP SIGNATURE-----
-- 
gentoo-embedded@lists.gentoo.org mailing list

Re: [gentoo-embedded] Embedded linux toolchain question

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2609 bytes --]

On Tuesday 22 January 2008, Mike Auty wrote:
> I've got some existing code for tying python to some system libraries,
> and I was hoping to port it onto an embedded device, specifically an
> ipod.  I've managed to source myself three old ipods (one 3rd Gen
> and two 4th gen).  I've got ipodlinux happily running on one of them,
> installed python, rebuilt the kernel using ipodlinux's pre-packaged
> toolchain (which they seem to call arm-uclinux-elf/arm-elf).
>
> I went to build the system libraries I needed and noticed the toolchain
> didn't seem able to support shared objects, and hence the python
> C-extension modules probably wouldn't compile either.  Attempting to
> compile python natively also failed, so building the extension right in
> to python looks difficult.

i'm pretty sure the ipod lacks an mmu which means you can only use FLAT 
binaries.  which means no shared libraries.  the arm-elf toolchain is to 
build up code that will run without an operating system (like the kernel or a 
bootloader or a standalone app) while the arm-uclinux toolchain is used to 
build FLAT binaries which will run under Linux (with the mmu disabled).

what this means is that you only get static libraries and when producing the 
final executable, you have to link with -elf2flt which will produce a FLAT 
binary from the statically linked ELF.

you can test this theory by making a simple hello world app:
$ cat <<EOF > hello.c
#include <stdio.h>
int main(){printf("hello\n");}
EOF
$ arm-uclinux-elf-gcc hello.c -elf2flt -o hello

now get the "hello" binary onto the target and run it ... if it runs, it means 
what i said above is true.

ive run python on a Blackfin as FLAT, but no dynamic extensions obviously.

> So, I started investigating building the toolchain on Gentoo using
> crossdev.  So far I've successfully built arm-elf, but ipodlinux seems
> to mention uclinux a lot and I haven't been able to build an
> arm-unknown-uclinux target successfully.  Also, there seemed to be a few
> posts about the gentoo arm-elf toolchain not supporting elf2flt (which
> seemed necessary to reuse any existing ipodlinux applications).  I'm
> also not certain if the arm-elf toolchain built on gentoo will let me
> build shared objects or not.

by default, elf2flt is not enabled in any toolchain.  it's trivial to add:
 - roll a snapshot of the upstream elf2flt cvs
 - set ELF2FLT_VER in the binutils ebuild
but i dont have any toolchains integrated into Gentoo where i care about FLAT 
binaries, so i havent done any work beyond the infrastructure
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-embedded] Embedded linux toolchain question

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
| i'm pretty sure the ipod lacks an mmu ...

~From what I've read I think you're right, it has no mmu.

| ... which means no shared libraries. ...

Oh, that's a pity...  5:(

I think you're spot on with the elf2flt stuff too, so if there's no way
of getting shared objects going on the hardware, I guess I'll stick with
their pre-compiled toolchain and look into coding it up in C and making
a final executable instead.

Thanks very much for your response, it was easy to understand and much
appreciated...  5:)

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFHl5KGu7rWomwgFXoRAolcAKCgo932pbGl8qVB4Iwel4kBHHLD3wCfQ1SH
e98XMiwGJc+gtBO5k9bNRx4=
=Jxqz
-----END PGP SIGNATURE-----
-- 
gentoo-embedded@lists.gentoo.org mailing list

Re: [gentoo-embedded] Embedded linux toolchain question

[Christopher Friedt]

Depending on what you're doing, you could also build it in
as a module to the ipodlinux tree. Then at least you'd be able to
link to other code within ipodlinux.

They use a kernel-esque system of making modules. I'm a big fan ;-)

~/Chris

Mike Auty wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mike Frysinger wrote:
> | i'm pretty sure the ipod lacks an mmu ...
> 
> ~From what I've read I think you're right, it has no mmu.
> 
> | ... which means no shared libraries. ...
> 
> Oh, that's a pity...  5:(
> 
> I think you're spot on with the elf2flt stuff too, so if there's no way
> of getting shared objects going on the hardware, I guess I'll stick with
> their pre-compiled toolchain and look into coding it up in C and making
> a final executable instead.
> 
> Thanks very much for your response, it was easy to understand and much
> appreciated...  5:)
> 
> Mike  5:)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> 
> iD8DBQFHl5KGu7rWomwgFXoRAolcAKCgo932pbGl8qVB4Iwel4kBHHLD3wCfQ1SH
> e98XMiwGJc+gtBO5k9bNRx4=
> =Jxqz
> -----END PGP SIGNATURE-----
-- 
gentoo-embedded@lists.gentoo.org mailing list

Re: [gentoo-embedded] Embedded linux toolchain question

[Mike Auty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, I've identified it's related to floating point (and I'm trying
softfloat, which is probably why the other n810 instructions didn't run
into it).  I've tried setting a couple of autoconf overrides relating to
fenv.h and importing C99 functions into tr1/cfenv in namespace std::tr1,
but they don't seem to be passing through.

I've no idea what TR1 is, or why it's trying to import the fenv
functions, nor more importantly why it's failing to import them (given
that all configure's test programs seem to suggest everything's there).
 I've also tried the stable glibc (2.8_p20080602-r1) but with the same
results...

As ever, I'd be happy to hear any information anyone might have in this
area,

Mike  5:)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)

iEYEARECAAYFAkm9qNYACgkQu7rWomwgFXo+PACeI3Ui9wdYHQa6rP0ajcKTHB/t
Dj0An16h0Mwu3RIkmdea2TvdCFAt0SIH
=ugxg
-----END PGP SIGNATURE-----