[SOLVED] RPi 4B missing /dev/dri/renderD128 aarch64 only

[WebReflection]

TL;DR

ArchLinuxARM-rpi-aarch64-latest.tar.gz works just fine but it doesn't properly bootstrap the GPU, so that, once booted and performed the following:

$this->bbcode_second_pass_code('', '
pacman-key --init
pacman-key --populate archlinuxarm
')

I have also forced-installed linux-raspberrypi4 which replaces both linux and uboot.

Bear in mind, before rebooting, it's necessary to change back the mmcblk1 prefix to mmcblk0 because this kernel looks for that card, not the 1 one:
$this->bbcode_second_pass_code('', '
sed -i 's/mmcblk1/mmcblk0/g' root/etc/fstab
')

Reboot, et voila ... all /dev/dri/* things are there

- - - - - - - - - - - -

The current 32bit version of ArchLinux ARM for RPi4 allows HW acceleration without issues, and exposes /dev/dri/renderD128, among /dev/dri/card0 and /dev/dri/card1.

It goes "bananas" if I specify both cards in weston config output section, but that's another story.

The very same aarch64 bit version of ArchLinux ARM works like a charm for my RPi3 too, where /dev/dri/renderD128 is there, as well as the single card.

The 32bit version of ArchLinux ARM works equally well in both RPi2, and RPi3, so I have HW accelerated WPEWebKit in every RPiX except the latest one on the 64bit version, which is odd to explain/understand.

Is this a well known issue? Apologies but searching /dev/dri/renderD128 brought me zero results.

Is this meant, or something low priority? I understand RPi3 is still cool and everything, but I think most old/new users are moving to the RPi4 these days, so it'd be great to have it run full steam at 64bits too.

Thoughts?

[graysky]

What are you asking/reporting??

RPi4B/aarch64:
$this->bbcode_second_pass_code('', '% ls -l /dev/dri
total 0
drwxr-xr-x 2 root root 100 Aug 31 09:11 by-path
crw-rw----+ 1 root video 226, 0 Aug 31 09:11 card0
crw-rw----+ 1 root video 226, 1 Oct 3 16:51 card1
crw-rw-rw- 1 root render 226, 128 Aug 31 09:11 renderD128
')

RPi4B/armv7h:
$this->bbcode_second_pass_code('', '% ls -l /dev/dri
total 0
drwxr-xr-x 2 root root 100 Aug 31 09:12 by-path
crw-rw----+ 1 root video 226, 0 Aug 31 09:12 card0
crw-rw----+ 1 root video 226, 1 Oct 3 21:48 card1
crw-rw-rw- 1 root render 226, 128 Aug 31 09:12 renderD128
')

[WebReflection]

The fact this is all I read in RPi4B/aarch64 only:

$this->bbcode_second_pass_code('', '
% ls -l /dev/dri
total 0
drwxr-xr-x 2 root root 100 Aug 31 09:11 by-path
crw-rw----+ 1 root video 226, 0 Aug 31 09:11 card0
')

But I have exact same result you have for the RPi4B/armv7h.

So ... what could be different?

I have tried both vc4-fkms-v3d and vc4-fkms-v3d-pi4 without luck, and tried tons of gpu_mem configuration.

Is there any way I could have what you see on my Pi4 too? This is also something someone else told me form another OSS project, behind WPEWebKit, so I am trying to have an answer to this situtation that happens to 2 boards I have, but also other poepl boards.

Thanks!

edit to clarify, the installed software and procuder is just about identical across the two versions ... same board, same software, issues only on aarch64. Could it be something related to the flushed eeprom version of the board? Just wondering ...

[graysky]

Does yout /boot/config.txt look like this: https://github.com/archlinuxarm/PKGBUIL ... onfig8.txt

[WebReflection]

If I don't enable_uart=1 it won't boot at all, on aarch64, but yes, those two lines, plus enable_uart=1, are there, still no card 1 or render in the /dev/dri

edit I'll try to flush the bare minimum and put only that on boot/config.txt and see if there's something else I do that could compromise, but AFAIK on aarch64 both my Pi4 aren't able to HW accelerate with latest kernel.

[WebReflection]

I can confirm, after a fresh aarch64 install, following all instructions, and after updating everything to latest, and using only this content in my boot/config.txt

$this->bbcode_second_pass_code('', '
dtoverlay=vc4-kms-v3d
initramfs initramfs-linux.img followkernel
enable_uart=1
')

and after adding alarm user to video group too, and rebooting, and updating, there is no card1 and no renderD128, and this is what others are experiencing too ... are instructions missing some step for the GPU? is the eeprom to blame for this?

Thanks!

edit I can also confirm is not an eeprom issue, as I've updated both boards to stable (July 2021) and while one USB gotcha got solved, the GPU is still not fully accessible with aarch64 on RPi4

[WebReflection]

FWIWI I believe others had similar issues with aarch64
viewtopic.php?f=65&t=15394

all reports about frozen GPU or super slow are what I am experiencing in here too.

If anyone has any idea how to solve it, or when it'll be solved, please let me know, thank you.

[graysky]

Post the output of uname -a

[WebReflection]

Linux alarm 5.14.9-2-ARCH #1 SMP Sun Oct 3 13:45:37 MDT 2021 aarch64 GNU/Linux

once again, I have followed these exact instructions and 2 boards out of two don't show /dev/dri/card1 and /dev/dri/renderD128 but only on aarch64, the 32bit version works just fine.

[WebReflection]

OK ... I have just realized I am not on linux-raspberrypi4 kernel ... is that mandatory/necessary these days? If that's the case, shouldn't be mentioned on the installation guide? Thanks!

P.S. now it doesn't boot, but that's something I can debug/test further, I still need to check if with that one the GPU goes up nicely.