I received my Raspberry Pi 5 yesterday and immediately gave it a shot with Manjaro ARM KDE.
I’m happy to report that it works very well, except for sound thru HDMI, as my PI5 sees no audio device.
There are also a few, not very annoying, GPU artifacts in Wayland.
And chromium-docker does not work.
Besides this everything looks alright and I’m typing this post on it.
Performance wise, there is just no comparison between the #RaspberryPi 4 and the 5 : The 5 is the very first ARM SBC that gives a swift, reactive desktop experience that truly compares to a “PC”. That’s great !
I coud overclock mine to 3 GHz CPU / 980 MHz GPU and it runs perfectly stable and even faster
What I did to “install” is that I just cloned the SD card from my Pi4 using Clonezilla, applied all updates from the unstable branch, removed the pi4-specific packages (kernel etc) and installed the pi5 ones instead, put the card into the Pi5, fired it up, et voilà.
Pi5 better stay Bookworm for better supported, and wait ManjaroArm turn stable, my2c.
Did you try
hdmi_drive:0=2 if you are using the 1st hdmi port in config.txt? I have not seen anyone reporting this. It may not be getting the right EDID info from your monitor.
Did you install the Pi OS patched mesa?
I would stay on the unstable branch at least for a while to get the latest fixes as they do them.
I already have a general
hdmi_drive=2 in config.txt, so I would expect it to work… It works with the Pi4.
I will give a shot to your patched Mesa and let you know.
Here is what I get with the patched Mesa :
❯ glxinfo -B
name of display: :1
WARNING: v3d support for hw version 71 is neither a complete nor a conformant OpenGL implementation. Testing use only.
display: :1 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Broadcom (0x14e4)
Device: V3D 7.1 (0xffffffff)
Video memory: 8048MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.1
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES profile version: 3.1
OpenGL vendor string: Broadcom
OpenGL renderer string: V3D 7.1
OpenGL core profile version string: 3.1 Mesa 23.2.1+rpt2.1
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL version string: 3.1 Mesa 23.2.1+rpt2.1
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 23.2.1+rpt2.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
❯ inxi -G
Device-1: bcm2712-hdmi0 driver: vc4_hdmi v: N/A
Device-2: bcm2712-hdmi1 driver: vc4_hdmi v: N/A
Display: wayland server: X.org v: 22.214.171.124 with: Xwayland v: 23.2.2
compositor: kwin_wayland driver: X: loaded: modesetting dri: vc4
gpu: vc4_hdmi,vc4_hdmi resolution: 1920x1080
API: EGL v: 1.4,1.5 drivers: swrast,v3d,vc4
API: OpenGL v: 4.5 compat-v: 3.1 vendor: broadcom mesa v: 23.2.1+rpt2.1
renderer: V3D 7.1
API: Vulkan v: 1.3.269 drivers: v3dv,llvmpipe surfaces: xcb,xlib,wayland
(Some weird GPU artifacts are still there…)
Looks pretty good. That is the same mesa with their patches PiOS uses for the pi5 so the V3D is showing up now. It will be a while until upstream mesa gets it in theirs.
I am running into the following with the mesa package
vc4-drm axi:gpu: [drm] ERROR Failed to allocate DLIST entry. Requested size=19. ret=-28
Which mesa package. Are you on the unstable branch?
They have been trying to figure that out for ever. They thought they had it fixed. Yours is a little different.
Its the mesa patched you uploaded on the rpi4 rpi5 post
So you never saw it with the mesa in the repo? @tartanpion was seeing his with the mesa in the repo. Are you using the latest kernel packages in the unstable branch?
To be honest I never noted it on the repo based mesa
This is the thread on raspberry pi forum
My sound issue was actually caused by a combination of a spurious monitor EDID and some specifc video fix that applied where it shouldn’t have and broke sound.
So that’s fixed
I have noticed that package
rpi4-post-install 20231112-1 puts a
MODULES=(vc4) entry into
With this, I get a black text screen with only a blinking
_ cursor during boot, and no Plymouth display (annoying for knowing when to type my LUKS password).
Without this module, I get a proper Plymouth display.
Weird that you are getting the spinning circle with out the module at boot. strit put it there at the time because it was not getting loaded in the early boot process for plymouth before the login screen. With that said the whole process does not account for people who have to enter a LUKS password in the early boot process. I personally do not like the whole process with plymouth and screen blanking. I disabled all of that stuff here. I like to see what is going on with my system.
Well, Plymouth takes good care of the LUKS passphrase input if
plymouth-encrypt is properly called in the mkinitcpio conf.
All I can report is that it works well without the
MODULES=(vc4) entry, and does not work at all when this module is loaded…
My Pi5 boots correctly but mkinitcpio fails somewhat:
[root@amiberry ~]# mkinitcpio -p linux-rpi5
==> Building image from preset: /etc/mkinitcpio.d/linux-rpi5.preset: 'default'
==> Using configuration file: '/etc/mkinitcpio.conf'
-> -k 6.1.63-2-MANJARO-RPI5 -c /etc/mkinitcpio.conf -g /boot/initramfs_2712
==> Starting build: '6.1.63-2-MANJARO-RPI5'
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [kms]
-> Running build hook: [keyboard]
-> Running build hook: [keymap]
-> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: '/boot/initramfs_2712'
==> WARNING: errors were encountered during the build. The image may not be complete.
This has been reported upstream but no higher up has commented on it. I do not know about other devices that will run into this but the RPi’s do not need a initramfs to boot. The needed modules are builtin the kernel.
Pi may or may not need an initramfs depending upon what you do with it. Mine have LUKS-encrypted root FS, so I definitely need an initramfs.
I fell on the same issue (error at the end of
mkinitcpio build without previous reported errors), and having
kms in the hooks list caused it. Removing both
vc4 from the
MODULES list and
kms from the HOOKS solved it.
Give it a shot an please report it upstream if it helps - I do not have an account there…
Sure if you have some customization’s that requires modules to be loaded early that is not built in the kernel.
Seems the guy above you in your arch-arm forum post narrowed down to what he thinks is the root issue to a change made to usr/lib/initcpio/functions line that says this and commented it out then posted an issue on their gitlab. This is happening on other devices also as reported in the arch-arm forums; not just the pi’s. The other devices do not use VC4. It happened on my pinebookpro here also but I did not check what all modules it was trying to load.
usr/lib/initcpio/install/kms: add_checked_modules_from_symbol ‘drm_privacy_screen_register’ ‘=drivers/platform’
It’s not the
vc4 module but
kms in the hooks that causes the mkinitcpio to bail out in error.
vc4 module allows initramfs to build but prevents Plymouth from displaying anything during boot.