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
