Re: [Qemu-devel] Loading image/elf to cpu that has different not system memory address space

[Peter Crosthwaite]

On Thu, Sep 24, 2015 at 10:14 AM, mar.krzeminski
<address@hidden> wrote:
>
>
> W dniu 24.09.2015 o 05:07, Peter Crosthwaite pisze:
>
> On Wed, Sep 23, 2015 at 8:06 PM, Peter Crosthwaite
> <address@hidden> wrote:
>
> On Wed, Sep 23, 2015 at 10:31 AM, mar.krzeminski
> <address@hidden> wrote:
>
> W dniu 23.09.2015 o 17:46, Peter Maydell pisze:
>
> On 23 September 2015 at 08:17, Marcin Krzemiński
> <address@hidden> wrote:
>
> Hello,
>
> I am trying to write a model of embedded board that have corterx-m3 and
> cotex a9 processors.
> Because M3 see different memory at address 0x0 than A9 (m3 has small rom,
> a9
> has whole ram) I created different address space for m3 (thanks Peter
> Crosthwaite! for hints how to do this!).
> Now I stacked at loading "kernel" to start M3. If I use default address
> space for M3 I can load I run my elf filr (it can be image, but currently
> it
> is easiest for me with elf) all works fine.
> The problem is when I switch to my new (root MR is not from
> get_system_memory() call ) i got execution outside RAM exception.
> That is happening because there are only zeroes in memory pointed by my
> second address space.
> The question is how can I load image to this memory (it might be elf, but
> binary image also is fine)?
> I can not even find the code that loads data to memory in fist place.
> Could
> you point me where the loading is done in the code?
>
> This is going to be complicated. I suspect you will need to add
> some infrastructure for specifying per-CPU image loading (maybe
> via CPU properties?), which we don't have at all right now.
>
> (Our current image loading code for arm lives in hw/arm/boot.c.)
>
> thanks
> -- PMM
>
> I couldn't find the place were actual data are put int M-, I don't know why
> I haven't seen
> rom_add_blob() in boot.c.
> At the machine init level I know all MRs, so I'll use
> memory_region_get_ram_ptr(),
> and put data there.
> If you have idea how to add this into framework, and someone beside me needs
> this,
> maybe I can implement that?
>
> We definately need it. We need to be able to associate multiple
> softwares with multiple CPUs.
>
> This is known to work, and could be what you are looking for:
>
> https://github.com/Xilinx/qemu/blob/pub/2015.2.plnx/hw/misc/blob-loader.c
>
> You pass -device loader,cpu=#,...
>
> then various other fields, all on the command line (depending if your
> loading elfs or raw blobs). It is badly named, it is more than just a
> blob loader now. It works best when you don't use -kernel (you may
> need to hack your machine model to disable any checks that forces
> -kernel).
>
> The key feature of that device is it loads from the argument CPUs
> perspective, so if your M3 CPU AR is correctly set it will load via it
> when you use -device loader,cpu=1,foo.elf.
>
> Other key feature, is the command line options is repeatable for
> multiple blobs and multiple CPUs.
>
> Regards,
> Peter
>
> The implementation is slightly bogus, it is using a global AS pointer
> loader_as to pass the cpu AS to loader infrastucture. git grep that
> tree (2015.2.plnx branch) for "loader_as" to see the needed changes to
> core loader infrastructure and cherry pick the device and it should be
> close to working.
>
> HTH
>
> Regards,
> Peter
>
> Thanks,
> Marcin
>
> Great functionality, I'll probably integrate it, but for fast checking if
> all works I'll use also
> global pointer ( generally it is used already in load.c).
> As I looked into code it seem that it is possible to pass CPU state down to
> loading functions,
> so those can use AS connected with CPU. If someone is interested in that
> patch I can try to prepare it...
>

I'll take a CC :).

> Today I stacked on other interesting think - and I do not want to spam this
> list - it is hack in cortex-m3
> from armv7m.
>
>     /* Hack to map an additional page of ram at the top of the address
>        space.  This stops qemu complaining about executing code outside RAM
>        when returning from an exception.  */
>     memory_region_init_ram(hack, NULL, "armv7m.hack", 0x1000, &error_abort);
>     vmstate_register_ram_global(hack);
>     memory_region_add_subregion(system_memory, 0xfffff000, hack);
>
> Why it is there, seem to be old...
>

I'm not sure. Alistair may know more.

But for your project, I would definitely avoid that ARMv7M code and
just take M3 as a CPU. Pull out any extra pieces you want from
armv7m.c as needed to build something from scratch. To support the
multi-as work that ARMv7M stuff would need an overhaul I think. It is
stylistically out of date and due for a rewrite.

Regards,
Peter

> Thanks,
> Marcin