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

["mar.krzeminski" <mar.krzeminski@gmail.com>]

W dniu 24.09.2015 o 20:38, Peter Crosthwaite pisze:
> On Thu, Sep 24, 2015 at 10:14 AM, mar.krzeminski
> <mar.krzeminski@gmail.com> wrote:
>>
>> W dniu 24.09.2015 o 05:07, Peter Crosthwaite pisze:
>>
>> On Wed, Sep 23, 2015 at 8:06 PM, Peter Crosthwaite
>> <crosthwaitepeter@gmail.com> wrote:
>>
>> On Wed, Sep 23, 2015 at 10:31 AM, mar.krzeminski
>> <mar.krzeminski@gmail.com> wrote:
>>
>> W dniu 23.09.2015 o 17:46, Peter Maydell pisze:
>>
>> On 23 September 2015 at 08:17, Marcin Krzemiński
>> <mar.krzeminski@gmail.com> 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 :).
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 :)
For now it seem that this all is working fine. Last not implemented 
think is this loading firmware to proper CPU.

>> Thanks,
>> Marcin