Oh, I see, I didn't realize you were trying to call it from python, or even
that that was exposed to python. It would probably be possible to expose
that parameter as well, although that would require a change to gem5. I
think that change would be worth doing, but may be a bit of a tangent from
what you're doing. Alternatively, you could define a different Workload
class in C++ which would do your extra set up there, where you can use the
extra argument.
Gabe
On Tue, Oct 26, 2021 at 5:30 PM Monsalve, Jose Manuel <jmonsalved...@anl.gov>
wrote:
> Sorry for the typo. I meant Gabe.
>
> Jose Monsalve
> ------------------------------
> *From:* Gabe Black <gabe.bl...@gmail.com>
> *Sent:* Tuesday, October 26, 2021 7:27:58 PM
> *To:* gem5 users mailing list <gem5-users@gem5.org>
> *Cc:* Jason Lowe-Power <ja...@lowepower.com>; Tianshuo Su <
> t...@uchicago.edu>; Andronicus Samsundar Rajasukumar <
> androni...@uchicago.edu>; Andrew A. Chien <ach...@cs.uchicago.edu>;
> Monsalve, Jose Manuel <jmonsalved...@anl.gov>
> *Subject:* Re: [gem5-users] Re: How to map elf section to physical memory
>
> You can also take a look at the "clobber" argument which will tell the
> mapping function to overwrite existing mappings. You can see in the panic
> that that's what it's checking, ie it found an overlap and it wasn't told
> to go ahead and clobber those, so it has to give up.
>
> Gabe
>
> On Tue, Oct 26, 2021 at 5:13 PM Monsalve, Jose Manuel via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Jason,
>
>
>
> Thanks for the answer.
>
>
>
> Let me take a look into this idea and I will get back to you.
>
>
>
> Jose
>
>
>
> *From: *Jason Lowe-Power <ja...@lowepower.com>
> *Date: *Tuesday, October 26, 2021 at 5:58 PM
> *To: *gem5 users mailing list <gem5-users@gem5.org>
> *Cc: *Tianshuo Su <t...@uchicago.edu>, Andronicus Samsundar Rajasukumar <
> androni...@uchicago.edu>, "Andrew A. Chien" <ach...@cs.uchicago.edu>,
> "Monsalve, Jose Manuel" <jmonsalved...@anl.gov>
> *Subject: *Re: [gem5-users] How to map elf section to physical memory
>
>
>
> Hi Jose,
>
>
>
> This is an interesting question! My quick suggestion would be to "hack"
> the loader/page table to skip the mapping portion when loading the elf
> section.
>
>
>
> I don't fully understand exactly what the underlying "problem" is. That
> said, we may be able to solve it "correctly" by generally skipping the
> mapping during the elf loading if it's already been manually mapped by the
> process.map function. This may be useful to upstream if this idea works.
>
>
>
> Cheers,
>
> Jason
>
>
>
> On Fri, Oct 22, 2021 at 4:30 PM Monsalve, Jose Manuel via gem5-users <
> gem5-users@gem5.org> wrote:
>
> Hi everyone,
>
>
>
> I am working on developing the simulation of a system that contains two
> different regions of memory. One that maps to the cachable system memory
> (including cache hierarchy) but another region that is non-cachable, and
> which goes to a different memory (similar to scratchpad memory for the sake
> of this question). Additionally, in the executing code, I am trying to
> allocate some objects into this scratchpad memory address space from a
> section in the elf file. While running in SE mode. So, for example:
>
>
>
> System Memory address range -> 0x-00000 to 0x00FFF
>
> Scratchpad memory address range -> 0x01000 to 0xFFFFF
>
>
>
> And in the linker script I place some sections in this region like:
>
>
>
> . = 0x1000
>
> .scratchpad {
>
> /* all symbols */
>
> }
>
>
>
> Then to use the __attribute__((section(“.scratchpad”)) in a given
> definition.
>
>
>
> However, when the loader loads this elf file, the virtual memory is
> assigned correctly, but it is mapped to another physical memory range that
> is different to the physical memory of the SPmem device.
>
>
>
> I know I can use the *.map()* method in the process like this (in python)
>
>
>
> process.map(Addr(args.mem_size),
>
> Addr(args.mem_size),
>
> SPMemorySize,
>
> False)
>
>
>
> This will only work if I don’t use sections in the linker script, and
> instead, manually assign the value of a pointer. (e.g. int **a = (int**)
> 0x1000;)
>
>
>
> But when I run it with the elf sections I get the error:
>
> build/RISCV/mem/page_table.cc:60: panic: panic condition !clobber
> occurred: EmulationPageTable::allocate: addr 0xc0000000 already mapped
>
>
>
> Because by the moment I reach the second map, the loader has already
> mapped the region before.
>
>
>
> I would appreciate if someone can share nay pointers on how to properly do
> this mapping between virt and physical.
>
>
>
> Thanks!
>
>
>
> Jose M Monsalve Diaz
>
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> _______________________________________________
> gem5-users mailing list -- gem5-users@gem5.org
> To unsubscribe send an email to gem5-users-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
_______________________________________________
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
