Raspberry Pi OS Bookworm Released

retropieuser555

@mitu ahhh yeah sorry you're right, I had the nightly build of PPSSPP, forgot about that. The dev for that emulator seems to update it constantly, always seems to be something new there. You're right though, aside from a couple of games (retro city rampage became 8mb instead of 120 ish, and street fighter came down to 80mb), cso seems to compress roughly the same as chd.

duglor

@retropieuser555 What's the latest build date for retropie's PPSSPP?

retropieuser555

@duglor I use @ExarKunIv 's Extras scripts and get the ppsspp-dev script. It downloads the master branch.

https://github.com/Exarkuniv/RetroPie-Extra

ParadoxGBB

Hi there,

I love Retropie so also wanted to share my notes when I attempted to get it working on Bookworm 64-bit in case it helps with future development. Some of this will sound familiar but a few things seem new. I might try again with 32-bit just to see if some of these clear up --- initially, I really wanted to see if I could get some performance improvements with 64-bit but I was having enough issues, some even performance on 64-bit bullseye, so I think I'm going to give up on that.

mupen64plus does not compile (this is the case in Bullseye 64-bit as well) --- first install libvulkan-dev as described here: https://retropie.org.uk/forum/topic/34679/could-not-successfully-build-mupen64plus/5?_=1698098017277
Oddly, after installing the samba shares through RetroPie-Setup the shares were not set up correctly and I only saw a share called "nobody" that was exposed when I accessed it via my windows box (that I do not have access to). I ran the "fix permissions" routine and then the samba shares routine again, and that did it, but that share is still there. The Retropie-Setup logs indicated that package "wsdd" was not installed the first time (it does not appear to be listed as part of the new packages installed in the log).
Although in another thread someone reported that they were able to get Kodi to install on 64-bit Bookworm, for me the package details show only the binary option (no source) and selecting that reports "Sorry, but Kodi is not installable for your OS/Platform via RetroPie-Setup". Kodi does install via apt-get (Nexus!) but the configuration does not point correctly to the shares and there is an error when launching about a missing config file, but I'm having a tough time finding the output as it's not in the console anymore when I F4. Outside of that, the default out-of-box experience is better than in 64-bit Bullseye --- the default is headphones audio but once you switch it things seem to work, although I haven't been able to test much yet though. Overall I've been seeing a lot of behavioral quirks with Matrix over Leia (one example being https://forum.kodi.tv/showthread.php?tid=374638) and at least some of the issues appear to be platform OS-related, at least on Bullseye.
Oddly, my 8BitDo N30 with a USB wireless adapter is being detected in EmulationStation as an XBOX 360 controller, whereas on Bullseye it's identified correctly. Not sure if it's related or not but I've been having a hard time getting specific ports in retropie like RetroPie to work due to input detection issues (example https://github.com/mmatyas/openblok/issues/26) but that is probably not related to this. OpenBlok looks like it doesn't even compile at the moment in Bookworm 64-bit (https://github.com/mmatyas/openblok/issues/59).

Happy to collect logs or further diagnostics if requested.

Thanks for the hard work! I look forward to grabbing a Pi5 someday, but probably not until another board revision is released.

mitu

@ParadoxGBB said in Raspberry Pi OS Bookworm Released:

mupen64plus does not compile (this is the case in Bullseye 64-bit as well)

Yes, there's a PR fixing that that will be merged soon.

Oddly, after installing the samba shares through RetroPie-Setup the shares were not set up correctly and I only saw a share called "nobody" that was exposed when I accessed it via my windows box (that I do not have access to). I ran the "fix permissions" routine and then the samba shares routine again, and that did it, but that share is still there.

Hm, that's strange. I'll take a look - there's only one change to the samba module (adding the wsdd for easier LAN discovery) and it shouldn't behave like that.

Although in another thread someone reported that they were able to get Kodi to install on 64-bit Bookworm, for me the package details show only the binary option (no source) and selecting that reports "Sorry, but Kodi is not installable for your OS/Platform via RetroPie-Setup". ...

Kodi should be installed from the RPI repos, but there's a bit of a slow start on getting there from their part (i.e. no HW acceleration in the default package config, conflicting add-ons versions). It's something we'll take a look once again when a new version is added.

Oddly, my 8BitDo N30 with a USB wireless adapter is being detected in EmulationStation as an XBOX 360 controller, whereas on Bullseye it's identified correctly.

I don't have one to check, but using the dongle may have an influence on how is detected.

Not sure if it's related or not but I've been having a hard time getting specific ports in retropie like RetroPie to work due to input detection issues (example https://github.com/mmatyas/openblok/issues/26) but that is probably not related to this. OpenBlok looks like it doesn't even compile at the moment in Bookworm 64-bit (https://github.com/mmatyas/openblok/issues/59).

Thanks for the heads up. From the error log looks like the newer gcc version stricter requirements and a header is missing to complete the compilation.

dodonpachi

@retropieuser555 I wonder what the file size difference is between CHD and CSO?

Having been part of the PSP scene back in the late 2000s, the trick was to open the ISO in UMDGen, remove the firmware update data (every game has it), then compress as CSO. You would shave off an additional 10-60 MB on top of the CSO compression. That doesn't sound like a big deal now, but back when 2 GB memory cards were expensive, every megabyte counted!

There's only two games I know of which can't utilize the update rip trick: Ikkitousen Xross Impact (can still compress CSO), and Tekken 6 (cannot compress to CSO).

ParadoxGBB

@mitu Thanks for taking your precious time as I'm sure there's lots of other stuff to look out out there. Next week for fun I'm going to repeat this with 32-bit and I'm curious if the samba thing reproduces.

If it helps, the basic procedure I do is after setting up permissions and SSH I follow the rest of the procedures for RetroPie manual installation via SSH, including installing RetroPie-Setup through it and by extension configuring the samba shares. It's more convenient than moving around hardware or keyboards to / from my TV.

Just so I understand correctly re:Kodi, I understand that there are a lot of moving parts (some on their end) but since it does install and so far as I can tell functional I would have expected RetroPie-Setup to allow it. If it's about protecting users the opening warning about 64-bit not being supported should do it I would think. Normally it's not a big deal to install manually but as I mentioned doing so seems to not have the configuration at the right spot.

Speaking of protecting users, just to post here in case folks are trying at home: if you're trying to install Steamlink, it's a similar thing to kodi in that it's disabled. In the case of Bullseye 64-bit installing it via apt-get didn't work due to some confusion about the audio differences, even when trying procedures like https://blog.iancolwell.ca/steamlink-aarch64. On Bookworm, the setup complained that a number of dependency packages not being available yet (for example libx264/265), and if you follow through with setup before it detects that (there are two steps for setup, one via apt-get and one on first launch) it is very naughty and uninstalls a number of packages like kodi and samba dependencies. So if you want to do testing, don't do that.

windg

If someone else experimenting with RPi4 and Bookworm Lite 32 bit, have seen any black screen ? Screen going black and the only think i can do is to use alt+ctrl+del. I think is happening, most of the time, if i start a game with scummvm standalone, exit and then start a game from other system and wait without press a button for few minutes. I think is happening and without start scummvm. The trick is to choose the game and wait.

mitu

@windg Are you experiencing this issue ? Check dmesg for the error reported in the issue.

retropieuser555

@windg funnily enough I noticed this on 64bit bookworm build on pi 4 , but I suspected it was my TV/display as I couldn't replicate the error consistently. I did find it in Retroarch as well, not just on standalone emulators like mupen64plus , flycast or scummvm (tbf haven't played much of scummvm to test). I found it most common playing donkey Kong 64, but that could just be because I happened to play a few hours of that game recently moreso than anything else. If I'd played hours in something else perhaps I could replicate it

windg

@mitu said in Raspberry Pi OS Bookworm Released:

@windg Are you experiencing this issue ? Check dmesg for the error reported in the issue.

I checked dmesg but didn't find this error maybe because I tried the command after rebooting the system, I tried to connect from SSH when the system froze but it wasn't possible. Thanks!

windg

@retropieuser555 Thank you! At least now I know that I don't have a hardware problem.

RapidEdwin08

I may be experiencing this issue as well, I have not dmesg'd it, I honestly thought it was Dreamcast mem leak at first, but then the issue still occurred using lr-flycast on x2 different Pi4's with same build.

Bookworm Lite 64bit, TDE, RetroPie 4.8.5, and dtoverlay=vc4-kms-v3d build working perfectly for me except this black screen issue.
Screen goes black, but can here sound in background, just black screen, ssh still accessible.

Tried adding this to config .txt as well:

hdmi_force_hotplug=1

I will try the fix mentioned in this issue and see if it helps:

sudo rpi-update pulls/5684

Thanks for the info.

windg

@mitu It was possible to reproduse the issue and take a log from dsmeg . I confirm, is the issue you had reference.

[ 1719.110492] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.122901] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.142546] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.512824] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.558539] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.712749] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.764220] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1719.815609] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28
[ 1720.213005] vc4-drm gpu: [drm] *ERROR* Failed to allocate DLIST entry: -28

Full dsmeg log: https://pastebin.com/75t7DSy9

mitu

@windg well, if you feel adventurous, you can try to install the ~~latest~~ rpi-update kernel from the linked issue and see if it fixes it. But, if you have any drivers installed for one of your gamepads, they'll likely break since there's no corresponding headers installed.

windg

~~I will leave it for now, i~~t is obvious that the OS needs time before it can be used for our purpose.

Ok i installed the latest kernel, i reinstall also xpad driver. So far no issues but will need few days to be sure.

windg

I used this setting in the last few days, with the kernel fix, and so far the system hasn't frozen again. If anyone wants to try it be careful, as mitu warns, it breaks the gamepads drivers.

mitu

@windg The fix has been merged into the RPI kernel, it will probably be in the next kernel package upgrade.

windg

@mitu This merge will add and the headers? Thanks!

RapidEdwin08

@windg said in Raspberry Pi OS Bookworm Released:

I used this setting in the last few days, with the kernel fix, and so far the system hasn't frozen again. If anyone wants to try it be careful, as mitu warns, it breaks the gamepads drivers.

Same here on x2 RPi 4's, No Issues since applying Kernel mentioned above.

I did not have to touch anything in regards to my generic xbox360 style joypad/receiver on either Pi.
Both of them worked out of the box before even installing xpad driver (or Kernel Fix) from RetroPie-Setup to begin with.
Ran lsusb -t and both appear to be using Driver=xpad at the moment.