Yes the newly booted core reads it before caches get enabled. Shouldn't it be going to memory then instead?
On Thu, Jul 12, 2012 at 3:15 PM, Ali Saidi <[email protected]> wrote: > ** > > 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]> 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] >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
