Bootable 64-bit RPi3 Gentoo image (OpenRC/Xfce/VC4) UPDATED

[honeymak]

I'm still trying to get my RPi3 installing gentoo on that
What I'm having now is xzcat the sakaki's gentoo image
and then compile all the stuff native on my RPi3
sakaki's image is already great with seven hundred something pkgs in it already
for my own gentoo installation generally I usually have around 300 pkgs
that's why I'm still figuring out stuff inside sakaki's gentoo image
_________________
hackers - make sth real
academics - read sth said to be real

[NeddySeagoon]

honeymak,

There is a 64 bit Pi3 binhost too and an image of my Pi3 64bit install
Its not nearly as well presented as Sakaki's image.

The binhost is just my ./packages directory from the Pi install.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Leio]

On ARM -mcpu can be significant too instead of -march or as a more specified version, compared to only doing -march.
_________________
GNOME team lead; GStreamer; MIPS/ARM64

[honeymak]

i tried to use sakaki's image to boot up my rpi3
and then
tried to install gentoo like normal steps in handbook
the kernel8.img from sakaki's image is retained
that means i didn't compile and install my own kernel and grub( i guess arm does not use grub)
but my rpi3 does not boot up (i.e. just stayed in the color screen)

what am I missing?

_________________
hackers - make sth real
academics - read sth said to be real

[NeddySeagoon]

honeymak,

The Pi staying at the rainbow test screen means that it can't read the boot partition properly.
It must read /boot/bootcode.bin as that's what draws the rainbow.

Did you change anything in /boot at all?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[honeymak]

i didn't do anything to /boot
just (u)mount several times

_________________
hackers - make sth real
academics - read sth said to be real

[NeddySeagoon]

honeymak,

Run a fsck on the Pis boot and be prepared to restore it.
Even with no root filesystem at all, everything should work until the kernel tries to mount root.

Did sakaki's image work at one time?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[honeymak]

i am trying to xzcat again
_________________
hackers - make sth real
academics - read sth said to be real

[Sakaki]

Hi honeymak,

I assume from your previous posts that you have managed to get the gentoo-on-rpi3-64bit image to boot in its original form?

If so, then if you are trying to progress to your own version step-by-step, one thing I would definitely recommend is commenting out the line beginning

[AJM]

I have been using this on a couple of thin clients recently with mixed success. Overall performance isn't bad, using Remmina to connect to a FreeNX server (actually this doesn't seem to work at all on any recent version of Raspbian which is why I resorted to Gentoo on the Pi in the first place!)

The snag is that when I use FreeRDP to connect to a Windows server (within the NX session) the RDP session is slow as treacle and I can't see any indication why. It doesn't happen on my amd64 desktop so it's nothing directly to do with Remmina/NX as far as I can see.

Anyone have any ideas? I'm out of them...

Edit - PS Thanks to those who released the image and have done subsequent work on this - I never thought I'd be running Gentoo on a RPi!

[Sakaki]

Hello,

just to let you know that version 1.1.0 of my bootable 64-bit Gentoo image for the RPi3 has just been released, on GitHub (here).

As before, the image's userland contains a complete (OpenRC-based, Xfce4) Gentoo system (including a full Portage tree) - so you can run emerge operations immediately - and has been pre-populated with a reasonable package set, so you don't need to compile anything to try it out. Just download, xzcat to an microSD card, and boot! The Pi3's integrated WiFi, Bluetooth, ALSA sound, and VC4 graphics acceleration are supported.

A detailed changelog from prior release image may be viewed here, but in summary:

• added libreoffice-5.3.4.2, thunderbird-52.2.0 and gimp-2.9.4-r3 to the preinstalled package list;
  
• all other packages brought up-to-date against the Gentoo tree as of 9 July 2017 (includes firefox-53.0.3 etc);
  
• all installed packages are now backed by a weekly-autobuild binhost, at https://isshoni.org/pi64 (*);
  
• the binary kernel package bcmrpi3-kernel-bin-4.10.17 is supplied on the image, and a weekly autobuild of the default branch (currently rpi-4.9.y) is provided too, in case you want to use that (better backport support, but no audio) (you can still build your own, if you like);
  
• a la dantrell, a custom Gentoo profile for the rpi3 is used (visible here); this helps keep USE flags, package.accept_keywords etc in lockstep with the binhost;
  
• similarly, the binhost provides a weekly-gated Gentoo repo snapshot via rsync, with signed hash authentication;
  
• the image is now set to auto-update (using genup) from the binhost once a week, by default (this can easily be disabled, of course);
  
• all RPi3-specific startup scripts (ondemand frequency governor, hciattach for Bluetooth etc) have now been migrated into OpenRC services (see the rpi3 overlay for details);
  
• all custom firmware (for e.g. Bluetooth, WiFi, and the non-kernel boot firmware in the first partition) are similarly under ebuild control, from the same rpi3 repo.

Full instructions for download and use (and a pretty screenshot ^-^) are available on the project's GitHub page.

As the previous (1.0.2) version of the image has had over 2,600 downloads to date, there may be those who would prefer to upgrade an existing system to 1.1.0 (to avail of the autobuild binhost backing, binary kernel packages etc.), rather than start afresh from the 1.1.0 image. Accordingly, I have also put together (and tested) a set of manual upgrade instructions (here), to enable 1.0.2->1.1.0 migration.

As always, any problems, please feel free to contact me!

(*) I can make no guarantees about the future availability of the weekly autobuilds on isshoni.org, nor the autoupated binary kernel packages (on GitHub). However, we use these as part of our own production infrastructure, so they should be around for a while. Use the provided binary packages at your own risk.

PS: if you have other packages running on your RPi3 that are not included in the image's pre-installed set, I'd be happy to take PRs for the appropriate elements of the custom profile (package.accept_keywords, package.bashrc and package.use entries, for example). Not only will upstreaming your changes help other users in the short term, it will also create a shared knowledge base (about how to get various packages working on arm64) that can be used as a sourcebook for normalizing arm64 within the main Gentoo tree (something I'd like to have another push at again shortly).

PPS: within reason, I'm also happy to consider adding working packages to the set maintained by the weekly-autobuild binhost; just open an issue to request this.
_________________
Regards,

sakaki

[Sakaki]

Hi,

I've just posted a v1.1.1 bugfix release of my bootable 64-bit Gentoo image for the RPi3 on GitHub (here).

Existing users of the v1.1.0 image can simply run genup (as root) to effect the upgrade (or wait for the weekly autoupdate to take care of this on your behalf); those looking to migrate from a v1.0.{0,1,2} image should follow the instructions here (the final genup step of which will now land you at v1.1.1, instead of v1.1.0).

Changes in this release:

• In v1.1.0, I had blithely commented out "disable_overscan=1" in config.txt (wrt v.1.0.2), which proved to be a mistake. It turns out that the (open-source driver) vc4 hardware cursor blitting does not account for the overscan "bezel" in all cases, leading sometimes to an offset mouse cursor. This only happens with HDMI TVs, not computer monitors, and only then at certain resolutions, but it is very annoying when it manifests. To address this, I have reverted the default "disable_overscan=1" again, and also provided a simple OpenRC service, rpi3-safecursor, which forces the modesetting driver to use software cursor blitting (slower, but always pointing in the right place) should the user turn overscan back on (it also disables compositing when the swcursor is in use).
  
• Switched to PARTUUID naming in cmdline.txt and /etc/fstab, and also modified the autoexpand-root service (requested by a user who is not booting the image from a microSD card).
  
• Various other ebuild tidy-ups.
  
• Packages brought up-to-date against the Gentoo tree as of 20 July 2017 (using the isshoni.org binhost, which did its first 'live' binary package weekly auto-update run yesterday).

Apologies for the inconvenience caused to HDMI TV users. ><

PS one other note, since a few people have asked - if you would like to play high-res videos on VLC or SMplayer, you'll get significantly better frame rates if you turn off the window manager's compositor (at least while you watch); to do this, select [Applications] -> [Settings] -> [Window Manager Tweaks], select the "Compositor" tab, and untick the "Enable display compositing" checkbox.
_________________
Regards,

sakaki

[Sakaki]

Pi-Top Variant Bootable 64-Bit Gentoo Image Released

If you have a Pi-Top (an RPi3-based DIY laptop), you may be interested to know that I've just released a variant of the gentoo-on-rpi3-64bit bootable image for this.

The variant has all the features of the standard image (described earlier in this thread), but also, courtesy of rricharz's work, contains:

• a patched xfce4-battery-plugin that queries the RPi3's battery over I2C (and displays a gauge in the panel);
  
• working backlight brightness (communicates with the Pi-Top's controller hub over SPI) with keyboard shortcuts;
  
• full poweroff on shutdown (ditto); and
  
• support for playing HDMI audio via any installed pitopSPEAKER units.

There's also a 64-bit version of Gordon Henderson's handy wiringpi library (and gpio utility) included on the image (my ebuild for this may be found here), as the above drivers need it to operate (PS this ebuild should work on a 32-bit RPi also, but I haven't tested it).

Full details of how to download and use the variant image (and the vanilla RPi3 version too, of course) are available on the project's page on GitHub, here. As with the standard version, it boots straight to an Xfce4 desktop; there's nothing to configure or compile if you just want to play around with it.

If you get a chance to try it out, please let me know how you get on!

PS: The Pi-Top image will have the same weekly autobuild support from the isshoni.org binhost as the vanilla image going forward.

PPS: If you have been using an older release of this image on a Pi-Top, and would like to retain your existing work while taking advantage of the drivers now available, I have provided a short set of manual 'crossgrading' instructions here. (Pi-Top users coming to this for the first time should of course simply download the variant image directly)

Baseline Image Updated to v1.1.2

The baseline image itself has also been bumped to v1.1.2; a full changelog is available here. Existing users of the v1.1.{0,1} image can simply run genup (as root) to effect the upgrade (or wait for the weekly autoupdate to take care of this on your behalf); those looking to migrate from a v1.0.{0,1,2} image should follow the instructions here (the final genup step of which will now land you at v1.1.2, instead of v1.1.0).

New users should of course simply download the new image directly, from the project's GitHub page, here.
_________________
Regards,

sakaki

[Sakaki]

Hi,

apologies, the weekly autobuild was somewhat delayed this week, due to a number of large packages version bumping (libreoffice -> 5.4.0.3, gcc->6.4.0, firefox->55.0, mesa->17.1.6) and the build turning out to be not so 'auto'.

Two main issues which may be of interest to others working with arm64 on the RPi3:

• mesa-17.2.0_rc3 builds (and I've pushed its tbz2 to the binhost, for reference) but it doesn't seem to work correctly with VC4, at least not on the kernels I tried (the desktop is there and the hardware cursor works, but the display is badly corrupted). (It does work fine with the default framebuffer.) So, I have masked it in the custom profile used on the image, pro tem. mesa-17.1.6 works fine with VC4 and the binary package for this has also been pushed.
  
• firefox-53.0.3 dropped off the tree, so it was a choice between going back to 52.3 or forward to 55.0. Unfortunately, the system programming language rust has become mandatory for >= 55.0, but, as NeddySeagoon had already successfully emerged firefox-55.0 I thought I'd give it a try. I had problems getting dev-lang/rust-1.19.0 to build; it sets up a variable $TRIPLE which defaults to "i686-unknown-linux-gnu", causing the src_install step to fail. Similar story with dev-util/cargo-0.20.0 (cargo is the package manager for rust). So, I have created variants of these ebuilds that work for arm64, in the rpi3 overlay used by the image (see this commit); with these in place (and appropriate package.accept_keywords) it is possible to emerge firefox-55.0. The tbz2s for all of these are now on the isshoni.org binhost (here, here and here). (By the way, rust creates its own LLVM copy when it builds (1.15.1's handy "system-llvm" flag having disappeared), and that process doesn't distribute over distcc, so building it natively takes around a day of elapsed time.) firefox-55.0 seems to startup and run fine (but I have only done limited testing on it, so beware!)
  

I will submit a PR for the arm64-modded cargo and rust when I get a chance. In any case, they are now on the autobuild list for the binhost. Next up is icedtea - @NeddySeagoon, is the preferred method still to do the gcj build via gcc-5.4 per your post here?

After that I will clean up the custom profile's package.accept_keywords (there are some redundant entries in there) and then the fun of a few hundred PRs to try to get everything keyworded upstream ^-^
_________________
Regards,

sakaki

[NeddySeagoon]

Sakaki,

I couldn't get rust-1.19 to build ether on the Pi itself or in my arm64 chroot, so I stayed with rust-1.16 for firefox-55.
I've not had a chance to try it yet.

I can confirm the VC4 issues. I wasn't sure if its my new kernel or mesa.

[akabane]

This seems nice ! Anyone has been able to successfully compile and run kodi with mmal or omxplayer acceleration on this ?
I might give it a try myself

[Sakaki]

akabane,

There's currently a problem with MMAL and OpenMAX IL on 64-bit (at least, as far as I know). Please see my post here for further details.
_________________
Regards,

sakaki

[akabane]

Thanks for the info Sakaki, I just read your post and I think you saved me several hours of headache around that (resolving this kind of issue is far beyond my knowledge)

[Sakaki]

I've added a few more things to the weekly 64-bit autobuild that may be of use / interest (available as binary packages on the isshoni.org binhost):

• dev-java/icedtea-3.5.1 (icedtea:8, FOSS build of OpenJDK 8)
  
• dev-java/icedtea-7.2.6.11 (icedtea:7, FOSS build of OpenJDK 7)
  
• media-tv/kodi-17.4_rc1 (FOSS media player)
  
• x11-misc/twofing-0.1.2-r2 (converts touchscreen two-finger gestures to mouse and key events)

Thanks to NeddySeagoon for instructions on how to get IcedTea to build (see his notes here; I bootstrapped icedtea:7 via gcj-jdk-5.4.0-r1, then icedtea:8 using icedtea:7).

To install IcedTea OpenJDK on a system booted with the gentoo-on-rpi3-64bit image, simply do:

[PeterBell]

New user here.

I recently took delivery of a Pi-Top, and was looking for something better than Pi-Top OS to run on it, when I came across this build. I have experience of many Linux distros, but have never used Gentoo before - it's a bit of a steep learning curve, especially installing additional packages. I tend to use Arch Linux on my embedded Pi systems.

I have to say that, for the Pi-Top, this Gentoo build is a great deal better than the default Pi-Top OS (... and my wife agrees with me!) - so very many thanks for the effort put into this.

I would like to get systemd running, but gather that this needs a setting in the kernel build - any chance of this being added to the standard build, or can someone give me pointers for rebuilding the kernel myself?

[NeddySeagoon]

PeterBell,

The kernel build instructions are in the Raspberry Pi 3 64 bit Install page on the wiki.

That page describes a kernel cross compile because its much faster that the Pi and you need a kernel on the Pi before you can boot it to have it build its own kernel.
The gentoo kernel, derived from Linus kernel will not support all of the Pi hardware, as of 4.12, so you need to use the Foundation kernel.
The 4.9 branch gets all the fixes first.

The Foundation kernel lacks the gentoo-sources easy switch for systemd.

The bcmrpi3_defconfig turns on everything that is even remotely useful, so you may not need to build a kernel for systemd support.
Sakakis kernel is closely based on the Foundation kernel.

[Sakaki]

PeterBell,

glad you have found the Gentoo image useful so far, and welcome to Gentoo!

If you want to build a new kernel while booted into the image, you should follow the instructions on the project's GitHub page, here. The image contains a binary kernel package, and that needs to be disabled when you install your own (so your work does not get overwritten on an update).

As NeddySeagoon has said however, the default bcmrpi3_config ('foundation') kernels have most options turned on already, so systemd will probably be OK even if you choose not to spin your own. You can extract the necessary list of options from this table if you want to double-check.

One other issue - the image as shipped is subscribed to a custom Gentoo profile (rpi3:default/linux/arm64/13.0/desktop/rpi3), supplied by the rpi3 ebuild repository (aka, overlay). The profile acts as a convenience to supply many of the build settings for the RPi3 used by Gentoo's package manager, Portage. As you're new to Gentoo, you might find this a useful introduction to its 'build-from-source' oriented package management system, USE flags, keywording, masks, ebuilds etc. You can review the profile settings here (you'll probably need to override some of these if shifting init system).

The repository also provides a number of RPi3/Pi-Top utilities (dev-embedded/pitop-speaker, sys-apps/rpi3-ondemand-cpufreq etc.) which currently only work in OpenRC, not systemd. You can review a list here. It wouldn't be particularly difficult to port these for systemd, but at the moment I don't have the bandwidth to maintain two separate builds (OpenRC and systemd) for testing.

Also, bear in mind that arm64 is still in the early stages with Gentoo. If you are considering some major changes wrt the current image (such as a shift to systemd) it might be an idea to try things out first on a arm (32-bit) install on your RPi3/Pi-Top, since this is a more trodden path. If you have time, installing a Gentoo system on your PC (or a VM) would also be time well spent to learn the ropes. The canonical guide is the Gentoo Handbook; I also maintain a somewhat more discursive install guide for EFI machines (here).

I'll leave the last word to xkcd ^-^
Good luck!
_________________
Regards,

sakaki

[dr_wulsen]

@roylongbottom: First, thank you for providing your benchmark suite and results, this led me to some interesting investigations on the CFLAGS used.

I have compiled the whetstone.c under 32bits for armv7-a and armv8-a+crc, both in conjunction with every possible -mfpu= unit.
Results can be found here.

It made no difference if it was compiled with "-march=armv7-a or armv8-a+crc.
I was surprised that the vfpv3-* and neon/neon-fp16 fpu implementations gave the highest score.

Results below: Whetstone Double Precision, tested on Raspberry Pi3, 1200MHz static clock (performance) and with two GCC-6.4.0 and -O2
In repetitive testes, the pattern was the same, with marginal fluctuations.
Also the pattern was the same on GCC-5.4.0 only with lower figures.
Still the pattern is the same when using "-O3" "-O2 -funsafe-math-optimizations" "-O3 -funsafe-math-optimizations"
And it does not change when running the Single-Precision Whetstone, only difference is that the "SP" implementations catch up, of course.

[Zucca]

I've decided to get back on playing with RPi3.
It seems that when running 64-bit Gentoo all the hardware can be utilized. Right? BT, Wi-Fi.... And even the 7" touchscreen.

I've downloaded Sakaki's image. I need to modify it a bit... I want / to be on my USB memory "stick". /boot and maybe some backups on the SDcard. I'd propably also put distfiles and binpkgs on the SDcard as weel, since it's 32Gig one.

I'd suspect this being doable just by

• copying all the files from the image
  
• (re)partition the SDcard and USB stick
  
• mount the Pi3 filesystems
  
• copy files (back) to SDcard and USBstick
  
• edit Pi3's fstab
  
• disable the service that expands the root partition on first boot

Am I on the right tracks?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--

[Sakaki]