Embedded Handbook (5)(b) clarification

I'd like to get some clarification on the Embedded Handbook, 
particularly Chapter 5, subsection 5(b) "Filesystem Setup"

I'm trying to cross-compile on an AMD64 for two Marvel ARM architectures:
a) SheevaPlug which as the ARMv5TE without a numeric coprocessor "softfloat"
     http://en.wikipedia.org/wiki/SheevaPlug

b) OpenRD Client which has the ARMv5TE
    http://globalscaletechnologies.com/t-openrdcdetails.aspx#features

I previously had problems trying to install and work my cross compiler, 
so I simply rebuilt my AMD box and see that the Embedded Handbook has 
recently been updated in September, 2009.  I had considerable help from 
Mike Frysinger back in May and June on IRC, but I lost my chat logs due 
to a crash on Windows which I was going to use to refer to and to 
reconstruct what I had learned.  I haven't had the time to devote to 
this project until now and find myself not fully understanding the 
instructions.

From 
http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=5

vvvvvvvvvv
5.b. Filesystem Setup

Cross-compiling a system generally involves two directory trees. The 
first is where all development files are normally installed. This is 
your sysroot. The other tree is where only your runtime files are 
installed. You emerge all of your fun packages into your sysroot 
(without trimming down any files), and then either install via binary 

Re: Embedded Handbook (5)(b) clarification

From: John Poole <jlpoole@...>
Subject: [gentoo-embedded] Embedded Handbook (5)(b) clarification
Date: Mon, 05 Oct 2009 19:18:08 -0700

> I'd like to get some clarification on the Embedded Handbook,
> particularly Chapter 5, subsection 5(b) "Filesystem Setup"

[cut]
> 
> From
> http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=5
> 
> vvvvvvvvvv
> 5.b. Filesystem Setup
> 
> Cross-compiling a system generally involves two directory trees. The
> first is where all development files are normally installed. This is
> your sysroot. The other tree is where only your runtime files are
> installed. You emerge all of your fun packages into your sysroot
> (without trimming down any files), and then either install via binary
> packages or copying files by hand all the stuff you need in your
> runtime tree.
> 
> The common convention is to use your /usr/CTARGET/ tree as your
> sysroot as the include/library directories in this tree are already
> encoded into the gcc cross-compiler for searching. You could use
> another directory and then add custom -I/-L paths to your
> CPPFLAGS/LDFLAGS, but this has historically proven to be
> problematic. Yes, it works most of the time, but the corner cases are
> why this method is discouraged. In the embedded handbook, we'll assume

bootable iso9660 CD without initrd

Hi,

I'm trying to prototype & demo a x86 embedded system on a virtual 
machine with a RO root file system.  I thought of making a bootable CD 
to do it.  I'm trying to do it without a initrd to keep the footprint to 
a minimum, the kernel boots but getting the error of init unable to open 
the initial console.  I suspect the problem is that iso9660 can not 
store /dev/console correctly as a character device.

Does anyone know if this is possible, and if there are examples anywhere 
on how to do it?

Thanks.

Re: bootable iso9660 CD without initrd

Karl Hiramoto wrote:
> Does anyone know if this is possible, and if there are examples
> anywhere on how to do it?

Not possible I think - you need a root device with a fully functional
filesystem. Maybe you can hack something up with UMSDOS (IIRC) but I
doubt it. If you need a CD, make a minimal initramfs which mounts
your ro filesystem using loopback.

//Peter

Re: bootable iso9660 CD without initrd

Peter Stuge wrote:
> Karl Hiramoto wrote:
>   
>> Does anyone know if this is possible, and if there are examples
>> anywhere on how to do it?
>>     
>
> Not possible I think - you need a root device with a fully functional
> filesystem. Maybe you can hack something up with UMSDOS (IIRC) but I
> doubt it. If you need a CD, make a minimal initramfs which mounts
> your ro filesystem using loopback.

Actually with a few more tries i got it to work, got busybox running now.

my iso9660 loop:

 ls -la /mnt/tmp/dev/
total 8
drwxr-xr-x  3 root root  2048 2009-10-06 15:47 .
drwxr-xr-x 20 root root  4096 2009-10-07 20:11 ..
crw-rw-rw-  1 root root 5,  1 2009-10-07 20:11 console
lrwxrwxrwx  1 root root     8 2009-10-05 19:43 log -> /tmp/log
drwxr-xr-x  2 root root  2048 2009-10-05 19:43 pts
crw-rw-rw-  1 root root 4, 64 2009-10-07 20:11 ttyS0
crw-rw-rw-  1 root root 4, 65 2009-10-07 20:11 ttyS1

Thanks,

Karl

(unknown)

failing to arm...-emerge python-2.6.3

Hello,

I'm new to this list and also relatively new (several weeks) to
cross-compiling.
I'm trying to create a Gentoo Base system for a Netus G20 (mounted on a
Fox Board G20, http://netus.acmesystems.it/doku.php ).

It's mostly done, but some last ebuilds fail. So I hope, someone here on
this list might help me.
The output of armv5tejl-softfloat-linux-gnueabi-emerge -pv system:
http://php-pro.de/tmp/emerge-system.txt
armv5tejl-softfloat-linux-gnueabi-emerge --info:
http://php-pro.de/tmp/info.txt
And the build log of the "bad guy":
http://php-pro.de/tmp/python-2.6.3-arm-build.log
On the host system, also python 2.6.3 is installed.

one second question is: will I need libtool to be able to continue
emerging on the arm system? it depends on libperl, and libperl also
won't cross-compile and so I would like to do that later on the
arm-system ...

Thanks in advance,
Michael

Re: failing to arm...-emerge python-2.6.3

2.6.3 doesn't compile for me, 2.6.2-r2 does.  i don't know if you have
an overlay for this, but the 2.6.2-r2 out of the openmoko overlay builds
and runs fine.  i think you've already noted that you need to have the
same python version built on target as on host.

i've no idea about libperl, don't want to go there :>

-david

M. Buchzik wrote:
> Hello,
>
> I'm new to this list and also relatively new (several weeks) to
> cross-compiling.
> I'm trying to create a Gentoo Base system for a Netus G20 (mounted on a
> Fox Board G20, http://netus.acmesystems.it/doku.php ).
>
> It's mostly done, but some last ebuilds fail. So I hope, someone here on
> this list might help me.
> The output of armv5tejl-softfloat-linux-gnueabi-emerge -pv system:
> http://php-pro.de/tmp/emerge-system.txt
> armv5tejl-softfloat-linux-gnueabi-emerge --info:
> http://php-pro.de/tmp/info.txt
> And the build log of the "bad guy":
> http://php-pro.de/tmp/python-2.6.3-arm-build.log
> On the host system, also python 2.6.3 is installed.
>
> one second question is: will I need libtool to be able to continue
> emerging on the arm system? it depends on libperl, and libperl also
> won't cross-compile and so I would like to do that later on the

Re: failing to arm...-emerge python-2.6.3

I'll fix python in openmoko overlay soon(in next few days)

On 10/18/09, David Ford <david@...> wrote:
> 2.6.3 doesn't compile for me, 2.6.2-r2 does.  i don't know if you have
> an overlay for this, but the 2.6.2-r2 out of the openmoko overlay builds
> and runs fine.  i think you've already noted that you need to have the
> same python version built on target as on host.
>
> i've no idea about libperl, don't want to go there :>
>
> -david
>
> M. Buchzik wrote:
>> Hello,
>>
>> I'm new to this list and also relatively new (several weeks) to
>> cross-compiling.
>> I'm trying to create a Gentoo Base system for a Netus G20 (mounted on a
>> Fox Board G20, http://netus.acmesystems.it/doku.php ).
>>
>> It's mostly done, but some last ebuilds fail. So I hope, someone here on
>> this list might help me.
>> The output of armv5tejl-softfloat-linux-gnueabi-emerge -pv system:
>> http://php-pro.de/tmp/emerge-system.txt
>> armv5tejl-softfloat-linux-gnueabi-emerge --info:
>> http://php-pro.de/tmp/info.txt
>> And the build log of the "bad guy":
>> http://php-pro.de/tmp/python-2.6.3-arm-build.log
>> On the host system, also python 2.6.3 is installed.
>>

Re: failing to arm...-emerge python-2.6.3

i have a long list of this-makes-it-work that i wrote up while i was
emerging everything for my 'moko

Maksim 'max_posedon' Melnikau wrote:
> I'll fix python in openmoko overlay soon(in next few days)
>