Hi Sebastian, It's hard to say which MemObject received the packet where the flag cacheResponding was set. In typical Arm systems (not very different from the one you have), packets with cacheResponding set would stop at the CoherentXBar which has the point_of_coherence parameter set (configuration parameter). In your system, I would start by making sure that MemBus has point_of_coherence set.
Nikos On 27/07/2018, 08:55, "gem5-users on behalf of Sebastian Rachuj" <[email protected] on behalf of [email protected]> wrote: Dear All, I am using gem5 with a self-written operating system (actually bare metal) for AArch64 and some custom SystemC modules, I connected using the ExternalSlave/TLM port. The dot plot of the config is attached. When only running one CPU core (that means that the other core is spinning in an endless loop) it works fine. All my bare-metal programs are running without any errors. However, when I also have a more complex program running on the second core, gem5 fails with panic: panic condition pkt->cacheResponding() occurred: Should not see packets where cache is responding I found out that this error occurs due to an express snoop going to the bridge's slave port. My assumption is that I somehow have to configure the connection from the membus (actually only a coherent XBar) to the bridge in a way that stops snoop packets from getting forwarded to the bridge. Unfortunately, I have no idea how this works or if this means implementing a coherent bridge. Additionally, I tried some other topologies of the XBars like directly connecting the IOBus (non-coherent XBar) to the MemBus (coherent XBar). However, then it fails with panic: system.iobus.slave[0] was not expecting a tryTiming Connecting the ExternalSlave directly to the MemBus does not work neither due to the same error: panic: system.tlm.port was not expecting a tryTiming When changing the MemBus to a non-coherent XBar, the following assertion fails: design: build/ARM/mem/noncoherent_xbar.cc:110: virtual bool NoncoherentXBar::recvTimingReq(PacketPtr, PortID): Assertion `!pkt->isExpressSnoop()' failed. Is my approach for connecting an ExternalSlave to the processor system even the correct one or do I have to do it in a different way? The gem5 commit I'm currently working on (with some changes to debug my problem with software traps) is 0473286ab1e9992a906eff380000bf90c82eeccb. Any help is appreciated. Best Regards, Sebastian Rachuj 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. _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
