Gentoo Linux

[ryao]

I know that Ubuntu Linux images will not be available for these devices when they become available, but is there any word on Gentoo Linux images?

[doobedoobedo]

Yes Gentoo supports arm.emerge crossdev and read this.

[ShiftPlusOne]

I am sure Ubuntu images WILL be available, just not officially.

And yes, Gentoo works just fine on ARM. Be careful with Gentoo's embedded handbook though. Important steps are missing, but if you have enough experience, you'll figure it out.

[thebuell]

I, for one, will be porting Gentoo to the Raspberry PI as soon as I have one in my hands!

[ShiftPlusOne]

There's no porting to do, they already have ARM support. It should just be a matter of dropping in the multimedia drivers and the rest is per the handbook.

It would be nice to build an optimized stage3 tarball though. Right now, it's armv5, so it would be a good idea to change CHOST or build a new stage3 from scratch. The documentation is a bit sketchy on it, but it's not too hard.

But yeah, I'll probably be running gentoo.

[asb]

As a proof of concept it would be great to see a -mcpu=arm1176jzf-s with -mfpu=softfp build to see if there's an observable performance difference.

[thebuell]

From what I've read of the specs, having a VFP will make quite a big difference.

[asb]

Definitely some apps and benchmarks could be massively improved, it's more a question of whether the difference will be noticeable in general usage over a wider range of programs. That would give a helpful indication of whether it's worth compiling the whole base system, or whether instead you can just opt to use a few optimised libraries/programs.

[CERN]

"emerge -DNu world" is one command I would absolutely dread running on that little 700mhz ARM! Not to say that the Pi can't benefit from Gentoo, of course, but it certainly would be frustrating to keep it up-to-date.

And it'd be hectic on the memory card's MTBF! (even with distcc)

I think the coolest thing to do would be to create a Pi-oriented fork of Gentoo, where it retains portage, etc, but has an additional package manager for pre-Pi-compiled binary packages. Something like Sabayon, if Sabayon did ARM (it doesn't!). :p

If the preset USE flags on the binaries were sane, it would be pretty great. People who want more/less functionality could always use emerge (probably with distcc), but more or less, a binary package system could save a lot of compile time / save the need to be near computers set up for distributed compiling, at least for most things.

[thebuell]

The GPU onboard is very powerful, perhaps someone might do a Canadian cross compile using it to generate ARM binaries. Just a thought.

AS for memory cards, there's no evidence to suggest that it would wear out prematurely. It's just a case of finding good quality ones that will last.

[jamesh]

Quote from asb on September 20, 2011, 21:58
As a proof of concept it would be great to see a -mcpu=arm1176jzf-s with -mfpu=softfp build to see if there's an observable performance difference.

Hmm. I might try building the Debian kernel with that enabled (if it isn't already) - anyone have any ideas in the makefiles/config I would set that up - to save me looking for it?

[ShiftPlusOne]

I don't think it will be that easy.

[jamesh]

I'm presuming there are some global compiler options in the kernel build somewhere....is that not the case?

[thebuell]

I think you'll probably have to select the ARM processor in the kernel configuration *and* specifiy the compiler flags you need when building the kernel. Sometihng like

MAKEOPTS="-mpu=... ..." make kernel
should do the job...

[ShiftPlusOne]

If you know all the options you need, then yeah, it's not a problem (as long as the CPU shows up under 'system type').

[jamesh]

Been digging around the Arm makefiles. We already compile for Armv6 specifically, but not for the specific Arm device being used, and as far as I can see we don't set -mfloat-abi=softfp, although since the kernel is integer anyway I am not sure that would make any difference.

This is the c flags line for Arm, not sure whether -msoft-float is the best option, and it appears Thumb is enabled - not sure that is necessary. I think the following tuning is done

tune-$(CONFIG_CPU_V6) :=$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm)

KBUILD_CFLAGS +=$(CFLAGS_ABI) $(CFLAGS_THUMB2) $(arch-y) $(tune-y) $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) -msoft-float -Uarm

[doobedoobedo]

Quote from CERN on September 22, 2011, 00:41
I think the coolest thing to do would be to create a Pi-oriented fork of Gentoo, where it retains portage, etc, but has an additional package manager for pre-Pi-compiled binary packages. Something like Sabayon, if Sabayon did ARM (it doesn't!). :p

If the preset USE flags on the binaries were sane, it would be pretty great. People who want more/less functionality could always use emerge (probably with distcc), but more or less, a binary package system could save a lot of compile time / save the need to be near computers set up for distributed compiling, at least for most things.No need for a fork, emerge -k will pull in pre-compiled binary packages, emerge -b will build them. See man emerge.

[jamesh]

Actually, the only important bit in my last email is the tuning line - the other line isn't used.

So we might be able to get a slightly faster kernel by modding the tune line to exactly match the processor, and enable softfp

[Blars]

Actually, for gentoo you should enable hardfp not softfp. They are not binary compatable, but gentoo isn't about binary compatability. Debian armel uses softfp to be binary compatable with arms with no vfp.

[asb]

Blars: Is armel not using -mfpu=soft for compatibility with cores with no FP. -mfpu=softfp as I suggested means to use a floating point unit, but retain soft floating point calling conventions. Though yes, -mfpu=hard would be better still, but you sacrifice binary compatibility with normal armel binaries.

[jamesh]

Arm compiler options here...

http://gcc.gnu.org/onlinedocs/.....tions.html

[asb]

Aargh, I meant -mfloat-abi.

[PhilipJFry]

I've been using gentoo for nearly 10 years and find it difficult using anything else. Anyway if any one is interested I've compiled a very raspberry tuned gentoo. According to this page http://dev.gentoo.org/~armin76...../chost.xml the processor used on the raspberry pi is ARMv6ZK Subarchitecture so I've built using the CHOST armv6zk-unknown-linux-gnueabi. I've then recompiled the entire system using the the following CFLAGS -O2 -pipe -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard. It's running nicely on qemu at the moment, can't wait to try it on the real thing.

[thebuell]

Quote from PhilipJFry on October 17, 2011, 21:53
I've been using gentoo for nearly 10 years and find it difficult using anything else. Anyway if any one is interested I've compiled a very raspberry tuned gentoo. According to this page http://dev.gentoo.org/~armin76...../chost.xml the processor used on the raspberry pi is ARMv6ZK Subarchitecture so I've built using the CHOST armv6zk-unknown-linux-gnueabi. I've then recompiled the entire system using the the following CFLAGS -O2 -pipe -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard. It's running nicely on qemu at the moment, can't wait to try it on the real thing.

Do you have a bootable image and stages I can test out with my qemu? Thanks

[cb88]

will it be possible to get both hardfloat and softfloat versions of the graphics drivers? Because if not then you won't be able to do anything with 3D at reasonable speed on gentoo hardfloat.