That would be for the mainline kernel, right? I should see the correct module loaded when using the official Raspberry kernel, but I'm not seeing that. So I'm a bit stumped.

Yes, the bug report is for the mainline kernel. Those commits are from the Raspberry Pi kernel. I will take a look more tomorrow and read the source code for both kernels to compare.

This is exactly why I've been waiting to diagnose the vc4 and v3d kernel drivers. I do not want to waste my time fixing/patching code if it could be addressed in the next kernel release. What is more interesting is the Raspberry Pi 3 B I have is showing the same bug since the updates to kernel 5.18.3. You may be right about it not being a kernel issue. That leaves us with the boot firmware and the kernel firmware. Seeing as HDMI works in u-boot up until the initrd loads, it could be possible that it is another issue. In my research I saw it mentioned that the "flip_done" type errors are generic and might mean that a number of different issues are present.

I did some more digging and it looks like we should be seeing:
showing up in the dri directory. Substitute the * for numbers. From what I have read, if the rednerD file is not being created, then GPU rendering will not work. This is not created in either the mainline or the raspberry kernel. So I think something is amiss elsewhere.

Sorry if I'm deviating too much from the original topic. We can create a new thread.

So I found this thread.

The .config file for the rpi kernel is:
and mainline:
I even tried switching to:
in config.txt. However, that didn't make a difference. The renderD devices were not created.

Some progress. I grabbed the latest firmware version from the raspberry git site. Version 1.20220331.

I noticed that:
file from the firmware tar file was double the size as the one provide in Slackware aarch64. So I went ahead and swapped that one file and proceeded to reboot using the rpi kernel. The renderD file is now being created along with card1:
When I rebooted to the mainline kernel, the renderD128 and card1 did not get created.

Even after doing this, I am still getting llvmpipe. I feel like I'm very close to figuring out this puzzle.

"dtoverlay=vc4-fkms-v3d" Is if you you use RPI´s kernel and have RPI´s V3D drivers installed in /opt/vc, however if you are using kernel that ships with Slackware ARM you should use "dtoverlay=vc4-kms-v3d".

OK, looks like progress is being made here, and thanks to all those who are contributing!

I've finally found time to do a complete re-install on my Pi400, and the results are - er - interesting!

At first I was unable to get X to start again, so I uncommented to the gpu_mem line, as I've found that helped in the past. I also added the rpi-400 device tree line. This eventually got xfce running after a very long wait, and also got KDE running after an even longer wait! Interestingly, despite appearing to be "frozen" (no hdmi output), the keyboard still appeared to be responding, unlike previously. I could shorten the time to get into X considerably by doing a "ctl-alt-F4" immediately after the startX command, and then switching to "alt-F1". Lo and behold, there was xfce! It also works with KDE!

I need to do some more playing around to confirm this, but it looks as if after starting X, it switches to a non-existent console (tty7?), and following the procedure above seems to get it back to the right one. Could someone else try this and confirm? You need to allow a short amount of time for xfce (or KDE) to actually start, but nowhere near the time when left to its own devices!

One other point of interest. In dmesg (and the boot screen), I'm seeing:But hdmi IS enabled in config.txt (attached).

I get the feeling config.txt is either not being read, or not being read properly.

Can someone check my config.txt in case of an error on my part?

Cheers,

--
Pete

Attached Files

config.txt (2.7 KB, 10 views)

You are telling it to load the Pi 400 dtb for the pi 4. Change:

to
I have a working KDE and Xfce- both without with the compositor disabled. I played some videos in youtube, copied files via the file manager from my samba share, and other things. Here is the config.txt I have on my pi 4, simplified:

Everything else was commented out. This configuration allows me to run a GUI with llvmpipe and no lock ups. I left it running on youtube with auto play enabled for several hours last night. I may try out 4k today to see what happens.

I forgot to mention I had to black list the snd_bcm2835 kernel module. HDMI sound output still works with this change. Requires reboot.

I did wonder about that! I'm sure I tried it both ways, but will try again!

I'll also have a look at your other suggestions.

UPDATE: OK, tried uncommenting the pi400 line, but no difference - and still getting the "enable_hdmi" messages. I'm not convinced the config.txt file is being read.

Update 2: Blacklisting the snd_bcm2835 kernel module, as suggested by mralk3, has got Plasma starting normally now, without the long wait! Still getting the enable_hdmi message, though.

Cheers,

--
Pete

Add to your pi400 section:

KDE and Xfce work normally now on my Pi 4. BUT, I highly suggest that compositing is disabled. Performance will be better. The llvmpipe renderer is still used.

@stormtracknole

Yes, it is close. I thought maybe the issue was related to the rpi-userland package. It needs polishing. The hwm-bw-raspberrypi package handles all the firmware, including the rpi-eeprom utilities. The firmware tarball can be updated by changing the git tags in slackware/a/hwm-bw-raspberrypi/sources/get-firmware.sh. Then install the package you generate with the hwm-bw-raspberrypi.SlackBuild script.

I think there is some small detail I've missed that will allow the /dev/renderD* to be created. 3D acceleration would be a nice thing to have and would bring the Slackware Pi support up to speed with Raspberry Pi OS, I think.

Have you installed the RPI´s V3D drivers in /opt/vc?

If so, You will have to edit /etc/ld.so.conf for required libraries links.
This is done like this:

[QUOTE=mralk3;6361782]Add to your pi400 section:

No, that didn't help. I didn't really expect it to, as otherwise I shouldn't have got the errors before I uncommented the [pi400] line.

I'm not sure how important the "enable-hdmi" errors are, as my monitor can only do 30Hz at 4K anyway (it was very cheap! ) The fact that they are there and I'm unable to get rid of them point to some other underlying issue, though. The only thing I can think of is that - for whatever reason - config.txt is not getting read at all!

I might try commenting everything in it out and see what difference (if any) that makes. (Clutching at straws here!)

UPDATE: I had already commented out everything under the [pi4] and [pi3x] headers, so I commented out everything under the [pi400]. The only difference it made was to the size of the font on the initial boot screen! Aside from that, everything else seemed to be exactly the same!

It looks as if the file is actually being read, but chunks of it are being ignored!

--
Pete

You wouldn't see any errors. The only sections in your config.txt that were active were the Rpi 4, 3s, and the all portions. [pi400] was commented out. Meaning anything you put there would be picked up by the pi 4 config. Resulting in your pi 400 booting with whatever was in the [all] section and the defaults applied by the raspberry pi 400 eeprom firmware.

The config file is in fact being read by my Pi 3 and my Pi 4. The Pi400 isn't supported because neither myself or MoZes have a Pi 400. I have no plans to purchase one either. You will have to tweak the config file yourself. It is kind of hard for me to know your monitor specs, if you have dual displays, or what your configuration file looks like.

If it were my system I would take a look at the documentation here: https://www.raspberrypi.com/document...#video-options

I briefly looked over the docs. Try out hdmi_safe=1 first. Provided that doesn't work, you should take a look at:
https://www.raspberrypi.com/document...-configuration

Specifically the mention of the refresh rates.
Finally, as I stated several posts back, use a fresh config.txt file. Put in the options you know you need and reboot. Rinse and repeat if you do not find desired outcome.

I'm beginning to think that this hdmi error message is associated with the oddball way that slackwareaarch64 is handling the graphics drivers. I did try importing the config.txt file from slarm64 (which works without the hdmi errors) and the only change I made was that necessary to point to the correct u-boot file. I still got the hdmi error. Conclusion: something else somewhere must be preventing the 60Hz hdmi setting from being enabled. It is not the config.txt file.

Just to clarify: I am getting 4K out at 30Hz, which is all my monitor can cope with anyway, but I am getting the "enable_hdmi" error message which suggests something is odd about the graphics drivers - something of which we are already aware.

I have a feeling that once we can get the correct drivers running, instead of llvmpipe, this error will go away.

In the meantime, at least the system seems to be otherwise stable now. X hasn't crashed since the upgrades, and once I blacklisted the snd_bcm2835 kernel module, the startup became about what I would expect. This is all good progress.

However, I'm afraid the internal workings of the graphics are way above my pay grade, so I'm not sure how much more help I can be, other than as a voluntary test-bed for any suggestions.

Cheers,

--
Pete

same here

Latest with my aarch64 setup on rpi4 is display is on, display goes off, like I'll be changing something system settings, hit apply and display goes away, I think I've come back little while later and it'll be back.