[Raspberry Pi 5] 4KB Page Memory Incompatible with 16KB Page Memory #1047
Comments
|
Which dynarec are you using? I'm sure they have different code for allocating
executable pages.
Richard
…On 11/8/23 19:09, retropieuser wrote:
Raspberry Pi 5's kernel is built with 16kb rather than with 4kb page memory.
Because of this while you can compile mupen64plus you cannot run it as you
will always get a crash as the Pi can't handle the 4kb memory.
This is similar to the issue here with flycast:- flyinghead/flycast#1288
<flyinghead/flycast#1288>
Can anyone point to me where the page memory is specified by mupen64plus
please? As have found manually setting it to 16kb fixes the issues for flycast.
—
Reply to this email directly, view it on GitHub
<#1047>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPQSH3O3CHR3ZO2EQ4ZK7TYDRCNNAVCNFSM6AAAAAA7D3ZE22VHI2DSMVQWIX3LMV43ASLTON2WKOZRHE4DINZTG4ZDGNQ>.
You are receiving this because you are subscribed to this thread.Message ID:
***@***.***>
|
|
|
|
I realized after I sent my earlier email, that since you're on the raspberry
pi, it is an ARM CPU so you must be using the new dynarec. The old one is only
x86.
You can choose Pure or Cached interpreter here and they shouldn't have the 4k
page size problem, but they will also be much more CPU-intensive since they
won't be using the dynarec.
Richard
…On 11/8/23 19:40, retropieuser wrote:
|# Use Pure Interpreter if 0, Cached Interpreter if 1, or Dynamic Recompiler
if 2 or more R4300Emulator = 2|
Should I attempt Pure or Cached? Will that make any difference?
—
Reply to this email directly, view it on GitHub
<#1047 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPQSHZZTGEV6CHIUM4HAWLYDRGBTAVCNFSM6AAAAAA7D3ZE22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTGEYTGOJUGI>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Thanks Richard, I tested changing to pure and cached interpreter and can load mupen64plus now thanks. Perhaps it is very CPU intensive but the games do seem to work. There's no way to use the dynarec in 16kb by changing the way it builds? Or that wouldn't optimise the emulator on pi5 anyway? |
|
Using the dynamic recompiler instead of the pure/cached interpreter should improve speed and/or reduce CPU usage. But after looking through the code of the new dynarec, I don't think the page size should affect this software. It just allocates a big 32 megabyte buffer to store the executable recompiled code and runs everything from within that big block. It doesn't do anything with page-sized memory blocks, so I don't understand why the 16k page size of the RPi5 would cause problems. Additionally, Mupen64Plus has recently been tested to work on Apple Silicon M1/M2 chips, and from what I've read, these also use 16k pages. |
|
That's true regarding the Silicon Mac machines, but they have their own workaround that's mentioned here that explains why it affects Linux aarch64 but not OSX:- https://github.com/AsahiLinux/docs/wiki/Broken-Software Perhaps it's not the page memory that's causing the failure then if the memory in it isn't 16k |
|
that link was informative. it seems these 16k page systems have problems when the executable sections are not aligned. I'm pretty sure that we don't have any makefile gcc/clang options to force 4k sections, but maybe there's some option is needed to set the alignment to 16k. Can you send me the terminal dump from when you run the mupen64plus front-end and it crashes, and also an archive of the entire build directory with the libraries and executable? I don't have a raspberry pi 5 to make builds. |
|
Hi there this was the error you get, doesn't really tell you much:- `pi@raspberrypi:~ $ /opt/retropie/emulators/mupen64plus/bin/mupen64plus mupen64plus-video-GLideN64 "/home/pi/RetroPie/roms/n64/007 - GoldenEye (USA).n64" | / |_ _ _ __ ___ _ __ / /_ | || | | _ | |_ _ ___ UI-Console: attached to core library 'Mupen64Plus Core' version 2.5.9 |
|
Well the problem cannot be the section alignment issue discussed in your AsahiLinux link, because everything loads and runs if you use the cached/pure interpreter. So it must have something to do with the dynarec, but I think there's not enough information here to really understand the cause. I don't think it has anything to do with the 16kb page alignment, because the executable memory which the new dynarec allocates to store the JIT-recompiled code is allocated in a single big block which is aligned to a 64kb boundary. Perhaps there is some other difference with the CPU in the raspberry pi 5 which is causing this crash. In order to debug this, we need to run it in the debugger and see exactly where it crashed. Can you install "gdb" on your system and run a few simple commands? You just need to start it up and take a back trace when it crashes, like this: Then post here the stack trace that you get from the "bt" command. It would also be nice to see the output of the "disassemble" command to see exactly which instruction caused the crash. |
|
Hi Richard, here you are:- `(gdb) run | / |_ _ _ __ ___ _ __ / /_ | || | | _ | |_ _ ___ UI-Console: attached to core library 'Mupen64Plus Core' version 2.5.9 Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault. |
|
Try defining |
|
I'm not 100% confident I built it all correctly as I use this script usually:- https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/mupen64plus.sh I edited lines 177 and added in the above, that should've built the ui-console differently right? Sorry I know that's not your script so am asking a bit much for to take a look. But anyway after my edits it all built but still only works only pure or cached interpeter |
|
Even better, use: You don't need to edit anything. |
|
I think we need to look at the exact instruction which is causing the segfault. maybe the dynarec is writing out some opcode which is not supported by the ARM CPU on the pi5. Can you use the "disassemble" command to get an assembly listing of the instructions around the crash point? Like in your previous example, where you got the error at this location:
You would type:
|
|
(gdb) bt (gdb) disassemble (eventually changes to this and goes on forever) (gdb) frame 1 (gdb) disassemble (gdb) info registers relevant info proc mappings |
|
Okay, it looks like the piles of undefined instructions do end at the memory address where the segfault happens: |
|
Benjamin, this is good debugging info here, but I suspect that this is a different problem than the one originally reported by retropieuser. He was experiencing the crash with the mupen64plus console UI, while I see that you are a running retroarch/libretro, which is a fork of mupen64plus and a different code base. In your case, we can see that the code branched to 0x7fffe324bfd0 (start of new_recompile_block()) but then somehow ended up crashing at 0x00007fffe97fe000, which is 100 megabytes away in the memory map. It's not clear how it got from that starting place all the way to the end. |
Raspberry Pi 5's kernel is built with 16kb rather than with 4kb page memory. Because of this while you can compile mupen64plus you cannot run it as you will always get a crash as the Pi can't handle the 4kb memory.
This is similar to the issue here with flycast:- flyinghead/flycast#1288
Can anyone point to me where the page memory is specified by mupen64plus please? As have found manually setting it to 16kb fixes the issues for flycast.
The text was updated successfully, but these errors were encountered: