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

[Peter Crosthwaite]

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