On Thu, Sep 24, 2015 at 11:58 AM, mar.krzeminski <mar.krzemin...@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.krzemin...@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 >>> <crosthwaitepe...@gmail.com> wrote: >>> >>> On Wed, Sep 23, 2015 at 10:31 AM, mar.krzeminski >>> <mar.krzemin...@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.krzemin...@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 > > >
