readelf
So this confirms an armv7 build then ?
osmc@vero3:/opt/retropie/emulators/amiberry$ readelf amiberry-vero4k -A
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv4
Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_rounding: Needed
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_enum_size: int
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6
Tag_MPextension_use: Allowed
Tag_DIV_use: Allowed in v7-A with integer division extension
Tag_Virtualization_use: TrustZone and Virtualization Extensions
Yes.
@hissingshark FYI The June monthly stable update was just released with Vero4k kernel 150 which includes the xpad patch for triggers_to_buttons. (And with working WiFi, hehe)
BTW I’m not sure if you’ve said before but what contoller do you use with retropie ?
I spotted that blog post last night but I’ve not managed to get the update yet. Just tried manually checking again and it’s not picking anything up yet.
Are the updates rolled out in some staggered way to avoid sudden demand at the server end or something? Can I force the issue from the command line? A dist-upgrade maybe? Don’t want to mess anything up. I’m back on a fresh May image now because I hosed my box by running rm -r *<hits return by accident at this point> while I was removing some erroneously placed config files that had landed in /. Very very bad!
I’m particularly keen to try it because I think my Hyperion fixes are in it. I’ll need to merge in my update branch on my installer so folks can have the newer version, but I like to test everything first.
These days I use a Giotech VX-2. Was very plug and play. The triggers are button, not analog. But I also have 2 Xbox360 controllers and a Chinese wireless receiver from my xboxdrv days on the RPi so I’ll be testing this new xpad.
I got Quake III Arena working last year (q3lite) and I’ve been finishing off a Retropie module for that this week. That natively needs keyboard and mouse of course but I tried xboxdrv to give it gamepad support. it worked well but an analog thumb stick has nowhere near the twitch response you need for a game like that. My mouse works well on the couch.
I’ve started going through the Amiberry source to look for some reason why the config loading isn’t working right. Have you had Apidya working by any chance? That was one I really enjoyed as a kid.
Another straw to clutch at:
According to RetroPie-Setup/scriptmodules/emulators/amiberry.sh they are building with SDL1.2 on the RPi. But according to the Amiberry Makefile it should be possible to build with SDL2. So you could try building from source on the RPi, but for SDL2 as used on the Vero4k - see if that reproduces the fault on your RPi.
You’d just need to change line 21:
if ! isPlatform "rpi" || isPlatform "kms" || isPlatform "vero4k"; then
to
if isPlatform "rpi" || isPlatform "kms" || isPlatform "vero4k"; then
And also line 42:
amiberry_bin="$__platform-sdl1"
to
amiberry_bin="$__platform-sdl2"
Thanks, I’ll give that a try. 
SDL handles joystick input among other things ?
Usually yes. So it sounds at least potentially relevant! Not sure how the implementation would differ between loading a config at launch vs menu, but we have to test all variables.
There are also 2 syntaxes for specifying the config file. Run it with --help and you’ll see. I think you used -config=foo style before? Try the other way too? From the source it looks like it works the same, but one to try.
I also noticed a few build flags that they DON’T use on the RPi. Their inclusion on Vero4k and others might be a factor. I’ll bung you another Makefile patch later so you can try those.
Made those changes but this doesn’t look right during build ?
g++ -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -pipe -Ofast -frename-registers -falign-functions=16 -pipe -Wno-shift-overflow -Wno-narrowing -std=gnu++14 -fpermissive -MD -MT src/akiko.o -MF src/akiko.d -DUSE_DISPMANX -I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -DARMV6_ASSEMBLY -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DUSE_ARMNEON -DARM_HAS_DIV -DUSE_SDL1 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include -Isrc/archivers -I/usr/include/libxml2 -DAMIBERRY -c -o src/akiko.o src/akiko.cpp
g++ -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -pipe -Ofast -frename-registers -falign-functions=16 -pipe -Wno-shift-overflow -Wno-narrowing -std=gnu++14 -fpermissive -MD -MT src/ar.o -MF src/ar.d -DUSE_DISPMANX -I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -DARMV6_ASSEMBLY -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DUSE_ARMNEON -DARM_HAS_DIV -DUSE_SDL1 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include -Isrc/archivers -I/usr/include/libxml2 -DAMIBERRY -c -o src/ar.o src/ar.cpp
g++ -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -pipe -Ofast -frename-registers -falign-functions=16 -pipe -Wno-shift-overflow -Wno-narrowing -std=gnu++14 -fpermissive -MD -MT src/aros.rom.o -MF src/aros.rom.d -DUSE_DISPMANX -I/opt/vc/include -I/opt/vc/include/interface/vmcs_host/linux -I/opt/vc/include/interface/vcos/pthreads -DARMV6_ASSEMBLY -D_FILE_OFFSET_BITS=64 -DARMV6T2 -DUSE_ARMNEON -DARM_HAS_DIV -DUSE_SDL1 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -Isrc -Isrc/osdep -Isrc/threaddep -Isrc/include -Isrc/archivers -I/usr/include/libxml2 -DAMIBERRY -c -o src/aros.rom.o src/aros.rom.cpp
Still says -DUSE_SDL1 ? Is the downloaded Amiberry source makefile itself causing this ?
Build also failed, but I think only because the executable name built was not matching what the build script expected ?
g++ -o amiberry-rpi2-sdl1 src/akiko.o src/ar.o src/aros.rom.o src/audio.o src/autoconf.o src/blitfunc.o src/blittable.o src/blitter.o src/blkdev.o src/blkdev_cdimage.o src/bsdsocket.o src/calc.o src/cd32_fmv.o src/cd32_fmv_genlock.o src/cdrom.o src/cfgfile.o src/cia.o src/crc32.o src/custom.o src/def_icons.o src/devices.o src/disk.o src/diskutil.o src/dlopen.o src/drawing.o src/events.o src/expansion.o src/fdi2raw.o src/filesys.o src/flashrom.o src/fpp.o src/fsdb.o src/fsdb_unix.o src/fsusage.o src/gayle.o src/gfxboard.o src/gfxutil.o src/hardfile.o src/hrtmon.rom.o src/ide.o src/inputdevice.o src/keybuf.o src/main.o src/memory.o src/native2amiga.o src/rommgr.o src/rtc.o src/savestate.o src/scsi.o src/statusline.o src/traps.o src/uaelib.o src/uaeresource.o src/zfile.o src/zfile_archive.o src/archivers/7z/7zAlloc.o src/archivers/7z/7zBuf.o src/archivers/7z/7zCrc.o src/archivers/7z/7zCrcOpt.o src/archivers/7z/7zDec.o src/archivers/7z/7zIn.o src/archivers/7z/7zStream.o src/archivers/7z/Bcj2.o src/archivers/7z/Bra.o src/archivers/7z/Bra86.o src/archivers/7z/LzmaDec.o src/archivers/7z/Lzma2Dec.o src/archivers/7z/Xz.o src/archivers/dms/crc_csum.o src/archivers/dms/getbits.o src/archivers/dms/maketbl.o src/archivers/dms/pfile.o src/archivers/dms/tables.o src/archivers/dms/u_deep.o src/archivers/dms/u_heavy.o src/archivers/dms/u_init.o src/archivers/dms/u_medium.o src/archivers/dms/u_quick.o src/archivers/dms/u_rle.o src/archivers/lha/crcio.o src/archivers/lha/dhuf.o src/archivers/lha/header.o src/archivers/lha/huf.o src/archivers/lha/larc.o src/archivers/lha/lhamaketbl.o src/archivers/lha/lharc.o src/archivers/lha/shuf.o src/archivers/lha/slide.o src/archivers/lha/uae_lha.o src/archivers/lha/util.o src/archivers/lzx/unlzx.o src/archivers/mp2/kjmp2.o src/archivers/wrp/warp.o src/archivers/zip/unzip.o src/caps/caps_win32.o src/machdep/support.o src/osdep/bsdsocket_host.o src/osdep/cda_play.o src/osdep/charset.o src/osdep/fsdb_host.o src/osdep/amiberry_hardfile.o src/osdep/keyboard.o src/osdep/mp3decoder.o src/osdep/picasso96.o src/osdep/writelog.o src/osdep/amiberry.o src/osdep/amiberry_filesys.o src/osdep/amiberry_input.o src/osdep/amiberry_gfx.o src/osdep/amiberry_gui.o src/osdep/amiberry_rp9.o src/osdep/amiberry_mem.o src/osdep/amiberry_whdbooter.o src/osdep/sigsegv_handler.o src/sounddep/sound.o src/osdep/gui/UaeRadioButton.o src/osdep/gui/UaeDropDown.o src/osdep/gui/UaeCheckBox.o src/osdep/gui/UaeListBox.o src/osdep/gui/InGameMessage.o src/osdep/gui/SelectorEntry.o src/osdep/gui/ShowHelp.o src/osdep/gui/ShowMessage.o src/osdep/gui/SelectFolder.o src/osdep/gui/SelectFile.o src/osdep/gui/CreateFilesysHardfile.o src/osdep/gui/EditFilesysVirtual.o src/osdep/gui/EditFilesysHardfile.o src/osdep/gui/PanelAbout.o src/osdep/gui/PanelPaths.o src/osdep/gui/PanelQuickstart.o src/osdep/gui/PanelConfig.o src/osdep/gui/PanelCPU.o src/osdep/gui/PanelChipset.o src/osdep/gui/PanelCustom.o src/osdep/gui/PanelROM.o src/osdep/gui/PanelRAM.o src/osdep/gui/PanelFloppy.o src/osdep/gui/PanelHD.o src/osdep/gui/PanelInput.o src/osdep/gui/PanelDisplay.o src/osdep/gui/PanelSound.o src/osdep/gui/PanelMisc.o src/osdep/gui/PanelSavestate.o src/osdep/gui/main_window.o src/osdep/gui/Navigation.o src/osdep/gui/sdltruetypefont.o src/osdep/neon_helper.o src/newcpu.o src/newcpu_common.o src/readcpu.o src/cpudefs.o src/cpustbl.o src/cpuemu_0.o src/cpuemu_4.o src/cpuemu_11.o src/cpuemu_40.o src/cpuemu_44.o src/jit/compemu.o src/jit/compstbl.o src/jit/compemu_fpp.o src/jit/compemu_support.o src/archivers/7z/BraIA64.o src/archivers/7z/Delta.o src/archivers/7z/Sha256.o src/archivers/7z/XzCrc64.o src/archivers/7z/XzDec.o -lbcm_host -lvchiq_arm -L/opt/vc/lib -Wl,-rpath=/opt/vc/lib -L/usr/lib/arm-linux-gnueabihf -lSDL -lSDL_image -lSDL_ttf -lguichan_sdl -lguichan -flto -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -lpthread -lz -lpng -lrt -lxml2 -lFLAC -lmpg123 -ldl -lmpeg2convert -lmpeg2
strip amiberry-rpi2-sdl1
/home/pi/RetroPie-Setup
Could not successfully build amiberry - Amiga emulator with JIT support (forked from uae4arm) (/home/pi/RetroPie-Setup/tmp/build/amiberry/amiberry-rpi2-sdl2 not found).
Log ended at: Mon 24 Jun 10:52:52 UTC 2019
Total running time: 0 hours, 22 mins, 13 secs
Yes you’re right. The file name it looks for when installing isn’t preserved from the build step, so we need to fix that again
Line 64:
amiberry_bin="$__platform-sdl1"
to
amiberry_bin="$__platform-sdl2"
Yep. With rpi2it defaults to sdl1. You can also specify rpi2-sdl2 or rpi2-sdl2-dispmanx. But again it’s fixed from the Retropie end.
Line 43:
amiberry_platform="$__platform"
to
amiberry_platform="$__platform-sdl2"
Sorry, I was too quick to reply this morning.
That fixed the compilation itself but it still failed at the end because it was trying to copy the sdl1 version. I think this needed changing as well ?
function install_amiberry() {
local amiberry_bin="$__platform-sdl2"
if isPlatform "rpi" && ! isPlatform "kms"; then
amiberry_bin="$__platform-sdl1"
elif isPlatform "odroid-xu"; then
amiberry_bin="xu4"
elif isPlatform "tinker"; then
amiberry_bin="tinker"
elif isPlatform "vero4k"; then
amiberry_bin="vero4k"
fi
I’ve now changed
if isPlatform "rpi" && ! isPlatform "kms"; then
amiberry_bin="$__platform-sdl1"
To sdl2. Compiling again.
Defo.
Maybe I should just fork the Amiberry repo, or any other we are working on and have you point your Retropie source to that? Retropie itself for that matter. Would be less messy than this to and fro, patches etc.
Anyway, let me know what happens. Oh yeah, and have you had Apidya working on Amiberry?
You nailed it!! 
Successfully compiled with SDL2 on the Pi 2 and it reproduces the problem exactly - the joystick settings will not load on emulator start (thus no joystick mappings at all) but reloading the profile via the GUI does work.
So it’s a bug in Amiberry built against SDL2. The question is what to do about it. I suppose if it can be reproduced on a Pi just by changing it to build using SDL2 it is much more likely to get fixed than if it can only be tested on an “obscure” piece of hardware…
I’ll add a quick update in my GIT issue on how to reproduce it on a Pi build.
It occurs to me that as a control we would need to know that a binary built from source on the RPi2 for SDL1.2 was working for you. Was your working binary a Retropie pre-built one, or an “update from source” build? If not we should definitely confirm that to rule out some upstream change.
I did wonder about the SDL2 version as well. Maybe I could try building older versions to see if it used to be working correctly and that something has changed there. What version is installed on your RPi?
I’m building Amiberry again on my Vero4k now, so I can try out the configurations you supplied - see if my controllers reproduce the fault also.
Thank you all for the efforts to bring retropie to vero 4K.
So far I have tested the PSX, SNES, and MAME emulators and they all work perfectly.
The only problem I’m having is with ppsspp, my gamepad is a DragonRise Inc. Generic USB Joystick but the emulator doesn’t recognize the shoulder and trigger buttons. These buttons work correctly in the rest of emulators (PSX at least). The mapping is included in the file gamecontrollerdb.txt, this is the line where it appears:
03000000790000000600000010010000,DragonRise Inc. Generic USB Joystick ,platform:Linux,x:b3,a:b2,b:b1,y:b0,back:b8,start:b9,dpleft:h0.8,dpdown:h0.4,dpright:h0.2,dpup:h0.1,leftshoulder:b4,lefttrigger:b6,rightshoulder:b5,righttrigger:b7,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a3,righty:a4,
I have tested the controllermap tool as indicated in this guide and the codes it recognizes are the same as in the file
I’ve also tried another generic PS2 controller, with the same behavior. I can’t get the configuration menu by pressing the ESC key on the keyboard either, as it stops being recognized when the games are launched.
Any idea why these buttons are not being recognized by ppsspp?
Interesting. I used the same guide myself to submit my controller to the official gamecontrollerdb.txt. After that it worked.
Have you tried replacing the line in the database with the output from controllermap? For my controller there was already an entry but there the identifier has a 1 digit difference which I didn’t spot at first. Also the buttons were ordered differently.
03000000f0250000c183000010010000,Goodbetterbest Ltd USB Controller,platform:Linux,x:b0,a:b1,b:b2,y:b3,back:b8,guide:b12,start:b9,dpleft:h0.8,dpdown:h0.0,dpdown:h0.4,dpright:h0.0,dpright:h0.2,dpup:h0.0,dpup:h0.1,leftshoulder:h0.0,leftshoulder:b4,lefttrigger:b6,rightshoulder:b5,righttrigger:b7,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a2,righty:a3,
03000000f0250000c283000010010000,Goodbetterbest Ltd PC USB Controller,platform:Linux,a:b1,b:b2,x:b0,y:b3,back:b8,guide:b12,start:b9,leftstick:b10,rightstick:b11,leftshoulder:b4,rightshoulder:b5,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:b6,righttrigger:b7
Just in case there’s something like that or a subtle syntax issue with what they have on file.
I’ll have a look when I get chance, but this might turn out to be one to report upstream as a PPSSPP github issue.
I tried to change the line of the file/opt/retropie/emulators/ppsspp/assets/gamecontrollerdb.txt , but I see in the runcommand logs that it still recognizes the original mapping.
I have to travel this week and I won’t be able to try anything else for a few days. When I can I’ll post more detailed information about the logs and file contents to see if we can find the solution.
I will also try to get another gamepad to try.
Any movement on this? I wouldn’t mind seeing the output from controllermap so I can compare with the DB.
Are you sure about the log output? It’s frustratingly subtle! Reminds me of a girl a new once…
loading control pad mappings from gamecontrollerdb.txt: SUCCESS!
Control pad device 0 not supported by SDL game controller database, attempting to create default mapping…
Added default mapping ok
found control pad: Goodbetterbest Ltd PC USB Controller, loading mapping: SUCCESS, mapping is:
03000000f0250000c283000010010000,Goodbetterbest Ltd PC USB Controller,x:b3,a:b0,b:b1,y:b2,back:b8,guide:b10,start:b9,dpleft:b15,dpdown:b14,dpright:b16,dpup:b13,leftshoulder:b4,lefttrigger:a2,rightshoulder:b6,rightshoulder:b5,righttrigger:a5,leftstick:b7,leftstick:b11,rightstick:b12,leftx:a0,lefty:a1,rightx:a3,righty:a4
pad 1 has been assigned to control pad: Goodbetterbest Ltd PC USB Controller
If I remove my controller from the DB altogether I get the above output. The line in bold is the only giveaway anything changed, because it still reads like it found it. What actually happens is it reads the name directly from the controller and then the config you see above is a default it creates based on the PS3 Dual Shock.