brokenxorg means it crashes when launching the display manager, no X
But i fixed it with a little help from claude (if you mind the generated text stay on bookworm):
Debian 13 (trixie) working on the Pyra: three fixes
The pyra-trixie-t1-brokenxorg image has been sitting in packages.pyra-handheld.com/images/trixie/ since February with a name that promises a broken X server. I got it fully working on my V5.3 unit this weekend. MATE desktop, WiFi, touchscreen, keyboard, nubs, and hardware GLES2 through the SGX blob, all on the same 5.6.19-pyradef kernel that bookworm-7 uses. Three fixes: a symlink, a skipped first-run wizard, and one copied systemd unit.
Write the image to an SD card for the left slot as usual. It boots live and leaves the eMMC alone. Then, before first boot, mount the rootfs partition on any Linux box (I'll assume /mnt below) and apply the fixes offline. The wizard problem powers the unit off shortly after boot, so fixing things from a half-booted device is a chicken-and-egg fight you can skip entirely.
Fix 1: the Xorg segfault
Xorg 21.1.16 dies during GLX initialisation:
Code:
(EE) AIGLX error: dlopen of .../dri/armsoc_dri.so failed (... No such file or directory)
(EE) AIGLX error: unable to load driver armsoc
(EE) Segmentation fault at address 0x0
(EE) Caught signal 11 (Segmentation fault). Server aborting
armsoc_dri.so does not exist on bookworm either, which took me a while to notice. Bookworm's Xorg 21.1.7 logs the exact same two AIGLX errors and simply carries on. Somewhere between 21.1.7 and 21.1.16 that failure path picked up a NULL deref. So the fix is to hand AIGLX any loadable DRI driver so it never reaches the broken path:
Bash:
ln -s kms_swrast_dri.so /mnt/usr/lib/arm-linux-gnueabihf/dri/armsoc_dri.so
GLX lands on swrast, which sounds like a loss until you check bookworm and realise GLX was always software rendered on this platform. Desktop GL never touched the SGX. The hardware path is GLES2 through the blob's EGL and dri3wsegl, and that one survives intact. Numbers at the end.
Fix 2: the first-run wizard shuts the unit down
With X fixed you boot to the fullscreen Pyra wallpaper and then the device powers off. Nothing crashed. pyra-first-run.sh sets the wallpaper, then shows a zenity question dialog whose cancel button is labelled "Shutdown", and in that bare xinit session the dialog gets no usable input, so the script takes the cancel branch and calls poweroff. Fair warning, I never retested the wizard after properly fixing X, so it may well behave now. Skipping it is the path I know works:
Bash:
mkdir -p /mnt/var/lib/pyra
touch /mnt/var/lib/pyra/first-run.done
The wizard's main job is creating your user, so do that offline too:
Bash:
HASH=$(openssl passwd -6 'yourpassword')
echo 'pyra:x:1000:1000:,,,:/home/pyra:/bin/bash' >> /mnt/etc/passwd
echo 'pyra:x:1000:' >> /mnt/etc/group
echo "pyra:$HASH:20000:0:99999:7:::" >> /mnt/etc/shadow
mkdir -p /mnt/home/pyra
cp -a /mnt/etc/skel/. /mnt/home/pyra/
chown -R 1000:1000 /mnt/home/pyra
Then open /mnt/etc/group in an editor and add your username to the sudo, video, audio, netdev, plugdev, bluetooth and dialout lines.
Fix 3: dead nubs
This one is a genuine packaging bug, funkeymonkey-pyrainput 0.1.19 in the trixie repo ships without /lib/systemd/system/pyrainput.service. The identical version in the bookworm repo has it. Until the package is rebuilt, drop the file in yourself:
Code:
[Unit]
Description=Pyra Input Deamon (funkeymonkey)
After=network.target
Documentation=https://dev.pyra-handheld.com/packages/funkeymonkey-pyrainput
[Service]
ExecStart=/usr/sbin/funkeymonkey -g -p /usr/lib/funkeymonkey/libpyrainput.so -r 0,1,2,3 -m nub0 -m nub1 -m "tca8418" -m "pyra-game-buttons" -X config=/etc/pyrainput.cfg
ExecReload=/bin/kill -USR1 $MAINPID
KillMode=process
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=pyrainput.service
Save it as /mnt/lib/systemd/system/pyrainput.service, then after first boot run `sudo systemctl enable --now pyrainput`. All three pyraInput devices (keyboard, Gamepad, Mouse) show up and the nubs behave exactly as on bookworm.
Booting the card
One trap left. The U-Boot on this image (2016.11, rebuilt 2024) asks the Palmas PMIC why the unit powered on and refuses anything that is not a real button press. A short tap gives you a quarter second of LED and then silence, which looks exactly like a dead card or a dead battery. It is neither. Hold the power button until both LEDs go green, then release. The older U-Boot on a stock eMMC has no such check, which is why bookworm boots off a tap and this card appears not to boot at all.
Is the GPU actually working?
I wanted proof rather than a vibe, so I wrote a minimal X11+EGL+GLES2 client and compiled it on the device against the blob headers in /opt/omap5-sgx-ddk-um-linux/include (you need libx11-dev). Output on trixie, inside the X session:
Code:
DRI3 1.0
present 1.2
EGL_VENDOR: Imagination Technologies
GL_RENDERER: PowerVR SGX 544MP
GL_VERSION: OpenGL ES 2.0 build 1.14@3699939 (MAIN)
300 frames in 0.24s = 1270.9 fps
The DRI3/present lines mean libpvrDRI3WSEGL is doing the window integration, which is the same path the bookworm desktop uses. Bookworm manages 1170 fps on the identical test, so nothing was lost and trixie is marginally quicker. A side note for the armhf-curious: the test binary compiled on bookworm ran unmodified on trixie, so the 64-bit time_t transition did not bite this particular stack. Do not bother with the DDK's own gles2test1 for this, it is a direct-KMS test that wants DRM master and fails identically on both releases when X is running.
Not tried yet: gl4es and box86 on trixie. If someone beats me to those, post your results here. Happy to share the GLES test source if anyone wants to reproduce the numbers.
