Updated 64-bit Gentoo Image for RPi3 Released (now also for RPI3B+)

[jamesh]

The old Pi2 uses the BCM2836 SoC, the newer Pi2 uses the BCM2837.
Old 32bit only, new 32/64bit.
So this should work on the new Pi2, but I don't have any.

Gentoo32?
I have only found DIY build instructions, no ready to go image?

Not all Pi2 manufacture uses the bcm2837, some are still made with the bcm2836.

[Gavinmc42]

Not all Pi2 manufacture uses the bcm2837, some are still made with the bcm2836.

Hmm that could be confusing if I needed a lower power WiFi-less 64bit Pi
BCM2836 rev 1.1 , BCM2837 rev 1.2?

[Gavinmc42]

Hey, which is the lower power Pi2?
32ibt 2836 or 64bit 2837?

I suppose just for Ethernet gadgets the Pi2 rev 1.2 would be better than Pi3B or 3B+.
Is there a Pi2 rev1.3 with the metal top 2837 clocking at 1.4GHz?
Probably not, need a PCB redesign to get the heat out, 1.3GHz?
But old lan chip, so not as network fast as a 3B+

Hmm Pi2B+ in the works?
Rhetorical question - no answer expected

[sakaki]

Not all Pi2 manufacture uses the bcm2837, some are still made with the bcm2836.

Hmm that could be confusing if I needed a lower power WiFi-less 64bit Pi
BCM2836 rev 1.1 , BCM2837 rev 1.2?

Yes, afaik the rev 1.2 RPi2 has a 64-bit-capable SoC, whereas the earlier revs do not.

I have been informed by a user that the gentoo-on-rpi3-64bit image will boot on a rev 1.2 Pi2 board, provided that an appropriate dtb is present in /boot, by e.g. mounting the first partition of the image on a pc, at /mnt/piboot say, then doing.:

Code: Select all

# cp /mnt/piboot/bcm2710-rpi-3-b.dtb /mnt/piboot/bcm2709-rpi-2-b.dtb

Unfortunately I don't have a Pi2 to test this out.

do we have 32bit for Rip2 ?

A bootable 32-bit Gentoo image with integrated desktop etc. would definitely be possible but it's not on my todo list. There are of course the usual stage 3s etc available if you want to roll your own.

hth, sakaki

[Solid924]

Hello,

I tried to install Team viewer on Gentoo but it doesn't work. What's the correct command to install it? Sudo emerge teamviewer does NOT work.

Thanks!!

[sakaki]

Solid924,

Apologies for the delay in replying, I am currently travelling with only very intermittent internet access, and will respond on my return (last week of August).

In the meantime, please post a topic on the ARM subforum of the Gentoo board for support.

Best,

Sakaki

[sakaki]

Solid924,

I saw you posted an issue about this in the Gentoo forums. Did it get resolved to your satisfaction? Note that if can run 32-bit Raspbian apps from within 64-bit Gentoo if you need to: see for example my notes here.

Best,

sakaki

[sakaki]

All -

an apology - there is a bug (introduced by me) in porthash-1.0.6, that in turn is causing genup to fail. I've put a fix into porthash-1.0.7, and posted a news article via the rpi3-overlay, and a GitHub issue with the resolution, also copied below. ><

Diagnostics

Look near the end of your /var/log/latest-genup-run.log file to see if the issue affects you; if it does, you'll see something similar to the below:

Code: Select all

=== Sync completed for gentoo
q: Updating ebuild cache for /usr/portage ...
q: Finished xxx entries in yyy seconds
Checking master signature on gentoo repo...
porthash: Using public key 09F2FF455D90CAF4
porthash: Entering /usr/portage...
porthash: Verifying existing hashfile...
porthash: Hashfile signature and format valid
porthash: Computing master hash of /usr/portage, may take some time...
porthash: error: Hashfile and computed hashes DIFFER
Killing parent process... 

Fixing the Issue

To address the issue, open a terminal and issue the following commands, as the root user, on your rpi3:
(if running as demouser, prefix the following commands with sudo):

Code: Select all

pi64 ~ # emaint sync --repo sakaki-tools
pi64 ~ # emerge --update --oneshot --verbose app-portage/porthash

This should upgrade porthash to >= 1.0.7. Once this is done, your automatic weekly genup run should start working again.

That's it!

Background to the Issue (Optional Reading)

The porthash utility creates, or by default checks, the validity of a repository master hash (repo.hash) and counterpart digital signature (repo.hash.asc), to allow verification of a Portage tree distributed over an unauthenticated channel such as rsync. There was no such 'official' facility in Gentoo when the tool was originally deployed.

However, when Gentoo started rolling out its official app-portage/gemato manifest verification tool, porthash was modified (at v1.0.6) to migrate the location of the repo.hash{,.asc} files, from the top level /usr/portage/ directory (where they would clash with gemato) to /usr/portage/local/, which gemato ignores.

Unfortunately, during an rsync process of the Portage tree with the isshoni.org binhost, this local directory is not synced by default, but since (due to faulty logic; my bad) porthash-1.0.6 checks this location first when looking for the repo.hash{,.asc} files, the next time the tree is synced after the files have been migrated, the old (stale) /usr/portage/local/repo.hash{,.asc} files will be checked (not the fresh /usr/portage/repo.hash{,.asc} versions), and accordingly the signature verification will fail, and genup will halt with an error. (example)

This error is addressed in >=porthash-1.0.7, so upgrading this single package is sufficient to fix the problem.

Thanks to orion777 and ericbish for reporting this issue, and apologies again to all users for any inconvenience caused

[sakaki]

Hello,

I've just posted a v1.3.0 release of my bootable 64-bit Gentoo image for the RPi3 (model B and B+) on GitHub (here, includes full download instructions).

A changelog from the prior release image (with upgrade instructions) may be viewed here, but in summary:

• Migrated from porthash repository verification to Gentoo's own, official gemato-based approach (with failure quarantine). Accordingly, the porthash USE flag on dev-embedded/rpi3-64bit-meta has switched from default-on to default-off as of v1.3.0, and the weekly-gated rsync URI has changed (to one without polluting porthash signatures), from rsync://isshoni.org/gentoo-portage-pi64 to rsync://isshoni.org/gentoo-portage-pi64-gem. (The older version will continue to be supported for a time, for backwards compatibility during the changeover period.)
• Added support for the transparent-compression write-through zswap cache to bcmrpi3-kernel-bis, and created a startup service (rpi3-zswap) to start using it. Given the highly compressible nature of most RAM pages on a running system, and the RPi3's relatively meagre I/O capabilities, this should materially improve system responsiveness under load. Parameterized via /etc/conf.d/rpi3-zswap.
• Added a startup service (rpi3-expand-swap), to increase the ('real', backing-store-based) swapfile size to 1GiB, space permitting, as a one-off operation post root partition and filesystem resize. Parametrized via /etc/conf.d/rpi3-expand-swap.
• Various minor ebuild tidy-ups.
• All packages brought up-to-date against the Gentoo tree, as of 16 September 2018, including Firefox Quantum v61.0, GIMP v2.10.4 etc. Most packages have been rebuilt on gcc-8.2 (which should bring a small performance improvement).
• Kernel upgraded to sys-kernel/bcmrpi3-kernel-bis-bin-4.14.71.20180922, accompanying boot firmware to sys-boot/rpi3-64bit-firmware-1.20180919 (these will of course auto-update as new versions are unmasked).

A variant image for the Pi-Top v1 (an RPi3-based DIY laptop) is also included.

Have fun ^-^

And, as always, any problems or comments, please post either in this thread, or in the project's (sticky) thread on the Gentoo forums (here).

[Gavinmc42]

Thanks Sakaki,
Just in time for our long weekend

[sakaki]

The v1.3.0 gentoo-on-rpi3-64bit image is now also available for install through PINN (called Gentoo64 there), courtesy of procount.

Best, sakaki

[sakaki]

Hello,

FYI, firefox-62.0.2 (64 bit) has just been pushed to the binhost. Following upstream, I've built this under clang-7 rather than gcc, with lto (link-time optimization) turned on; this route reportedly yields measurable speedups during use. I've also turned on the hwaccel USE flag, so hopefully video blitting from youtube etc. will now be using the vc4 gl pipeline.

Here's a screenshot (note the app's title name has changed from 'Aurora' to 'Nightly', as it is a release-channel build with the bindist USE flag):



Users on the latest v1.3.0 gentoo-on-rpi3-64bit image just need to run genup (as root, or using sudo) to get the updated browser via binary package - or, if you prefer, simply wait for the system's weekly autoupdate to do this for you. (If you have a significant amount of work invested in an older release of this image, I have also provided manual upgrade instructions (from 1.0.0 thru 1.2.2 → 1.3.0) here.)

As there are quite a few things changed with this new release of firefox, please let me know if you find it any faster / more flaky etc. than before, so I know whether to keep the changes or revert to gcc / no lto / no hwaccel. Many thanks!

have fun ^-^

sakaki

PS: firefox-62.0.2 requires a small patch to build on arm64; I discuss this here, and have pushed a matching www-client/firefox-62.0.2 ebuild to the rpi3-overlay used by the gentoo-on-rpi3-64bit image. If you want to build it yourself from source, you'll probably need to use a user mode binfmt_misc qemu chroot on a PC, as I did, to avoid stalling out on swap: the final lto link step is very memory hungry.

[katte]

Hi, thanks for your work.
Is possible to run 64bit Gentoo on the compute module 3?

[sakaki]

Is possible to run 64bit Gentoo on the compute module 3?

I don't see why not, although I don't currently own one to check. The inbuilt wifi and bluetooth are not present on the CM3, so you'd have to disable the matching services (rpi3-bluetooth and rpi3-wifi-regdom), but even with those left active the image should still boot, I think.

You may have an issue with storage though. The baseline CM3 has 4GB of onboard eMMC I believe, and my full Gentoo system as shipped needs at least 8GB (when uncompressed), but then this is for a system with a full graphical desktop, libreoffice, firefox quantum, clang/llvm, gcc, etc. (package list here).

You could almost surely pare the system down to <4GB if you uninstalled what you didn't need: I have instructions for doing this on the project's wiki here. You could also/alternatively use a compressed r/o 'base' filesystem (e.g. SquashFS) with changes written to a writeable fs (ext4 etc.) via e.g. OverlayFS (see e.g. here), this is relatively sane if your deployed embedded application won't try to update itself that often. Given that the (xz) compressed gentoo-on-rpi3-64bit system is <1.5GB, you could conceivably even run the full image that way.

Alternatively, according to this post, NEC produce a version of the CM3 with 16GB flash, or yet again, you could use the CM3L which allows an external SD to be used on the carrier.

If you try this out, please let me know how it goes; I'll help out if I can.

Best, sakaki