From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfBjQ-0008Ew-WF for qemu-devel@nongnu.org; Thu, 24 Sep 2015 14:59:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZfBjN-0003IC-Pz for qemu-devel@nongnu.org; Thu, 24 Sep 2015 14:59:00 -0400 Received: from mail-la0-x232.google.com ([2a00:1450:4010:c03::232]:35682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZfBjN-0003HE-EN for qemu-devel@nongnu.org; Thu, 24 Sep 2015 14:58:57 -0400 Received: by lacwc7 with SMTP id wc7so17171466lac.2 for ; Thu, 24 Sep 2015 11:58:56 -0700 (PDT) References: <5602E1DB.1060201@gmail.com> <56042F6A.2030804@gmail.com> From: "mar.krzeminski" Message-ID: <560447EE.5070503@gmail.com> Date: Thu, 24 Sep 2015 20:58:54 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] Loading image/elf to cpu that has different not system memory address space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Edgar Iglesias , Peter Maydell , Alistair Francis , "qemu-devel@nongnu.org Developers" , Peter Crosthwaite W dniu 24.09.2015 o 20:38, Peter Crosthwaite pisze: > On Thu, Sep 24, 2015 at 10:14 AM, mar.krzeminski > wrote: >> >> W dniu 24.09.2015 o 05:07, Peter Crosthwaite pisze: >> >> On Wed, Sep 23, 2015 at 8:06 PM, Peter Crosthwaite >> wrote: >> >> On Wed, Sep 23, 2015 at 10:31 AM, mar.krzeminski >> wrote: >> >> W dniu 23.09.2015 o 17:46, Peter Maydell pisze: >> >> On 23 September 2015 at 08:17, Marcin Krzemiński >> 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