Cross-compile packages for RPI1
-
Recently I wanted to experimented with running mame standalone on an RPI zero W.
Just to see if low-end drivers would run with enough speed on a zero.
I decided to alter the mame.sh module-script so it would only compilechannelf
on a zero.
It took about 60 hours to complete but it worked quite good when enabling "-frameskip 10" in the mame command.
Now I want to test some more drivers but building mame totally would take more than a month i read in this topic :
https://retropie.org.uk/forum/topic/19303/installation-of-mamedev-mameI that topic cross-compiling is also described as a solution.
Just to speed up the proces of making a binary for the zero quicker.So I tried these steps (https://retropie.org.uk/forum/topic/19303/installation-of-mamedev-mame/55) :
# install dependancies for the cross-compiler environment sudo ./retropie_packages.sh crosscomp depends # build the cross-compiler sudo ./retropie_packages.sh crosscomp setup bullseye
Also tried
buster
in above line.
I tried on many OSes (Ununtu 18.04 / Debian buster / Debian bullseye )
However the setup will not compete.Any Idea if this approach still works or what I am missing here ?
binary for my RPI zero / zero W.
-
It should be possible, but it's a bit more complicated. Haven't used it in a long time, so I forgot how to use the
builder
to build packages.
If you have a Pi4, you can compile a Pi0/1 binary by using the__platform=rpi1
option when building:sudo ./retropie_packages __platform=rpi1 mame
and it will create a Pi1/0 compatible package under
/opt/retropie/emulators/mame
. -
@mitu said in Cross-compile packages for RPI1:
sudo ./retropie_packages __platform=rpi1 mame
That's even simpler ;-)
I will try that first.I tried this but it fails :
sudo ./retropie_packages.sh __platform=rpi1 mame No module '__platform=rpi1' found.
Is the command correct ?
Of-course I removed the the
!arm6
flag from themame.sh
module script. -
@Folly Hm, I think I switched the order of the arguments:
sudo __platform=rpi1 ./retropie_packages.sh mame
-
I was thinking somewhat the same.
I will try.Edit :
Command seems to be correct now.
When the flag!arm6
is on it will complain so that is a conformation that the __platform string is read correctly.Had to change the module-scrip as it produces an error :
GCC 10.2.1 detected makefile:1054: *** Python is not available in path. Stop. strip: 'mame': No such file Removing additional swap Could not successfully build mame - MAME emulator (/home/pi/RetroPie-Setup/tmp/build/mame/mame not found). /home/pi/RetroPie-Setup Errors: Could not successfully build mame - MAME emulator (/home/pi/RetroPie-Setup/tmp/build/mame/mame not found).
I changed it into this, so it will not produce the python error and it will only compile for channelf hopefully ( it already runs now ;-) ) :
function build_mame() { # More memory is required for 64bit platforms if isPlatform "64bit"; then rpSwap on 8192 else rpSwap on 4096 fi # Compile MAME #local params=(NOWERROR=1 ARCHOPTS=-U_FORTIFY_SOURCE PYTHON_EXECUTABLE=python3) #QT_SELECT=5 make "${params[@]} SUBTARGET=mame SOURCES=fairchild/channelf.cpp" #strip mame make SUBTARGET=mame SOURCES=fairchild/channelf.cpp rpSwap off md_ret_require="$md_build/mame" }
Edit :
First try failed, probably need to increase the swap space (running on Raspi OS Debian 11 32 bit OS on RPI4/8GB) -
Add manually more swap (8/12Gb ?) before compiling, the memory requirements for compilation fluctuate from release to release with MAME.
-
Indeed I will try that later.
Looks promising though. -
@mitu said in Cross-compile packages for RPI1:
Add manually more swap (8/12Gb ?) before compiling, the memory requirements for compilation fluctuate from release to release with MAME.
Doesn't seem to be the issue, it still fails.
Although, I will indeed add more with future tests to prevent this issue.I see something like this in the "log" :
PTR64 is on but compiled for 32 bits
Not sure if it is related but it could be
I will try some simpler packages first to see if that will work.
Could also be that it doesn't work correctly on Bullseye 32 bits.
Will have a look at what Buster 32 bits does. -
@Folly said in Cross-compile packages for RPI1:
Doesn't seem to be the issue, it still fails.
What's the error ?
-
I will check this evening again.
Not at my pi at the moment. -
@Folly just curious, are there performance issues when running channelf games with other available emulators on pi0 ?
-
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. -
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).
-
@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. -
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-m9juiaJclVtNARPoThis 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....
-
@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). -
I checked my OS.
It gives aarch64 as architecture but I am sure it's 32 bit.
I tested it also withpi@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.
-
@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 withThe 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
toconfig.txt
and reboot, then re-try the build. -
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/LinuxCompiling 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_2I would somehow expect to see :
+= -DPTR64=0 -
You should add arm_64bit=0 to config.txt and reboot
Try adding PTR64=0 to the build optionsThat 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 !
-
-
-
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.