[gentoo-embedded] compiling on openmoko

[gentoo-embedded] compiling on openmoko

[Previdi Roberto]

hello gentooers. I have installed gentoo on my openmoko gta02 with
good results, and i am using the native approach because the cross
compiling way seems too much complicated and much less fun.. Anyway
the 400 Mhz processor is really slow for compiling and i decided to
setup the distributed compilation with distcc, and it works well
ewithoutu much effort. The remaining problem is that each package
configure phase is very slow, i think because of the slow disk access
(it must read/write on the microsd card..).
so, is there any tested way to speed up everything? i used ext3 for
the partition filesystem, so i think that is slowing down everything..
i think that a ramdisk is very difficult to use because the device
have got really small ram (120 Mb!), so maybe a network filesystem
could do?
another option seems to be an autotools capability of using a
centralized cache file, and there was a portage feature "confcache",
but it seems to have been removed for incorrect behaviour.. anyone
know something about or has got good results with autotools caching?

thanks for any reply

-- 
roby

Re: [gentoo-embedded] compiling on openmoko

[Daniel Glaser]

Hi Roberto,
> hello gentooers. I have installed gentoo on my openmoko gta02 with
> good results, and i am using the native approach because the cross
> compiling way seems too much complicated and much less fun.. Anyway
> the 400 Mhz processor is really slow for compiling and i decided to
> setup the distributed compilation with distcc, and it works well
> ewithoutu much effort. The remaining problem is that each package
> configure phase is very slow, i think because of the slow disk access
> (it must read/write on the microsd card..).
> so, is there any tested way to speed up everything? i used ext3 for
> the partition filesystem, so i think that is slowing down everything..
> i think that a ramdisk is very difficult to use because the device
> have got really small ram (120 Mb!), so maybe a network filesystem
> could do?
>   

For embedded target tests I always mounted some NFS filesystem on the
/var/tmp directory. I can not estimate how it will behave with wireless
network, but wir wired one, the performance was quite good.

> another option seems to be an autotools capability of using a
> centralized cache file, and there was a portage feature "confcache",
> but it seems to have been removed for incorrect behaviour.. anyone
> know something about or has got good results with autotools caching?
>   

Do you mean ccache??? Need to install the package also named ccache and
add "ccache" to your FEATURES in make.conf

Cheers,
Daniel

Re: [gentoo-embedded] compiling on openmoko

[Nicola Mfb]

2009/4/23 Previdi Roberto <previdi.roberto@gmail.com>:
> ewithoutu much effort. The remaining problem is that each package
> configure phase is very slow, i think because of the slow disk access
> (it must read/write on the microsd card..).
> so, is there any tested way to speed up everything? i used ext3 for
> the partition filesystem, so i think that is slowing down everything..

I did not digged deeply but ext3 for me is too slow, I returned to
ext2 without trying to tune it.
Using NFS for /var/tmp is a good idea as it eliminates dangerous
write/rewrite to SD card,  but you cannot take the freerunner with you
for many hours/days/weeks!
I setupped a qemu-system-arm box on my server farm that compiles
binary packages for freerunner, it's slow but faster than freerunner,
when it finished I emerge -gK packages I need.

I hope I'll have the sheeva plug in the next month hoping I will be
able to compile very fast.

Ah! a problem with the qemubox is that I was not able to find an
updated kernel, so if you update glibc with new kernel-headers it will
happens strange things (eg. svn does not works anymore with neon).

Regards

     Nicola

Re: [gentoo-embedded] compiling on openmoko

[Maksim 'max_posedon' Melnikau]

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

On Thursday 23 April 2009 18:31:47 Previdi Roberto wrote:
> hello gentooers. I have installed gentoo on my openmoko gta02 with
> good results, and i am using the native approach because the cross
> compiling way seems too much complicated and much less fun.. Anyway
> the 400 Mhz processor is really slow for compiling and i decided to
> setup the distributed compilation with distcc, and it works well
> ewithoutu much effort. The remaining problem is that each package
> configure phase is very slow, i think because of the slow disk access
> (it must read/write on the microsd card..).
> so, is there any tested way to speed up everything? i used ext3 for
> the partition filesystem, so i think that is slowing down everything..
> i think that a ramdisk is very difficult to use because the device
> have got really small ram (120 Mb!), so maybe a network filesystem
> could do?
> another option seems to be an autotools capability of using a
> centralized cache file, and there was a portage feature "confcache",
> but it seems to have been removed for incorrect behaviour.. anyone
> know something about or has got good results with autotools caching?
>
> thanks for any reply
1. Why don't put hole rootfs to NFS? Boot from SHR, chroot, and let's emerge 
begin.
2. Wireless network on neo can be faster than wired. (usb1.1 net too slow)
3. swap file on nfs should work too.

BUT I really suggest cross compilation
1. more fun
2. it is the way, what all embedded should use
3. don't be lazy!


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

Re: [gentoo-embedded] compiling on openmoko

[Previdi Roberto]

On Thu, Apr 23, 2009 at 5:54 PM, Daniel Glaser <lists@chaintronics.com> wrote:
> For embedded target tests I always mounted some NFS filesystem on the
> /var/tmp directory. I can not estimate how it will behave with wireless
> network, but wir wired one, the performance was quite good.
I will try this. My connection is an "ethernet over usb" (driver
g_ether) with usb 1.0, so i don't know if it's quick enough, but i
will give it a try surely.

>> know something about or has got good results with autotools caching?
> Do you mean ccache??? Need to install the package also named ccache and
> add "ccache" to your FEATURES in make.conf
no, i was referring to this:
http://www.gnu.org/software/autoconf/manual/autoconf.html#Cache-Files
From what i know ccache is useful only if i recompile something
without changes to the source file neither the compile flags.
Practically never useful...

-- 
roby

Re: [gentoo-embedded] compiling on openmoko

[Nicola Mfb]

2009/4/23 Maksim 'max_posedon' Melnikau <maxposedon@gmail.com>:
[...]
> BUT I really suggest cross compilation
> 1. more fun

Yes :) the only reason for using native compilation too, is that  you
may ~arm and a lot of packages builds

> 2. it is the way, what all embedded should use

+10, gentoo has a big heart, and it may be patched to become a full
cross-compile environment, but I suppose there is a lot of work to do
and we need support from official portage and upstream. Every peoples
cross-compiling may help in this.

> 3. don't be lazy!

Hawnnn :)

Regards and tanks for your effort!

    Nicola

Re: [gentoo-embedded] compiling on openmoko

[wireless]

Nicola Mfb wrote:
> 2009/4/23 Previdi Roberto <previdi.roberto@gmail.com>:
>> ewithoutu much effort. The remaining problem is that each package
>> configure phase is very slow, i think because of the slow disk access
>> (it must read/write on the microsd card..).
>> so, is there any tested way to speed up everything? i used ext3 for
>> the partition filesystem, so i think that is slowing down everything..

> I did not digged deeply but ext3 for me is too slow, I returned to
> ext2 without trying to tune it.

You know, I do not even have one of these devices. However,
I have read about "squashfs" as part of the 2.6.29 kernel
offering. It's suppose to be the best thing, since sliced
bread, for embedded devices.


Have not got around to using it on any device, but, it
*may* be what your need....

http://www.squashfs-lzma.org/

Maybe others have experience with squashfs?

Re: [gentoo-embedded] compiling on openmoko

[Maksim 'max_posedon' Melnikau]

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

On Thursday 23 April 2009 23:16:37 wireless wrote:
> Nicola Mfb wrote:
> > 2009/4/23 Previdi Roberto <previdi.roberto@gmail.com>:
> >> ewithoutu much effort. The remaining problem is that each package
> >> configure phase is very slow, i think because of the slow disk access
> >> (it must read/write on the microsd card..).
> >> so, is there any tested way to speed up everything? i used ext3 for
> >> the partition filesystem, so i think that is slowing down everything..
> >
> > I did not digged deeply but ext3 for me is too slow, I returned to
> > ext2 without trying to tune it.
>
> You know, I do not even have one of these devices. However,
> I have read about "squashfs" as part of the 2.6.29 kernel
> offering. It's suppose to be the best thing, since sliced
> bread, for embedded devices.
>
>
> Have not got around to using it on any device, but, it
> *may* be what your need....
>
> http://www.squashfs-lzma.org/
>
> Maybe others have experience with squashfs?
1. squashfs-lzma isn't supported nether by vanilla or openmoko kernel
2. squashfs is *read-only* FS, it isn't what he need now, and actually it hard 
use it as rootfs, maybe just in pair with unionfs or aufs
3. compression is very good, portage in squashfs-gzip just ~60Mb


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

Re: [gentoo-embedded] compiling on openmoko

[Martin Guy]

On 4/23/09, wireless <wireless@tampabay.rr.com> wrote:
>  Maybe others have experience with squashfs?

In my 2002 analysis of the performance of compressed read-only
filesystems (for the purpose of Linux live CDs) squashfs won hands
down for both compression ratio and RAM/VM usage.
Mind you, that was in an I/O-bound, RAM-limited environment whereas in
this context the CPU needed for on-the-fly decompression may be
prohibitive.

    M