Cross-compile packages for RPI1

mitu

@Folly said in Cross-compile packages for RPI1:

Doesn't seem to be the issue, it still fails.

What's the error ?

Folly

@mitu

I will check this evening again.
Not at my pi at the moment.

barbudreadmon

@Folly just curious, are there performance issues when running channelf games with other available emulators on pi0 ?

Folly

@barbudreadmon

Don't think so.
I will try them soon and let you know.

Channelf was just a test.
I helped someone who wanted to know if mame would work on a pi0.
He wanted to run a homebrew that only worked on mame.
So that was basically the reason to use mame.
Eventually he got it working on a pi3.

But I was still curious if I could get it working on a pi0.
Now that it works I was curious about if other "low-end" drivers could work.
But compiling on a pi0 takes just too much time.
That is why I opened this topic.

Folly

@mitu

Just to see if the method works correctly I have successfully "cross-compiled" some packages.
For test I did a libretro-core and a standalone emulator :

lr-freechaf
vice

Going back to mame standalone now.
I will take some extra time to figure things out.
First I want to successfully compile mame on a rpi4 (for rpi4) with just one driver without changing too much parameters in the module-script.
Just to see if it compiles correctly.
Choosing just one driver will drastically reduce the time to test things.

If it succeeds I will move forward again other wise I will probably post the error(s).

mitu

@Folly said in Cross-compile packages for RPI1:

First I want to successfully compile mame on a rpi4 (for rpi4) with just one driver without changing too much parameters in the module-script.

You can manually compile MAME based on the scriptmodule, just use the CXXFLAGS/CFLAGS for the RPI0/1 that RetroPie uses ( -mcpu=arm1176jzf-s -mfpu=vfp -O2) when building.

Folly

@mitu

I tried a few things to compile manually, like this :

# on RPI4/8GB for RPI4, tried on both Buster and Bullseye 32 bit
make SUBTARGET=msx SOURCES=msx/msx2.cpp REGENIE=1 -j2

# on RPI4/8GB for RPI0/1, tried on both Buster and Bullseye 32 bit
make CFLAGS='-mcpu=arm1176jzf-s -mfpu=vfp -O2' CXXFLAGS='-mcpu=arm1176jzf-s -mfpu=vfp -O2' SUBTARGET=msx SOURCES=msx/msx2.cpp REGENIE=1 -j2

Somehow both fail.

So I tried your fist advice again and just use :

# on RPI4/8GB for RPI0/1, tried on Bullseye 32 bit
sudo __platform=rpi1 ./retropie_packages.sh mame

Swap in module-script was set to 12288 and !arm6 flag was removed.

This is the log :
https://drive.google.com/drive/folders/1qTrU_eMUxpZPAXL-m9juiaJclVtNARPo

This is a returning error every time :

../../../../../src/emu/validity.cpp: In function ‘void {anonymous}::validate_integer_semantics()’:
../../../../../src/emu/validity.cpp:179:31: error: static assertion failed: PTR64 flag enabled, but was compiled for 32-bit target

  179 |  static_assert(sizeof(void *) == 8, "PTR64 flag enabled, but was compiled for 32-bit target\n");
      |                ~~~~~~~~~~~~~~~^~~~

make[2]: *** [emu.make:1410: obj/Release/src/emu/validity.o] Error 1
make[2]: *** Waiting for unfinished jobs....

mitu

@Folly Is your compiling system a 64bit or 32bit system ? Try adding PTR64=0 to the build options, seems MAME assumes it's building for a 64bit system (which the Pi0/1 is not).

Folly

@mitu

I checked my OS.
It gives aarch64 as architecture but I am sure it's 32 bit.
I tested it also with

pi@raspberrypi:~ $ getconf LONG_BIT
32

uname -a gives :

Linux raspberrypi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

I had that same idea earlier on with PTR64=0 but in other tests it still failed.

I can try again if you like.

mitu

@Folly said in Cross-compile packages for RPI1:

I checked my OS.
It gives aarch64 as architecture but I am sure it's 32 bit.
I tested it also with

The kernel may be 64bit with recent updates - see https://retropie.org.uk/forum/topic/34185. This may confuse MAME's build system thinking it's building for 64bit. You should add arm_64bit=0 to config.txt and reboot, then re-try the build.

Folly

@mitu

Good suggestion.
Will reboot and will check again what the output is of uname -a.
Then try again.
To be sure I will also add PTR64=0 to the options in the module script.

Edit :
Looks promising, uname -a now gives :
Linux raspberrypi 6.1.21-v7l+ #1642 SMP Mon Apr 3 17:22:30 BST 2023 armv7l GNU/Linux

Compiling has started though I checked for PTR64=1 in the make files in many generated makefiles I still see :
DEFINES += -DPTR64=1 -DNDEBUG -DCRLF=2 -DLSB_FIRST -DFLAC__NO_DLL -DPUGIXML_HEADER_ONLY -DLUA_COMPAT_ALL -DLUA_COMPAT_5_1 -DLUA_COMPAT_5_2

I would somehow expect to see :
+= -DPTR64=0

Folly

@mitu

You should add arm_64bit=0 to config.txt and reboot
Try adding PTR64=0 to the build options

That were the solutions.
I expect it will also work without using PTR64=0 now.
Compiling seems to be about 10 hours on a RPI4/8GB which is much better than 1 month on a PI0/1.

So now I have a working binary and channelf is working as expected ;-)
Will try some other systems later.

Thanks !