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

[Goverp]

Sakaki,

Whee! Thanks so much - I've been putting off going 64-bit on my Pi4; now I've run out of excuses.

[spork_kitty]

Are there any plans to add nftables support? I checked out /boot/config and saw something about XTABLES. None of the family support appears to be there, either.

If that file is incorrect, my apologies. I didn't see /proc/config.gz either, to check what the running kernel is using. Which package do you build your kernels from? I can try building my own from it to enable nftables.

If there are any features missing from the kernel you feel would be generally useful, feel free to submit a PR against the conform_config.sh script of bcmrpi3-kernel-bis (and/or bcm2711-kernel-bis, for the RPi4), which are the weekly autobuilds that supply the kernels. Here's an example.

BTW the reason you can't see /proc/config.gz is that to save RAM, bcm{rpi3,2711}_defconfig specify this feature be built as a module. If you "sudo modprobe configs", /proc/config.gz should magically appear ^-^

Nice to know it's in a module! Thanks for the tip.

I think maybe my modules are broken, though:

Code: Select all

# modprobe configs
modprobe: FATAL: Module config not found in directory /lib/modules/4.19.49-v8-4395da031338-bis+

I haven't made any real modifications to the system, though my migration process was a little bumpy. I'll give it another genup run and re-read your wiki to see if maybe I missed something.

[Sakaki]

spork_kitty,

if you have updated fully, your kernel will have been updated, to 4.19.66...

In which case, your old /lib/modules/4.19.48... directory will no longer exist. Reboot, and then try the modprobe again.

[Sakaki]

Sakaki,
I had to revert the firmware change as dmesg filled up with

Code: Select all

...
[  969.734489] scsi host0: uas_eh_device_reset_handler start
[  969.863916] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[  969.891451] scsi host0: uas_eh_device_reset_handler success
[ 1000.470943] sd 0:0:0:0: [sda] tag#6 uas_eh_abort_handler 0 uas-tag 1 inflight: IN 
[ 1000.470954] sd 0:0:0:0: [sda] tag#6 CDB: opcode=0x28 28 00 1b e2 38 91 00 01 00 00
[ 1000.486938] scsi host0: uas_eh_device_reset_handler start
[ 1000.616014] usb 2-2: reset SuperSpeed Gen 1 USB device number 2 using xhci_hcd
[ 1000.642181] scsi host0: uas_eh_device_reset_handler success
...

Oh, that's UAS in use. Its fine with the old firmware.

Have you seen this thread re UAS on the Pi4?

https://www.raspberrypi.org/forums/view ... 8&t=245931

[NeddySeagoon]

Sakaki,

Thank you. There is lots of food for thought there.

I don't really want to turn off UAS as I want trim to work.
There are several things to look at, the first being a firmware update so my USB3 to SATA3 cable actually supports trim. :)

A power issue would not surprise me as I'm using the PoE HAT, which is only good for 2.5A at 5v.
I can probably test briefly with a powered hub, then butcher two USB3 extension cables to make a Y cable, if that's the fix.

[Sakaki]

For those who prefer that install route, the v1.5.0 RPi4B/3B+/3B-compatible gentoo-on-rpi-64bit image is now also available for install through PINN (called gentoo64 - and, for the PiTop v1 variant, gentoo64pt - there).

[spork_kitty]

spork_kitty,

if you have updated fully, your kernel will have been updated, to 4.19.66...

In which case, your old /lib/modules/4.19.48... directory will no longer exist. Reboot, and then try the modprobe again.

Derp; that was indeed the issue! Thanks for such a quick response.

EDIT: I see that conform_config.sh has nftables support enabled via module. I have rebooted my Pi and confirmed that `uname` output matches the dir it searches for modules. `modprobe nf_tables` doesn't work:

Code: Select all

# modprobe nf_tables
modprobe: FATAL: Module nf_tables not found in directory /lib/modules/4.19.66-v8-fc5826fb999e-bis+

# uname -a
Linux dootdoot 4.19.66-v8-fc5826fb999e-bis+ #2 SMP PREEMPT Fri Aug 16 13:29:15 GMT 2019 aarch64 GNU/Linux

# insmod /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko 
insmod: ERROR: could not insert module /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko: Unknown symbol in module

# objdump -s -j .gnu.linkonce.this_module /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko 

/lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko:     file format elf64-littleaarch64

Contents of section .gnu.linkonce.this_module:
 0000 00000000 00000000 00000000 00000000  ................
 0010 00000000 00000000 6e665f74 61626c65  ........nf_table
 0020 73000000 00000000 00000000 00000000  s...............
 0030 00000000 00000000 00000000 00000000  ................
 0040 00000000 00000000 00000000 00000000  ................
 0050 00000000 00000000 00000000 00000000  ................
 0060 00000000 00000000 00000000 00000000  ................
 0070 00000000 00000000 00000000 00000000  ................
 0080 00000000 00000000 00000000 00000000  ................
 0090 00000000 00000000 00000000 00000000  ................
 00a0 00000000 00000000 00000000 00000000  ................
 00b0 00000000 00000000 00000000 00000000  ................
 00c0 00000000 00000000 00000000 00000000  ................
 00d0 00000000 00000000 00000000 00000000  ................
 00e0 00000000 00000000 00000000 00000000  ................
 00f0 00000000 00000000 00000000 00000000  ................
 0100 00000000 00000000 00000000 00000000  ................
 0110 00000000 00000000 00000000 00000000  ................
 0120 00000000 00000000 00000000 00000000  ................
 0130 00000000 00000000 00000000 00000000  ................
 0140 00000000 00000000 00000000 00000000  ................
 0150 00000000 00000000 00000000 00000000  ................
 0160 00000000 00000000 00000000 00000000  ................
 0170 00000000 00000000 00000000 00000000  ................
 0180 00000000 00000000 00000000 00000000  ................
 0190 00000000 00000000 00000000 00000000  ................
 01a0 00000000 00000000 00000000 00000000  ................
 01b0 00000000 00000000 00000000 00000000  ................
 01c0 00000000 00000000 00000000 00000000  ................
 01d0 00000000 00000000 00000000 00000000  ................
 01e0 00000000 00000000 00000000 00000000  ................
 01f0 00000000 00000000 00000000 00000000  ................
 0200 00000000 00000000 00000000 00000000  ................
 0210 00000000 00000000 00000000 00000000  ................
 0220 00000000 00000000 00000000 00000000  ................
 0230 00000000 00000000 00000000 00000000  ................
 0240 00000000 00000000 00000000 00000000  ................
 0250 00000000 00000000 00000000 00000000  ................
 0260 00000000 00000000 00000000 00000000  ................
 0270 00000000 00000000 00000000 00000000  ................
 0280 00000000 00000000 00000000 00000000  ................
 0290 00000000 00000000 00000000 00000000  ................
 02a0 00000000 00000000 00000000 00000000  ................
 02b0 00000000 00000000 00000000 00000000  ................
 02c0 00000000 00000000 00000000 00000000  ................
 02d0 00000000 00000000 00000000 00000000  ................
 02e0 00000000 00000000 00000000 00000000  ................
 02f0 00000000 00000000 00000000 00000000  ................
 0300 00000000 00000000 00000000 00000000  ................
 0310 00000000 00000000 00000000 00000000  ................
 0320 00000000 00000000 00000000 00000000  ................
 0330 00000000 00000000 00000000 00000000  ................

Not sure what's going on.

[Kashire]

I slimmed it down, as per https://github.com/sakaki-/gentoo-on-rp ... -the-Image
I'd like to point out that something weird happened with the audio. I switched over to alsa exclusively, so if someone does this
and still wants sound but pulseaudio isn't working... you're going to watch to switch to alsa. It works out of the box just fine.

I went to the .config file and added in "-pulseaudio", updated world, and it worked out. Just a heads up if anyone runs into this problem.
The USB audio worked. It was the 3.5mm jack that was the issue. I almost bugged you all about it, but wanted to try that first..and it worked.

Thanks again, Sakaki-. Because of you, I'm fully switched over to a rpi4 desktop. Here's what it looks like at the moment,
if anyone is curious: https://0x0.st/zWRk.png It works for literally everything I've thrown at it for my needs, from college work
to making latex documents to watching 1080p videos. The compile time is pretty smooth, the only thing that actually sucked
was qtwebengine, but that's because it requires -j1 -l1 apparently. (It took three whole days!)

Cheers!

[Sakaki]

EDIT: I see that conform_config.sh has nftables support enabled via module. I have rebooted my Pi and confirmed that `uname` output matches the dir it searches for modules. `modprobe nf_tables` doesn't work:

Code: Select all

# modprobe nf_tables
modprobe: FATAL: Module nf_tables not found in directory /lib/modules/4.19.66-v8-fc5826fb999e-bis+

# uname -a
Linux dootdoot 4.19.66-v8-fc5826fb999e-bis+ #2 SMP PREEMPT Fri Aug 16 13:29:15 GMT 2019 aarch64 GNU/Linux

# insmod /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko 
insmod: ERROR: could not insert module /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko: Unknown symbol in module
...

Not sure what's going on.

modprobe nf_tables works for me on 4.19.66-v8-7ee8d72eeb56-bis+

Something looks to have gone wrong with your kernel update. You are booted with 4.19.66-v8-fc5826fb999e-bis+ (uname -a) but have the more modern /lib/modules directory (4.19.66-v8-7ee8d72eeb56-bis+). Are you sure /boot is mounted OK? Do you have perhaps a split /boot and /root (/boot on microSD card say, and /root on a USB drive or similar)?

If you are sure your real /boot is mounted OK you can just:

Code: Select all

# emerge -v1 bcm2711-kernel-bis-bin bcmrpi3-kernel-bis-bin

To forcibly re-emerge the kernels. Then reboot and try again.

[spork_kitty]

EDIT: I see that conform_config.sh has nftables support enabled via module. I have rebooted my Pi and confirmed that `uname` output matches the dir it searches for modules. `modprobe nf_tables` doesn't work:

Code: Select all

# modprobe nf_tables
modprobe: FATAL: Module nf_tables not found in directory /lib/modules/4.19.66-v8-fc5826fb999e-bis+

# uname -a
Linux dootdoot 4.19.66-v8-fc5826fb999e-bis+ #2 SMP PREEMPT Fri Aug 16 13:29:15 GMT 2019 aarch64 GNU/Linux

# insmod /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko 
insmod: ERROR: could not insert module /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+/kernel/net/netfilter/nf_tables.ko: Unknown symbol in module
...

Not sure what's going on.

modprobe nf_tables works for me on 4.19.66-v8-7ee8d72eeb56-bis+

Something looks to have gone wrong with your kernel update. You are booted with 4.19.66-v8-fc5826fb999e-bis+ (uname -a) but have the more modern /lib/modules directory (4.19.66-v8-7ee8d72eeb56-bis+). Are you sure /boot is mounted OK? Do you have perhaps a split /boot and /root (/boot on microSD card say, and /root on a USB drive or similar)?

If you are sure your real /boot is mounted OK you can just:

Code: Select all

# emerge -v1 bcm2711-kernel-bis-bin bcmrpi3-kernel-bis-bin

To forcibly re-emerge the kernels. Then reboot and try again.

Code: Select all

# mount | grep /boot
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1   63M   44M   20M  70% /boot

It turns out bcm2711-kernel-bis-bin wasn't installed. When I reinstalled both and rebooted, nf_tables was probed correctly.

I assume I'll need to put the 2711 package into a set somewhere to prevent this from happening again. Thanks for another quick response!

However, my /boot is getting very cramped now, with only 2% left. I haven't modified the SD card from what the image uses by default. Are there any files that are safe to remove from a Pi3B installation? I can resize partitions from another computer, if I must..

Code: Select all

# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1   63M   62M  1.7M  98% /boot

# ls -Alh /boot
total 60M
drwxr-xr-x 5 root root 8.0K Jan 21  2017 .Trash-1000
-rwxr-xr-x 1 root root  423 Aug 24 04:55 COPYING.linux
-rwxr-xr-x 1 root root 1.5K Aug 22 11:21 LICENCE.broadcom
-rwxr-xr-x 1 root root 3.2M Aug 25 09:25 System-p4.map
-rwxr-xr-x 1 root root 2.9M Aug 24 04:55 System.map
-rwxr-xr-x 1 root root  512 Aug 25 09:25 armstub8-gic.bin
-rwxr-xr-x 1 root root  27K Aug 24 04:55 bcm2710-rpi-3-b-plus.dtb
-rwxr-xr-x 1 root root  26K Aug 24 04:55 bcm2710-rpi-3-b.dtb
-rwxr-xr-x 1 root root  25K Aug 24 04:55 bcm2710-rpi-cm3.dtb
-rwxr-xr-x 1 root root  40K Aug 25 09:25 bcm2711-rpi-4-b.dtb
-rwxr-xr-x 1 root root  20K Aug 24 04:55 bcm2837-rpi-3-b.dtb
-rwxr-xr-x 1 root root  52K Aug 22 11:21 bootcode.bin
-rwxr-xr-x 1 root root  106 Aug 23 06:23 cmdline.txt
-rwxr-xr-x 1 root root 153K Aug 24 04:55 config
-rwxr-xr-x 1 root root 174K Aug 25 09:25 config-p4
-rwxr-xr-x 1 root root 2.4K Jul 14 01:26 config.txt
-rwxr-xr-x 1 root root 6.6K Aug 22 11:21 fixup.dat
-rwxr-xr-x 1 root root 6.0K Aug 22 11:21 fixup4.dat
-rwxr-xr-x 1 root root 3.0K Aug 22 11:21 fixup4cd.dat
-rwxr-xr-x 1 root root 9.0K Aug 22 11:21 fixup4db.dat
-rwxr-xr-x 1 root root 9.0K Aug 22 11:21 fixup4x.dat
-rwxr-xr-x 1 root root 2.6K Aug 22 11:21 fixup_cd.dat
-rwxr-xr-x 1 root root 9.6K Aug 22 11:21 fixup_db.dat
-rwxr-xr-x 1 root root 9.6K Aug 22 11:21 fixup_x.dat
-rwxr-xr-x 1 root root  15M Aug 25 09:25 kernel8-p4.img
-rwxr-xr-x 1 root root  16M Aug 24 04:55 kernel8.img
drwxr-xr-x 2 root root  16K Aug 25 09:24 overlays
-rwxr-xr-x 1 root root 2.8M Aug 22 11:21 start.elf
-rwxr-xr-x 1 root root 2.7M Aug 22 11:21 start4.elf
-rwxr-xr-x 1 root root 748K Aug 22 11:21 start4cd.elf
-rwxr-xr-x 1 root root 4.6M Aug 22 11:21 start4db.elf
-rwxr-xr-x 1 root root 3.6M Aug 22 11:21 start4x.elf
-rwxr-xr-x 1 root root 670K Aug 22 11:21 start_cd.elf
-rwxr-xr-x 1 root root 4.7M Aug 22 11:21 start_db.elf
-rwxr-xr-x 1 root root 3.7M Aug 22 11:21 start_x.elf

[Sakaki]

spork_kitty,

depending on your target, you could remove some of the start*.elf files, the System*.map files and unused entries in overlays/.

However, I don't recommend that - it's only a short term fix as these files will get reinstalled when the relevant underlying packages upgrade (and eventually, you will run out of space). Unfortunately, when I put together the v1.0.0 gentoo-on-rpi3-64bit image way back in Jan 2017, I used a 63MiB bootfs as that was what Raspbian used back then. Turns out that was a mistake / hostage to fortune, and I should have chosen a larger partition (to provide room for the dual kernels of an RPi3/4 image, etc. in the future) Apologies ><

As such, I recommend to grow the boot partition and filesystem to 255MiB when upgrading to v1.5.0, shrinking (and moving forward) the root partition and filesystem to create the necessary space. (The v1.5.0 downloadable image ships with this resize already done.)

The gparted tool provides a nice GUI-driven way to achieve the above changes.

[spork_kitty]

spork_kitty,

depending on your target, you could remove some of the start*.elf files, the System*.map files and unused entries in overlays/.

However, I don't recommend that - it's only a short term fix as these files will get reinstalled when the relevant underlying packages upgrade (and eventually, you will run out of space). Unfortunately, when I put together the v1.0.0 gentoo-on-rpi3-64bit image way back in Jan 2017, I used a 63MiB bootfs as that was what Raspbian used back then. Turns out that was a mistake / hostage to fortune, and I should have chosen a larger partition (to provide room for the dual kernels of an RPi3/4 image, etc. in the future) Apologies ><

As such, I recommend to grow the boot partition and filesystem to 255MiB when upgrading to v1.5.0, shrinking (and moving forward) the root partition and filesystem to create the necessary space. (The v1.5.0 downloadable image ships with this resize already done.)

The gparted tool provides a nice GUI-driven way to achieve the above changes.

Aha, no worries. Who could have predicted there'd be a need for more kernels? At least it wasn't pebcak this time.

I've used gparted in the past but haven't moved or resized a partition in the CLI yet. Now's a good time to learn as any.

EDIT: I'm building my own kernel since something's up with the conform_config.sh nftables options. Despite some lines being set to "=m", it's not actually fully available. I've never used nftables as a module, and it's missing important things like NF_TABLES_IPV4. Take a look:

conform_config.sh on master, nftables-related lines highlighted

(note that CONFIG_NF_TABLES_IPV4 is enabled as a module, on line 85)

Code: Select all

# modprobe nf_tables_ipv4
modprobe: FATAL: Module nf_tables_ipv4 not found in directory /lib/modules/4.19.66-v8-7ee8d72eeb56-bis+

# uname -a
Linux dootdoot 4.19.66-v8-7ee8d72eeb56-bis+ #2 SMP PREEMPT Tue Aug 20 13:29:50 GMT 2019 aarch64 GNU/Linux

# zgrep CONFIG_NF_TABLES /proc/config.gz 
CONFIG_NF_TABLES=m
# CONFIG_NF_TABLES_SET is not set
# CONFIG_NF_TABLES_INET is not set
# CONFIG_NF_TABLES_NETDEV is not set
# CONFIG_NF_TABLES_IPV4 is not set
# CONFIG_NF_TABLES_ARP is not set
# CONFIG_NF_TABLES_IPV6 is not set
# CONFIG_NF_TABLES_BRIDGE is not set

# lsmod
Module                  Size  Used by
configs                53248  0
nf_nat                 36864  0
nft_ct                 20480  0
nf_conntrack          135168  2 nf_nat,nft_ct
nf_defrag_ipv6         20480  1 nf_conntrack
nf_defrag_ipv4         16384  1 nf_conntrack
nf_tables             118784  1 nft_ct
nfnetlink              20480  1 nf_tables
lz4                    16384  4
lz4_compress           45056  1 lz4
hci_uart               40960  1
btbcm                  16384  1 hci_uart
serdev                 20480  1 hci_uart
bnep                   24576  2
bluetooth             405504  24 hci_uart,btbcm,bnep
ecdh_generic           28672  1 bluetooth
ipv6                  466944  32
brcmfmac              237568  0
brcmutil               16384  1 brcmfmac
sha256_generic         20480  0
bcm2835_codec          40960  0
bcm2835_v4l2           45056  0
v4l2_mem2mem           24576  1 bcm2835_codec
cfg80211              643072  1 brcmfmac
bcm2835_mmal_vchiq     28672  2 bcm2835_codec,bcm2835_v4l2
videobuf2_vmalloc      16384  1 bcm2835_v4l2
videobuf2_dma_contig    20480  1 bcm2835_codec
videobuf2_memops       16384  2 videobuf2_vmalloc,videobuf2_dma_contig
videobuf2_v4l2         24576  3 bcm2835_codec,bcm2835_v4l2,v4l2_mem2mem
rfkill                 28672  5 bluetooth,cfg80211
videobuf2_common       45056  4 bcm2835_codec,videobuf2_v4l2,bcm2835_v4l2,v4l2_mem2mem
v4l2_common            16384  1 bcm2835_v4l2
videodev              229376  6 bcm2835_codec,v4l2_common,videobuf2_v4l2,bcm2835_v4l2,videobuf2_common,v4l2_mem2mem
snd_bcm2835            28672  0
uas                    24576  0
media                  36864  2 videodev,v4l2_mem2mem
snd_pcm               114688  1 snd_bcm2835
vc_sm_cma              32768  1 bcm2835_mmal_vchiq
snd_timer              36864  1 snd_pcm
snd                    77824  3 snd_bcm2835,snd_timer,snd_pcm
vchiq                 323584  3 vc_sm_cma,snd_bcm2835,bcm2835_mmal_vchiq
sdhci_iproc            16384  0
spi_bcm2835            20480  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq

As you can see, I tried loading some modules manually, starting with nf_tables, and seeing what I could enable related to it. I couldn't get very far due to the lack of family and chain support. The config appears mostly correct, but maybe there's some logic when the kernel's checking the config and it doesn't respect certain settings unless others are built as modules, too?

I usually build nftables into my kernels, without modules, so this is new ground for me.

I have successfully built my custom kernel, with nftables built-in, so once I resize the partitions I'll test it and share the resulting config file. (though, it will be littered with Y instead of M) Hopefully we'll find what's missing (i.e. present in my config but not in conform_config.sh)

EDIT2: Partition resizing worked, and so did my configuration of nftables! It's too late to get a relevant diff for you; I'll try to have it this week.

[Sakaki]

Hello,

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

As always, you can burn the image (~1,720MiB 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.

For details of the major changes - including RPi4 support - introduced in 1.5.0, please see my earlier post.

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

• Fixed a pulseaudio problem that was causing glitchy audio playback on some systems (by setting tsched=0 in /etc/pulse/default.pa; credit: Darksky). Thanks to Gazzy for reporting.
• Reversed a change to the default /boot/config.txt that was causing monitor autodetection problems for some users (hdmi_drive=2 was uncommented in v1.5.0, my fault ><). Thanks to Gavinmc42 for reporting / testing the fix.
• Upgraded the shipped kernels, to bcm{rpi3,2711}-kernel-bis-bin-4.19.67.20190827, and boot firmware, to sys-boot/rpi3-64bit-firmware-1.20190819 (which inter alia should hopefully also solve a number of HDMI issues; thanks to derders and MamiyaOtaru for reporting). The shipped RPi4 kernel contains a PR which fixes a rather serious under-load WiFi problem for >1GiB systems (thanks to jfikar for reporting / testing, and also to pY4x3g for testing).
• Changed the pyconfig_gen WiFi regulatory domain setup code, so that it also sets cfg80211 ieee80211_regdom via an entry in /etc/modprobe.d/ (the original iw reg set approach is retained also, but it is reportedly not sufficient in all locales). Thanks to Gazzy for suggesting. The combination of this fix and updated kernel should hopefully address the WiFi connection problems that some have reported on the RPi4 (thanks to roylongbottom for providing diagnostic information on this, and to Mrsell for testing).
• Fixed an (unrelated) bug in pyconfig_gen, which prevents it starting up if the framebuffer display driver was specified (by omission of an vc4-{f,}kms-v3d entry in /boot/config.txt).
• Improved the build settings for dev-lang/python, by adopting the Debian approach of using -O3 and turning on profile-guided optimisation. This should significantly improve performance of e.g. emerge. For more details, please see this post. Thanks to ejolson for drawing the relatively poor Python performance on the v1.5.0 image to my attention, and to InBetweenNames for the pgo-enabled ebuilds.
• Added python3_7 to PYTHON_TARGETS, and unmasked for arm64. Following upstream, retained python:3.6 as the default interpreter for now (although you can easily change this if you wish, via eselect python list / sudo eselect python set <...>).
• Various minor ebuild tidy-ups (including the addition of USE-flag control for a number of RPi-specific patches e.g. rpi-v3d to media-libs/mesa etc.).
• Split out the core USE-controlled package group in rpi-64bit-meta, into the new innercore and a now-reduced core. This is to allow a minimal image to be more easily specified.
• All packages brought up-to-date against the Gentoo tree, as of 24 August 2019.

Users already on the prior 1.5.0 or earlier release can upgrade manually by following the instructions given here.


Pi-Top Image EOL; CLI-Only 'Lite' Image Added

Unfortunately, I have had to drop support for the Pi-Top specific image as of this v1.5.1 release. My Pi-Top v1's hub has recently suffered a hardware failure, leaving me unable to charge the internal battery, or boot an RPi3 in its chassis. As such, I am unable to test this variant of the image going forward - and I am not comfortable releasing images I haven't tested myself. You should still be able to bring up the Pi-Top specific drivers by setting the pitop USE flag globally, and then re-emerging rpi-64bit-meta however. My apologies for the inconvenience to users on this platform ><

On a happier note, as of v1.5.1, a 'lite' 64-bit Gentoo image is also provided (as requested here). This contains only the innercore (see above) package set and @system set plus deps, and boots to a CLI. No desktop environment is provided by default, nor are any of the heavyweight applications (Chromium etc.) bundled. It may be installed to any microSD card marked as >= 8GB. The same dual (-bis) kernels and Pi-specific startup services as the main image are used.

Note that for ease of binhost maintenance, this image still derives from the custom (desktop) profile as the 'full-fat' version, and as such contains quite a few more packages than a truly minimal stage 4 would do. But hopefully it should still be a useful starting point for those who want to e.g. build up a headless server. Feedback welcome.


Miscellaneous Hints

Updated EEPROM Firmware
If you are using a Pi4, don't forget to update your EEPROM firmware; there's an official fix released (version 0137a8) that will allow your system to use ~300mW less power. For more information, please see here.

Pimoroni Fan SHIM
If you are using the Pimoroni Fan SHIM with your RPi4, note that you can easily have it turn on and off in a temperature-controlled manner. To do so, simply add the following to /boot/config.txt:

Code: Select all

dtoverlay=gpio-fan,gpiopin=18,temp=65000

The temp parameter controls the point at which the fan comes on (in the above, 65°C). Adapt as appropriate. The driver has a built-in 10°C hysteresis, so using the parameters above for example, it will switch off again at 55°C automatically. Thanks to PeterO for the hint.


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

sakaki

PS I aim to provide PINN versions of both images shortly, for those that prefer that installation route.

[Sakaki]

The v1.5.1 full and lite images are now also available for downloading via PINN (called gentoo64 and gentoo64lite there; the latter may be found under the 'Minimal' tab in PINN's GUI).

I've also published the script I use to prepare my images for hosting on PINN, here, in case that is of interest to anyone.

Also, a new EEPROM firmware update for the RPi4, promising better powersaving, has been made available for testing today (0137ab); details here.

[axl]

I think you can throw this one in the bin.

But it's so cool to just read a thread by sakaki. BTW, because of google & facebook i've also identified you on facebook. I don't know why it happened, but I was like: hey... is the professor sakaki. hmmm... what do you know. it was in my suggested friends. i can't help it. And no, I didn't bother you on facebook.

long time listener, first time commenter. thank you for all your work. i remember the first noobs, and now it's just cool sakaki announcing new pinn release. 9000 cool.

I'm sorry.

[Sakaki]

axl,

the good professor would have been rather surprised to hear from you, as I've never been on Facebook, so just as well you didn't post, lol

But thanks for the nice feedback anyway ^-^

[axl]

George Varghese. is that not you?

[axl]

if i'm right, google or facebook or a combination of the two are making your identity public. i don't know how I ran into that profile. I still hope I'm wrong and that's not you professor.

(a bit of x-men).

[Sakaki]

Definitely not me!
Wrong gender, ethnicity, age and current locale, but otherwise a perfect match... ^-^

[axl]

Can we delete my previous question pls? It's stupid and it's just poisoning the thread for outside people. I'm sorry I had such a curiosity to begin with.


ANYWAY. New question. I'm pretty sure I know the answer to this already, but I would feel much better if the answer came out of someone else's mouth.

My assumption is that without USE=mmal (not available in 64 bits/aarch64), or sometime(s) marked as USE=raspberry-pi (also not available in 64 bits), there's no hardware accelerated video decoding.

Therefor... whatever you do, in 64 bits, you will not be able to make kodi work right. nor build omxplayer at all. ATM. At This Moment.

Anyone care to confirm this?

[ozbird]

Thank you very much NeddySeagoon and Sakaki - and others - for making 64-bit Gentoo Linux on Raspberry Pi 4 a thing.

I used Sakaki's bootable "Lite" image to get into a 64-bit environment on the Pi 4, then "emerge -e world" (ish...)

https://miro.medium.com/max/455/1*snTXF ... ZKJ6IA.png



* it still works(?)

[Sakaki]

ANYWAY. New question. I'm pretty sure I know the answer to this already, but I would feel much better if the answer came out of someone else's mouth.

My assumption is that without USE=mmal (not available in 64 bits/aarch64), or sometime(s) marked as USE=raspberry-pi (also not available in 64 bits), there's no hardware accelerated video decoding.

Therefor... whatever you do, in 64 bits, you will not be able to make kodi work right. nor build omxplayer at all. ATM. At This Moment.

Anyone care to confirm this?

You can use the V4L2 M2M endpoints to access the hardware codecs. Please see my response on your other thread (here).

[n1ese]

Sakaki, good day,

Using your Lite image, would it be overly difficult, other than time consuming, for one to build X11 with the VC4 driver? I don't want a complete desktop environment just an old school, lightweight, window manager. I have no need for LibreOffice or many of the other apps you include with your full image as well.

Thanks

[NeddySeagoon]

n1ese,

You can put your Gentoo together as lite as you like if you do it yourself.
You can still use Sakakis binhost to avoid long compile times. Or even my binhost

When you go the DIY route, you may find that the USE flags you want don't match those on the binhosts.
Then you change your USE flags or build your own.

There is a middle of the road way too. Take a working install. Look at /var/lib/portage/world, don't edit it, just look.

Code: Select all

emerge -c <list of packages in world that I don't want>
emerge --depclean -p

The first command removes all the deliberately installed packages that you don't want.
The second command (without) the -p removes all the packages that are no longer required as a result of the first command.
You have just 'filleted' your install.

Take great care with --depclean. Be sure to review the package list before you let it do anything.

[Sakaki]

Sakaki, good day,

Using your Lite image, would it be overly difficult, other than time consuming, for one to build X11 with the VC4 driver? I don't want a complete desktop environment just an old school, lightweight, window manager. I have no need for LibreOffice or many of the other apps you include with your full image as well.

Thanks

Ditto with all Neddy has said above.

And also, yes, you can use the 'lite' image to easily set up a simple X11 system. In fact, since it still uses the same custom desktop profile as the 'full' variant, all USE flags (provided you don't change them o/c!) will be automagically correct for use of the vc4 drivers etc., and you should find that almost everything you require is already built on the binhost (so you have to do very little local compilation).

For fun, I've just tried setting up a trivial system this way; took about 15 minutes on an RPi4 to get to a simple graphical desktop, from first (textual) boot.

Here's what I did. Begin by starting up a fresh copy of the 'lite' image. Login as root at the terminal (password "raspberrypi64"), then:

Code: Select all

pi64 ~ # emerge -v xorg-server xterm xsetroot xclock openbox

Of these, all but openbox is already on the binhost, so the emerge (provided you have network connectivity) shouldn't take long (hint: if you only have WiFi, you can use the bundled nmtui tool to easily setup a (persistent) network connection from the command line.)

Once done, become demouser (you can easily set up your own 'normal' users o/c), and edit .xinitrc, so:

Code: Select all

pi64 ~ # su - demouser
demouser@pi64 ~ $ nano -w ~/.xinitrc

Put the following (for example) in .xinitrc for a trivial desktop display:

Code: Select all

openbox &
xsetroot -solid CornflowerBlue &
xclock -geometry 100x100-1+1 &
xterm -geometry 80x50+494+51 &
xterm -geometry 80x20+494-0 &
exec xterm -geometry 80x66+0+0 -name login

Save, and exit nano. Then start up your desktop:

Code: Select all

demouser@pi64 ~ $ startx

You should find, if you examine /var/log/Xorg.0.log, that accelerated (glamor) rendering via the vc4/v3d driver is in use.

Enter "exit" in the leftmost terminal to quit X and return to the command line.

Of course, you can use any lightweight window manager you like, setup a proper login manager etc. Up to you!