I think the map function has a parameter for "cacheable". From
src/sim/Process.py:
@classmethod
def export_methods(cls, code):
code('bool map(Addr vaddr, Addr paddr, int size, bool
cacheable=true);')
Cheers,
Jason
On Mon, Jan 30, 2017 at 6:44 PM Lorenzo Zuolo <[email protected]> wrote:
> Hi Jason,
>
> I've double-checked in the request sruct (req) coming from the processor
> and flowing thru the cache down to the mshr engine and it seems that the
> transaction is not set as uncacheable. In fact, the request hitting my
> address range is manged as a standard cache miss (the processor issue a 64
> Bytes cache line refill to the memory). As a matter of facts Iit seems
> that all the map function does is to sets a region of the address space
> which can be virtual-to-physical mapped but it doesn't set any cacheability
> property.
> Any thought on this? How can I set the uncacheable flag?
>
> Thanks,
> Lorenzo
>
>
> 2017-01-27 17:04 GMT+01:00 Jason Lowe-Power <[email protected]>:
>
> Hi Lorenzo,
>
> If the access flows through the cache, the cache might be creating an MSHR
> and upgrading the packet to a full cache line. You may need to somehow
> update the page table entry to make that region as uncachable. I believe
> there is a field in either the packet or the request that is set when the
> access in uncacheable. You can check this field for the request to your
> uncachable region to make sure they are actually uncacheable requests.
>
> Jason
>
> On Fri, Jan 27, 2017 at 5:06 AM Lorenzo Zuolo <[email protected]> wrote:
>
> Hi Jason,
>
> thank you again for the help.
> Finally I got it. Basically, I've modified the Simulation.py script and
> I've added the map function right before the "*** REAL SIMULATION***" print.
> I did that because I've realized that I was trying to use a method of the
> LiveProcess class when the class itself was not yet instantiated.
> Now, I've a new problem. My memory mapped device works with 32 bits
> packets, but when I try to access it, I receive a 64 Bytes packet size from
> the processor.
> I think that the processor is not aware that the access to a device which
> is outside its address range should not be treated as a normal cache miss
> (cache-line-refill).
>
> Any thought on how to fix that?
>
> Thanks,
> Lorenzo
>
>
> 2017-01-26 18:06 GMT+01:00 Jason Lowe-Power <[email protected]>:
>
> Hi Lorenzo,
>
> This error means you're trying to access a member of a SimObject from the
> Python configuration script that isn't exposed. If you're trying to add a
> new member, then you can use an '_' prefix (IIRC). But this new member will
> only be accessible from the Python config script, not the C++
> implementation of the SimObject. If you want to add a new parameter to the
> SimObject, you need to edit the SimObject declaration Python file in src/
> and the SimObject code itself.
>
> Hope this helps,
> Jason
>
> On Thu, Jan 26, 2017 at 5:46 AM Lorenzo Zuolo <[email protected]> wrote:
>
> Hi Jason,
>
> Sorry for the late replay.
> Thank you for your hint. I've used the "map" method exposed by the
> LiveProcess class to make my address range not cacheable, however when I
> run the se.py script I have this error:
> "(C++ object is not yet constructed, so wrapped C++ methods are
> unavailable.)"
>
> Any thought on this?
>
> Thanks,
> Lorenzo
>
>
> 2016-11-21 16:09 GMT+01:00 Jason Lowe-Power <[email protected]>:
>
> Hi Lorenzo,
>
> Are you trying to use [0x10000-0xFFFFF] as PIO? If so, this example might
> help you figure out how to do what you want.
>
> https://github.com/powerjg/gem5/commit/86394e326cede3be7b26eb728dd6a9a0a93406bf
>
> It's for x86, but it contains an example of how to use PIO in SE mode to
> communicate from a user-mode program running on the guest into the
> simulator.
>
> Cheers,
> Jason
>
> On Mon, Nov 21, 2016 at 8:22 AM Swapnil Haria <[email protected]>
> wrote:
>
> Hey Lorenzo,
>
> Just to see if I understand your question, you want to have uncacheable
> address range 0x10000-0xFFFFF in physical memory and not virtual memory?
>
> I hope you realize that accesses to physical memory not actually mapped to
> DRAM is only allowed for devices. I am guessing that you don't just want
> memory in that range, for which you simply have to increase the memory size
> (using --mem-size=2GB, if you are using example scripts).
>
> For having an uncacheable region (for devices), you could try this - in
> src/arch/arm/process.cc, in ArmLiveProcess32/64::initState()
>
> MultiLevelPageTable<PageTableOps> *pt =
> dynamic_cast<MultiLevelPageTable<PageTableOps> *>(pTable);
>
> pt->map(<Virtual Address>, <Physical Address>, <Region Size>, <bool
> cacheable>);
>
> Check out src/mem/pagetable.hh for the map function, and
> src/arch/x86/process.cc and src/sim/process.cc for more information about
> this.
>
>
> Cheers,
> Swapnil Haria,
> Graduate Student,
> Dept of Computer Sciences,
> University of Wisconsin-Madison
>
> On Fri, Nov 18, 2016 at 3:47 AM, Lorenzo Zuolo <[email protected]> wrote:
>
> Hi everybody,
>
> I have a very stupid question.
> I'm new in gem5 and I would like to understand how to make an address
> region uncacheable with ARM architecture in se mode.
> Problem is. I would like to have the possibility to access an address
> outside the dram range from a c program I'm executing in SE mode.
> Example is:
> Dram range is [0x0-0xFFFF]
> Desired address region is: [0x10000-0xFFFFF]
>
> In the c program I'm running on the core I would like to be able to do
> something like this:
>
> int main {
> char *reg=(char*)0x10000 //pointer to non cacheable memory region
>
> printf("value is %d\n",*reg);
> }
>
> Any thought on that?
>
> Thanks in advance
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
>
> --
> Lorenzo Zuolo, Ph.D.
> PostDoc position
> Università degli studi di Ferrara
> Dip. di Ingegneria (ENDIF)
> Via Saragat n°1
> 44122 Ferrara Fe
> Italy
>
> Office: 304
> Phone: +39-0532-974891 <+39%200532%20974891>
> Skype: lorenzo.zuolo
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
>
> --
> Lorenzo Zuolo, Ph.D.
> PostDoc position
> Università degli studi di Ferrara
> Dip. di Ingegneria (ENDIF)
> Via Saragat n°1
> 44122 Ferrara Fe
> Italy
>
> Office: 304
> Phone: +39-0532-974891 <+39%200532%20974891>
> Skype: lorenzo.zuolo
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
>
> --
> Lorenzo Zuolo, Ph.D.
> PostDoc position
> Università degli studi di Ferrara
> Dip. di Ingegneria (ENDIF)
> Via Saragat n°1
> 44122 Ferrara Fe
> Italy
>
> Office: 304
> Phone: +39-0532-974891 <+39%200532%20974891>
> Skype: lorenzo.zuolo
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
