Hi,

I'm attempting to use qemu-user-arm in a very weird way:

I'm using it to simulate a firmware image for an arm mcu. I only need to
emulate the arm core, not specific periferals (I'm use semihosting to
interact with an abstraction level).

I use the same ELF file resulted from the process (I'm using the gnuarm
toolset, with a custom entry routine and a custom link script).

Everything works fine, except that the entry points attempts to copy memory
from what it believes to be the "rom" image and the ram segment. The thing
is that qemu already does that itself, because it looks at my data segment
in the elf file and puts it at the right virtual address (what on the
microcontroller would be the ram area). But that's not a problem: I could
let the entry point copy it again by itself. But qemu does not map the data
segment on the physical address area, so the startup code ends up reading
the remaning of the  code segment (where it believes it will find the
original data segment) until the page boundary, where it segfaults.

I looked at elfload.c, and found in the function load_elf_binary(...) where
it maps the segments, and at the same time it seemed trivial to do the trick
of mapping the segment twice (once as a read-only segment, mapped to the
physical area [p_paddr], and once as it already is, or just creating a fresh
mapping at the virtual address).

However after this first impression I got a bit confused. If someone could
tip me on how to achieve that, I would appreciate.

If there are other ways to do that without modifying the entry loader (I
have strong reasons to keep it intact, believe me), I'm open to suggestions
as well.

Before someone points me to the system qemu (I know that what I'm trying to
do is quite non-standard use of the software), I must say it would not be
quite as handy as using the user one, specially in automated tests where
there's no user intervention. It already does everything I need, except this
little thing.

Thanks,

Alexandre

Reply via email to