Building Kernel Modules for AllWinner A10 Android Devices (e.g. Joystick Support)

Reader JP has enabled Joystick support in Android 4.0.4 on its Mele A1000, this now works with a Playstation2 joystick via USB adapter, a Huskee PC joystick, and 2 other unbranded joysticks. In order to enable Joystick support he had to build a kernel module, and encountered a few issues, so he wrote an how-to which shows what challenges he went through and what solutions he found to those issues.I’m sharing today a slightly edited version of this how-to.

This How-to assumes that you have a valid Linux environment where you can build allwinner A10 kernel. The toolchain used was “Sourcery CodeBench for ARM GNU/Linux Lite“ which can be downloaded here: http://www.codesourcery.com/sgpp/lite/arm/portal/package7853/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi.bin

To install it, simply run:


You’ll also need the latest Allwinner A10 kernel source:


Then follow the usual procedure:


I then selected the modules needed for different kind of joysticks namely:


I saved the settings and continued the build:


Then I copied my modules to my sdcard, went to a terminal that I downloaded from the android market and did (as root):


And received the following error:


So I thought: “It cannot be, I compiled the right kernel the right way, with the correct compiler that the guys at Mele used…” After some cups of coffee I found the mystical mistake by checking an existing kernel module from the Mele:


And compared it to the output generated with my module:


Do you see the small difference?

Original Mod:


My Module compiled from amery sources:


So that was the problem, the kernel refused to load the module because the “vermagic” is not the same.

So the logical thought would be to get the sources of 3.0.8+ kernel, and amery github repo has that too in a specific branch (lichee-3.0.8-sun4i)

So I compiled it, made the modules and the new vermagic looked as follows:


The missing “+” is the problem, as it should show 3.0.8+ instead..

So I said, If I change the vermagic of the module the problem will be resolved, but.. if I change the vermagic and use the 3.0.39 source the kernel will explode and the world will collapse!

According to tldp.org and haifu.org, you can build a kernel module using version 3.0.xx (e.g. kernel 3.0.39), and load it in a system running kernel 3.0.yy (e.g. kernel 3.0.8.

So here are 2 methods I’ve followed to change the vermagic:

  • The hard and dirty way: With objcopy you can remove the .modinfo from the original Mele Module and insert that part on your compiled module, so the vermagic will be the same.
  • The easy and “not so dirty way”: Well, I know that this is dirty, but if you’re in a hurry…
    Go to amery source folder, edit the .config file and change:

    to

    Then edit the Makefile file and change:

    to

    and then complete the full build:

You MUST compile the entire kernel, so the proper vermagic is inserted into the modules, if you are lazy and just compile the modules, the vermagic will be not inserted and you’ll see the same error again.

Then I checked the vermagic again:

Original Mele Module


My NEW Module


So to be sure, I copied the module to the sdcard, went to the terminal as root and did:


and no message was displayed, so I typed:


And at the end of the message, the module was correctly inserted!!

So that’s all what I needed.

Share this:

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

Radxa Orion O6 Armv9 mini-ITX motherboard
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
29 Comments
oldest
newest
Boardcon CM3588 Rockchip RK3588 System-on-Module designed for AI and IoT applications