Hi Roger, The two locations in the code that are of most importance is src/mem/physical.cc where you have the simulators view of the address space encompassed through an untimed API. The address map is simply a look-up function in a tree. The other location is src/mem/bus.cc where you find the address lookup as seen from the perspective of a packet in the guest system. This API is used by the conventional functional/atomic/timing accessors to send packets to the right destination.
I hope that??s enough to get you started. Good luck. Andreas On 18/04/2014 19:25, "Roger Smith" <[email protected]> wrote: >Hi Andreas, > >I would like to pursue the address decoding approach and take the plunge >into a bigger physical address space. > >This is the first time I will be looking at the code and am wondering >where would be a good place to start. Is there a specification? I realize > >its a lot of code and want to be comfortable I am catching all of the >options. > >I am thinking it may be advantageous to use the ARM processor in this >case. It seems there are two master CPU ports, one for instructions, the >other for data. > >Thank-you for you help. > >Cheers, >Roger > > >On Tue, 15 Apr 2014 16:54:10 -0600, Roger Smith <[email protected]> >wrote: > >> Hi Andreas, >> >> Thank-you for this information. I will have to digest it, but will get >> back with you. >> >> Cheers, >> Roger >> >> On Tue, 15 Apr 2014 16:30:11 -0600, Andreas Hansson >> <[email protected]> wrote: >> >>> Hi Roger, >>> >>> I think you??ll struggle to accomplish anything like this with the >>> existing >>> address mapper. The memories in gem5 (all inheriting from >>> AbstractMemory), >>> presents themselves to the system in two ways: >>> >>> 1) Through an address decoding process done by the interconnect. This >>> would be easy to change. >>> >>> 2) Through a direct function-call API where a global interval-tree >>>keeps >>> track of what memory corresponds to what address. The latter is used >>>for >>> debugging/introspection etc. >>> >>> The two views are kept in sync, and if you start to tamper with 1), I >>> fear >>> 2) will quickly break. >>> >>> I would suspect your best bet is to either take the plunge and have a >>> bigger physical address space, do the replication ??properly?? in the >>> interconnect (i.e. Actually write to different addresses), and let the >>> >>> OS >>> handle the VA->PA mapping. >>> >>> The other extreme option is to hide it within the AbstractMemory >>> somehow. >>> I am not sure what that would look like, and it depends on how much you >>> want to expose to the OS etc. >>> >>> Andreas >>> >>> On 4/15/14, 7:21 PM, "Roger Smith" <[email protected]> wrote: >>> >>>> Hi Andreas, >>>> >>>> I would like to dynamically configure memory in dual, triple >>>>redundancy >>>> and copy on write (cow) failure modes. Blacklist failed memory areas >>>> and >>>> create memory sandboxes at the interconnect level. >>>> >>>> Thanks, >>>> >>>> Roger >>>> >>>> >>>> On Tue, 15 Apr 2014 11:32:15 -0600, Andreas Hansson >>>> <[email protected]> wrote: >>>> >>>>> Hi Roger, >>>>> >>>>> Could you perhaps shed some light on the bigger picture here. Why do >>>>> >>>>> you >>>>> want to re-map a slave? >>>>> >>>>> You are right about the fact that ARM and Ruby does not work. In >>>>> general, >>>>> the classic memory system has a broader support. The crossbar model >>>>> that >>>>> is part of the classic memory system can be used to build quite >>>>> elaborate >>>>> interconnect topologies, so hopefully that is enough. >>>>> >>>>> Thanks, >>>>> >>>>> Andreas >>>>> >>>>> On 15/04/2014 18:13, "Roger Smith" <[email protected]> wrote: >>>>> >>>>>> I have a newby question. I would like to modify the Interconnect >>>>>> module(s) >>>>>> located between the CPU and Slave module to remap the Slave module >>>>>> address >>>>>> space. The diagram showing these modules can be seen in the ARM gem5 >>>>>> Tutorial, Bischoff & Hansson, slide 70, titled Ports, Masters, and >>>>>> Slaves. >>>>>> >>>>>> I appears there a couple of paths. The first is to modify the >>>>>> AddrMapper >>>>>> class the second is to modify or write a Ruby script. It seems there >>>>>> are >>>>>> some issues with Ruby and ARM non-contiguous memory. >>>>>> >>>>>> Any suggestions on a place to start and route to take? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Roger >>>>>> >>>>>> -- >>>>>> >>>>>> _______________________________________________ >>>>>> gem5-dev mailing list >>>>>> [email protected] >>>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>>>> >>>>> >>>>> >>>>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>>>> are >>>>> >>>>> confidential and may also be privileged. If you are not the intended >>>>> recipient, please notify the sender immediately and do not disclose >>>>> the >>>>> >>>>> contents to any other person, use it for any purpose, or store or >>>>>copy >>>>> the information in any medium. Thank you. >>>>> >>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>>>> Registered in England & Wales, Company No: 2557590 >>>>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>>>> 9NJ, Registered in England & Wales, Company No: 2548782 >>>>> >>>>> _______________________________________________ >>>>> gem5-dev mailing list >>>>> [email protected] >>>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>> >>>> >>>> -- >>>> >>>> _______________________________________________ >>>> gem5-dev mailing list >>>> [email protected] >>>> http://m5sim.org/mailman/listinfo/gem5-dev >>>> >>> >>> >>> -- IMPORTANT NOTICE: The contents of this email and any attachments >>>are >>> confidential and may also be privileged. If you are not the intended >>> recipient, please notify the sender immediately and do not disclose >>>the >>> contents to any other person, use it for any purpose, or store or copy >>> >>> the information in any medium. Thank you. >>> >>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >>> Registered in England & Wales, Company No: 2557590 >>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 >>> 9NJ, Registered in England & Wales, Company No: 2548782 >>> >>> _______________________________________________ >>> gem5-dev mailing list >>> [email protected] >>> http://m5sim.org/mailman/listinfo/gem5-dev >> >> > > >-- > >_______________________________________________ >gem5-dev mailing list >[email protected] >http://m5sim.org/mailman/listinfo/gem5-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
