Menu
What's new
By:
Filters

Porting Mupen64Plus to Android

OP
paulscode

paulscode

New member
Hmm.. Still getting the same error. I've also changed the APP_PLATFORM setting to android-8 (since I don't have a 2.3 device to test this on), and I've tried running "android update project -p ." and "ndk-build clean" commands, but nothing seems to help. I'm sure it is a simple setting I'm missing, but I can't seem to spot it. I'd like to get it running in its current form so I can use it as a baseline project to build off of, but I may just have to try and port it to a JNI project first, and hope whatever setting is causing the problem won't migrate along with it.
 
C

Cpasjuste

New member
It's strange, i did clone my droid64 repo, edited the "Application.mk" file to point to the newly cloned repo ( "NDK_MODULE_PATH := /home/cpasjuste/dev/android/droid64-test/droid64/jni/" ) and it was built without any problem. Else, you should be able to run the binary even if your on a 2.2 device since we are not using any jni for now, just the 2.3 toolchain.
 
J

jkimber

Kim
Cpasjuste, I clone your project and build ok, but when I run it, I met the similar crash issue you met before.
>>>
I'm also playing with the sources. First thing to say, i'm on a Samsung Galaxy S (i9000). But i'm not working exactly like you, i decided to first have it running without the jni wrapper, i mean i'm building the "mupen core" as an executable (using dummy plugins of course) so if i understand correctly i should not have to play with memory management but just use the "Xlinker" ld flag ?.

Well, for me it segfault on the "new_dyna_start()" function which is the starting point of the asm code it seems. Here is informations, any hint would be appreciated


- mupen64plus memory maps before the gdb "continue" function : http://pastebin.com/P2wtSE1a
- mupen64plus memory maps at the segfault (new_dyna_start()) : http://pastebin.com/xu6C9EVM ( the "80000000-80800000" region is the rdram memory map ? )
- mupen64plus objdump : http://pastebin.com/mJWhP6Vv

Of course, i'm building it in arm mode, for armv7-a architecture. Finding the problem here is probably a little beyond my knowledge, but maybe ari64 or paulscode will have some hint


Is it fixed now? How to fix that? thanks
>>>> my console crash logs


(I added some print in the source file so you see my print logs)
Compression: Uncompressed
Imagetype: .v64 (byteswapped)
Rom size: 8388608 bytes (or 8 Mb or 64 Megabits)
MD5: 20B854B239203BAF6C961B850A4A51A2
80 37 12 40
ClockRate = f
Version: 1444
CRC: 635a2bff 8b022326
Name: SUPER MARIO 64
Manufacturer: Nintendo
Cartridge_ID: 4d53
Country: USA
PC = 80246000
EEPROM type: 0
ENTER startEmulation
init timer!
ENTER plugin_load_plugins
Load1 (null),(null),(null),(null)
LEAVE plugin_load_plugins
memory initialized
GFX: RomOpen()
Starting r4300 emulator
R4300 Core mode: Dynamic Recompiler
new_dynarec_init()
Init new dynarec
new_dyna_start()
[1] + Stopped (signal) ./n
#

[1] Segmentation fault (core dumped) ./n



Thanks
--Kimb
 
Last edited:
OP
paulscode

paulscode

New member
Sorry, I am not much help on this one. The only potential problem that I can see (unrelated to your segfault) is the directory structure. In your case, the plug-ins are in "/data/misc/droid64/plugins/", but if you look at Cpasjuste's hack in main.c, they are expected to be in "/data/droid63/plugins/". Come to think of it, you probably already corrected the paths in main.c, since you mentioned information that was read from the rom file in "/data/misc/droid64/roms/".

jkimber said:
if i understand correctly i should not have to play with memory management but just use the "Xlinker" ld flag
Click to expand...
Actually, the Xlinker flag seems to be ignored. You shouldn't need it, because the problem was solved by Ari64 adding the >32MB trampolines. Leaving the flag in there shouldn't cause any problems, though.

Perhaps enabling the debug messages might be useful (for someone other than me)?
 
A

Ari64

New member
jkimber said:
Well, for me it segfault on the "new_dyna_start()" function which is the starting point of the asm code it seems. Here is informations, any hint would be appreciated
Click to expand...

Get a register dump and dissassembly of the code around the point where it crashed.
 
J

jkimber

Kim
Logs show it crash at PC 7e34124 which shall be dynarec codes I think
>>>> The full crash logs including register dumping

01-27 14:00:18.323 I/DEBUG ( 1072): signal 4 (SIGILL), fault addr 07e34124
01-27 14:00:18.323 I/DEBUG ( 1072): r0 00000000 r1 06800000 r2 11c1844f r3 11c1844f
01-27 14:00:18.323 I/DEBUG ( 1072): r4 0011f448 r5 00000000 r6 00000000 r7 00000000
01-27 14:00:18.323 I/DEBUG ( 1072): r8 00000000 r9 00000000 10 00003c78 fp 00434820
01-27 14:00:18.323 I/DEBUG ( 1072): ip 00000000 sp beeefbd8 lr 000e3774 pc 07e34124 cpsr 60000010
01-27 14:00:18.331 I/DEBUG ( 1072): #00 pc 07e34124
01-27 14:00:18.338 I/DEBUG ( 1072): #01 pc 000e3770 /data/droid64/mupen64plus
01-27 14:00:18.338 I/DEBUG ( 1072):
01-27 14:00:18.338 I/DEBUG ( 1072): code around lr:
01-27 14:00:18.338 I/DEBUG ( 1072): 000e3764 e1a00003 e59d170c e59d2710 ebfed82c
01-27 14:00:18.338 I/DEBUG ( 1072): 000e3774 ea0000ae e51f385c e79b3003 e5933000
01-27 14:00:18.338 I/DEBUG ( 1072): 000e3784 e1a03a83 e1a03aa3 e51f2874 e79b2002
01-27 14:00:18.338 I/DEBUG ( 1072):
01-27 14:00:18.338 I/DEBUG ( 1072): stack:
01-27 14:00:18.338 I/DEBUG ( 1072): beeefb98 00115de8 /data/droid64/mupen64plus
01-27 14:00:18.346 I/DEBUG ( 1072): beeefb9c 0b021425
01-27 14:00:18.346 I/DEBUG ( 1072): beeefba0 0f1a1d0c
01-27 14:00:18.346 I/DEBUG ( 1072): beeefba4 ff24091b
01-27 14:00:18.346 I/DEBUG ( 1072): beeefba8 00434c08
01-27 14:00:18.346 I/DEBUG ( 1072): beeefbac 11c1844f
01-27 14:00:18.346 I/DEBUG ( 1072): beeefbb0 00000010
01-27 14:00:18.354 I/DEBUG ( 1072): beeefbb4 0011f448
01-27 14:00:18.354 I/DEBUG ( 1072): beeefbb8 00000000
01-27 14:00:18.354 I/DEBUG ( 1072): beeefbbc 00000000
01-27 14:00:18.354 I/DEBUG ( 1072): beeefbc0 00000000
01-27 14:00:18.354 I/DEBUG ( 1072): beeefbc4 00000000
01-27 14:00:18.362 I/DEBUG ( 1072): beeefbc8 00000000
01-27 14:00:18.362 I/DEBUG ( 1072): beeefbcc 00000000
01-27 14:00:18.362 I/DEBUG ( 1072): beeefbd0 df002777
01-27 14:00:18.362 I/DEBUG ( 1072): beeefbd4 e3a070ad
01-27 14:00:18.362 I/DEBUG ( 1072): #01 beeefbd8 635a2bff
01-27 14:00:18.362 I/DEBUG ( 1072): beeefbdc 00000400
01-27 14:00:18.362 I/DEBUG ( 1072): beeefbe0 0011f448
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbe4 00000000
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbe8 00000000
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbec 000138b0 /data/droid64/mupen64plus
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbf0 000fb8a4 /data/droid64/mupen64plus
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbf4 00000000
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbf8 00000000
01-27 14:00:18.370 I/DEBUG ( 1072): beeefbfc afe14db9 /system/lib/libc.so
01-27 14:00:18.370 I/DEBUG ( 1072): beeefc00 00000000
01-27 14:00:18.370 I/DEBUG ( 1072): beeefc04 00000000
01-27 14:00:18.377 I/DEBUG ( 1072): beeefc08 0000000b
01-27 14:00:18.377 I/DEBUG ( 1072): beeefc0c 000001e0
01-27 14:00:18.377 I/DEBUG ( 1072): beeefc10 00000280
01-27 14:00:18.377 I/DEBUG ( 1072): beeefc14 00000000
01-27 14:00:18.377 I/DEBUG ( 1072): beeefc18 00000000
01-27 14:00:18.377 I/DEBUG ( 1072): beeefc1c 00000000


>>>>>>
e3734: e59d2710 ldr r2, [sp, #1808]
e3738: ebfed83a bl 99828 <ll_remove_matching_addrs>
e373c: e51f3820 ldr r3, [pc, #-2080] ; e2f24 <new_recompile_block+0x1f904>
e3740: e79b3003 ldr r3, [fp, r3]
e3744: e5933000 ldr r3, [r3]
e3748: e1a03a83 lsl r3, r3, #21
e374c: e1a03aa3 lsr r3, r3, #21
e3750: e2833b02 add r3, r3, #2048 ; 0x800
e3754: e1a02103 lsl r2, r3, #2
e3758: e51f3850 ldr r3, [pc, #-2128] ; e2f10 <new_recompile_block+0x1f8f0>
e375c: e79b3003 ldr r3, [fp, r3]
e3760: e0823003 add r3, r2, r3
e3764: e1a00003 mov r0, r3
e3768: e59d170c ldr r1, [sp, #1804]
e376c: e59d2710 ldr r2, [sp, #1808]
e3770: ebfed82c bl 99828 <ll_remove_matching_addrs>
e3774: ea0000ae b e3a34 <new_recompile_block+0x20414>
e3778: e51f385c ldr r3, [pc, #-2140] ; e2f24 <new_recompile_block+0x1f904>
e377c: e79b3003 ldr r3, [fp, r3]
e3780: e5933000 ldr r3, [r3]
e3784: e1a03a83 lsl r3, r3, #21
e3788: e1a03aa3 lsr r3, r3, #21
e378c: e51f2874 ldr r2, [pc, #-2164] ; e2f20 <new_recompile_block+0x1f900>
e3790: e79b2002 ldr r2, [fp, r2]
e3794: e7923103 ldr r3, [r2, r3, lsl #2]
 
A

Ari64

New member
Well, that is odd. 0x07e34124 is about 14MB into the dynarec cache. If it compiled 14MB of code, the emulator must have been running for a long time. How long was it running, and what instruction is at 0x07e34124?
 
J

jkimber

Kim
1. App crash very quickly (1~2 seconds after launch)


2. I added code to dump the crash content. This is the new crash. Asm show it is illegal access addr [R3=$ffffffff]
>>>
e39c4: e59d3710 ldr r3, [sp, #1808]
e39c8: e1a02352 asr r2, r2, r3
e39cc: e59d170c ldr r1, [sp, #1804]
e39d0: e59d3710 ldr r3, [sp, #1808]
e39d4: e1a03351 asr r3, r1, r3
e39d8: e1520003 cmp r2, r3
e39dc: 0a00000a beq e3a0c <new_recompile_block+0x202f4>
e39e0: e59d3708 ldr r3, [sp, #1800]
e39e4: e2833004 add r3, r3, #4 ; 0x4
e39e8: e5933000 ldr r3, [r3]
e39ec: e2432701 sub r2, r3, #262144 ; 0x40000
e39f0: e59d3710 ldr r3, [sp, #1808]
e39f4: e1a02352 asr r2, r2, r3
e39f8: e59d170c ldr r1, [sp, #1804]
e39fc: e59d3710 ldr r3, [sp, #1808]
e3a00: e1a03351 asr r3, r1, r3
e3a04: e1520003 cmp r2, r3
e3a08: 1a00001b bne e3a7c <new_recompile_block+0x20364>
e3a0c: e59d3708 ldr r3, [sp, #1800]
e3a10: e5931000 ldr r1, [r3]
e3a14: e59d3708 ldr r3, [sp, #1800]
e3a18: e2833004 add r3, r3, #4 ; 0x4
e3a1c: e5932000 ldr r2, [r3]
e3a20: e51f3a14 ldr r3, [pc, #-2580] ; e3014 <new_recompile_block+0x1f8fc>
e3a24: e08f3003 add r3, pc, r3
e3a28: e1a00003 mov r0, r3
e3a2c: ebfe64bf bl 7cd30 <nullf>
e3a30: e59d3708 ldr r3, [sp, #1800]
e3a34: e2833008 add r3, r3, #8 ; 0x8
e3a38: e5932000 ldr r2, [r3]
e3a3c: e59d3708 ldr r3, [sp, #1800]
e3a40: e5832000 str r2, [r3]
e3a44: e59d3708 ldr r3, [sp, #1800]
e3a48: e2833004 add r3, r3, #4 ; 0x4
e3a4c: e59d2708 ldr r2, [sp, #1800]
e3a50: e282200c add r2, r2, #12 ; 0xc
e3a54: e5922000 ldr r2, [r2]
e3a58: e5832000 str r2, [r3]
e3a5c: e59d3708 ldr r3, [sp, #1800]
e3a60: e2832008 add r2, r3, #8 ; 0x8
e3a64: e59d3708 ldr r3, [sp, #1800]
e3a68: e283300c add r3, r3, #12 ; 0xc
e3a6c: e3e01000 mvn r1, #0 ; 0x0
e3a70: e5831000 str r1, [r3]
e3a74: e5933000 ldr r3, [r3]
e3a78: e5823000 str r3, [r2]
e3a7c: e59d37e4 ldr r3, [sp, #2020]
e3a80: e2833001 add r3, r3, #1 ; 0x1
e3a84: e58d37e4 str r3, [sp, #2020]
e3a88: e59d37e4 ldr r3, [sp, #2020]
e3a8c: e353001f cmp r3, #31 ; 0x1f
e3a90: daffff93 ble e38e4 <new_recompile_block+0x201cc>
e3a94: ea000024 b e3b2c <new_recompile_block+0x20414>
e3a98: e51f3a84 ldr r3, [pc, #-2692] ; e301c <new_recompile_block+0x1f904>
e3a9c: e79b3003 ldr r3, [fp, r3]
e3aa0: e5933000 ldr r3, [r3]
e3aa4: e1a03a83 lsl r3, r3, #21
e3aa8: e1a03aa3 lsr r3, r3, #21
e3aac: e3530000 cmp r3, #0 ; 0x0
e3ab0: 1a000002 bne e3ac0 <new_recompile_block+0x203a8>
e3ab4: e3a00406 mov r0, #100663296 ; 0x6000000
e3ab8: e3a01302 mov r1, #134217728 ; 0x8000000
e3abc: eb00bfe6 bl 113a5c <__clear_cache>
e3ac0: e51f3aac ldr r3, [pc, #-2732] ; e301c <new_recompile_block+0x1f904>
e3ac4: e79b3003 ldr r3, [fp, r3]
e3ac8: e5933000 ldr r3, [r3]
e3acc: e1a03a83 lsl r3, r3, #21
e3ad0: e1a03aa3 lsr r3, r3, #21
e3ad4: e1a02103 lsl r2, r3, #2
e3ad8: e51f3ac8 ldr r3, [pc, #-2760] ; e3018 <new_recompile_block+0x1f900>
e3adc: e79b3003 ldr r3, [fp, r3]
e3ae0: e0823003 add r3, r2, r3
e3ae4: e1a00003 mov r0, r3
e3ae8: e59d170c ldr r1, [sp, #1804]
e3aec: e59d2710 ldr r2, [sp, #1808]
e3af0: ebfed78a bl 99920 <ll_remove_matching_addrs>
e3af4: e51f3ae0 ldr r3, [pc, #-2784] ; e301c <new_recompile_block+0x1f904>
e3af8: e79b3003 ldr r3, [fp, r3]
e3afc: e5933000 ldr r3, [r3]
e3b00: e1a03a83 lsl r3, r3, #21
e3b04: e1a03aa3 lsr r3, r3, #21
e3b08: e2833b02 add r3, r3, #2048 ; 0x800
e3b0c: e1a02103 lsl r2, r3, #2
e3b10: e51f3b00 ldr r3, [pc, #-2816] ; e3018 <new_recompile_block+0x1f900>
e3b14: e79b3003 ldr r3, [fp, r3]
e3b18: e0823003 add r3, r2, r3
e3b1c: e1a00003 mov r0, r3
e3b20: e59d170c ldr r1, [sp, #1804]
e3b24: e59d2710 ldr r2, [sp, #1808]
e3b28: ebfed77c bl 99920 <ll_remove_matching_addrs>
e3b2c: e51f3b18 ldr r3, [pc, #-2840] ; e301c <new_recompile_block+0x1f904>
e3b30: e79b3003 ldr r3, [fp, r3]
e3b34: e5933000 ldr r3, [r3]

>>Got signal: 11 si_code=1 si_addr=0xffffffff at 0xe3b34
CPU regs(R0-R15)
00435bf0 ffffffff 00000000 ffffffff 00120448 00000000 00000000 00000000
00000000 00000000 00003c78 00435840 ffffffff bee1bbd8 0009a344 000e3b34
40000010 ffffffff

Dump PC
e5933000 e2833001 e1a03803 e1a03823 e51f2b30 e79b2002 e5823000 e51f3b3c
e79b3003 e5932000 e59d3714 e1520003 1afffeec e3a03000 e1a00003 e51f3b58
e79b3003 e59d2984 e5933000 e1520003 0a000000 ebfcb74c e28ddf63 e28ddb02
e8bd8ff0 e24dd008 e58d0004 e58d1000 e59d3004 edd37a00 eef87ae7 e59d3000

e3b38: e2833001 add r3, r3, #1 ; 0x1
e3b3c: e1a03803 lsl r3, r3, #16
e3b40: e1a03823 lsr r3, r3, #16
e3b44: e51f2b30 ldr r2, [pc, #-2864] ; e301c <new_recompile_block+0x1f904>

NEXT, I will dig into new_recompile_block() to see what happens .
 
Last edited:
A

Ari64

New member
This code (the calls to ll_remove_matching_addr) is at the very end of new_recompile_block(). It deallocates memory, so it seems a likely place to crash if you've got memory corruption or bad pointers. I don't think there is anything wrong with that code per se, rather you need to figure out which pointers got corrupted, and where that happened.

Paul's crash reports showed memory corruption too, just in a different place. Something about Android's memory layout perhaps?
 
OP
paulscode

paulscode

New member
I fixed my problem by doing a complete uninstall and reinstall of the NDK. Next step will be to plug in my version of Ari64's dynarec, since I can't use rdram at 0x80000000 on my phone.
 
OP
paulscode

paulscode

New member
Ok, another Android newbie question. I can't push it to /data/droid64, because I get "permission denied". I can, however, push it to /sdcard/data/droid64. But then when I try to run it from the "terminal emulator", I get another "permission denied". Anyone know if there is a way to do this without having to root my phone? I'll ask on various Android forums if no one here happens to know. I will root my phone as a last resort, but I would prefer not to because doing so voids the warranty.
 
F

Forlan

New member
paulscode said:
Ok, another Android newbie question. I can't push it to /data/droid64, because I get "permission denied". I can, however, push it to /sdcard/data/droid64. But then when I try to run it from the "terminal emulator", I get another "permission denied". Anyone know if there is a way to do this without having to root my phone? I'll ask on various Android forums if no one here happens to know. I will root my phone as a last resort, but I would prefer not to because doing so voids the warranty.
Click to expand...

Yes you must root to be able to access /data folder.

And rooting doesn't always void the warranty unless you unlock the bootloader.
Which phone are you using?

I'm happy to help with this project in terms of testing/android help but sadly I can't develop.
Perhaps you could get me to test whatever you're doing as my N1 is rooted.
 
A

Ari64

New member
I posted updated source code here.

This has the option to relocate the ram to a location other than 0x80000000. Define RAM_OFFSET if you need to use this. It benchmarks about 2.5% slower with this option enabled.
 
OP
paulscode

paulscode

New member
Cpasjuste said:
paulscode i think you could maybe write to /data/misc without root acces ? (not sure about that)
Click to expand...
Unfortunately not (at least for my phone).

I'll try temporarily rooting my phone. I suppose I could always flash my phone back to factory settings if it breaks and I need to utilize the warranty.
 
OP
paulscode

paulscode

New member
Actually, I think I'll try porting it to JNI first without changing too much, and hope that it works right away (however unlikely). If not, then I'll root the phone and try getting it to work as a standalone executable first so I'm not debugging multiple things at the same time again.
 
You must log in or register to reply here.

Top