I see what you mean. Let me explore these options, and see if I can provide that modification to Gem5.
Jose From: Gabe Black <gabe.bl...@gmail.com> Date: Tuesday, October 26, 2021 at 7:46 PM To: "Monsalve, Jose Manuel" <jmonsalved...@anl.gov> Cc: gem5 users mailing list <gem5-users@gem5.org>, Jason Lowe-Power <ja...@lowepower.com>, Tianshuo Su <t...@uchicago.edu>, Andronicus Samsundar Rajasukumar <androni...@uchicago.edu>, "Andrew A. Chien" <ach...@cs.uchicago.edu> Subject: Re: [gem5-users] Re: How to map elf section to physical memory 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<mailto:jmonsalved...@anl.gov>> wrote: Sorry for the typo. I meant Gabe. Jose Monsalve ________________________________ From: Gabe Black <gabe.bl...@gmail.com<mailto:gabe.bl...@gmail.com>> Sent: Tuesday, October 26, 2021 7:27:58 PM To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Cc: Jason Lowe-Power <ja...@lowepower.com<mailto:ja...@lowepower.com>>; Tianshuo Su <t...@uchicago.edu<mailto:t...@uchicago.edu>>; Andronicus Samsundar Rajasukumar <androni...@uchicago.edu<mailto:androni...@uchicago.edu>>; Andrew A. Chien <ach...@cs.uchicago.edu<mailto:ach...@cs.uchicago.edu>>; Monsalve, Jose Manuel <jmonsalved...@anl.gov<mailto: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<mailto: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<mailto:ja...@lowepower.com>> Date: Tuesday, October 26, 2021 at 5:58 PM To: gem5 users mailing list <gem5-users@gem5.org<mailto:gem5-users@gem5.org>> Cc: Tianshuo Su <t...@uchicago.edu<mailto:t...@uchicago.edu>>, Andronicus Samsundar Rajasukumar <androni...@uchicago.edu<mailto:androni...@uchicago.edu>>, "Andrew A. Chien" <ach...@cs.uchicago.edu<mailto:ach...@cs.uchicago.edu>>, "Monsalve, Jose Manuel" <jmonsalved...@anl.gov<mailto: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<mailto: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<mailto:gem5-users@gem5.org> To unsubscribe send an email to gem5-users-le...@gem5.org<mailto:gem5-users-le...@gem5.org> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org<mailto:gem5-users@gem5.org> To unsubscribe send an email to gem5-users-le...@gem5.org<mailto: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
