insmod problem on ARM with more than 16MB of RAM?

insmod problem on ARM with more than 16MB of RAM?

[Sergei Poselenov]

Hi all,

I'm working with an ARM Cortex-M3 port of Linux 2.6.33. Everything is
fine except the target board has 32MB memory and this breaks the
loadable modules support:
...
~ # insmod sample.ko 
sample: relocation out of range, section 2 reloc 0 sym 'printk'
insmod: can't insert 'sample.ko': invalid module format
~ # 
..

The reason for this error is that the module_alloc() for non-MMU
ARM target is just kmalloc(size), which obviously returns the memory
area too far for allowed range of the thumb2 branch instructions.

Currently, I worked around this by restricting kernel memory usage with
"mem=16M".

Is anybody solved this problem in 2.6 no-MMU ARM kernels?

In the lists I only found this thread
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/037837.html
, but it discussed different problem.

I looked at the recent 3.x kernels and didn't see support for loadable
modules at all for the non-mmu ARM. Any plans to add it there?

Merry Christmas!

Regards,
Sergei

insmod problem on ARM with more than 16MB of RAM?

[Catalin Marinas]

On 22 December 2011 16:35, Sergei Poselenov <sposelenov@emcraft.com> wrote:
> I'm working with an ARM Cortex-M3 port of Linux 2.6.33. Everything is
> fine except the target board has 32MB memory and this breaks the
> loadable modules support:
> ...
> ~ # insmod sample.ko
> sample: relocation out of range, section 2 reloc 0 sym 'printk'
> insmod: can't insert 'sample.ko': invalid module format
> ~ #
> ..
>
> The reason for this error is that the module_alloc() for non-MMU
> ARM target is just kmalloc(size), which obviously returns the memory
> area too far for allowed range of the thumb2 branch instructions.
>
> Currently, I worked around this by restricting kernel memory usage with
> "mem=16M".
>
> Is anybody solved this problem in 2.6 no-MMU ARM kernels?

You could change the testofs-y in arch/arm/Makefile to something like
16MB and it could be reachable from all 32MB of RAM.

A more general solution may be to move the kernel in the top 16MB of
RAM (in case you have more than 32MB), enable ZONE_DMA and make all
the memory up to the kernel part of the DMA zone. The top 16MB would
be ZONE_NORMAL and modules would in general be allocated from there
(but there is no guarantee).

A completely generic solution would be to modify the module loader to
cope with longer relocations by setting up some trampoline code.

-- 
Catalin

insmod problem on ARM with more than 16MB of RAM?

[Russell King - ARM Linux]

On Thu, Dec 22, 2011 at 04:49:13PM +0000, Catalin Marinas wrote:
> A completely generic solution would be to modify the module loader to
> cope with longer relocations by setting up some trampoline code.

That was discussed when the module format changed, and decided it was
not possible because of circular dependencies to do it right.

The reason is you can't modify the size of the allocation after the
module has been loaded to add trampolines, and you can't parse the
object file until memory has been allocated to load it into.  So you
either have to allocate a trampoline for every function symbol in the
kernel which the module _might_ use (which wastes lots of memory) or
you just arrange for stuff to be placed within range of the kernel.

So for MMU platforms, we just ensure that modules are always placed
within reach of the kernel text.  For nommu platforms, modules are
a bitch - and TBH given the virtually non-existent activity/interest
from the nommu sector, it's something I'm willing to spend the grand
total of zero time to solve this _really_ _hard_ problem.

insmod problem on ARM with more than 16MB of RAM?

[Vladimir K]

> So for MMU platforms, we just ensure that modules are always placed
> within reach of the kernel text.  For nommu platforms, modules are
> a bitch - and TBH given the virtually non-existent activity/interest
> from the nommu sector, it's something I'm willing to spend the grand
> total of zero time to solve this _really_ _hard_ problem.

Wouldn't just adding a -mlong-calls to CFLAGS_MODULE
resolve the problem?

Something along the lines of:

ifeq ($(CONFIG_MODULES),y)
CFLAGS_MODULE    += -mlong-calls
endif

in arch/arm/Makefile.

This this change, modules work fine for me on a 32MBytes RAM
Cortex-M3 configuration.

Regards,
Vladimir Khusainov