Gentoo on Raspberry Pi 2

Message

el_Salmon · Post by **el_Salmon** » Mon Feb 09, 2015 8:08 am

Hi,

I'm ordering a Raspberry Pi 2 to replace my old RPi 1, that runs Raspbian (Debian) currently. I'm thinking to begin to use Gentoo Linux but I'm not sure if the new model be able to compile ebuilds itself without distcc. I'm suppose it does, because is a Quad-core 900 MHz with 1 GB DDR2 RAM. What's your experience or technical opinion?

Roman_Gruber · Post by **Roman_Gruber** » Mon Feb 09, 2015 8:18 am

Nope. AFAIK its arm, like my smartphone and that architecture has not much calc power.

Code: Select all

cat /proc/cpuinfo 
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     T9500  @ 2.60GHz
stepping	: 6
microcode	: 0x60f
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips	: 5189.68
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

processor	: 1
vendor_id	: GenuineIntel
cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     T9500  @ 2.60GHz
stepping	: 6
microcode	: 0x60f
cpu MHz		: 800.000
cache size	: 6144 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
apicid		: 1
initial apicid	: 1
fpu		: yes
fpu_exception	: yes
cpuid level	: 10
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips	: 5189.68
clflush size	: 64
cache_alignment	: 64
address sizes	: 36 bits physical, 48 bits virtual
power management:

You may compare my antiquie cpu with the bogomips with your newly bought pi and you will may understand why it does not make much sense.

and it does not matter what you push on your pi, afaik debian is a binary distro and afaik you only put a binary distro on a pi.
so you can crosscompile and put a binary "gentoo" on that pi.
but compiling on the pi could be fun when you have much time. does it makes sense, i doubt.

Do not get fooled by fancy arm MHZ Numbers, they say nothing.
The architecture + bogomips determines the calculations.

snkmoorthy · Post by **snkmoorthy** » Mon Feb 09, 2015 11:48 am

http://wiki.gentoo.org/wiki/Raspberry_Pi

use crossdev on your powerful machine and compile for armv6[7] to your hearts content. Native compilations will be slow.

Post by **Leio** » Mon Feb 09, 2015 1:32 pm

BogoMIPS is NOT usable for performance comparison between different CPUs. Especially not with ARM vs not ARM - http://en.wikipedia.org/wiki/BogoMips#T ... sed_delays

With RPi2 now being quad-core, native compilation isn't that slow; and together with --jobs=n or something, to battle slow single core configure runs, it shouldn't be all that bad. Of course at least distcc is hugely desirable still.

I didn't find any RPi2 specific material in our wiki page yet, so keep that in mind (CFLAGS, etc). But most other things are equal, including graphics stuff.
I'm setting up a full graphical system on RPi2 with Gentoo now, so happy to share notes, mostly via IRC. #gentoo-embedded or #rpi-gentoo channel or something.

Code: Select all

# cat /proc/cpuinfo  # without overclocking config
processor	: 0
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 1
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 2
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

processor	: 3
model name	: ARMv7 Processor rev 5 (v7l)
BogoMIPS	: 38.40
Features	: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xc07
CPU revision	: 5

Hardware	: BCM2709
Revision	: a01041
Serial	: <snipped>

Roman_Gruber · Post by **Roman_Gruber** » Tue Feb 10, 2015 7:39 pm

I read about today taht the cpu gets full utilization when playing fullhd videos. i do not trust much about golem.de knowledge base at all.

I am interested in user expierence here.

The hardware could be fun for some small projects though I wonder if I can find really a use case for it

1clue · Post by **1clue** » Tue Feb 10, 2015 7:51 pm

I tried Gentoo on a model b+ for awhile. Never got a working kernel, I robbed the one from Raspbian and used that mostly.

A kernel compile on a B+ is 10+ hours unless something went wrong. If you can avoid doing a clean, subsequent compiles are quicker. First time I've ever spent less time configuring the kernel than compiling it on Gentoo. Back in the pentium days I could, because the kernel was a lot simpler and CPUs slower than the pi.

I also had tried to set up Gentoo for distcc but never got it to work from the pi.

You're using armv7 where I was using armv6, so that might make a difference by itself.

My opinion is that if you're doing this for fun and have lots of time and patience, then it might be worthwhile. If you actually want to use the pi for a project and don't need an extremely customized install then it's probably better to trim down/modify some other distro.

Post by **Leio** » Tue Feb 10, 2015 7:51 pm

CPU utilization ought to be in the 20% area of one core for 720p/1080p playback. At least so it was with the weaker model, and all the video bits are still the same, just with different/more memory.
If it's full utilization, they are doing something wrong and aren't using acceleration via OpenMAX properly.

Post by **Leio** » Tue Feb 10, 2015 9:12 pm

Setting up distcc is trivial with portage on rpi and crossdev on the helper machine.
Just did a toolchain for rpi2 to my desktop today

Code: Select all

crossdev --target armv7a-hardfloat-linux-gnueabi

20 minutes later and all done.

Now I just need to install distcc on rpi2, add it to FEATURES, configure hosts, increase some MAKEOPTS and good to go. Though I have distcc on the amd64 already all set up, otherwise there is some more work there.

Though currently going native only and things speed along quickly for my ~arm upgrades, it seems. Will get to webkit-gtk and the likes soon enough

Right now I'm using

CFLAGS="-O2 -pipe -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -mtls-dialect=gnu2"

as the basis for RPi2, as far as CFLAGS are concerned, btw. (I don't know about the tls-dialect exactly, that's what -mcpu=native seems to enable with =gnu, gcc man page suggests gnu2 might be better if I have new enough toolchain, which is very likely to be the case).

Kernel compile on a big host is trivial with the appropriate env var that just makes everything a given CHOST, but I don't bother with that either for now and simply grab prebuilt ones from git clone https://github.com/raspberrypi/firmware.git (kernel7.img) together with all the other boot files and the modules directory to /lib/modules too. Something to tune much much later in my case.

keet · Post by **keet** » Sat Feb 14, 2015 8:50 pm

I just got my Raspberry Pi 2. I'm thinking of using it as a file server. The only problem is that the storage would need to be encrypted, and my Raspberry Pi 1 was much too slow for this (3MB/s). Does anyone here know how well the 2 performs in this respect? I hope to start installing Gentoo on it soon.

1clue · Post by **1clue** » Sun Feb 15, 2015 2:22 am

100 mbps nic should tell you everything you need to know about a pi as a file server.

keet · Post by **keet** » Thu Feb 19, 2015 1:24 am

I have mine working so far. I downloaded a stage 3, but took the boot files from a Raspbian installation. After that and other basic configuration, I set up distcc, ran 'emerge -e system', and installed a few world packages.

I got the Raspberry Pi 2 kernel sources from Github and built them within an hour or so, and rebooted successfully.

Udev failed to build, so I am curious about that, but I'm not worried about it.

Another odd thing that I noticed is that only about 750MB of R.A.M. are available. I set gpu_mem=16, so that is probably not the problem. Considering that it has four cores, and only 1GB of R.A.M., it would be nice to have more available. A potential fix is at http://www.raspberrypi.org/forums/viewt ... 7&start=25, so I will try that when I have time.

Post by **Leio** » Thu Feb 19, 2015 10:40 am

keet wrote:Udev failed to build, so I am curious about that, but I'm not worried about it.

Another odd thing that I noticed is that only about 750MB of R.A.M. are available. I set gpu_mem=16, so that is probably not the problem. Considering that it has four cores, and only 1GB of R.A.M., it would be nice to have more available. A potential fix is at http://www.raspberrypi.org/forums/viewt ... 7&start=25, so I will try that when I have time.

If you use my CFLAGS with -mtls-dialect=gnu2, then that fails with udev due to systemd configure (which udev uses as it's building out of the systemd tree) forcing the gold linker if it's present. But it fails at linking udev itself (as opposed to the tiny test program they test gold with before forcing its usage) as gold linker doesn't seem to support those tls relocations yet. I workarounded it by adding -Wl,-fuse-ld=bfd to LDFLAGS for udev building. Using the default tls-dialect of gnu should work too, but I use gnu2, which is ARM specific and supposedly a bit faster in relocations, just cause I can and I'm not completely sure if mixing gnu and gnu2 is fine or not. I filed https://bugs.gentoo.org/show_bug.cgi?id=539998 for this.

Regarding the RAM, I heard the kernel from RPi Foundation came with a 1/3 GB memory model split at some point, and that was the problem; while 2/2 GB had problems on some specific other things at some point. Maybe your kernel configuration has that memory model choice as well. I *think* this is the choice between VMSPLIT_3G, VMSPLIT_2G and VMSPLIT_1G in kernel configuration and/or CONFIG_HIGHMEM.
I just use prebuilt kernel and modules from https://github.com/raspberrypi/firmware for the time being, until I have everything else going good. Those use VMSPLIT_2G and do not have HIGHMEM set

olek · Post by **olek** » Thu Feb 19, 2015 6:13 pm

I'm using the original model B and even compile everything right on it with an attached hard drive.
it's a headless server and I also like to choose less boated software on all of my machines. it works fine.

keet · Post by **keet** » Sat Feb 21, 2015 12:01 am

Choosing VMSPLIT_2G fixed the memory problem; I now have about 975MB. Thank you for the tip.

Now I'm working on building media-tv/kodi-14.1. I a'm not sure whether I will end up using this, but I want to see whether it works. Of course, it's in ~x86 and ~amd64, but not marked for arm at all, but I'll try it.

Yamakuzure · Post by **Yamakuzure** » Fri Feb 27, 2015 3:55 pm

Leio wrote:Setting up distcc is trivial with portage on rpi and crossdev on the helper machine.
Just did a toolchain for rpi2 to my desktop today
Code: Select all
crossdev --target armv7a-hardfloat-linux-gnueabi
20 minutes later and all done.

I am stuck right there. The re-merge of glibc fails with the following error:

Code: Select all

checking for .preinit_array/.init_array/.fini_array support... no
configure: error: Need linker with .init_array/.fini_array support.

I have already tried to build newer versions, clearing my LDFLAGS as suggested in [topic=703438][solved] Crossdev, ".init_array/.fini_array support"[/topic] and unmerged/remerged all crossdev packages again, and switched between with and without stable switch "-S".

Everything that google comes up with is very old, or suggests to remove -fPIC - which is not enabled here...

I am completely at sea, does anybody have an idea?

Versions that are to be installed:

Code: Select all

 ~ # eix -I -C cross-armv7a-hardfloat-linux-gnueabi -c
[I] cross-armv7a-hardfloat-linux-gnueabi/binutils [1] (2.25(2.25)@27.02.2015): Tools necessary to build programs
[I] cross-armv7a-hardfloat-linux-gnueabi/gcc [1] (4.9.2(4.9.2)@27.02.2015): The GNU Compiler Collection
[I] cross-armv7a-hardfloat-linux-gnueabi/glibc [1] (2.20-r2(2.2)@27.02.2015): GNU libc6 (also called glibc2) C library
[I] cross-armv7a-hardfloat-linux-gnueabi/linux-headers [1] (3.18@27.02.2015): Linux system headers

Yamakuzure · Post by **Yamakuzure** » Fri Feb 27, 2015 6:56 pm

Solved it myself.

As you can see above, I am using gcc-4.9.2. The problem is, that this does not set __ARM_ARCH (ARM support was dropped?) and in the glibc build dir one can find in sysdeps/arm/sysdep.h:

Code: Select all

/* The __ARM_ARCH define is provided by gcc 4.8.  Construct it otherwise.  */

I found out about this after yet another clear of the toolchain and a retry. When merging the glibc headers, a lot of messages that the arch architecture would be unknown are shown. But I never actually watched the build process, so I missed the message. The glibc headers are merged nevertheless.

My fix, as I do not want to install another gcc on my system but need gcc-4.9.2 for my work:

Set the crossdev toolchain to build gcc-4.8.3 for itself (by masking/keywording)
Build the toolchain and halt the build of the glibc-headers using ctrl+z once prepared
Add "#define __ARM_ARCH_7A__" in the glibc build dir/sysdeps/arm/sysdep.h
continue with "fg"

And now 2.20-r2 just got merged successfully. *yay*

UncleVan · Post by **UncleVan** » Sat Feb 28, 2015 10:13 pm

Hi Leio,

Now, this wold be my second Gentoo ARM clone, since I succesfully build a fully functional distro for Raspberry Pi model B: cross(dev) toolchain, kernel from source, distcc/qemu user emu etc - details on request - but I have a pretty basic question about the cross-compiler:

How you came across this tuple:

Code: Select all

crossdev -t armv7a-hardfloat-linux-gnueabi

and I mean the ARCH one "armv7a" ?

How you know this is the "right one" for Pi 2 ? Where can one get a list of tuples avialable for/supported by the current gcc ?

(Somehow this https://www.gentoo.org/proj/en/base/emb ... tuples.xml doesnt work for me)

Thanks in aDVANCE.

cwr · Post by **cwr** » Mon Mar 02, 2015 3:43 pm

A while back I built a Gentoo system for a BeagleBone Black which had the root filesystem on NFS.
Cross-compiling the kernel wasn't a problem, and nor was most of the other cross-compiling
I did. I found an ARM Stage 3 somwhere, and built relatively few packages; some stuff (eg. Python)
had to be build natively.

Will

Post by **Leio** » Tue Mar 03, 2015 2:19 pm

UncleVan wrote:(Somehow this https://www.gentoo.org/proj/en/base/emb ... tuples.xml doesnt work for me)

Try https://wiki.gentoo.org/wiki/CHOST meanwhile.
But basically you want the CHOST that your stage tarball uses, and for rpi2 you can pick an ARMv7 one, and you find that CHOST from its make.conf

UncleVan · Post by **UncleVan** » Tue Mar 03, 2015 8:28 pm

@Leio : Thanks - nevertheless it's a fuzzy area

@cwr:
Simply cross compiling on the host - "i686-pc-linux-gnu" - didn't work well for me either, or is simply too complicated. You can run builds on the target - Raspberry Pi for me - with cross-distcc on some bigger machine; but is still very slow, because all autoconf checks and unpack/install stuff are still local.

Best way I found is with qemu user emulation + chroot into the target file system; could be directly on the SD card too. You'd need binformat (module binfmt_misc) enabled & set up - in the "local" services for example.
Everything is very well documented by Gentoo or Sysresccd.

This waS THE ONLY WAY FOR ME TO RECOMPILE THE GCC ITSELF TO 4.7.3

Funniest thing is if you still could use cross-distcc on the same machine to utilize other cores, gotta try this out.

PS:
Dont know whether applicable for BB though...

PPS:
don't forget to comment out the line in the /etc/ld.so.preload if you are emulating into the original raspbian, or qemu will core-dump

el_Salmon · Post by **el_Salmon** » Wed Mar 04, 2015 4:31 pm

keet wrote:I have mine working so far. I downloaded a stage 3, but took the boot files from a Raspbian installation. After that and other basic configuration, I set up distcc, ran 'emerge -e system', and installed a few world packages.

I got the Raspberry Pi 2 kernel sources from Github and built them within an hour or so, and rebooted successfully.

Udev failed to build, so I am curious about that, but I'm not worried about it.

Another odd thing that I noticed is that only about 750MB of R.A.M. are available. I set gpu_mem=16, so that is probably not the problem. Considering that it has four cores, and only 1GB of R.A.M., it would be nice to have more available. A potential fix is at http://www.raspberrypi.org/forums/viewt ... 7&start=25, so I will try that when I have time.

Which instructions have you followed? Gentoo Wiki is for model 1 (armv6), not the new one. I have tried the Wolfgang steps but keyboard doesn't response after first boot, so I cannot continue with the Gentoo setup.

f.kater · Post by **f.kater** » Wed Mar 04, 2015 4:38 pm

Just for those thinking about cross compiling, qemu or direct compilation on
the RPI:

I've tried all the three ways, but finally found that compiling on the RPI is
absolutely ok for everything that might be necessary on that box (samba,
gnumeric, ...), compared to the whole configuration overhead you have with
maintaining gcc/arm cross-compilers, the whole qemu image, dependant arm
libraries etc.

Just compile on the RPI -- I am using the old A model (with systemd
and paludis/cave instead of emerge).

About the kernel: Get the rpi kernel sources via github. Note: Since the
developers are working on new versions constantly, make sure you grab all the
required commits on top of the usual kernel tag (this might require to compare
two or three version tags to understand what is required extra stuff). And
then just try the "simple" kernel config example given in the kernel sources as
a start. I only had to add the HID driver for my cherry keyboard later on.

The resulting kernel is quite small, compilation takes way less than 10+ hours
(see postings above). Also, you might want to avoid kernel modules totally,
so you can exchange kernel images easily.

UncleVan · Post by **UncleVan** » Thu Mar 05, 2015 10:49 am

Sorry Kater, cant confirm nor recommend: It is much better - and easier in long terms - to spend, say, 6 hours to set up arm cross-compiler + distcc and user-qemu ONCE and them use it anytime anywhere, then to wait days and weeks for some native build. It can not recompile gcc itself (and most other complex stuff) just bec. lack of memory - as far as Raspberry 1 is concerned. I still dont have model 2, but curious about it's gcc performance...

Last evening build the Raspperry kernel 3.18.8 from git:

Code: Select all

git clone --depth 1 git://github.com/raspberrypi/linux.git linux-rpi

with

Code: Select all

cross-armv6j-hardfloat-linux-gnueabi/gcc-4.8.3:4.8

Took 1:40h for Intel(R) Core(TM) i3 CPU U 380 @ 1.33GHz on a single core; with -j4 could do better. Works perfect OOB on both original 2014-12-24-wheezy-raspbian.img as well with my own Gentoo port based on armv6j_hardfp-20130207.tar.bz2.

imagetool-uncompressed.py not needed anymore; just pick /sources/linux-rpi/arch/arm/boot/zImage and "ab die Post", even with the firmware from mid 2013...

I simply took the /proc/config.gz from original raspbian wheezy and run oldconfig over it.

Right know I consider building an armv7a-hardfloat-linux-gnueabi to compile a kernel + modules for the new one, but I still havent got a model 2 board, so someone of you here will have to test it - can someone provide me the original /proc/config.gz ? And the git location, if different ?

Post by **Leio** » Thu Mar 05, 2015 12:24 pm

UncleVan wrote:Right know I consider building an armv7a-hardfloat-linux-gnueabi to compile a kernel + modules for the new one, but I still havent got a model 2 board, so someone of you here will have to test it - can someone provide me the original /proc/config.gz ? And the git location, if different ?

Just grab kernel7.img and the matching modules (in the <kernelver>-v7+ modules dir) from git://github.com/raspberrypi/linux.git, boot from that and you can get the config.gz of that.
kernel7.img is booted by armv7 new pi, kernel.img by armv6 old pi's.
You would be getting the firmware files (bootcode.bin, start.elf and many more) from there too.

ShiroiKuma · Post by **ShiroiKuma** » Thu Mar 05, 2015 12:41 pm

Just wondering, has anyone got "crossdev -S -v -t armv6j-hardfloat-linux-gnueabi" to work on the Pi2 yet?

Thanks to this thread my Pi2 is running nicely with Gentoo, but thinking... maybe I could use the Pi2 to assist with compiles (distcc) from the Pi1 still laying around.

Everytime I try crossdev I'm ending up with a "the selected processes does not support thumb" error. Just trying one last time with "CLFLAGS="-marm" crossdev -S -v -t armv6j-hardfloat-linux-gnueabi" to see if that helps but I'm not holding hope. It's only the final glibc stage that's failing.

Gentoo on Raspberry Pi 2

Gentoo on Raspberry Pi 2

Re: Gentoo on Raspberry Pi 2

@ Leio

Re: @ Leio

Best way of cross compiling

raspi kernel 3.18.8 successfullybuild

Re: raspi kernel 3.18.8 successfullybuild