installation README.TXT

kernel 5.17.7

slarm64-current-aarch64-server-quartz64-5.17.7-build-20220515.img.zst
slarm64-current-aarch64-server-quartz64-5.17.7-build-20220515.img.zst.sha256
slarm64-current-aarch64-xfce-quartz64-5.17.7-build-20220515.img.zst
slarm64-current-aarch64-xfce-quartz64-5.17.7-build-20220515.img.zst.sha256

installation README.TXT

kernel 4.19.248

slarm64-current-aarch64-server-quartz64-4.19.248-build-20220626.img.zst
slarm64-current-aarch64-server-quartz64-4.19.248-build-20220626.img.zst.sha256
slarm64-current-aarch64-xfce-quartz64-4.19.248-build-20220626.img.zst
slarm64-current-aarch64-xfce-quartz64-4.19.248-build-20220626.img.zst.sha256

installation README.TXT

kernel 5.19-rc3

slarm64-current-aarch64-server-quartz64-5.19.0-rc3-build-20220626.img.zst
slarm64-current-aarch64-server-quartz64-5.19.0-rc3-build-20220626.img.zst.sha256
slarm64-current-aarch64-xfce-quartz64-5.19.0-rc3-build-20220626.img.zst
slarm64-current-aarch64-xfce-quartz64-5.19.0-rc3-build-20220626.img.zst.sha256

installation README.TXT

kernel 4.19.193

slarm64-current-aarch64-server-quartz64-4.19.193-build-20220707.img.zst
slarm64-current-aarch64-server-quartz64-4.19.193-build-20220707.img.zst.sha256
slarm64-current-aarch64-xfce-quartz64-4.19.193-build-20220707.img.zst
slarm64-current-aarch64-xfce-quartz64-4.19.193-build-20220707.img.zst.sha256

latest xorg updates kinda break display on both legacy and next
 

This one has me scratching my head. I run a Quartz64-A legacy image daily. When I installed the latest batch of xorg updates (on 15.0, not current), my default screen resolution dropped from 1920x1080 down to 1200x1080. I know it was the xorg updates because everything was working like normal before those, and I updated nothing else.

I checked a freshly-built quartz64-a next image, and it boots up just fine. However, if you run the updates and let the xorg updates install, then on reboot, X does not start at all, regardless of the resolution.

I am going to try some older images to isolate if any specific kernels, u-boot versions, or ATF blobs change anything. I just wanted to give you a heads up on this one because you can probably check it yourself (just update any xfce image for the quartz-a and see if X behaves any differently afterwards).

I checked other machines, and the Pinebook seems to be affected also. X starts but then is completely blank, no output at all. None of my x86 machines are acting like this, so it seems slarm64 or aarch64 specific maybe? I can also test my Rock64.

Or maybe this is just me? I only have one monitor to test, sadly. If anyone notices anything similar with the xorg updates on any quartz64 images, I would love to hear about it. Thanks.

let's see dmesg and Xorg.0.log

installation README.TXT
kernel 5.19-rc6

slarm64-current-aarch64-server-quartz64-5.19.0-rc6-build-20220717.img.zst
slarm64-current-aarch64-server-quartz64-5.19.0-rc6-build-20220717.img.zst.sha256
slarm64-current-aarch64-xfce-quartz64-5.19.0-rc6-build-20220717.img.zst
slarm64-current-aarch64-xfce-quartz64-5.19.0-rc6-build-20220717.img.zst.sha256

i built a new image kernel-5.19.0-rc6 with the latest xorg:
xorg works:

I have been able to isolate this to the stable 15.0 branch. The problem is present on Rock64, Pinebook, and Quartz64 (legacy and next), only as long as I am on the stable branch. Checking the current branch, I see the problem is not there. So this has something to do with the stable xorg updates.

I will try to generate some logs. I can say for sure on the Pinebook the error message is "no display found". Stay tuned for more info. I was busy testing my other boards to try to isolate the issue.

I know I should always generate logs before I even report here. In any case, here are the relevant logs for a recent Quartz64-A next image on the 15.0 stable branch:

https://slarmboards.3space.xyz/quartz64/logs/

Xorg.0.log, dmesg, and also Xorg.1.log are there as text files, renamed for the board and kernel branch.

I will generate more logs as I have time.

Thanks for the logs.

it is not immediately clear why lib instead of lib64 (clearly, in 15.0 it is)
error in this: modesetting_drv.so: undefined symbol: shadowRemove

Good catch. Yeah I saw that too, but I was not sure what to make of it. Looking around the 'net, I found this thread:

https://forums.gentoo.org/viewtopic-...8-start-0.html

They mention the same problem and a fix. I tried the fix on a Rock64 that was behaving exactly the same as the Quartz64. I added a Modules section to /etc/X11/xorg.conf.d/10-monitor.conf. I put in the same modules that were used in the other thread. Upon booting, X seems to start fine now, but I have no keyboard or mouse at all. Maybe I have to add these too? Or maybe I added the wrong modules. In any case, X starts now, which is interesting. I think if I can just figure out the right modules and the right order, this might correct the problem.

Thanks for the lead, that helped.

For some mad reason I was compiling Mesa (version 18 or 19?) when it went over to some crazy build system. My first reaction was that some friend of the devs must have cobbled it up, and bought the drinks:rolleyes:.

Alien Bob promptly did a build script for it, which tied every single detail and didn't allow it to do any thinking at all. If you guys building the OS asked him nicely, I'm sure you'd get a copy. I did, many years ago.

the solution is simple, when building in patches, all flags were applied, and deleting flags CFLAGS -fno-plt, CXXFLAGS -fno-plt, LDFLAGS -z,now solves this problem.
packages updated.

Yes, that did the trick, problem solved here. Thank you!