RetroPie-Extra Repository - lr-samecdi

Folly

I tried it on my rpi5/8gb/64bit-bookworm and it freezed the first time.
So, just like with lr-mess, I added an additional swap to the module-script.
For me the additional swap worked.

However I can imagine that if you have a 32bit-bookworm running that it will refuse to compile correctly.
You will probably get a PTR error.
Might be that you need to set changes in the /boot/firmware/config.txt

This is what I changed for now :

function build_lr-same_cdi() {
    if isPlatform "64bit"; then
        rpSwap on 10240
    else
        rpSwap on 6144
    fi
    make -f Makefile.libretro clean
    make -f Makefile.libretro
    rpSwap off
    md_ret_require="$md_build/same_cdi_libretro.so"
}

I will see if I can test it later on a 32bit-os.
If I get it working I will do a pull-request.

Edit :
Just tried on a 32bit os and as expected I got the error :

error: static assertion failed: PTR64 flag enabled, but was compiled for 32-bit target

My config.txt has (manually added) :
arm_64bit=0

Folly

@Retrodade

Do you run a 32bit-os ?
How much ram does your pi5 have ?

ExarKunIv

@Folly thanks for looking into this
ill add it to my script and test with mine,
i have a 4 gig

Folly

@ExarKunIv

For a 32bit OS (Bullseye/Bookwork) we probably need to patch the Makefile.libretro so it will use the flag PTR64=0.
Most likely that will be a quick fix.
Good info about conditions can be found over here :
https://stackoverflow.com/questions/4879592/whats-the-difference-between-and-in-makefile
The idea is to change PTR64 ?= 1 into PTR64 := 0 in :
https://github.com/libretro/same_cdi/blob/master/Makefile.libretro#L07
According to the conditions info that should force the PTR64 flag to 32bit even if it later detects it differently.
:= should force it the first time it's found.

Alternatively I tried to add -DPTR64=0 to the make command with forcing the libretro makefile, earlier on, but that made no difference.
This is most likely due to the fact that in newer OSes the arch is always detected as aarch64 no matter if it's running 32bit.
So if it uses that info to see if it is 64bit or 32bit it will always be detected as 64bit.
If it could work it also means patching the makefile.
However I can't find the part yet what's responsible for that.
You will also see that in the makefile it is guessed to set it to 1 in the beginning and in most functions it's not altered so it will stay on 1.
Which is off-course correct if it 64bit is detected correctly.

Using the regular Makefile could be an option just like with lr-mess as lr-same_cdi is basically a patched mame driver.
Then we could add the flags just like with lr-mess and only add the PTR64=1 if needed. If we want to use this approach we need to find out how to compile for cdimono1 only otherwise it will try to do all mamedrivers which don't exist it this source.

When I can I will test the first approach first.

ExarKunIv

@Folly sounds good to me, this one is a bit more on what you have delt with then I. so big thanks for looking into this

Folly

@ExarKunIv

Tried everything to no avail.
Every time I try PTR64 is forces to 1, even if I quickly use sed to change the generated make files.
Adding this to the config.txt also makes no difference :

kernel=kernel8.img
arm_64bit=0

The only options seems to be :

use the 64bit OS
create a real 32 kernel and try again.

More info can be found here :
https://forums.raspberrypi.com/viewtopic.php?t=366246
Conclusion is that the system kernel used in the RPi5 BookWorm 32-bit system is still 64-bit.

For mame and lr-mame/lr-mess this problem is the same as far as I know.

Could be that 32bit is a dead end in the future.

Not sure what flag we need to put in.

ExarKunIv

@Folly thanks for trying, if it only will work on 64bit, it is what it is.

as for the flag we just need to use 64bit and we should be good

Folly

@ExarKunIv

I am trying on rpi4 now using kernel7l and Bookworm and see what it does.
Using the same image as used on the rpi5 but now with :

kernel=kernel7l.img
arm_64bit=0

(Btw. the pi5 would not boot with these settings)

About the flag, if we use 64bit then all older pi's and older OSes will also not work anymore.
We could make it 64bit if the platform contains rpi5 agree ?

This code ~~should probably work~~ (update : doesn't work) :

rp_module_flags="$([[ ${__platform_flags} == *rpi5* ]] && echo 64bit)"

Edit :
Post should now be good I edited many times ;-)

Folly

@ExarKunIv

On my pi4 it compiled ok. (32bit/Bookworm/kernelv7l)
Tested this binary on my pi5 by switching the SD card.
Of-cource commenting the kernel :

#kernel=kernel7l.img
arm_64bit=0

The binary now runs on the pi5 "32bit OS".

ExarKunIv

@Folly said in RetroPie-Extra Repository - lr-samecdi:

We could make it 64bit if the platform contains rpi5 agree ?

If your code works. I have no problem going with it that way.

Or have it switch on what it needs to compile depending on what OS type they are using

Maybe something like this

if isPlatform "odroid-n2"; then
	/home/aresuser/ARES-Setup/fixmali.sh
    elif isPlatform "rockpro64"; then
    /usr/lib/arm-linux-gnueabihf/install_mali.sh
	fi

Not sure if that will work for you are trying

mth75

@ExarKunIv I removed rp_module_flags="!rpi5" and could compile samecdi and start the core. Only problem: Fatal error: required files are missing. The bios files are all in place ...

ExarKunIv

@mth75 yes folly is still working on it. but its looking good so far

Folly

@mth75

Summary is that the core will compile ok if the rpi5 has a 64bit os running.
However if you use the "32bit version" on the rpi5 it will not compile correctly as the rpi5 still runs a 64bit kernel (with 32bit userspace).

For now all tests to compile the core on rpi5 with "32bit Bookworm" have failed.
Perhaps it's possible to cross-compile it on the rpi5.
I might have a look.

If someone really wants to run the core on an rpi5 with "32bit Bookworm" then you can install it using a rpi4 instead and switch back later to the rpi5 with the same SD.

We are discussing now how to disable the module-script the correct way if no cross-compile solution comes along.
Flags can be set in the module-script to disable it but if we enable it for 64bit only then older 32bit OSes or other rpi's, that were compiling it ok, will also be disabled.

Hope you understand the discussion now.

mth75

@Folly Yes, I do now, thx for the explanation! For my full understanding ... the "Fatal error: required files are missing." is to be expected on the Pi5 for the time being?

ExarKunIv

@mth75 said in RetroPie-Extra Repository - lr-samecdi:

"Fatal error: required files are missing." is to be expected on the Pi5 for the time being?

if you are using the script from my repo, yes. it has not been updated with the new code that folly is messing with.
once he is done with trying the different things, he will update the script and i will incorporate it into my repo

Folly

@mth75 said in RetroPie-Extra Repository - lr-samecdi:

@Folly Yes, I do now, thx for the explanation! For my full understanding ... the "Fatal error: required files are missing." is to be expected on the Pi5 for the time being?

Yes, if you have 32bit OS running then this behavior is expected..

mth75

@Folly said in RetroPie-Extra Repository - lr-samecdi:

this behavior is expe

But I'm running the 64-bits PiOS.

Folly

@mth75

Did you add the swap to your module-script as suggested over here.

Do you have the core installed ?
(check for /opt/retropie/libretrocores/lr-same_cdi/same_cdi_libretro.so)

Can you explain where you got the message from ?
(runcommand.log or a Retropie install log)

Are you having the BIOS file in the correct place ?
(BIOS/same_cdi/bios/cdimono1.zip)

Folly

@ExarKunIv said in RetroPie-Extra Repository - lr-samecdi:

@Folly said in RetroPie-Extra Repository - lr-samecdi:

We could make it 64bit if the platform contains rpi5 agree ?

If your code works. I have no problem going with it that way.

Or have it switch on what it needs to compile depending on what OS type they are using

Maybe something like this
if isPlatform "odroid-n2"; then
	/home/aresuser/ARES-Setup/fixmali.sh
    elif isPlatform "rockpro64"; then
    /usr/lib/arm-linux-gnueabihf/install_mali.sh
	fi
Not sure if that will work for you are trying

I had a look at this code and I think it's not usable for what I want.
I think both platforms run 64bit only so I think there is no need to filter on these platforms.

I tested this platform independent code and it seems to work fine (code can be reduced see Edit):

rp_module_flags="$([[ $(getconf LONG_BIT) == 32 && $(arch) == aarch64 ]] && echo !32bit)"

It means that if a 32 userspace kernel is found that the !32bit flag is enabled.

I think there is no way to use "RetroPie flags" for detecting that a 32 userspace kernel is found.

Edit :

Seems we can reduce the code to (*first example):

rp_module_flags="$([[ $(arch) == aarch64 ]] && echo !32bit)"

Means that the 64bit kernel is detected even if it runs in 32bit userspace.
We know that the compilation fails for 32bit userspace and RetroPie will set the flag on 32bit if 32bit userspace is detected.
Therefor no need for using the getconf LONG_BIT command.
By disabling 32bit when the 64bit kernel is detected we should be good to go.

What do you think of using this ?

The code from above could be changed to :

[[ $(arch) == aarch64 ]] && rp_module_flags="!32bit"

However in the first example* we have to ability to add more flags in the same line if needed.

ExarKunIv

@Folly I'm good with using what works. I'm not picky with how it works, as long as in the end it works.