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

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

[Marcin Krzemiński]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

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?

Regards,
Marcin Krzemiński

[-- Attachment #2: Type: text/html, Size: 1127 bytes --]

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

[Peter Maydell]

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

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

[mar.krzeminski]

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?

Thanks,
Marcin

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

[Peter Crosthwaite]

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.

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

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
<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

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

[mar.krzeminski]

[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]



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...

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...

Thanks,
Marcin

[-- Attachment #2: Type: text/html, Size: 5669 bytes --]

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
<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 :).

> 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

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

[mar.krzeminski]

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

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
<mar.krzeminski@gmail.com> wrote:
>
>
> 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 :).

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
>
>
>

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

[Peter Maydell]

On 29 September 2015 at 23:40, Alistair Francis <alistair23@gmail.com> wrote:
> On Thu, Sep 24, 2015 at 11:58 AM, mar.krzeminski
> <mar.krzeminski@gmail.com> wrote:
>>
>>
>> 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:
>>>> 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);

>> 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.

Sort of. This is for the exception-return mechanism, which on
M-profile works by having the function-return instructions
special-case attempts to "return" to addresses 0xfffffffx, which
should do exception return semantics. QEMU's implementation
handles this by treating "attempt to execute at 0xfffffff0"
specially in the translator (we generate EXCP_EXCEPTION_EXIT).
For this to work we have to have some fake RAM at that address.

This isn't actually an architecturally correct way to do it,
because the architecture says that you should only get the
special exception-return behaviour if you use the right
instructions to return to one of the magic addresses. If
you just try to branch into those addresses you should
get some kind of fault instead.

However, like many things in our M-profile implementation,
it sort of works and nobody has cared enough about M-profile
to try to clean it up. (An efficient implementation of the
right behaviour could be a bit tricky.)

thanks
-- PMM

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

[Marcin Krzemiński]

[-- Attachment #1: Type: text/plain, Size: 2434 bytes --]

2015-09-30 0:59 GMT+02:00 Peter Maydell <peter.maydell@linaro.org>:

> On 29 September 2015 at 23:40, Alistair Francis <alistair23@gmail.com>
> wrote:
> > On Thu, Sep 24, 2015 at 11:58 AM, mar.krzeminski
> > <mar.krzeminski@gmail.com> wrote:
> >>
> >>
> >> 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:
> >>>> 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);
>
> >> 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.
>
> Sort of. This is for the exception-return mechanism, which on
> M-profile works by having the function-return instructions
> special-case attempts to "return" to addresses 0xfffffffx, which
> should do exception return semantics. QEMU's implementation
> handles this by treating "attempt to execute at 0xfffffff0"
> specially in the translator (we generate EXCP_EXCEPTION_EXIT).
> For this to work we have to have some fake RAM at that address.
>
> This isn't actually an architecturally correct way to do it,
> because the architecture says that you should only get the
> special exception-return behaviour if you use the right
> instructions to return to one of the magic addresses. If
> you just try to branch into those addresses you should
> get some kind of fault instead.
>
> However, like many things in our M-profile implementation,
> it sort of works and nobody has cared enough about M-profile
> to try to clean it up. (An efficient implementation of the
> right behaviour could be a bit tricky.)
>
> thanks
> -- PMM
>
I have at 0xfffffff0 real memory now (with aliasing to lower memory
address).
Does it mean that qemu might try to execute some instructions from there?

Regards,
Marcin

[-- Attachment #2: Type: text/html, Size: 3581 bytes --]

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

[Peter Maydell]

On 30 September 2015 at 06:18, Marcin Krzemiński
<mar.krzeminski@gmail.com> wrote:
> I have at 0xfffffff0 real memory now (with aliasing to lower memory
> address).
> Does it mean that qemu might try to execute some instructions from there?

As I say, we need there to be fake RAM at that address. We never
try to read its contents, though.

-- PMM

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

[Marcin Krzemiński]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

2015-09-30 12:44 GMT+02:00 Peter Maydell <peter.maydell@linaro.org>:

> On 30 September 2015 at 06:18, Marcin Krzemiński
> <mar.krzeminski@gmail.com> wrote:
> > I have at 0xfffffff0 real memory now (with aliasing to lower memory
> > address).
> > Does it mean that qemu might try to execute some instructions from there?
>
> As I say, we need there to be fake RAM at that address. We never
> try to read its contents, though.
>
> -- PMM
>

That wasn't clear for me.
Since I have real and used memory there in my model I worried that I my get
sometimes unexpected behavior.

Thanks,
Marcin

[-- Attachment #2: Type: text/html, Size: 1141 bytes --]

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

[Peter Maydell]

On 30 September 2015 at 13:15, Marcin Krzemiński
<mar.krzeminski@gmail.com> wrote:
>
>
> 2015-09-30 12:44 GMT+02:00 Peter Maydell <peter.maydell@linaro.org>:
>>
>> On 30 September 2015 at 06:18, Marcin Krzemiński
>> <mar.krzeminski@gmail.com> wrote:
>> > I have at 0xfffffff0 real memory now (with aliasing to lower memory
>> > address).
>> > Does it mean that qemu might try to execute some instructions from
>> > there?
>>
>> As I say, we need there to be fake RAM at that address. We never
>> try to read its contents, though.

> That wasn't clear for me.
> Since I have real and used memory there in my model I worried that I my get
> sometimes unexpected behavior.

It seems very unlikely that you would have real memory there in an
M profile CPU system -- that address range is part of the Vendor
System section of the address space. (Among other things it's
compulsorily execute-never.)

thanks
-- PMM