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 <start+24> ldr r10, [pc, #16] ; 0x6401030 <halt+8> and this is whats at 0x6401030 0x6401030 <halt+8>: 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
