Did one of them save/read it with caches disabled?
Ali On 12.07.2012 08:07, Samuel Hitz wrote: > Ok I digged a little deeper now. The problem isn't the SYSFLAG register anymore, the second core gets booted. However I save right at the beginning the base of the .got section in r10. This is the instruction which achieves this > 0x6401018 ldr r10, [pc, #16] ; 0x6401030 > and this is whats at 0x6401030 > > 0x6401030: 0x06427acc > which is indeed the address of the .got section. The problem is that after this instruction r10 contains 0 with caches enabled and the real value if I disable caches. I traced cache accesses and I didn't give me any clues. You said once that Gem5 handles cache coherency on it's own. Do you have any ideas how this can happen and what I could do to fix it? > Best, > Samuel > > On Thu, Jul 12, 2012 at 12:15 AM, Ali Saidi <[email protected] [3]> wrote: > >> On 11.07.2012 03:35, Samuel Hitz wrote: >> >>> Hi there, >>> I have a problem reading/writing to the SYSFLAG register when caches are turned on. I wan to write the entry point for the new core in there, which works fine when caches are turned of. However when caches are turned on I get >>> >>> gem5.debug: build/ARM/dev/arm/rv_ctrl.cc:55: virtual Tick RealViewCtrl::read(Packet*): Assertion `pkt->getSize() == 4' failed. >>> Here is a dump of the 'pkt' in question >>> >>> (gdb) p/x *pkt >>> $4 = {= {},= {_vptr.Printable = 0x2020d30}, static PUBLIC_FLAGS = 0x0, static PRIVATE_FLAGS = 0x7f0f, >>> >>> static COPY_FLAGS = 0xf, static SHARED = 0x1, static EXPRESS_SNOOP = 0x2, static SUPPLY_EXCLUSIVE = 0x4, static MEM_INHIBIT = 0x8, >>> static VALID_ADDR = 0x100, static VALID_SIZE = 0x200, static VALID_SRC = 0x400, static VALID_DST = 0x800, static STATIC_DATA = 0x1000, >>> static DYNAMIC_DATA = 0x2000, static ARRAY_DATA = 0x4000, static SUPPRESS_FUNC_ERROR = 0x8000, flags = {_flags = 0x6700}, cmd = { >>> static commandInfo = 0x28ce780, cmd = 0x12}, req = 0x39024a0, data = 0x468b0d0, addr = 0xff000000, size = 0x40, src = 0x0, dest = 0x2, origCmd = { >>> static commandInfo =, cmd = 0x0}, bytesValidStart = 0x0, bytesValidEnd = 0x0, time = 0x2495f27114, >>> >>> finishTime = 0x2495f2e450, firstWordTime = 0x7fff000a6425, senderState = 0x0} >>> (gdb) p/x pkt->getAddr() >>> $5 = 0xff000000 >>> (gdb) p/x pkt->getSize() >>> $6 = 0x40 >>> >>> and a backtrace of whats happening >>> >>> #0 RealViewCtrl::read (this=0x382c350, pkt=0x466a3f0) at build/ARM/dev/arm/rv_ctrl.cc:54 >>> #1 0x0000000001788b16 in PioPort::recvAtomic (this=0x382c380, pkt=0x466a3f0) at build/ARM/dev/io_device.cc:60 >>> #2 0x00000000018a1421 in MasterPort::sendAtomic (this=0x38f9f50, pkt=0x466a3f0) at build/ARM/mem/port.cc:111 >>> #3 0x0000000001885564 in Bus::recvAtomic (this=0x38f9c60, pkt=0x466a3f0) at build/ARM/mem/bus.cc:566 >>> #4 0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x38fa670, pkt=0x466a3f0) at build/ARM/mem/bus.hh:105 >>> #5 0x00000000018a1421 in MasterPort::sendAtomic (this=0x3813cf8, pkt=0x466a3f0) at build/ARM/mem/port.cc:111 >>> #6 0x0000000001876d26 in Bridge::BridgeSlavePort::recvAtomic (this=0x3813c38, pkt=0x466a3f0) at build/ARM/mem/bridge.cc:413 >>> #7 0x00000000018a1421 in MasterPort::sendAtomic (this=0x380be50, pkt=0x466a3f0) at build/ARM/mem/port.cc:111 >>> #8 0x0000000001885564 in Bus::recvAtomic (this=0x38125e0, pkt=0x466a3f0) at build/ARM/mem/bus.cc:566 >>> #9 0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x36fc8e0, pkt=0x466a3f0) at build/ARM/mem/bus.hh:105 >>> #10 0x00000000018a1421 in MasterPort::sendAtomic (this=0x38f9140, pkt=0x466a3f0) at build/ARM/mem/port.cc:111 >>> #11 0x0000000001969a2a in Cache::atomicAccess (this=0x38a03f0, pkt=0x466a170) at build/ARM/mem/cache/cache_impl.hh:675 >>> #12 0x0000000001971b6c in Cache::CpuSidePort::recvAtomic (this=0x38f8fc0, pkt=0x466a170) at build/ARM/mem/cache/cache_impl.hh:1605 >>> >>> #13 0x00000000018a1421 in MasterPort::sendAtomic (this=0x38f9690, pkt=0x466a170) at build/ARM/mem/port.cc:111 >>> #14 0x0000000001885564 in Bus::recvAtomic (this=0x38f9490, pkt=0x466a170) at build/ARM/mem/bus.cc:566 >>> #15 0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x38f9790, pkt=0x466a170) at build/ARM/mem/bus.hh:105 >>> #16 0x00000000018a1421 in MasterPort::sendAtomic (this=0x39f1f80, pkt=0x466a170) at build/ARM/mem/port.cc:111 >>> #17 0x0000000001969a2a in Cache::atomicAccess (this=0x399a180, pkt=0x7fffffffc6f0) at build/ARM/mem/cache/cache_impl.hh:675 >>> #18 0x0000000001971b6c in Cache::CpuSidePort::recvAtomic (this=0x39f1df0, pkt=0x7fffffffc6f0) at build/ARM/mem/cache/cache_impl.hh:1605 >>> >>> #19 0x00000000018a1421 in MasterPort::sendAtomic (this=0x39023d8, pkt=0x7fffffffc6f0) at build/ARM/mem/port.cc:111 >>> #20 0x000000000151ea11 in AtomicSimpleCPU::writeMem (this=0x39020d0, data=0x7fffffffc84c "", size=4, addr=4278190128, flags=163, res=0x0) >>> at build/ARM/cpu/simple/atomic.cc:387 >>> #21 0x00000000008e7938 in writeMemTiming(xc=0x39020d0, traceData=0x0, mem=83890176, addr=4278190128, flags=163, res=0x0) >>> at build/ARM/arch/generic/memhelpers.hh:84 >>> #22 0x00000000008e7851 in writeMemAtomic(xc=0x39020d0, traceData=0x0, mem=@0x7fffffffc938: 83890176, addr=4278190128, >>> >>> flags=163, res=0x0) at build/ARM/arch/generic/memhelpers.hh:93 >>> #23 0x000000000080532d in ArmISAInst::STORE_IMM_AY_PN_SN_UN_WN_SZ4::execute (this=0x46a3200, xc=0x39020d0, traceData=0x0) >>> at build/ARM/arch/arm/generated/atomic_simple_cpu_exec.cc:27640 >>> #24 0x000000000151f675 in AtomicSimpleCPU::tick (this=0x39020d0) at build/ARM/cpu/simple/atomic.cc:494 >>> #25 0x000000000151b028 in AtomicSimpleCPU::TickEvent::process (this=0x3902360) at build/ARM/cpu/simple/atomic.cc:72 >>> #26 0x000000000145df30 in EventQueue::serviceOne (this=0x28cc8c0) at build/ARM/sim/eventq.cc:204 >>> #27 0x00000000014b2487 in simulate (num_cycles=9223372036854775807) at build/ARM/sim/simulate.cc:73 >>> >>> It also doesn't work if I map in the page containing the register as uncacheable. >>> Can someone with more insight guess why this is happening? As I said with caches turned of the same code works like a charm. >>> Best, >>> Samuel >> >> Hi Samuel, >> >> I don't think you're managing to actually mark the page as uncachable. The read that you're doing is actually causing the cache to fetch 64 bytes from the device, which is the cause of the issue. If you've updated the translation in memory, have you flushed the TLB? >> >> Thanks, >> >> Ali >> >> _______________________________________________ >> gem5-users mailing list >> [email protected] [1] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2] Links: ------ [1] mailto:[email protected] [2] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [3] mailto:[email protected]
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
