Are you running the current/stock kernel?
I get the exact same error with that xpad build module, and also when I try to install the headers with vero364-headers-3.14.29-143-osmc
But I’m running a custom *-145-osmc kernel, as I’m doing some tests for Hyperion fixes. So I guess that’s why it doesn’t find 143 on my box, but odd that it wasn’t looking for 145.
Retropie fixes applied upstream to hide the toxic emulators. So we can now do the bulk build “basic install”.
We now build for armv7 by default as these binaries will run fine and avoid many compiler warnings.
I’ve also discovered armv7 circumvents the mysterious Mupen64plus segfaults that appeared last year, so whether they accept my other PR or not we can now build from master again, all cutting-edge like. So no need to apply the sed patch in future.
I’m on 143 and I have the correct vero364-headers-3.14.29-143-osmc package installed. The build symlink in lib/modules/–version–/ is missing which is why dkms can’t find the kernel sources.
You can create the missing symlink that will match up with the osmc directory layout for the vero4k with:
sudo ln -s /usr/src/vero364-headers-$(uname -r) /lib/modules/$(uname -r)/build
After I create this symlink the kernel headers are found and compilation attempted, but it fails with a completely different error. (Sorry don’t have it handy)
I’ve spoken to Sam and he says that there is a long standing bug with the kernel header packages on osmc that is probably causing this so he’ll look into it with a bit of testing from me, however he is on the road at the moment so I’m not sure how soon that will be, could be a few days.
If the Retropie patches applied to xpad solves the issue and doesn’t have any negative consequences I’ve suggested that maybe we should include that patch in the in-tree version of xpad that ships in osmc by default, which would remove that as a necessary step to getting retropie working optimally on osmc and vero4k in particular.
One problem I’ve noticed with the xboxdrv userspace driver aside from the issue with amiberry forgetting the joystick setting all the time, is that the receiver for the controller has to be plugged in at boot time when rc.local executes xboxdrv - if it is plugged in later it doesn’t work, which is a bit annoying on a multi-use device like a Kodi box.
The only way to automate that would probably be to move it out of rc.local and trigger based on udev rules but that may get complicated as you’d have to know what usb device id’s should launch it. If we can get xpad patched and working better then I think that may be the better route than xboxdrv.
Perfect! While not all the emulators are guaranteed to work they’re at least not going to install inappropriate dev libraries on the system and leave apt in a messed up state.
Nice - funnily enough I noticed those arm v8 related errors and knew that the vero4k will run regular armv7 code so attempted to make the same change as you before I even posted in this thread - however not knowing what I was doing I only changed it in a couple of the places necessary so of course it didn’t work.
The change you’ve made is global for all emulators compiled on the vero4k ? Do you think there will be a significant reduction in emulation performance by doing this or should it be minimal ? On the plus side I suppose there might be some emulators aside from mupen64plus that failed to build (or crashed) before that may build and work now ?
I’m very much no expert in this regard. The big deal with armv8 I thought was some improvements by going 64bit, but as we are in 32bit userland that is not a factor. And of course clock speed is the same regardless.
Assembler sections in some emulators I’ve seen are targeting armv7 as well, so you start to wonder what’s the point if you’re running that anyway.
Retropies prebuilt binaries for RPi3 are targeted for armv7 as well:
# note the rpi3 currently uses the rpi2 binaries - for ease of maintenance - rebuilding from source
# could improve performance with the compiler options below but needs further testing
function platform_rpi3() {
__default_cflags="-O2 -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations"
The final push to explore this was when I was testing Hyperion builds and Sam asked if they were targeted for armv7, which I subsequently did. That’s how I stumbled on the Mupen “fix”.
I think we should be fine. Individual emulators can of course override these global settings. If some are specifically seeking armv8 in their Makefiles they may be taking advantage of some instruction-set benefit, but I don’t think I’ve seen it yet. PPSSSPP is building for armv8 for now because that’s in the cmake toolchain file I gave them as part of my original PR to get it supported on the Vero4k.
Should performance be sub-optimal with any emulator we can give it scrutiny and address it either upstream or at the Retropie end.
Thanks for the workaround there.
I was going to do a clean install this week just to get back on the same playing field now I’m done with my kernel tests. I was trying earlier to help with the xpad build debug, so I’ll follow this method in the meantime.
I’ll give you system.unit a go tonight. Looks very clean.
Nice. Not come across this before so had a quick Google. I can think of a few places I’d have used that previously!
Aarch64 builds will probably break support for some emulators, so I would recommend avoiding this for now.
You could increase the Mali’s clock frequency via sysfs which should give some modest improvements.
I’ve updated the XPad driver in the kernel and map buttons to triggers by default. See
It will build in a few hours when Jenkins has some capacity.
Sam
__ __ _ _ _ __ _
\ \ / /___ _ __ ___ | || | | |/ / __ _ __| | ___
\ \ / // _ \| '__|/ _ \ | || |_ | ' / / _` | / _` | / _ \
\ V /| __/| | | (_) ||__ _|| . \| (_| || (_| || __/
\_/ \___||_| \___/ |_| |_|\_\\__,_| \__,_| \___|
Kernel vero364-image-3.14.29-148-osmc is now in staging and should fix xpad for emulation. It includes a version of the Retropie patch that enables LED support and triggers_to_buttons to work on all controllers not just unknown, and has triggers_to_buttons=1 set by default. (It can be overridden to the old behaviour of 0 with modprobe options however)
This works for me on both my 360 wireless controller with usb receiver and my xbox one s controller with a USB cable. For some reason I can’t get OSMC bluetooth to pair with the xbox one s controller to try it wirelessly however that’s a problem for another time…
Initially we tried the latest version of xpad however it doesn’t seem to work properly on the 3.14 kernel as it presents only buttons and no axes! (as reported by jstest) which is very weird. (And emulationstation would not detect any gamepad at all) So we ended up patching the existing version of xpad, at least for now. (It might be possible to backport the newer xpad driver later, which would gain support for additional 3rd party/clone xbox controllers)
Enabling or disabling triggers_to_buttons causes the buttons to be completely renumbered, rendering any previous emulation station input mapping invalid, so you should expect to have to reconfigure emulation stations input settings when changing.
The same applies for joystick support in Kodi - it will have to be remapped in settings to match the new button numbering.
BTW @hissingshark - while this fixed xpad driver seems to work perfectly in emulation station and all other emulators I’ve tried, (as well as Kodi after remapping the buttons in Kodi settings) it doesn’t help with the issue of amiberry forgetting its joystick configuration on launch. 
This is perhaps not surprising because I see the same problem with xboxdrv on vero4k, so I think that rules out the joystick driver as being the cause.
The problem is even weirder because I’ve discovered that if I load amiberry with a config profile applied (either using emulation station or just from the command line) it reads all the configuration except the joystick, however if I then through the GUI in amiberry choose to re-load the exact same profile the joystick and custom button configuration does load and work perfectly! 
I tried my xbox one s controller via USB (which also works nicely with the patched xpad) and it behaves the same.
I think all this points squarely towards a bug in amiberry that is somehow triggered on the vero4k so after not finding any existing issues that seemed similar I’ve opened up a new git issue:
I’ve ruled out most of the possible differences between the platforms but after thinking about the mupen64plus issue where armv8 code introduced a crashing bug I wonder whether different compile options for amiberry on the vero4k could be exposing a source or compiler bug in a similar way to mupen64plus ?
I was under the impression that your patch would change all emulators to armv7 code on vero4k (due to the change in system.sh) but that doesn’t actually seem to be the case ? I’ve verified that I’ve updated my RetroPie build scripts to the latest and mupen64plus compiles and works without a patch now, however when I rebuild amiberry from source the gcc lines that scroll by still talk about armv8 code and show armv8 related warnings…
Can you confirm whether you intended amiberry and other emulators to compile as armv7 code not just mupen64plus and if so can you do test compile of amiberry and see which code it is using for you ?
If it’s not compiling as armv7 now would you be able to throw together a quick Retropie build script patch and post it in this thread so I could try recompiling as armv7 code (with as similar compile options to Pi 2 as possible) to see if it has any bearing on this bizarre joystick profile loading issue…(even if it doesn’t help it’s one more difference ruled out!)
Thanks! 
It’s certainly worth a look. Stranger things have happened as you say!
The change is indeed global for safety, but as I mentioned previously just like compiler optimisation settings and library locations the individual emulators can of course override these global settings if there is a benefit.
You are quite right about Amiberry. That is one I originally patched upstream to get the Vero4k building. That is an example of the CFLAGS being overridden and as you can see that would be armv8.
So I could make up a git diff patch that will apply to the Makefile at once the source has been downloaded at build time, and patch the scriptmodule to do that.
What’s the best way of sharing these? I don’t want to choke up the thread really. OSMC pastebin or such?
p.s: don’t forget your retropie/mame4all issue is still open.
Ahh I see, so the amiberry source is intentionally overriding it. Makes sense. I agree it’s probably safer to have the global default be armv7 code unless the specific emulator’s build script or source overrides it.
You could use http://paste.osmc.tv/ - you can either just paste into the website in a browser, or on an osmc device you can use the paste-log command - it will accept either a filename or piped input and will happily accept other text based files like source code.
Keep in mind paste.osmc.tv files are deleted about every 30 days though, but that’s fine for a quick test.
Don’t worry about trying to do it cleanly - just the quickest hack you can come up with that changes the compile options to armv7 with as similar compiler build options as the Pi 2 as possible. If it doesn’t help then we rule that possibility out and don’t need to worry about a clean way to do it.
I really have no idea what the cause of the issue is, it’s very very strange…hence why I’m clutching at straws now… 
I had forgotten. Do you want me to just close it ?
Hey, clutching at straws got us to the moon. Probably.
I’ve just pulled the Amiberry source and I’ll do the patch in a bit. The temporary paste should be fine for this. It’s a bit long winded but Retropie doesn’t hold onto the downloaded sources so they need to be patched on the fly, or we have our own fork and point it at that. It’ll be fine.
Might as well close the issue as there nothing really to be fixed and the referenced commit means it wont happen to anyone again.
Done.
By the way on the existing amiberry build script I see a lot of this:
warning: switch -mcpu=cortex-a7 conflicts with -march=armv8-a switch
Is this something to worry about or harmless ? Also
IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8
The first is a new one on me. That’ll be because Amiberry is automatically building for armv8 due to it’s Makefile detecting the Vero4k, but since my PR the other day Retropie has said to do armv7. So this is the compiler pointing out it’s been asked to do 2 different things. From what you said earlier I’m assuming the Makefile wins and we are doing armv8. It doesn’t matter because we are fixing that anyway.
The current builds are patched by Retropie to remove that very behaviour on RPi, so that Retropie has control over the options. Just like the patch I’m doing for you now.
The second one we see all over that place, I think because we are building 32bit software on what we have told compilers is our armv8/64bit hardware. If we build for armv7 that goes away. I take that as another sign that building for armv8 is pointless for us! Hence I’ve been happy to go for armv7 globally for now. We can take care of edge cases later.
You should build for armv7 for now. You won’t see any benefit unless you use the aarch64 toolchain
Sam
Just overwrite ~/RetroPie-Setup/scriptmodules/emulators/amiberry/01_remove_cflags.diff with this.
From then on it will use whatever options were specified by Retropie in ~/RetroPie-Setup/scriptmodules/system.sh here:
function platform_vero4k() {
__default_cflags="-I/opt/vero3/include -L/opt/vero3/lib -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations"
__default_asflags=""
__default_makeflags="-j4"
__platform_flags="arm armv7 neon vero4k gles"
}
You can play with those as you see fit to debug.
It builds OK but I’m at work so I can’t test the final product.
Thanks, I’ll give it a try. 
Just a quick warning to anyone following this thread - the 148 kernel with xpad improvements has (due to unrelated experimental patch testing) broken WiFi - so don’t install it if you use WiFi. We should have a kernel with the improved xpad support and WiFi working again soon. As I use Ethernet on that box I didn’t notice WiFi was broken.
And don’t use the 149 kernel as it has a broken xpad driver in it…
Good news and bad news.
The good news is that the patch works and from what I can see watching the build it is now using armv7 instructions, (although is there an easy way for me to check the binary to see what instructions it was built with ?) and all the warnings seem to be gone.
Also emulation speed seems to be the same - I tried a few demos that push right to the edge of even the vero4k’s performance (mainly copper effects) and they didn’t seem any worse than before - so I think Sam’s right that dropping to armv7 won’t have any impact on performance with 32 bit code.
The bad news is that it didn’t help with the joystick settings not loading from config profiles during load - it was always a long shot though!
So I’m officially completely stumped on the joystick issue - it’s now in the lap of the amiberry devs to see if they have any suggestions on the git issue I posted.