On loading userspace data into particular section of physical memory (ARM)

I am looking at a problem that might be too difficult to solve, or
might not if I'm missing something so I thought I'd bounce it off this
group,

Basically I have an application in userspace who's ".data" section
_has_ to be loaded into particular locations in physical memory. That
is, there is a chunk of physical memory that has to contain the .data
section and no other part of physical memory should.

What is the easiest way to do this? I guess, changes might be required
to the ELF loaders in fs/bin*.c. Any other tricks?

Is it non-trivial to add a new memory zone to the kernel that manages
a particular section of physical memory? I thought if a new zone could
be added, then we could possibly modify the kernel ELF loader to
recognize a specially marked .data section and alloc memory from that
special zone when allocating page frames.

Let me know if you have any ideas, Thanks,

Regards,
Joel

I am looking at a problem that might be too difficult to solve, or
might not if I'm missing something so I thought I'd bounce it off this
group,

Basically I have an application in userspace who's ".data" section
_has_ to be loaded into particular locations in physical memory. That
is, there is a chunk of physical memory that has to contain the .data
section and no other part of physical memory should.

What is the easiest way to do this? I guess, changes might be required
to the ELF loaders in fs/bin*.c. Any other tricks?

I thought gcc/ld/elf understood absolute sections and you could do
this with a gcc linker script. If Linux would load it at the fixed
location, I have no idea.

[4] seems to impact what you are needing. [5] seems to show change
1.555 introduced a similar test on bfd_is_abs_section and alteration
if the section is ignored. The note on the commit goes along with
that. I'm a bit surprised this change was only introduced on
2012/05/17.

[4] http://sourceware.org/ml/binutils/2012-04/msg00095.html
[5] http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf.c?annotate=1.577&cvsroot=src
[6] http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf.c.diff?r1=1.554&r2=1.555&cvsroot=src&f=h

Is it non-trivial to add a new memory zone to the kernel that manages
a particular section of physical memory? I thought if a new zone could
be added, then we could possibly modify the kernel ELF loader to
recognize a specially marked .data section and alloc memory from that
special zone when allocating page frames.

Does mmap in the devmem2 example[1] not do what you need? CMEM [2]
used to provide this type of functionality, but it was never in
mainline from what I recall. I found [3] seems to do something
similar, but might not allow the setting of a specific address. Either
way, I think you'd need to modify the kernel to hold on to the memory
and hand it to you if it would otherwise be handed out to other
applications.

[1] http://elinux.org/images/a/aa/Devmem2.c
[2] http://processors.wiki.ti.com/index.php/CMEM_Overview
[3] http://lwn.net/Articles/396702/

Let me know if you have any ideas, Thanks,

Excuse the naive response, but just wanting to help you move to the
next level of detail.

I am looking at a problem that might be too difficult to solve, or
might not if I'm missing something so I thought I'd bounce it off this
group,

Basically I have an application in userspace who's ".data" section
_has_ to be loaded into particular locations in physical memory. That
is, there is a chunk of physical memory that has to contain the .data
section and no other part of physical memory should.

What is the easiest way to do this? I guess, changes might be required
to the ELF loaders in fs/bin*.c. Any other tricks?

I thought gcc/ld/elf understood absolute sections and you could do
this with a gcc linker script. If Linux would load it at the fixed
location, I have no idea.

Yes, its Linux. Linker scripts only go as far as virtual addresses. :frowning:

Is it non-trivial to add a new memory zone to the kernel that manages
a particular section of physical memory? I thought if a new zone could
be added, then we could possibly modify the kernel ELF loader to
recognize a specially marked .data section and alloc memory from that
special zone when allocating page frames.

Does mmap in the devmem2 example[1] not do what you need? CMEM [2]
used to provide this type of functionality, but it was never in
mainline from what I recall. I found [3] seems to do something

The closest I could find is to mmap and have a driver use remap_pfn_range.
CMEM is kind of outdated, there is CMA that does a similar thing. I
haven't looked into it much yet.

Thanks for your response,

Regards,
Joel

Joel A Fernandes <agnel.joel@gmail.com> writes:

I am looking at a problem that might be too difficult to solve, or
might not if I'm missing something so I thought I'd bounce it off this
group,

Basically I have an application in userspace who's ".data" section
_has_ to be loaded into particular locations in physical memory. That
is, there is a chunk of physical memory that has to contain the .data
section and no other part of physical memory should.

Your statement is self-contradictory. Userspace, by definition, does
not care about anything but virtual addresses. If physical addresses
matter, you are dealing with something lower-level than userspace,
probably some hardware with particular requirements. Please state what
you are really doing, that we may better help you find a solution.

What is the easiest way to do this? I guess, changes might be required
to the ELF loaders in fs/bin*.c. Any other tricks?

Is it non-trivial to add a new memory zone to the kernel that manages
a particular section of physical memory? I thought if a new zone could
be added, then we could possibly modify the kernel ELF loader to
recognize a specially marked .data section and alloc memory from that
special zone when allocating page frames.

Although possible, I wouldn't recommend messing with the ELF loader for
this purpose. The easiest option is probably to carve out a memory hole
using mem= parameters on the kernel command line, and write a driver
exposing this region with mmap(). Then have the application mmap() this
memory and copy the data into place. If you're feeling lucky, you can
even run the app as root and mmap /dev/mem, avoiding the tedious task of
writing a driver.