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
