MagnificentPako
Raspberry Pi 5 and the official 7" display, Weston refusing to start because of missing drivers
Hello!
I have been trying to get Nerves on a Pi 5B together with the 7" Display sold by RaspberryPi working and only had mild successes.
First of all, I made sure the setup works with vanilla Raspberry Pi OS (the screen is picked up, DM starts, touch works).
I also managed to flash a nerves livebook image to the SD card and build one myself based on the livebook example repo, including modifications to the code like adding extra processes to the supervision tree. The display gets picked up and is used for iex.
I cannot start a project created with mix nerves.new <name>. The Pi is never reachable from the network, or does the screen light up, nothing. The status LED switches between long phases of solid green, to a short phase of solid red, which I assume means it is restarting after failing to start for some reason I have not figured out how to debug. (I did set up wifi in the config using vintagenet so it should be connecting fine)
Now, in this local livebook project I swapped out the regular rpi5 system for GitHub - nerves-web-kiosk/kiosk_system_rpi5: Experimental web kiosk for the RPi5 · GitHub
it boots fine, some poking around in iex reveals that i do have access to weston etc. Trying to execute weston however leads to an error that I am unable to figure out with my limited embedded linux experience.
iex(livebook@nerves-bcc1.local)8> cmd("XDG_RUNTIME_DIR=/run weston --shell=kiosk --continue-without-input &")
Date: 2025-01-30 UTC
[16:11:42.820] weston 13.0.3
https://wayland.freedesktop.org
Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
Build: 13.0.3
[16:11:42.820] Command line: weston --shell=kiosk --continue-without-input
[16:11:42.820] OS: Linux, 6.6.64-v8-16k, #1 SMP PREEMPT Mon Jan 20 14:16:05 UTC 2025, aarch64
[16:11:42.820] Flight recorder: enabled
[16:11:42.820] warning: XDG_RUNTIME_DIR "/run" is not configured
correctly. Unix access mode must be 0700 (current mode is 0755),
and must be owned by the user UID 0 (current owner is UID 0).
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
[16:11:42.820] Starting with no config file.
[16:11:42.820] Output repaint window is 7 ms maximum.
[16:11:42.820] Loading module '/usr/lib/libweston-13/drm-backend.so'
[16:11:42.821] initializing drm backend
[16:11:42.821] Trying libseat launcher...
[16:11:42.822] [seatd/seat.c:39] Created VT-bound seat seat0
[16:11:42.822] [seatd/server.c:145] New client connected (pid: 301, uid: 0, gid: 0)
[16:11:42.822] [libseat/backend/seatd.c:633] Started embedded seatd
[16:11:42.822] [seatd/seat.c:170] Added client 1 to seat0
[16:11:42.822] [seatd/seat.c:480] Opened client 1 on seat0
[16:11:42.822] [libseat/libseat.c:73] Seat opened with backend 'builtin'
[16:11:42.822] [libseat/backend/seatd.c:212] Enabling seat
[16:11:42.822] libseat: session control granted
[16:11:42.823] using /dev/dri/card0
[16:11:42.823] DRM: supports atomic modesetting
[16:11:42.823] DRM: supports GBM modifiers
[16:11:42.823] DRM: does not support async page flipping
[16:11:42.823] DRM: supports picture aspect ratio
MESA-LOADER: failed to open drm-rp1-dsi: /usr/lib/dri/drm-rp1-dsi_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open kms_swrast: /usr/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
MESA-LOADER: failed to open swrast: /usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
[16:11:42.825] failed to initialize egl
[16:11:42.825] [seatd/seat.c:418] No clients on seat0 to activate
[16:11:42.860] [seatd/seat.c:524] Closed client 1 on seat0
[16:11:42.860] [seatd/seat.c:192] Removed client 1 from seat0
[16:11:42.860] fatal: failed to create compositor backend
Internal warning: debug scope 'drm-backend' has not been destroyed.
[16:11:42.861] [seatd/client.c:471] Client disconnected
[16:11:42.861] [libseat/backend/seatd.c:645] Stopped embedded seatd
I have also tried this with different XDG_RUNTIME_DIRs and by passing weston a configuration file to make sure it isn’t related to either of those.
Is weston/mesa supposed to look for those drivers and should i have them? Are they not supposed to be around and it should try to load something else entirely?
How could I go about debugging something like this myself in the future? I tried looking around online and found a lot of random discussions, none of them fruitful. Some pointed towards building mesa in a different way, or updating mesa. Others sent me on a goose chase trying to load different overlays, changing my config and cmdline in small ways, but nothing led me anywhere.
If anyone has experienced this before or has any insights on what I might be doing wrong I would greatly appreciate any form of contact.
Thank you very much in advance, and have a great day.
Marked As Solved
fhunleth
Hi @MagnificentPako,
I assumed it was going to be really easy to point out the missing device tree overlay or kernel module. That’s not the issue, though. You actually found it. I’ll repeat what I saw when looking through Mesa 3D
The problem is that the version of Mesa 3D, 24.0.9, supplied by Buildroot isn’t new enough.
The technical issue is described pretty well in this Mesa 3D commit message. It looks like you found this and started down this path.
These updates are in the Mesa 3D 24.3.0 release.
The good news is that there’s a patch to update Mesa 3D to 24.3.3 that was posted on Jan 18. It’s part of a patch series that is more complicated than I was expecting.
Waiting for the Buildroot maintainers to accept the patch is by far the easiest option, but it takes time. Luckily, the submitter is a maintainer so it may take less time, but I’d still allow for it to take a few more weeks.
The alternative is to fork kiosk_system_rpi5, copy/paste in the Buildroot patch I linked above, rename the package to MESA3D_RPI (or anything that’s not MESA3D so that it doesn’t conflict), and update the nerves_defconfig to use it instead. This is more time consuming than I’m making it sound, and my strategy at this would be to get the update patch working in Buildroot first before trying it out with Nerves. The reason being that the patch looked more involved than I expected and I didn’t understand why on my brief skim of it.
If I get time this week, I’ll take a harder look at that patch. I have a 7" touchscreen, but not the right cable for the RPi 5. I’ll see if I can find one.
Anyway, the summary is that if you can wait, I’m pretty sure this will be fixed in the coming weeks. Thanks for posting that it didn’t work, since until I saw your post, I didn’t know that the situation had changed on the RPi5.
Also Liked
MagnificentPako
Thank you for the swift reply!
I don’t feel comfortable enough with my embedded Linux knowledge to attempt my own buildroot setup, especially considering this is already on its way to being accepted into the repo on its own. Can’t really justify a deep dive on company time and this project already skirts hard on the line if it should be done on company time at all or not haha.
For now I am going to switch to an rPi4 to continue testing my application itself but I will make sure to try it out on the rPi5 down the line once it has been merged to give further input if needed.
Also, thank you for the deep-dive explanation and links for further reading on e.g. the Mesa 3D commit and the buildroot patch. This has been extremely informative for me and I really want to spend some private time on learning more.
lawik
The RPi5 changed stuff about the IO to use the new RP1 chip for DSI displays. That means we need some more overlays and drivers in the system. And can probably remove an old one if we’re lucky.
If you can start the system on Raspberry Pi OS and run these and share the outputs we can get the full set of changed overlays and drivers:
Bootlog:
vclog --msg
Kernel modules:
lsmod
And that should give us roughly what we need to add support ![]()
MagnificentPako
Here is the output of
vclog --msg
004498.944: Initial voltage 800000 temp 30685
004696.400: avs_2712: AVS pred 8420 842000 temp 31235
004696.411: vpred 842 mV +15
005320.435: FB framebuffer_swap 1
005337.953: Select resolution HDMI0/2 hotplug 0 max_mode 2
005337.970: Select resolution HDMI1/2 hotplug 0 max_mode 2
006169.219: dtb_file 'bcm2712-rpi-5-b.dtb'
006264.633: Loaded overlay 'bcm2712d0'
006345.962: dtparam: audio=on
006350.401: Unknown dtparam 'audio' - ignored
006421.710: Loaded overlay 'vc4-kms-v3d-pi5'
006644.660: Loaded overlay 'vc4-kms-dsi-7inch'
009751.184: Starting OS 9751 ms
009753.823: 00000040: -> 00000480
009753.838: 00000030: -> 00100080
009753.854: 00000034: -> 00100080
009753.869: 00000038: -> 00100080
009753.885: 0000003c: -> 00100080
009855.906: sdram: sdram refresh 2081->8324 (1)
040639.290: sdram: sdram refresh 2081->4162 (2)
And the output of lsmod:
Module Size Used by
rfcomm 53248 4
snd_seq_dummy 12288 0
snd_hrtimer 12288 1
snd_seq 81920 7 snd_seq_dummy
snd_seq_device 16384 1 snd_seq
algif_hash 12288 1
algif_skcipher 12288 1
af_alg 24576 6 algif_hash,algif_skcipher
bnep 24576 2
binfmt_misc 16384 1
aes_ce_blk 32768 4
brcmfmac_wcc 12288 0
hci_uart 49152 0
aes_ce_cipher 12288 1 aes_ce_blk
ghash_ce 20480 0
btbcm 24576 1 hci_uart
gf128mul 16384 1 ghash_ce
sha2_ce 12288 0
sha256_arm64 24576 1 sha2_ce
brcmfmac 348160 1 brcmfmac_wcc
bluetooth 606208 33 hci_uart,btbcm,bnep,rfcomm
sha1_ce 12288 0
rpivid_hevc 45056 0
edt_ft5x06 28672 0
brcmutil 24576 1 brcmfmac
pisp_be 28672 0
ecdh_generic 16384 2 bluetooth
cfg80211 983040 1 brcmfmac
ecc 36864 1 ecdh_generic
v4l2_mem2mem 45056 1 rpivid_hevc
libaes 12288 4 aes_ce_cipher,bluetooth,ghash_ce,aes_ce_blk
raspberrypi_hwmon 12288 0
videobuf2_dma_contig 16384 2 pisp_be,rpivid_hevc
joydev 24576 0
rfkill 32768 6 bluetooth,cfg80211
videobuf2_memops 12288 1 videobuf2_dma_contig
videobuf2_v4l2 32768 3 pisp_be,rpivid_hevc,v4l2_mem2mem
videodev 303104 4 pisp_be,videobuf2_v4l2,rpivid_hevc,v4l2_mem2mem
videobuf2_common 69632 6 pisp_be,videobuf2_dma_contig,videobuf2_v4l2,rpivid_hevc,v4l2_mem2mem,videobuf2_memops
mc 61440 6 videodev,pisp_be,videobuf2_v4l2,videobuf2_common,rpivid_hevc,v4l2_mem2mem
rp1_adc 12288 0
raspberrypi_gpiomem 12288 0
nvmem_rmem 12288 0
uio_pdrv_genirq 12288 0
uio 20480 1 uio_pdrv_genirq
i2c_dev 16384 0
ledtrig_pattern 12288 0
fuse 139264 4
dm_mod 143360 0
ip_tables 32768 0
x_tables 49152 1 ip_tables
ipv6 565248 42
rpi_panel_attiny_regulator 12288 5
spidev 16384 0
regmap_i2c 12288 2 rpi_panel_attiny_regulator,edt_ft5x06
tc358762 12288 0
vc4 376832 7
snd_soc_hdmi_codec 20480 2
drm_display_helper 16384 1 vc4
cec 53248 1 vc4
snd_soc_core 286720 2 vc4,snd_soc_hdmi_codec
snd_compress 16384 1 snd_soc_core
i2c_brcmstb 12288 0
snd_pcm_dmaengine 16384 1 snd_soc_core
spi_bcm2835 20480 0
i2c_designware_platform 12288 0
snd_pcm 139264 4 snd_soc_hdmi_codec,snd_compress,snd_soc_core,snd_pcm_dmaengine
gpio_keys 16384 0
i2c_designware_core 24576 1 i2c_designware_platform
snd_timer 36864 3 snd_seq,snd_hrtimer,snd_pcm
drm_rp1_dsi 24576 6
drm_dma_helper 24576 3 drm_rp1_dsi,vc4
snd 110592 9 snd_seq,snd_seq_device,snd_soc_hdmi_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm
drm_kms_helper 212992 6 drm_dma_helper,drm_rp1_dsi,vc4,tc358762
v3d 90112 5
gpu_sched 49152 1 v3d
drm_shmem_helper 24576 1 v3d
panel_simple 90112 0
drm 643072 23 gpu_sched,drm_kms_helper,panel_simple,drm_dma_helper,v3d,drm_rp1_dsi,vc4,tc358762,drm_shmem_helper,drm_display_helper
drm_panel_orientation_quirks 28672 1 drm
backlight 24576 3 drm_kms_helper,rpi_panel_attiny_regulator,drm
Both of these were taken from a fresh installation of Raspberry Pi OS.
Thank you so much for looking into this!
Last Post!
MagnificentPako
Thank you for the swift reply!
I don’t feel comfortable enough with my embedded Linux knowledge to attempt my own buildroot setup, especially considering this is already on its way to being accepted into the repo on its own. Can’t really justify a deep dive on company time and this project already skirts hard on the line if it should be done on company time at all or not haha.
For now I am going to switch to an rPi4 to continue testing my application itself but I will make sure to try it out on the rPi5 down the line once it has been merged to give further input if needed.
Also, thank you for the deep-dive explanation and links for further reading on e.g. the Mesa 3D commit and the buildroot patch. This has been extremely informative for me and I really want to spend some private time on learning more.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex









