[yocto] Problems with building out-of-tree modules in morty

[Bogusz Brodziński]

Hi,

TL;DR after migrating from jethro to morty my out-of-tree modules do not
load.

Long version:
Im developing uio driver for a custom FPGA. The base is xilinx zu15 (note:
as the explanation will go on I *think* it will be clear that this is not
related to meta-xilinx).
It's basically a debug interface that generates IRQ-like events on files
(poll) for newly developed/tested features. The initial structure was poky
jethro, meta-xilinx with linux-xlnx 4.4 for aarch64. The module is
basically uio driver, but creates individual uio for each signal. The
makefile is straight from
https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.html and the
recipee inherits from module.
When using jethro the module got built out-of-tree with no problem and I
could load it. After migrating to morty (I also bumped meta-xilinx rev, but
I use the same kernel SRCREV and project layer) I still can build the
module, but when loading it I get:

$ modprobe uio_pdrv_testirq
[   79.059558] module uio_pdrv_testirq: unsupported RELA relocation: 275
modprobe: can't load module uio_pdrv_testirq (testirq/uio_pdrv_testirq.ko):
invalid module format

$ modinfo uio_pdrv_testirq
filename:       testirq/uio_pdrv_testirq.ko
license:        GPL v2
author:         BB
description:    Userspace I/O test driver irq handler
depends:
vermagic:       4.4.0-xilinx SMP preempt mod_unload modversions aarch64

I looked for a solution and found this
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/375429.html
thread
I checked that I have all the ERRATUM enabled (with emphasys on
ARM64_ERRATUM_843419):
CONFIG_ARM64_ERRATUM_826319=y
CONFIG_ARM64_ERRATUM_827319=y
CONFIG_ARM64_ERRATUM_824069=y
CONFIG_ARM64_ERRATUM_819472=y
CONFIG_ARM64_ERRATUM_832075=y
CONFIG_ARM64_ERRATUM_845719=y
CONFIG_ARM64_ERRATUM_843419=y

and I added
CFLAGS_MODULE  += -mcmodel=large

Result: no change; testirq still fails to load.

I would be grateful for any suggestions where to look or what to do next.

Best regards,
Bogusz Brodzinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20170124/d29011fc/attachment.html>