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

[ericbish]

ericbish,

you're welcome, glad it is finally working again!

PS: I'm a she not a he ^-^

Ooopsie, sorry.

Thank you Ma'am!

[Sakaki]

All,

I've just posted a v1.3.1 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:

• Added the full-scale www-client/chromium web browser (in addition to www-client/firefox, which remains supported and included on the image). Note that the version on the image (71.0.3578.62-r2) uses a slightly modified ebuild, which adds the openh264 USE flag, and is built with "-proprietary-codecs -openh264" USE (this removes all the (patent encumbered) h264 code from the application, so it may be lawfully distributed in binary form). You can rebuild it yourself with modified USE flags yourself if you wish, of course.
• The minimum supported microSD card capacity has been increased to 16GB (up from 8GB). In reality, with recent versions of the image 8GB cards were only really useful for a quick tryout; they were too small to properly genup etc., and 16GB cards are now readily available and relatively inexpensive. The initial (uncompressed) image size is now 11,328MiB (of which the root partition is 11,264MiB (11GiB), which will be autoexpanded to fill any additional free space on first boot of course), so this provides reasonable headroom. The current image is ~1.32GiB in compressed form.
• Added the pyconfig_gen utility, for easy (GUI-based) update of (a subset of the features contained in) the /boot/config.txt file on the RPi3. This utility is autostarted on first boot for each user. Changes made to the /boot/config.txt file using this application are subject to ratification on reboot; if the user does not explicitly accept them before a short time limit expires, an automatic reboot under the prior, 'last known good' config is performed. This prevents users locking themselves out by specifying (e.g.) an HDMI mode that is unsupported by their display (as an additional precaution against this particular case, only modes reported as being supported by the currently connected display are presented for selection in the GUI). Currently, only a small (but hopefully, useful) subset of the options available may be edited via this application, but this will be increased in future. It is still possible to directly edit /boot/config.txt - the app ignores keys it does not manage. A tool screenshot may be viewed here.
• As a bonus side-effect of the above, the PyQt5 framework - including the Qt5 Designer GUI editor - has been added to the image.
• Added an Xfce4 startup service, xfce-extra/xfce4-noblank, to prevent the user's xscreensaver blanking the display when notionally 'off', since this can cause problems with some displays (under vc4-{f,}kms-v3d graphics drivers, at least) where the display cannot be powered back up once blanked in this manner (by regular mouse or keyboard activity, anyhow). Installs an /etc/xdg/autostart/xfce4-noblank.desktop entry.
• Updated the kernel to sys-kernel/bcmrpi3-kernel-bis-bin-4.14.90.20181222 (and the boot firmware to sys-boot/rpi3-64bit-firmware-1.20181112).
• Various minor ebuild tidy-ups.
• All packages brought up-to-date against the Gentoo tree, as of 26 November 2018.

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

A screenshot of the (vanilla) image in use, on an RPi3B+, may be viewed here.

Have fun ^-^

And, as always, any problems or comments, please just post below.

PS: the isshoni.org binhost (and mirror) has been frozen vs the Gentoo tree since around a month ago, while this image has been in prep. Now the image is released, the autobuild process will be allowed to run again, so there should be an updated Portage tree plus updated binary package set available shortly, and the normal weekly-cadence service will resume thereafter. Apologies for any disruption this has caused ><

[Sakaki]

Hello,

If you'd like to try out .NET applications on your gentoo-on-rpi3-64bit system, you may be interested to know I've just pushed a build of dev-lang/mono-4.8.0.524 to the binhost (mono is a an open source implementation of Microsoft's .NET Framework).

To emerge it (assuming you're starting from a reasonably up-to-date version of the image), just issue:

Code: Select all

demouser@pi64 ~ $ emaint sync --repo rpi3
demouser@pi64 ~ $ emerge -av dev-lang/mono

This is a binary package, so shouldn't take too long to install.

Then you can try it. The bundled C# compiler is called mcs. So for a simple 'hello world' (following this post):

Code: Select all

demouser@pi64 ~ $ mkdir HelloWorld && cd HelloWorld
demouser@pi64 ~/HelloWorld $ nano -w HelloWorld.cs

Put the following text in that file:

Code: Select all

using System;

public class HelloWorld
{
    public static void Main()
    {
        Console.WriteLine("Hello World!");
    }
}

Save, and exit nano. Then:

Code: Select all

demouser@pi64 ~/HelloWorld $ TERM=xterm mcs HelloWorld.cs

(The TERM=xterm is to ensure you don't get hit by bug 6752; haven't got the mono-5.x series to build on aarch64 yet; if you have, please let me know!).

You should now have a HelloWorld.exe .NET program. To run it:

Code: Select all

demouser@pi64 ~/HelloWorld $ TERM=xterm mono HelloWorld.exe
Hello World!

[satanail]

First of all, good job Sakaki !! I have rpi3b+ as well, tried to test your img on it, connected to a webos powered lg tv, with autoroot_expand_none, with hanging on a blackscreen, maybe I should tweak something more, because using my own kernel or editing config.txt didn't work, but still I have a different use case for my it anyway, and I'm not asking for support. So I want to you ask you if you have any plans for making the same with musl instead of glibc? I've already built a stage3 hardened/arm64/musl and plan on sharing it, when it's more shaped. I want it to be as light as possible, plus the more 'gentoo stages' to choose from, the better. My 2015 phone is using cortex-a53 cpu as the rpi3b+, so 1 build env for 2 devices feels like Christmas to me. Through researching I found out that we could use neon vfpu4 for that CPU, which should use even less memory and speed up things even more, than pure 64bit. Having more people using hardened musl/arm64 on gentoo would definately improve things. It sucks having to look for workarounds in void/alpine for various packages. Out of curiosity, what is your evaluation about the performance of that device, using it as a fully-fledged gentoo system?

[Sakaki]

First of all, good job Sakaki !! I have rpi3b+ as well, tried to test your img on it, connected to a webos powered lg tv, with autoroot_expand_none, with hanging on a blackscreen, maybe I should tweak something more, because using my own kernel or editing config.txt didn't work, but still I have a different use case for my it anyway, and I'm not asking for support.

Thanks! Does the image work for you if you just write a vanilla copy of it to a >=16GB microSD card and don't set autoexpand_root_none prior to first boot? I haven't had any other reports of the 1.3.1 image failing to start up (so far anyhow ^-^). Of course it may not be recognizing your connected display for some reason: you could try setting hdmi_safe=1 in config.txt, to see if that helps.

So I want to you ask you if you have any plans for making the same with musl instead of glibc? I've already built a stage3 hardened/arm64/musl and plan on sharing it, when it's more shaped.

At the moment, I'm afraid not. Hands full with various RISC-V and Power9 projects right now ><

Out of curiosity, what is your evaluation about the performance of that device, using it as a fully-fledged gentoo system?

The RPi3B/B+ is very usable as a lightweight 64-bit desktop, and browser performance (Chromium / Firefox) is actually not too bad. The issue with Gentoo of course is the "compile everything" bit (^-^) which a small system like this is always going to struggle with. For that reason, the gentoo-on-rpi3-64bit project is backed by a binhost, custom profile and overlay, which means that for 'regular' users (not going off-piste with custom USE flags etc.) emerge updates to most of the mainstream large packages (libreoffice, firefox, gcc, llvm etc.) will essentially always be from binaries. To build binary packages for the binhost in the first place, I generally use a mix of distcc and (more and more now) a QEMU user-mode binfmt_misc chroot (into the image) on a PC workstation (see my notes here and here ff). That helps keep things manageable.

[satanail]

Thanks! Does the image work for you if you just write a vanilla copy of it to a >=16GB microSD card and don't set autoexpand_root_none prior to first boot? I haven't had any other reports of the 1.3.1 image failing to start up (so far anyhow ^-^). Of course it may not be recognizing your connected display for some reason: you could try setting hdmi_safe=1 in config.txt, to see if that helps.

Thank you for the fast response. Unfortunately can't test right now, seems like ext4 partition got corrupted, because of the hard shutdown. I'm testing on a 64gb sdcard, so I got plenty of space. Is hdmi_safe=1 set by default, if config.txt is not existing? Because I deleted it from my Image and HDMI works.

The RPi3B/B+ is very usable as a lightweight 64-bit desktop, and browser performance (Chromium / Firefox) is actually not too bad. The issue with Gentoo of course is the "compile everything" bit (^-^) which a small system like this is always going to struggle with. For that reason, the gentoo-on-rpi3-64bit project is backed by a binhost, custom profile and overlay, which means that for 'regular' users (not going off-piste with custom USE flags etc.) emerge updates to most of the mainstream large packages (libreoffice, firefox, gcc, llvm etc.) will essentially always be from binaries. To build binary packages for the binhost in the first place, I generally use a mix of distcc and (more and more now) a QEMU user-mode binfmt_misc chroot (into the image) on a PC workstation (see my notes here and here ff). That helps keep things manageable.

I never compiled anything, nor plan to compile on the rpi. I'm already using a qemu wrapper with --cpu=cortex-a53 to be able to chroot into the custom musl stage and compile 'natively'. I never used distcc. I have 5 phones, will it make it so they share compilation alltogether or it just works for 2 devices? I guess I have to do some bit of researching. Thanks again for the points you made.

[Sakaki]

Is hdmi_safe=1 set by default, if config.txt is not existing? Because I deleted it from my Image and HDMI works.

No, by default (empty or absent config.txt file), the RPi3 will attempt to set an appropriate HDMI group and mode automatically, based upon the EDID data reported by your display. NB if you delete config.txt, you'll also be using the fallback framebuffer display driver, not the accelerated vc4-(f)kms-v3d one, so video playback etc. will be slower.

I never used distcc. I have 5 phones, will it make it so they share compilation alltogether or it just works for 2 devices?

Given an appropriate build, and distcc{,d} configuration, it will use as many server nodes as you can throw at it ^-^ Not all builds can be distributed in this way however. See my notes linked above and this page on the Gentoo wiki, for more info.

[satanail]

Is hdmi_safe=1 set by default, if config.txt is not existing? Because I deleted it from my Image and HDMI works.

No, by default (empty or absent config.txt file), the RPi3 will attempt to set an appropriate HDMI group and mode automatically, based upon the EDID data reported by your display. NB if you delete config.txt, you'll also be using the fallback framebuffer display driver, not the accelerated vc4-(f)kms-v3d one, so video playback etc. will be slower.

I never used distcc. I have 5 phones, will it make it so they share compilation alltogether or it just works for 2 devices?

Given an appropriate build, and distcc{,d} configuration, it will use as many server nodes as you can throw at it ^-^ Not all builds can be distributed in this way however. See my notes linked above and this page on the Gentoo wiki, for more info.

Just to report back, the problem wasn't lying in your *.img. It was the SD card. Freshly 'dd'-ing your image to the sd was rendering ext4 corrupted, without even booting it, so I tested with another 32gb sdcard and it works. I got some weird resolution with fkms-v3d, got 1834x796 or sth, instead of 1920x1080p, was running very smooth and fast without the composer, until I tried out kodi. Not saying anything, it's not your fault, I'm actually really glad there's people like you, in fact I researched a bit about you and I think I'm in love.

[Sakaki]

I got some weird resolution with fkms-v3d, got 1834x796 or sth, instead of 1920x1080p, was running very smooth and fast without the composer, until I tried out kodi.

Assuming you're running version 1.3.1 of the image, you can use the graphical Applications -> Settings -> RPi3 Config Tool to change the HDMI group and mode to something appropriate for your display. Even if the EDID from your display is providing 'odd' values, you can check '"Override HDMI display's reported EDID (if any)", then choose either HDMI group 1 (CEA) HDMI mode 5 (which is 1920 x 1080; see the full list here) or HDMI group 2 (DMT) mode 82 (also 1920 x 1080), and click "Save and Exit". Your RPi3 will reboot into (hopefully) the correct resolution. Upon restart, choose when prompted to retain the changes.

Alternatively, you can just add the following (e.g.) to your config.txt (as that's what the config tool does):

Either append:

Code: Select all

hdmi_group=1
hdmi_mode=5
hdmi_ignore_edid=0xa5000080

or append:

Code: Select all

hdmi_group=2
hdmi_mode=82
hdmi_ignore_edid=0xa5000080

As for kodi playback, all 64-bit distros on the RPi3 (not just Gentoo) have the problem that the MMAL and OpenMax IL APIs, to access the gpu's h/w video codecs (amongst other things), are currently unsupported (when the SoC is booted in 64-bit mode). This limits the max performance when playing back video somewhat.

[satanail]

I got some weird resolution with fkms-v3d, got 1834x796 or sth, instead of 1920x1080p, was running very smooth and fast without the composer, until I tried out kodi.

Assuming you're running version 1.3.1 of the image, you can use the graphical Applications -> Settings -> RPi3 Config Tool to change the HDMI group and mode to something appropriate for your display. Even if the EDID from your display is providing 'odd' values, you can check '"Override HDMI display's reported EDID (if any)", then choose either HDMI group 1 (CEA) HDMI mode 5 (which is 1920 x 1080; see the full list here) or HDMI group 2 (DMT) mode 82 (also 1920 x 1080), and click "Save and Exit". Your RPi3 will reboot into (hopefully) the correct resolution. Upon restart, choose when prompted to retain the changes.

Alternatively, you can just add the following (e.g.) to your config.txt (as that's what the config tool does):

Either append:

Code: Select all

hdmi_group=1
hdmi_mode=5
hdmi_ignore_edid=0xa5000080

or append:

Code: Select all

hdmi_group=2
hdmi_mode=82
hdmi_ignore_edid=0xa5000080

As for kodi playback, all 64-bit distros on the RPi3 (not just Gentoo) have the problem that the MMAL and OpenMax IL APIs, to access the gpu's h/w video codecs (amongst other things), are currently unsupported (when the SoC is booted in 64-bit mode). This limits the max performance when playing back video somewhat.

Your so descriptive with every answer lol and yes, from the first boot I selected CEA with 1920x1080p@60Hz, but still it gets 1830xsth resolution(it's a 2016 lgtv), which is weird. Please do not stay with the impression that I seek for support or take it as whining, I'm just sharing, please let me fix issues myself lol Your github/gentoowikis are enough! I plan on using the PI as a router anyways, so give me the pleasure and fill me up with some userspace tools that'll make me do things faster, please

[NeddySeagoon]

satanail,

TV ..

Is something somewhere doing overscan, or expecting overscan?

Overscan was something common in the days of CRT TV, when the picture size on the screen varied noticeably with temperature and a few other things.
It ensures that the image always fills the screen by throwing some away at the edges.
The Pi can generate an image suitable for an overscanned display if you tell it to.
I'm fairly sure that Sakakis image does not do that.

What about your TV setup?
It will do both and by tradition, it will have overscan on. Search through the menus and check.

With a digital source (Pi) and digital screen (any LCD), overscan should be avoided. Its certainly not required.

-- edit --

Feel free to use my arm64 BINHOST if you feel the need for speed.
Its all Pi compatible.

[Sakaki]

satanail,
The Pi can generate an image suitable for an overscanned display if you tell it to.
I'm fairly sure that Sakakis image does not do that.

Yes, as shipped, overscan is turned off on the image, but the simple GUI-based config.txt editor bundled from the 1.3.1 release allows it to be set easily (screenshot).

[satanail]

satanail,

TV ..

Is something somewhere doing overscan, or expecting overscan?

Overscan was something common in the days of CRT TV, when the picture size on the screen varied noticeably with temperature and a few other things.
It ensures that the image always fills the screen by throwing some away at the edges.
The Pi can generate an image suitable for an overscanned display if you tell it to.
I'm fairly sure that Sakakis image does not do that.

What about your TV setup?
It will do both and by tradition, it will have overscan on. Search through the menus and check.

With a digital source (Pi) and digital screen (any LCD), overscan should be avoided. Its certainly not required.

-- edit --

Feel free to use my arm64 BINHOST if you feel the need for speed.
Its all Pi compatible.

Yes, I've rebooted around 10 times, tinkering with the specified GUI tool, tried every seemingly viable option. Also tried both enabled/disabled overscan. Both modes were same resolution. When disabled I was getting the mentioned 'throwing the screen away at the edges', so I re-enabled with four 0's. For real I bought this pi3 to replace an ancient tplink wr740nv4 router. In the meantime and while I'm prepping the rootfs I could use it to watch movies, cuz why not? I have two spare rpi0's, which I plan to use one of them with Kodi. Good thing it supports gbm... Will see how it goes. Thanks for sharing your binhost, maybe I can make use of it. By any chance, do you have a binhost for armv6j as well?

[Sakaki]

All,

h/w video acceleration on the RPi3 may be imminent. From this thread:

> Hardware video acceleration on Kodi using 64bit OS.

Should now be possible on the 4.19 branch using the V4L2 M2M interface (supported by FFmpeg and hence Kodi). The LibreELEC guys were working on patches for FFMpeg to export dmabufs from V4L2 so that they could import into DRM, but that seems to have dropped down their projects list.

There may be one fixup that I need to push as mapping a kernel pointer into an IDR to pass as a 32 bit value to VC. I'll confirm when I'm back in the office.

[NeddySeagoon]

satanail,

I put my Pi 1 away when I got a Pi 3.
There is some old armv6j binaries there but they predate my P3, so I should probably take them down now.

[twalter]

satanail,

TV ..

Is something somewhere doing overscan, or expecting overscan?

Overscan was something common in the days of CRT TV, when the picture size on the screen varied noticeably with temperature and a few other things.
It ensures that the image always fills the screen by throwing some away at the edges.
The Pi can generate an image suitable for an overscanned display if you tell it to.
I'm fairly sure that Sakakis image does not do that.

What about your TV setup?
It will do both and by tradition, it will have overscan on. Search through the menus and check.

With a digital source (Pi) and digital screen (any LCD), overscan should be avoided. Its certainly not required.

-- edit --

Feel free to use my arm64 BINHOST if you feel the need for speed.
Its all Pi compatible.

Yes, I've rebooted around 10 times, tinkering with the specified GUI tool, tried every seemingly viable option. Also tried both enabled/disabled overscan. Both modes were same resolution. When disabled I was getting the mentioned 'throwing the screen away at the edges', so I re-enabled with four 0's. For real I bought this pi3 to replace an ancient tplink wr740nv4 router. In the meantime and while I'm prepping the rootfs I could use it to watch movies, cuz why not? I have two spare rpi0's, which I plan to use one of them with Kodi. Good thing it supports gbm... Will see how it goes. Thanks for sharing your binhost, maybe I can make use of it. By any chance, do you have a binhost for armv6j as well?

Check for your TV's scaler mode; you want Dot-for-Dot if available. Some sets have a 'PC' input where this (and only on this input) will have this enabled. Mine enables it when I label the input 'PC' so there's options. Watch out if you're running through a receiver, you will need to set 'passthru' or cable around it.

[antonlacon]

All,

h/w video acceleration on the RPi3 may be imminent. From this thread:

> Hardware video acceleration on Kodi using 64bit OS.

Should now be possible on the 4.19 branch using the V4L2 M2M interface (supported by FFmpeg and hence Kodi). The LibreELEC guys were working on patches for FFMpeg to export dmabufs from V4L2 so that they could import into DRM, but that seems to have dropped down their projects list.

There may be one fixup that I need to push as mapping a kernel pointer into an IDR to pass as a 32 bit value to VC. I'll confirm when I'm back in the office.

I was configuring a kernel today and it appears that 4.19 has been pushed to the primary upstream kernel version, and it has 64-bit mmal commits. There's an open PR with more v4l2 work in it.

[Sakaki]

I was configuring a kernel today and it appears that 4.19 has been pushed to the primary upstream kernel version, and it has 64-bit mmal commits. There's an open PR with more v4l2 work in it.

Thanks for the heads up! I've updated my bcmrpi3-kernel and bcmrpi3-kernel-bis 64-bit autobuilds accordingly; binary kernel tarballs are therefore available for anyone who'd like to have a play (see links just given, for download instructions) ^-^

Hint: you may have better luck using vc4-kms-v3d than vc4-fkms-v3d with these kernels atm.

[Precision]

Thank you, Sakaki, for making this all possible.

I have reduced my Pi installation to a minimum, following Sakaki's guide. Next, I would like to replace networkmanager with connman, as connman is designed with small, embedded devices like the Raspberry Pi in mind. Can anyone think of a reason this would be a bad idea?

[NeddySeagoon]

Precision,

Do it!

Then tell us all about it :)

[Sakaki]

Hello,

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

This release marks a significant milestone for 64-bit OSes on the RPi3, as, leveraging the hard work by 6by9 and others on the rpi-4.19.y kernel, use of the Pi's camera module and the Pi's hardware video codecs are now both supported! [1]

These new features have been requested for some time, and indeed their absence in 64-bit mode has often been cited as a reason to stick with a 32-bit OS. To help showcase them, I've provided two (trivial! [2]) bundled apps, pi-ffcam and pi-ffplay, so you can quickly try them out yourself! Hopefully, the v4l2 m2m codec data paths, on which these apps rely, will soon also be integrated into VLC, Firefox etc. ^-^

A screenshot of the two apps running on an RPi3B+, with an attached Pi camera module v2 (Pi-Top v1 chassis) may be viewed here.

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

• Kernel migrated to rpi-4.19.y (sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226). As just noted, this represents a significant upgrade, as a number of features (such as v4l2 m2m codec support) are only available in 4.19, and will not (aiui) be backported to 4.14. The boot firmware was also updated to sys-boot/rpi3-64bit-firmware-1.20190213, and the userland libraries to media-libs/raspberrypi-userland-1.20190114.
• Thanks to advice and patches from 6by9, added a version of ffmpeg that can both access the Pi's v4l2 camera (via /dev/video0) and access the Pi's hardware video codec capabilities, via v4l2 m2m (memory-to-memory) interfaces at /dev/video{10,11,12}. The h264_v4l2m2m, mpeg4_v4l2m2m, and (if you have purchased a license key) mpeg2_v4l2m2m codecs all currently work from 64-bit userland. (Note, I have primarily tested decoding, as that is relevant for video playback, but these endpoints should support hw-based encoding too (for h264 and mpeg4, anyhow).)
• Added (via USE flag on media-plugins/gst-plugins-meta) the necessary additional gstreamer library, to allow it to also access the v4l2 m2m endpoints (media-plugins/gst-plugins-v4l2-1.14.4).
• Added the pi-ffcam app, a trivial 'live viewer' for the Pi camera module v1/v2 (available under the "Multimedia" menu, as shown in the screenshot above). This streams an h264-encoded live video feed from the camera, decodes it using h264_v4l2m2m (i.e., a hardware codec, just for fun ^-^), and then displays the output in an SDL desktop window. It is built on ffmpeg / ffplay. Note that due to buffering, the stream has around a 1s lag. (Also note that you wouldn't build a 'real' live view app like this of course; it's main purpose is to provide confidence that the various interfaces are working.)
• The media-tv/v4l-utils package is also included; this provides an app (Multimedia -> Qt V4L2 test Utility) that may also be used (inter alia) to live-view the camera (although I have found its GL output to be unreliable).
• Added the pi-ffplay app, a trivial video player that can utilize the Pi's built-in hardware codecs just described, for h264, mpeg4, and - if you have purchased the license - mpeg2 (this may also be found under the "Multimedia" menu; the cursor is on it in the screenshot above). The app prompts for a video to play, attempts to probe its video stream type, and plays it, forcing (where possible) an appropriate v4l2 m2m hardware codec (stream decode only; actual blit of the rendered bitmaps to the window is still via the regular pipeline). This uses the standard ffplay underneath, so consult its manpage for details (double-click to toggle full screen etc.) If the video contains an audio track, this will be played also. Unfortunately, the other bundled video playback apps (VLC, Kodi, and SMPlayer) do not yet leverage the m2m codec paths by default - at least, not in the versions currently provided. If you know how to make them do this (either by preference file, USE flag or patching) please let me know! It is a similar case (at the moment) for the bundled Firefox and Chromium browser (the latter can use v4l2 m2m, but only in an ozone build context right now). That's a shame - files like http://jell.yfish.us/media/jellyfish-50 ... d-h264.mkv (1920x1080 50Mbps) choke the RPi3 (even B+) under software rendering, but display relatively smoothly when using the v4l2 m2m codecs (you can easily try for yourself, just download the file and try playing it with e.g. VLC or SMPlayer (the latter does the better job), then try again with ff-play). But as making the connection (particularly where ffmpeg or gstreamer are used 'under the hood') is a relatively straightforward matter, these facilities will hopefully be added in relatively short order.
• The default GPU memory setting in /boot/config.txt has been increased, to 128 MiB from the prior (de minimis) 16 MiB. Per 6by9 and my own empirical tests, this should be sufficient to permit both camera and v4l2 m2m codec use simultaneously, for most use cases (as in the above screenshot). The camera interface has also been selected by default (start_x=1). NB: if you do not need to use the codecs (or camera) please feel free to revert these settings (memory being a precious resource on the RPi3!).
• The pyconfig_gen application has been updated; it now allows setting of gpu_mem, and selection of the camera interface (start_x=1).
• Although I have elected to stay with fkms in this release, for regular RPi3 users, 'true' kms (vc4-kms-v3d) should prove an entirely viable option now (and this can easily be selected via the pyconfig_gen application); I have one system that has been running this for weeks now, and it seems very usable (and exhibits maybe 5-10% more GL bandwidth relative to an fkms system, when compared on a like-for-like, no-display-manager-compositing basis). Please note that under vc4-kms-v3d, window manager compositing should be turned off to prevent periodic 'stalling' of the GUI, and so I have modified the existing rpi3-safecompositor service to do this automatically. For avoidance of doubt, fkms - the shipped default - is unaffected.
• Various minor ebuild tidy-ups.
• All packages brought up-to-date against the Gentoo tree, as of 19 February 2019 (which means e.g., www-client/firefox-65.0.1, www-client/chromium-72.0.3626.96-r1, app-office/libreoffice-6.1.5.2 etc. are bundled; a full list of installed packages may be found here).

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

A screenshot of the (vanilla) image in use, on an RPi3B+ may be viewed here.

Have fun ^-^

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

PS: the isshoni.org binhost (and mirror) has been frozen vs the Gentoo tree since 19 February, while this image has been in prep. Now the image is released, the autobuild process will be allowed to run again, so there should be an updated Portage tree plus updated binary package set available shortly, and the normal weekly-cadence service will resume thereafter. Apologies for any disruption this has caused ><

[1] There's still no 64-bit userland MMAL just yet, but things are getting closer; in any event, hardware video codec access is one of the big reasons people wanted MMAL ported to 64-bit in the first place, so getting access to this facility via the v4l2 m2m endpoints instead will obviate the need for it, in many cases ^-^

[2] Once ffmpeg has the necessary v4l2 m2m codec support built in (which the version on the image has) then exploiting these features from the command line is trivial - the provided demo apps are simply wrappers there to lower initial barrier to entry.

See for example the example CLI 'recipes' in this project's open wiki.

Edit: fix forum link

[Sakaki]

Hello,

I've just noticed there is an issue affecting video playback on sites like youtube with the version of chromium (72.0.3626.96-r1) supplied on the new 1.4.0 image (the bundled firefox however works fine).

To fix this, by rolling back to the prior version (72.0.3626.28-r2), first ensure you have network connectivity, then open a terminal and issue:

Code: Select all

demouser@pi64 ~ $ sudo emaint sync --repo rpi3
demouser@pi64 ~ $ sudo emerge -vu www-client/chromium dev-embedded/rpi3-64bit-meta

This will install the prior (72.0.3626.28-r2) version from a binary package, so the process shouldn't take long (10 minutes or so).

Apologies, I should have caught that in testing ><


Update 10 March 2019: a new 1.4.1 release of the image is available, which fixes this issue; please see this post for more details.

Best, sakaki

[antonlacon]

Unfortunately, the other bundled video playback apps (VLC, Kodi, and SMPlayer) do not yet leverage the m2m codec paths by default - at least, not in the versions currently provided.

V4L2 for Kodi is a version 19 feature. However, if you're feeling adventurous, you can try setting it up to use an external player: https://kodi.wiki/view/External_players

[Sakaki]

Hello,

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

For screenshots, and details of the major changes - including camera and hardware codec support - introduced in 1.4.0, please see my earlier post.

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

• Upgraded the bundled chromium web browser, to www-client/chromium-72.0.3626.121-r1; this version fixes the serious CVE-2019-5786 bug (thanks to cjan for pointing this out), and also a problem that was preventing videos playing correctly on YouTube.
• Made the boot-time services rpi3-spidev and rpi3-i2cdev core dependencies of rpi3-64bit-meta, so they are always installed, and also modified the rpi3-i2cdev service, so it only loads the relevant kernel module if I2C is turned on in /boot/config.txt. Fixes an issue where turning on I2C in the pyconfig_gen application was not sufficient to have it enabled after reboot. Thanks to procount for reporting.
• Various minor ebuild tidy-ups.
• All packages brought up-to-date against the Gentoo tree, as of 19 February 2019 (with the exception of chromium, which has been backported to address a serious security concern; as noted above).

Users on the prior 1.4.0 release can simply run "sudo genup" in a terminal to upgrade to 1.4.1 (or wait for the weekly autoupdate to do it on your behalf). Manual upgrade instructions for users on older versions of the image are also provided, here.

Have fun ^-^

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

[salfter]

I'm trying to block the 4.19.* kernel from installing since it has some USB problems described elsewhere. I have this in /etc/portage/package.mask/bcmrpi3-kernel-bis-bin:

Code: Select all

=sys-kernel/bcmrpi3-kernel-bis-bin-4.19.25.20190226

I tried this first:

Code: Select all

>=sys-kernel/bcmrpi3-kernel-bis-bin-4.19

Both of these are ignored when I emerge @world; it keeps wanting to pull in the newer kernel instead of leaving the 4.14.* kernel alone. This is blocking an update of other packages (though I suppose I could get the list of ebuilds to be updated, filter out the kernel update, and do the rest).