Bootable 64-bit RPi3/Pi4 Gentoo image (OpenRC/Xfce/VC4) Pt 2

[Sakaki]

orion777, Gavinmc42

The default autounmask behaviour in Portage changed with 2.3.77 (which the latest genup will have pulled in). Per release notes here:

[Sakaki]

Migration of certain Gentoo directory paths

Hello,

I'm in the final stages of preparing a v1.5.2 release of the image, and as part of this have, following upstream policy [1,2], migrated certain Gentoo system paths, as follows:

• /usr/portage -> /var/db/repos/gentoo ($PORTDIR)
  
• /usr/portage/distfiles -> /var/cache/distfiles ($DISTDIR)
  
• /usr/portage/packages -> /var/cache/binpkgs ($PKGDIR)
  
• /usr/local/portage/<overlay> -> /var/db/repos/<overlay>

If you are currently using v1.5.1 or earlier of this image, please be aware that a fixup script has been added to the repo, which will migrate the directories on your system to the new locations for you (script here).

This fixup script will be run automatically, within a week at most, by a cron.weekly service already installed on your RPi. However, if you wish to correct the directory locations immediately (or you have the weekly fixup service disabled), then simply issue the following commands on your RPi (if running as demouser, prefix them with sudo):

[n1ese]

[Sakaki]

[n1ese]

[Sakaki]

[n1ese]

[Sakaki]

[n1ese]

[Sakaki]

No worries, glad you got it tracked down ^-^
_________________
Regards,

sakaki

[n1ese]

Sakaki, something has changed in a recent update and I can't figure out how to fix it. On a fresh 1.5.1 install, emerge will ask me to autounmask packages but recent updates force me to manually unmask them.

For example, let's look at gpsd:

Fresh 1.5.1 install:

[Sakaki]

Hi n1ese,

I think this is the same point I responded to above?

Basically, the autounmask behaviour of Portage changed with v2.3.77 (release notes), which your update will have pulled in.

To get the old behaviour back, edit your /etc/portage/make.conf and add to the bottom:

[n1ese]

[Sakaki]

Hello,

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

In addition to the usual package version bumps, this update also includes (inter alia):

• (preliminary) support for MMAL from a 64-bit userland (including raspivid, raspistill, ffmpeg etc.);
  
• an EEPROM firmware auto-updater for the RPi4; and
  
• initial network setup for headless boot support.
  

A more detailed list of changes is provided below.

As always, you can burn the image (~1,842MiB compressed) to a microSD card (>=16GB), then boot your RPi3 or RPi4 from it directly (the root partition will be automatically resized to fill the card on first boot). Full instructions for download and use are provided on the project's GitHub page. As before, a 'lite' (CLI-only) image is also provided.

For a screenshot of the image running on a dual-display RPi4 B, please see here.

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

• Added a service, rpi4-eeprom-updater, to automate the upgrading of the RPi4's bootloader and VL805 (USB) EEPROM firmware, patterned on the official rpi-eeprom deb. This service has no effect on the RPi3. For further details, please see this post.
  
• Added (preliminary!) MMAL 64-bit userland support, via the inclusion of 6by9's pointer-wrangling PR#586 into media-libs/raspberrypi-userland (he tagged it "RFC", but as the functionality provided is useful and reasonably orthogonal, I've merged it anyway ^-^). As a result, tools such as raspivid and raspistill are now bundled with the image! (So now if, for example, you have the optional camera module attached, you should be able to issue e.g. raspivid -v -o test.h264 -t 10000 -g 1). (For those interested, OpenMAX-IL is not yet supported in 64-bit.)
  
• Also turned on the mmal USE flag for media-video/ffmpeg, as the necessary support libraries and headers are now present (thanks to the above PR). So, for example, you could play back the above test.h264 file using ffplay -vcodec h264_mmal -i test.h264 (as well as via e.g. ffplay -vcodec h264_v4l2m2m -i test.h264 of course, since the V4L2-M2M h/w codec endpoints remain supported too).
  
• In line with Gentoo upstream, migrated a number of core system paths, as follows (for more details, please see this post):
  • /usr/portage -> /var/db/repos/gentoo ($PORTDIR)
    
  • /usr/portage/distfiles -> /var/cache/distfiles ($DISTDIR)
    
  • /usr/portage/packages -> /var/cache/binpkgs ($PKGDIR)
    
  • /usr/local/portage/<overlay> -> /var/db/repos/<overlay>
    
  and added a fixup to effect the migration for updating users as well.
  
• Added the rpi-onetime-startup service. This runs the script startup.sh from the top-level directory of the FAT filesystem in partition 1, if present, on the first boot (after partition resizing), having first disabled itself from future invocation. It is particularly intended to allow e.g. initial networking to be configured for users of headless systems, and to that end the bundled (/boot/)startup.sh script contains a number of (commented) examples of configuring the wired and wireless interfaces (using nmcli). To use, edit the startup.sh script (on e.g. a Windows or Linux desktop box) on the microSD card to which you have just written the image, prior to first using the card to boot your headless RPi3/4 (users booting the image on a system with attached mouse, keyboard and monitor do not need to do use this facility of course, since networking can be configured via the GUI, once booted).
  
• Added support for the Pimoroni Fan SHIM (a neat, solderless active-cooling daughtercard for the RPi4) to pyconfig_gen (which allows you to set the temperature setpoint for spin-up; the driver has a built-in 10°C hysteresis); also added support for hdmi_enable_4kp60 (allows 60Hz modes on (one) 4K HDMI output). Accessed via Applications->Settings->RPi Config Tool on the image.
  
• In line with the deprecation (by its author) of wiringpi, removed this from the image, and in its place added dev-libs/pigpio's pigpiod daemon to the default runlevel. Its counterpart command-line tool pigs may be used to access the Pi's GPIO (a set of python library bindings for the underlying C library is provided also). wiringpi remains in the binhost, for now (so you can still emerge it if you wish).
  
• Following a suggestion by arizonadrscott (and the pattern used by Raspbian), set up groups and udev rules for GPIO, I2C and SPI, and made demouser a member of these groups. Also added some video group and serial-port aliasing udev rules, again following Raspbian. See sys-apps/rpi-gpio, sys-apps/rpi-i2c and sys-apps/rpi-spi; also sys-apps/rpi-serial and sys-apps/rpi-video for details. Added migration pkg_postinst() rules to join all wheel group members to the gpio, i2c and gpio groups, and dropped the (largely Pi-Top-specific) rpi3-i2cdev and rpi3-spidev services.
  
• Adopted more aggressive MAKEOPTS and MAKE_DEFAULT_OPTS values in /etc/portage/make.conf, as the restricted parallelism (conservatively) enforced in the last release turned out to be confusing for many new users.
  
• Added a fixup to turn off Xfce4-driven DPMS monitor power down, as this was causing (sometimes unrecoverable) monitor blanking during e.g. long genup runs. Thanks to Heeboo for the suggestion.
  
• As of v1.5.0 of the image, the custom x11-misc/arandr on the image installs an /etc/xdg/autostart entry, which invokes the config file ~/.screenlayout/default.sh (if one has previously been saved (from the arandr GUI) by the user). This is useful to create e.g. persistent dual-monitor layouts, but there was no (user-facing) way to stop it running if the commands therein were somehow inappropriate. However, in this release, any default.sh script is not run if the Ctrl key is held down during graphical login.
  
• Added usbhid.mousepoll=0 to /boot/cmdline.txt to improve mouse lag (reported for some setups); thanks to k3lt for the suggestion.
  
• Upgraded the shipped kernels, to bcm{rpi3,2711}-kernel-bis-bin-4.19.86.20191126, and boot firmware, to sys-boot/rpi3-64bit-firmware-1.20190925. Inter alia, the kernels now have CONFIG_STRICT_DEVMEM unset.
  
• Various minor ebuild tidy-ups (including making OpenRC deps conditional on -systemd USE (as requested by Avamander) etc.).
  > Note: the affected services do not yet have systemd unit files and so forth; this change is just to allow those who wish to e.g. cut over the 'lite' image to systemd boot, more easily so to do.
  
• All packages brought up-to-date against the Gentoo tree, as of 16 November 2019. So e.g., chromium bumped to 78.0.3904.50-r2, firefox to 70.0.1, libreoffice to 6.3.3.2 etc.
  

Users already on the prior 1.5.1 or earlier release can upgrade manually by following the instructions given 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 bootable images are also available for download via PINN, for those who prefer that route, called gentoo64 and gentoo64lite there.
_________________
Regards,

sakaki

[n1ese]

Sakaki, what would be the best way to remove bluetooth? Kernel support can stay.

[Sakaki]

[n1ese]

[Sakaki]

[roylongbottom]

Hi Sakaki

Is there a command that clearly identifies that v1.5.2 is installed? I wanted to know after noting the peculiar result, identified below, using the lscpu command. To me, it looks as though my main Gentoo SD card has been updated, with such as gcc now 9.2.0 and Chromium 78.0, then Linux being updated from:

[n1ese]

[roylongbottom]

[feffe]

Thank you very much for your work with this Sakaki!

Is MMAL-decoding supposed to work with Kodi yet? I installed the light-image and installed kodi from the gentoo ports tree (with this patch). ffmpeg is installed with mmal support, and it seems to work, but kodi still uses software decoding when playing videos.

I'm just guessing here; but searching in the source code shows references to MMAL closely related to references to "rbp", so my guess is that you have to create a raspberry-pi build of kodi to enable it. Unfortunately unmasking and enabling the raspberry-pi use flag does not seem to work (the build fails).

Has anyone successfully enabled hardware decoding in kodi on arm64?

[Sakaki]

[Sakaki]

All,

Updated CYW43455 Firmware

it has come to my attention that some of the uploadable firmware for the CYW43455 WiFi/BT chip (RPi3B+/RPi4B) shipped with my current Gentoo image is not the same as that provided by the Raspbian distribution. This appears to cause sub-optimal WiFi performance in some situations, particularly on the RPi4.

I have addressed this by adding Raspbian's version of the affected firmware file [1] to the sys-firmware/brcm43430-firmware package, controlled by the 43455-fix USE flag, removing it from sys-kernel/linux-firmware, basis the same USE flag, and adding the 43455-fix USE flag to the default profile.

So, to get the updated firmware, issue:

[keyson]

Fabulous job to bring gentoo to my pi, thank you Sakaki.

This is sent from my raspberry pi 4 / 4GB running genpi64 .

Regards