Gentoo on Raspberry Pi 2

[UncleVan]

@Leio: I would if I could .. - I still dont own a Pi2 board and I dont know when I will ... I suppose kernel7.img won't boot with the Pi 1 model B ? -!!! CORRECT ME IF I'M WRONG !!!
...which would be a smooth transition to

@ShiroiKuma: Sounds like kind of task for a Canadian Cross... I'dont know whether crossdev provides for non-intel CHOST - keep us updated.

So someone with RaspPi 2 board could friendly provide me with the /proc/config.gz from the kernel7.img, and I will retour with a fresh new 3.18.8 ARMv7 kernel image + Modules! (or at least Ill do my best to )
There are of course workarounds for this but I dont have the time for experiments right now...

Also I wonder whether I could use same git sources for both kernels ?

Thanks in advance !

[Leio]

@Leio: I would if I could .. - I still dont own a Pi2 board and I dont know when I will ... I suppose kernel7.img won't boot with the Pi 1 model B ? -!!! CORRECT ME IF I'M WRONG !!!
...which would be a smooth transition to

No, it won't boot. kernel7.img is built for armv7 with NEON support. pi1 can't run that. kernel.img renamed to kernel7.img might work up to a point, but probably slightly different device tree or whatnot, and so won't get far, but who knows.
But the whole point of the different names is exactly for co-existence and smooth transition of a SD card between different Pi's, if the userland is for Pi1. So raspbian and such distros can install both kernel.img and kernel7.img, and have the most important part (kernel) run in ARMv7 mode, so that it runs at optimal speed and selected userspace bits can be using dynamically chosen armv7 with NEON code paths when they find it present at runtime (if the rest is ARMv6 to remain pi1 compatible; or just everything from a ARMv7 stage as we do in Gentoo usually). The firmware (start.elf, bootcode.bin and the others) is built so that it sees which Pi it is and then chooses the kernel image filename accordingly, so you can have both on the same /boot.

So someone with RaspPi 2 board could friendly provide me with the /proc/config.gz from the kernel7.img, and I will retour with a fresh new 3.18.8 ARMv7 kernel image + Modules! (or at least Ill do my best to )
There are of course workarounds for this but I dont have the time for experiments right now...

If you are having trouble, really, just use the pre-built ones from firmware.git repo and worry about your own kernel much later on.
The pi2 kernel has the added suffix to it, so the modules reside in separate paths and can co-exist. And no, can't use the same modules for both pi1 and pi2, because the modules would be built for ARMv7 as well. Hence the different kernel name suffix, to have them also co-exist in /lib/modules different subdirs.

As for the /proc/config.gz, I think it's too large to put here. But I suspect it's what would come out of using raspberry pi 2's kernel default config, i.e as found here:
https://github.com/raspberrypi/linux/bl ... _defconfig

I think "make bcm2709_defconfig" in your rpi kernel clone might start using it? Of course prepending with any necessary environment variables (or exported earlier) as appropriate, especially if cross compiling on a x86_64 or whatnot.

bcm2709 is the rpi2 "platform" in kernel and bcm2708 is rpi1 platform.

Also I wonder whether I could use same git sources for both kernels ?

Yes, but might be useful to have a local copy or clone for the other, so that when you tweak a config, you don't need to rebuild all from scratch, had you happened to compile for the other pi type in the tree. Though maybe kernel supports building in builddirs too, then could do it easily in the same clone without any caveats.

[aahjnnot]

Has anyone managed to compile Firefox or Chromium for the Pi 2? I'm running KDE on mine with a surprising level of success, but Konqueror is a fairly restrictive web browser. Unfortunately, both Chromium and Firefox fail to build for me.

I've posted a question in the Portage forum but no-one has yet responded. I've since discovered this thread and it's possible that there's greater architecture expertise here than there.

[UncleVan]

@ Leio: Thanks once more !

No , it isn't about any trouble, it's just for the record, you know ... I feel so proficient with cross-compiling I want to test the extents
So if someone is willing - just put the original /proc/config.gz from raspbian armv7 into some file hoster and post me the link - thanks in advance !

@aahjnnot: This would be my next task too, but I will have to do it for the RaspPi 1 for the first time. Im using midori on my Raspberry Gentoo and seems OK. Of course no Flash Videos...

BTW just noticed this

Code: Select all

https://github.com/raspberrypi/userland

Does somebody know how/whether to deploy this in Gentoo ?

[aahjnnot]

BTW just noticed this

Code: Select all

https://github.com/raspberrypi/userland

Does somebody know how/whether to deploy this in Gentoo ?

This will do the trick:

Code: Select all

emerge --ask raspberrypi-userland

[MrHacky]

Has anyone managed to compile Firefox or Chromium for the Pi 2?

I've successfully compiled chromium on my pi 2. One problem i had with this is that it ran out of memory during the final link step and with the swapping to sdcard it seemed like it never was going to finish, so i aborted it. Then i enabled zram to 'swap' to compressed memory (http://wiki.gentoo.org/wiki/Zram) and the link succeeded. (i added a 2G zram 'disk' as swap space)

This zram seems to work very well in general, speeding up any workload that would require swapping tremendously.

I also had to enable the 'neon' useflag to stop it from trying to use a function which didn't exist. There were some NEON-related ifdefs nearby in the code so i tried the 'neon' useflag and it worked.

[ShiroiKuma]

@UncleVan: I need to test it now, but with the -marm CFLAG passed to crossdev it's compiled okay on the Rasberry Pi 2 now. I'll find out how well it works when the Pi 1 has a larger compile that'll use the distcc setup.

Regarding raspberrypi-userland, if using the 9999 git version it might be okay. However the current ~arm not hardmasked version fails to compile. The error I was getting with that myself seems to have been fixed 22 days ago according to this issue https://github.com/raspberrypi/userland/issues/214. Maybe it'll work if you just pass -fPIC along with the CFLAGS...

[Leio]

I have a newer raspberrypi-userland in my overlay - together with wayland wsys patches. I guess live can be fine too.
You need that newer to live to really have rpi2 support, and yes, there were compile errors in the old version when compiling for ARMv7 or something. Hit that too, hence the upgrade originally.
If other folks test it from my overlay (or a named date of live version or something) and find it good, I would feel more confident to version bump in the main tree.

I don't know why you are still asking for /proc/config.gz - didn't make bcm2709_defconfig work?

[UncleVan]

@Leio: Oh, simply a matter of experience and because I want to build a really working RasPi kernel. In the past when I started with this it proved to be the only way for building AND booting successfully on a headless Raspberry. So , why change it ? Admittedly, it won't be a great deal deal for someone to upload it ... So I'm asking further ...

@ShiroiKuma: You are on your own there ! Could you post the exact command you building with ? - Thanks !

PS: Last night did:

Code: Select all

FEATURES="-distcc" crossdev -S -t armv7a-hardfloat-linux-gnueabi

Worked like a charm !

Code: Select all

$ equery l cross-armv7a-hardfloat-linux-gnueabi/*
 * Searching for * in cross-armv7a-hardfloat-linux-gnueabi ...
[I-O] [  ] cross-armv7a-hardfloat-linux-gnueabi/binutils-2.24-r3:2.24
[I-O] [  ] cross-armv7a-hardfloat-linux-gnueabi/gcc-4.8.3:4.8.3
[I-O] [  ] cross-armv7a-hardfloat-linux-gnueabi/glibc-2.19-r1:2.2
[I-O] [  ] cross-armv7a-hardfloat-linux-gnueabi/linux-headers-3.16:0

Allready produced a little static a.out and tested it with qemu-arm. Seems OK.

[aahjnnot]

Has anyone managed to compile Firefox or Chromium for the Pi 2?

I've successfully compiled chromium on my pi 2. One problem i had with this is that it ran out of memory during the final link step and with the swapping to sdcard it seemed like it never was going to finish, so i aborted it. Then i enabled zram to 'swap' to compressed memory (http://wiki.gentoo.org/wiki/Zram) and the link succeeded. (i added a 2G zram 'disk' as swap space)

This zram seems to work very well in general, speeding up any workload that would require swapping tremendously.

I also had to enable the 'neon' useflag to stop it from trying to use a function which didn't exist. There were some NEON-related ifdefs nearby in the code so i tried the 'neon' useflag and it worked.

Thanks, @MrHacky. I kicked off a Chromium compile with the 'neon' use flag last night, and it's still emerging. I take that as a good sign - previous build attempts failed after 3-4 hours. I'm using distcc so I hope that I avoid the memory problems that you encountered. I'll wait patiently and see what happens.

[ShiroiKuma]

@UncleVan I think you misunderstood. I've got crossdev working fine on my Pi 2 now.

The command to build was

Code: Select all

CLFLAGS="-marm" crossdev -S -v -t armv6zk-hardfloat-linux-gnueabi

So now my Pi 2 is a cross compiling distcc server for my Pi B+. Now my Pi B+ is able to compile things so much faster thanks to the Pi 2's quad cores.

[UncleVan]

@ShiroiKuma: That's the way I got it - I just ment when you really start using it - Nevertheless it is a great news that crossdev can bulid on ARM Arch too - a whole lot of possibilities then ! Thank you once more !

BTW: wouldl you bother to send me - or upload somehow - the original /proc/config.gz from RasPi 2 ? - You know why ....

[ShiroiKuma]

I've used it to assist with recompiling my mail system, dns and postgres so far. No issues yet with any of them.

As for the kernel, my Pi 2 is current using the one from the Pi github repo's 3.18.8 branch.

The output of a zcat of the kernel is at https://bpaste.net/show/b4b528303f9a

Hope that helps

[aahjnnot]

So I'm happy to report that the Chromium web browser now compiles perfectly for me on the Pi 2. My first five minutes with it are much more pleasant than Konqueror - significantly faster and pages render more faithfully.

For the record, the tricks I used were:
- A swap file of 1.5GB
- The following entry in /etc/portage/package.use:

Code: Select all

www-client/chromium neon

- distcc (although this might not have been necessary)
- Patience: final linking took somewhere between 11 and 18 hours

[Yamakuzure]

Has anybody yet succeeded in starting a PI2 image with QEMU? No matter what I try it just doesn't want to work for me.

The nearest I got was:

Code: Select all

 # qemu-system-arm -machine cubieboard -cpu cortex-a8 -m 256 -no-reboot -kernel kernel7.img -serial stdio -append "root=/dev/sda2 panic=1 console=ttyAMA0" -hda gentoo-raspi2.img
Warning: Orphaned drive without device: id=ide0-hd0,file=gentoo-raspi2.img,if=ide,bus=0,unit=0

And then the cursor blinks a few times in the qemu windows and then halts.

I am aware that qemu can not fully emulate a Cortex-A7, but I do hope the previous model A8 might be close enough...

I followed the howto here and tried to adapt to the new PI2. I did not get qemu-nbd working so I mounted the image using a loop device. Maybe that was my problem?

Edith wants to add: If I try a different board, like the "realview-pb-a8", the qemu window always states: "Guest has not initialized the display (yet).". The "cubieboard" is the only one not showing this and looking like at least something was happening.

[UncleVan]

@ShiroiKuma: Thanks a lot - you saved my time ! Ill give a try ASAP.

@Yamakuzure: If you are trying the original Raspbian image: Did you comment out the line in /etc/ld.so.preload to look like this:

Code: Select all

$ cat /run/media/root/armroot/etc/ld.so.preload

#/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so

This was known to kill qemu in the RPi 1, because libcofi_rpi.so is RPi-hardware related, and obviously qemu dosn't emulate it.

[Yamakuzure]

@Yamakuzure: If you are trying the original Raspbian image: Did you comment out the line in /etc/ld.so.preload to look like this:

Code: Select all

$ cat /run/media/root/armroot/etc/ld.so.preload

#/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so

This was known to kill qemu in the RPi 1, because libcofi_rpi.so is RPi-hardware related, and obviously qemu dosn't emulate it.

No, I created one from scratch like shown in the howto I linked. The difference was, that I used

Code: Select all

make bcm2709_defconfig

like described here and then named it kernel7.img.

My bet is, that the howto I used is just not appropriate any more.

[UncleVan]

Maybe a little off-topic, but I just notice Im having a real problem. This one I experience from time to time and always forget the solution ! The following:

In order to run single arm binaries Im using qemu-arm. It's working fine with statically linked - of course. Also chroot is as expected. But when I try to run binaries with shared objects (dynamically linked) like this:

Code: Select all

qemu-arm -L /run/media/root/VIRTUALS/armroot /run/media/root/VIRTUALS/armroot/bin/ls 

where the "/lib/ld-linux-armhf.so.3" (loader) is supposed to be under /run/media/root/VIRTUALS/armroot fs - I get nothing. Even worse, qemu-arm is eating up CPU and memory and nothing happens ! The ld-linux-armhf.so gets picked up, because if I change the -L path - or omit it - Im getting the ubiquitous:

Code: Select all

/lib/ld-linux-armhf.so.3: No such file or directory

Tested also with earlier qemu version - still nops.
And Im absolutely sure I've done this thousands time and it used to work; and I sporadically get this problem...

Any suggestions/help ?

Im building qemu from git; now stable qemu-arm version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard


@Yamakuzure: My bet is it wouldnt work this way even for armv6j stage3, because to start with qemu you need a "special" build i.e. configured kernel... I couldn't manage to start the "old" Pi with my own kernel; always used a prebuild one from the net.

[el_Salmon]

Does anyone could prepare a minimal Gentoo image for Raspberry Pi 2? I cannot use my keyboard with the Raspbian kernel (but it works fine with Raspbian or Ubuntu).

[Leio]

Does anyone could prepare a minimal Gentoo image for Raspberry Pi 2? I cannot use my keyboard with the Raspbian kernel (but it works fine with Raspbian or Ubuntu).

Do you have the kernelmodules copied too? At least in raspberrypi firmware repository prebuilt kernels also have many modules in there in separate directory that you need. Pretty much everything is a module there, not compiled in. And that's the only thing I can think of why keyboard wouldn't work - usbhid or whatnot modules not found.

[el_Salmon]

Does anyone could prepare a minimal Gentoo image for Raspberry Pi 2? I cannot use my keyboard with the Raspbian kernel (but it works fine with Raspbian or Ubuntu).

Do you have the kernelmodules copied too? At least in raspberrypi firmware repository prebuilt kernels also have many modules in there in separate directory that you need. Pretty much everything is a module there, not compiled in. And that's the only thing I can think of why keyboard wouldn't work - usbhid or whatnot modules not found.

Yes, I copied the modules in /lib/modules/{kernel}, like the Gentoo wiki says, but it doesn't work

[UncleVan]

I recently managed to compile www-client/firefox-24.3.0 on my RasPi Model 1 - no neon support, of course, but the approach applies to both models I guess.

This specifical version of Firefox - the only one marked by the arm people as "stable" ! - breaks building pretty reproducible after 5115 compiled *.o files with error message about unresolved reference to some function called "yuv42x_to_rgb565_row_neon(....)". The functionis is defined in gfx/ycbcr/yuv_convert_arm.cpp. The "neon" in its name was mesleading me for a while thinking some flag was wrongly enabled.

Basically Firefox allways generates code for every arm arch it supports - thus, also for neon - and the decision about the actual plattform is made at run time.

It proved that there is a bug in Motilla's build infrastructure; specifically in gfx/ycbcr/moz.build - a Python code file. This bug effectively prevents build on either RasPi model.

You can find the whole discussion and my explanations in this thread: http://forums.gentoo.org/viewtopic-p-77 ... ml#7721186.

So I prepared a tinny patch in order do fix this issue: https://bpaste.net/show/51c484d2bd61. It has to be copied to
/etc/portage/patches/www-client/firefox-24.3.0/UncleVan-5115-os-test-arm.patch in order to be automatically applied by emerge (actually the file name doesn't matter as long as it suffix'es at .patch; the directory stucture is important !).

With this Firefox 24.3.0 emerges flawlessly and even works, but expect no wonders - performance is lousy... Also funny: They call it "Aurora" at arm

Even more - I build a binary package for those who are not willing to wait 9:30h (on RasPi 1) . It can be downloaded from here firefox-24.3.0.tbz2
put to your portage packages dir and carelessely installed with simple

Code: Select all

emerge -K www-client/firefox

provided you have the recent dependencies in place.

The highlight: it is supposed to work also on RasPi 2, allthough Im in doubt; so report your experience.

Your UncleVan.

PS: I also included the actual "/etc/portage/patches/www-client/firefox-24.3.0/UncleVan-5115-os-test-arm.patch" in the tarball so don't get scared and be aware that it is going to be swept on uninstall...

[garlicbread]

I've managed to get some distance installing gentoo onto the rpi2 using a usb harddisk and a raspian sd card without qemu or cross compiling
https://github.com/grbd/GBD.Rpi2.Gentoo
https://github.com/raspberrypi/linux

building nativley on the rpi2 is surprisingly fast (perhaps it's the hard disk or the -j5 option since it is quad core)
But I'm struggling to get a custom kernel to build and run
I'm booting off the raspian one which works fine, but the custom one just gives a black screen (there is a back light so it is initiating the screen, but no writing)

Code: Select all

make bcm2709_defconfig
make -j5
make modules_install1
imagetool-uncompressed.py arch/arm/boot/Image /boot/kernel7-gentoo.img

then edit /boot/config.txt to set

Code: Select all

kernel=kernel7-gentoo.img

perhaps an option needs to be set for Noobs that I don't know about

[garlicbread]

For anyone else building a kernel on the rpi2
the trick is to not use imagetool-uncompressed.py, it was originally a requirement for older bootloaders for the rpi, but for newer bootloaders it's no longer needed. With Noobs it actually stops the kernel from running

so instead of imagetool-uncompressed.py, just copy the image file directly instead

Code: Select all

cp arch/arm/boot/Image /boot/kernel7-gentoo.img

[UncleVan]

For anyone else building a kernel on the rpi2
the trick is to not use imagetool-uncompressed.py, it was originally a requirement for older bootloaders for the rpi, but for newer bootloaders it's no longer needed. With Noobs it actually stops the kernel from running
...

Yes, I can confirm this. Also, I don't configure with bcmXXX_defconfig. Instead, take the original Raspbian config "/proc/config.gz" and "make oldconfig" over it in the git sources - guaranteed to succeed