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

[Alistair Francis]

On Thu, Sep 24, 2015 at 11:58 AM, mar.krzeminski
<address@hidden> wrote:
>
>
> W dniu 24.09.2015 o 20:38, Peter Crosthwaite pisze:
>
>> 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 :).

Me too!

>
> Ok, so I'll try to implement this idea, hope I will work :)
>>>
>>> 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
>
> Generally I did that, I got from that file cpu init, nvic and added custom
> AS.
> I needed to make small changes in nvic to stop it from using default
> system_memory ( it might be worth to send a patch I think...).
> Then took me a while to understand why qemu crash while serving M3 exception
> because I haven't took this hack :)

It sounds like you figured out why it's there. From memory it is to
handle an exception, because the guest would just to a really high
memory area and if there is no memory there QEMU will throw an error.

Thanks,

Alistair

> For now it seem that this all is working fine. Last not implemented think is
> this loading firmware to proper CPU.
>
>>> Thanks,
>>> Marcin
>
>
>