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:

Code: Select all

portage-2.3.77
--------------
* The emerge --autounmask option is now disabled by default, except for
  portions of behavior which are controlled by the --autounmask-use and
  --autounmask-license options. For backward compatibility, previous
  behavior of --autounmask=y and --autounmask=n is entirely preserved.
  Users can get the old behavior simply by adding --autounmask to the
  make.conf EMERGE_DEFAULT_OPTS variable.

[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):

Code: Select all

pi64 ~ # emaint sync --repo genpi64
pi64 ~ # /etc/cron.weekly/fixup

Results may be viewed in /var/log/latest-fixup-run.log (the relevant fixup is number 0009, and lives at [3] pre-migration, and [4] post-migration). It does nothing on a system where the directories have already been migrated. (Also, if you are using any layman repos, note that these will not be moved.)

The migration script also ensures that /etc/portage/make.conf contains appropriate definitions for PORTDIR [5], PKGDIR and DISTDIR, and corrects the /etc/portage/make.profile symlink (so it still refers). It also leaves symlinks from the old to new locations, to ease migration (e.g., /usr/portage becomes a symlink to /var/db/repos/gentoo).

Because of the symlinks, any scripts you have that use the old locations should still work, but ideally, replace hardcoded references therein to the appropriate portageq calls. For example:

Code: Select all

#!/bin/bash
# My local script
PORTDIR="$(portageq get_repo_path / gentoo)"
PKGDIR="$(portageq pkgdir)"
DISTDIR="$(portageq distdir)"

Any issues, please post here or email me (sakaki@deciban.com)

Thanks!

References

[1] https://bugs.gentoo.org/378603
[2] https://projects.gentoo.org/council/mee ... ummary.txt
[3] /usr/local/portage/genpi64/app-portage/weekly-genup/files/fixup-0009-migrate-portage-paths.sh
[4] /var/db/repos/genpi64/app-portage/weekly-genup/files/fixup-0009-migrate-portage-paths.sh
[5] Now deprecated, but still used by various downstream scripts.

[n1ese]

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):

Code: Select all

pi64 ~ # emaint sync --repo genpi64
pi64 ~ # /etc/cron.weekly/fixup

I don't appear to have the script on my system. I just finished manually upgrading my 1.5.1 system today with genup.

Code: Select all

ganymede /home/n1ese # emaint sync --repo genpi64
>>> Syncing repository 'genpi64' into '/usr/local/portage/genpi64'...
/usr/bin/git fetch origin
Already up to date.
=== Sync completed for genpi64

Action: sync for repo: genpi64, returned code = 0


ganymede /home/n1ese # /etc/cron.weekly/fixup
bash: /etc/cron.weekly/fixup: No such file or directory

Also, could you help me understand what is going on here while updating?

Code: Select all

* Updating @world set (for new versions, or changed use flags)...
Calculating dependencies... done!

WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict:

dev-util/meson:0

  (dev-util/meson-0.52.0:0/0::gentoo, ebuild scheduled for merge) conflicts with
    <dev-util/meson-0.52 required by (gnome-base/dconf-0.32.0-r1:0/0::gentoo, installed)
    ^               ^^^^

>>> Auto-cleaning packages...

[Sakaki]

I don't appear to have the script on my system. I just finished manually upgrading my 1.5.1 system today with genup.

Do you have the dev-embedded/rpi-64bit-meta package weekly-genup USE flag unset by any chance (check with "eix rpi-64bit-meta")?
If so, the package app-portage/weekly-genup won't be pulled in automatically (and it is this which in turn provides the cron script and fixup files).

However, you can just download and run the relevant fixup script file directly if you like in this case; from here.

Also, could you help me understand what is going on here while updating?

This warning is benign: it just means that a newer version of dev-util/meson (0.52.0) is available and, in the absence of other constraints, could be updated to; however, one or more installed packages is preventing this (here, per the output, it is gnome-base/dconf-0.32.0-r1, which requires <dev-util/meson-0.52, due to this commit). As such, the version installed will remain at 0.51.2 pro tem.

[n1ese]

Do you have the dev-embedded/rpi-64bit-meta package weekly-genup USE flag unset by any chance (check with "eix rpi-64bit-meta")?

It is not unset via the USE flag but not installed.

Code: Select all

ganymede /home/n1ese # eix rpi-64bit-meta
[I] dev-embedded/rpi-64bit-meta [1]
     Available versions:  (~)1.5.0-r9 (~)1.5.1-r7{tbz2} (~)1.5.2-r2{tbz2} {apps +boot-fw +core +innercore +kernel-bin pitop -porthash +weekly-genup +xfce}
     Installed versions:  1.5.2-r2{tbz2}(05:56:43 PM 11/22/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -weekly-genup)
     Homepage:            https://github.com/sakaki-/gentoo-on-rpi-64bit
     Description:         Baseline packages for the gentoo-on-rpi-64bit image

[1] "genpi64" /usr/local/portage/genpi64

[Sakaki]

It is not unset via the USE flag but not installed.

I think it is unset; look at the "Installed versions" line in your reported output from eix ("weekly-genup" has a minus sign in front of it):

Code: Select all

Installed versions:  1.5.2-r2{tbz2}(05:56:43 PM 11/22/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -weekly-genup)

[n1ese]

It is not unset via the USE flag but not installed.

I think it is unset; look at the "Installed versions" line in your reported output from eix ("weekly-genup" has a minus sign in front of it):

Code: Select all

Installed versions:  1.5.2-r2{tbz2}(05:56:43 PM 11/22/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -weekly-genup)

Where would I have it unset? I haven't modified the global USE flag in make.conf other than to set 'python' in order for gpsd to install. Otherwise, it is a very clean, and updated as of today, 1.5.1 install of your image.

[Sakaki]

Where would I have it unset? I haven't modified the global USE flag in make.conf other than to set 'python' in order for gpsd to install. Otherwise, it is a very clean 1.5.1 install of your image.

Have a look in /etc/portage/package.use/rpi-64bit-meta to start with.

[n1ese]

Where would I have it unset? I haven't modified the global USE flag in make.conf other than to set 'python' in order for gpsd to install. Otherwise, it is a very clean 1.5.1 install of your image.

Have a look in /etc/portage/package.use/rpi-64bit-meta to start with.

Oh yeah, I'm dumb. Forgot I disabled all updates since I don't have a permanent internet connection on this device. Forgive me.

[Sakaki]

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

[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:

Code: Select all

# emerge --ask gpsd

Local copy of remote index is up-to-date and will be used.
 * Last emerge --sync was 93d 1h 14m 20s ago.

These are the packages that would be merged, in order:

Calculating dependencies \

!!! Problem resolving dependencies for sci-geosciences/gpsd                   ... done!

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by gpsd (argument)
=sci-geosciences/gpsd-9999 **

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.

Would you like to add these changes to your config files? [Yes/No]

1.5.2-r3{tbz2}(08:31:50 AM 11/24/2019) does not do this, it says everything is unmasked due to missing keyword and I have to manually unmask:

Code: Select all

# emerge --ask gpsd

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "gpsd" have been masked.
!!! One of the following masked packages is required to complete your request:
- sci-geosciences/gpsd-9999::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.19::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.18.1::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.17-r4::gentoo (masked by: missing keyword)
- sci-geosciences/gpsd-3.17-r3::gentoo (masked by: missing keyword)

# echo "=sci-geosciences/gpsd-9999 **" >> /etc/portage/package.accept_keywords/zzz_via_autounmask
# emerge --ask gpsd

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    *] sci-geosciences/gpsd-9999  USE="X bluetooth cxx dbus ipv6 ncurses python qt5 shm sockets udev usb -debug -latency-timing -ntp -static -test" GPSD_PROTOCOLS="aivdm ashtech earthmate evermore fury fv18 garmin garmintxt geostar gpsclock greis isync itrax mtk3301 navcom nmea0183 nmea2000 ntrip oceanserver oncore passthrough rtcm104v2 rtcm104v3 sirf skytraq superstar2 tnt tripmate tsip ublox" PYTHON_TARGETS="python2_7 python3_5 python3_6"

Would you like to merge these packages? [Yes/No]

[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:

Code: Select all

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --autounmask"

[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:

Code: Select all

EMERGE_DEFAULT_OPTS="${EMERGE_DEFAULT_OPTS} --autounmask"

Ahh. yes. You are correct. I'm sorry once again, I know I read this earlier.

[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.

[n1ese]

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

[Sakaki]

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

The simplest way would just be to start the pyconfig_gen app (Applications -> Settings -> RPi Config Tool), select the "Interfaces" tab, uncheck "Enable bluetooth (disables serial port)", and then click "Save and Exit" (being sure to confirm changes upon reboot when prompted).

This currently causes "dtoverlay=pi3-disable-bt" to be written to /boot/config.txt

I believe (though have not personally confirmed) that this will also work on the Pi4, despite the "pi3-" prefix, per this StackExchange post.

[n1ese]

The simplest way would just be to start the pyconfig_gen app (Applications -> Settings -> RPi Config Tool), select the "Interfaces" tab, uncheck "Enable bluetooth (disables serial port)", and then click "Save and Exit" (being sure to confirm changes upon reboot when prompted).

This currently causes "dtoverlay=pi3-disable-bt" to be written to /boot/config.txt

I believe (though have not personally confirmed) that this will also work on the Pi4, despite the "pi3-" prefix, per this StackExchange post.

Oh, I disabled this way a while ago. I was referring to all the software dependencies and so forth. I'm not sure how to remove blueman for instance.

[Sakaki]

Oh, I disabled this way a while ago. I was referring to all the software dependencies and so forth. I'm not sure how to remove blueman for instance.

Well, since e.g. blueman is pulled in by the dev-embedded/rpi-64bit-meta package (with xfce USE), the simplest thing might be to create a local overlay copy of this ebuild, and omit anything (like blueman) you don't want.

Or alternatively, you can also create /etc/portage/profile/package.provided (NB not simply /etc/portage/package.provided, that won't work); and put in it (e.g.):

Code: Select all

net-wireless/blueman-99999

(no = or >= prefix!) and then forcibly unmerge blueman. And so on for any other deps you don't want.

[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:

Code: Select all

Wed Sep 25 23:13:36 2019
Linux pi64 4.19.67-v8-174fcab91765-p4-bis+ #2 SMP PREEMPT Tue Aug 27 13:58:09 GMT 2019 aarch64 GNU/Linux

To

Code: Select all

Sun Dec  1 10:26:49 2019
Linux pi64 4.19.80-v8-3492a1b00349-p4-bis+ #2 SMP PREEMPT Tue Oct 22 13:59:52 GMT 2019 aarch64 GNU/Linux

To

Code: Select all

Sun Dec  1 17:33:57 2019
Linux pi64 4.19.86-v8-c078c64fecb3-p4-bis+ #2 SMP PREEMPT Tue Nov 26 14:00:29 GMT 2019 aarch64 GNU/Linux

Running lscpu via the last two provided the following details. Results using the first Linux did not include Vulnerability entries and neither did details from an older Gentoo SD card (still Linux pi64 4.19.66).

Code: Select all

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
Vendor ID:                       ARM
Model:                           3
Model name:                      Cortex-A72
Stepping:                        r0p3
CPU max MHz:                     1500.0000
CPU min MHz:                     600.0000
BogoMIPS:                        108.00
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm crc32 cpuid

[n1ese]

Is there a command that clearly identifies that v1.5.2 is installed?

Run: eix rpi-64bit-meta

Code: Select all

ganymede /home/n1ese # eix rpi-64bit-meta
[I] dev-embedded/rpi-64bit-meta [1]
     Available versions:  (~)1.5.0-r9 (~)1.5.1-r7{tbz2} (~)1.5.2-r8{tbz2} {apps +boot-fw +core +innercore +kernel-bin pitop -porthash -systemd +weekly-genup +xfce}
     Installed versions:  1.5.2-r8{tbz2}(04:21:26 PM 11/28/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -systemd -weekly-genup)
     Homepage:            https://github.com/sakaki-/gentoo-on-rpi-64bit
     Description:         Baseline packages for the gentoo-on-rpi-64bit image

[1] "genpi64" /usr/local/portage/genpi64

[roylongbottom]

Is there a command that clearly identifies that v1.5.2 is installed?

Run: eix rpi-64bit-meta

Code: Select all

ganymede /home/n1ese # eix rpi-64bit-meta
[I] dev-embedded/rpi-64bit-meta [1]
     Available versions:  (~)1.5.0-r9 (~)1.5.1-r7{tbz2} (~)1.5.2-r8{tbz2} {apps +boot-fw +core +innercore +kernel-bin pitop -porthash -systemd +weekly-genup +xfce}
     Installed versions:  1.5.2-r8{tbz2}(04:21:26 PM 11/28/2019)(boot-fw core innercore kernel-bin xfce -apps -pitop -porthash -systemd -weekly-genup)
     Homepage:            https://github.com/sakaki-/gentoo-on-rpi-64bit
     Description:         Baseline packages for the gentoo-on-rpi-64bit image

[1] "genpi64" /usr/local/portage/genpi64

Thanks, that's what I see on my Pi 4.

[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]

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?

Must admit I haven't tried building an MMAL-enabled version of kodi, as the next release will have support for the V4L2-M2M codec endpoints (I believe).

[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:

Code: Select all

demouser@pi64 ~ $ sudo emaint sync --repo genpi64
demouser@pi64 ~ $ sudo emerge -v1u sys-firmware/brcm43430-firmware

Reboot once done to start using the updated driver.

Thanks to haaldemir for reporting the issue, and for persisting through the follow up! [2]

64-bit Userland MMAL Support Merged Upstream

In other news, as 6by9's pointer-wrangling PR#586 [3] has now been tidied up and merged into raspberrypi-userland upstream, I have bumped the corresponding ebuild accordingly (removing the temporary patch for this PR).

To get the new version, issue:

Code: Select all

demouser@pi64 ~ $ sudo emaint sync --repo genpi64
demouser@pi64 ~ $ sudo emerge -v1u media-libs/raspberrypi-userland

Again, reboot once done to start using this.

best, sakaki

[1] /lib/firmware/brcm/brcmfmac43455-sdio.bin
[2] https://www.raspberrypi.org/forums/view ... 5#p1576715 ff
[3] https://github.com/raspberrypi/userland/pull/586

[keyson]

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

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

Regards