Discussion:
problem with read/write SYSFLAG register when caches turned on
(too old to reply)
Samuel Hitz
2012-07-11 07:35:41 UTC
Permalink
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 = {<FastAlloc> = {<No data fields>}, <Printable> = {_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 = <same as static member of an already seen type>,
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<LRU>::atomicAccess (this=0x38a03f0,
pkt=0x466a170) at build/ARM/mem/cache/cache_impl.hh:675
#12 0x0000000001971b6c in Cache<LRU>::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<LRU>::atomicAccess (this=0x399a180,
pkt=0x7fffffffc6f0) at build/ARM/mem/cache/cache_impl.hh:675
#18 0x0000000001971b6c in Cache<LRU>::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<AtomicSimpleCPU, unsigned int>
(xc=0x39020d0, traceData=0x0, mem=83890176, addr=4278190128, flags=163,
res=0x0)
at build/ARM/arch/generic/memhelpers.hh:84
#22 0x00000000008e7851 in writeMemAtomic<AtomicSimpleCPU, unsigned int>
(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
Ali Saidi
2012-07-11 22:15:25 UTC
Permalink
Post by Samuel Hitz
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
Post by Samuel Hitz
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
Post by Samuel Hitz
(gdb) p/x *pkt
$4 = {=
{},= {_vptr.Printable = 0x2020d30}, static PUBLIC_FLAGS = 0x0, static
PRIVATE_FLAGS = 0x7f0f,
Post by Samuel Hitz
static COPY_FLAGS = 0xf, static SHARED = 0x1,
static EXPRESS_SNOOP = 0x2, static SUPPLY_EXCLUSIVE = 0x4, static
MEM_INHIBIT = 0x8,
Post by Samuel Hitz
static VALID_ADDR = 0x100, static VALID_SIZE =
0x200, static VALID_SRC = 0x400, static VALID_DST = 0x800, static
STATIC_DATA = 0x1000,
Post by Samuel Hitz
static DYNAMIC_DATA = 0x2000, static ARRAY_DATA
= 0x4000, static SUPPRESS_FUNC_ERROR = 0x8000, flags = {_flags =
0x6700}, cmd = {
Post by Samuel Hitz
static commandInfo = 0x28ce780, cmd = 0x12}, req =
0x39024a0, data = 0x468b0d0, addr = 0xff000000, size = 0x40, src = 0x0,
dest = 0x2, origCmd = {
Post by Samuel Hitz
static commandInfo =, cmd = 0x0},
bytesValidStart = 0x0, bytesValidEnd = 0x0, time = 0x2495f27114,
finishTime = 0x2495f2e450, firstWordTime = 0x7fff000a6425, senderState =
0x0}
Post by Samuel Hitz
(gdb) p/x pkt->getAddr()
$5 = 0xff000000
(gdb) p/x
pkt->getSize()
Post by Samuel Hitz
$6 = 0x40
and a backtrace of whats happening
#0 RealViewCtrl::read (this=0x382c350, pkt=0x466a3f0) at
build/ARM/dev/arm/rv_ctrl.cc:54
Post by Samuel Hitz
#1 0x0000000001788b16 in
PioPort::recvAtomic (this=0x382c380, pkt=0x466a3f0) at
build/ARM/dev/io_device.cc:60
Post by Samuel Hitz
#2 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x38f9f50, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#3 0x0000000001885564 in Bus::recvAtomic
(this=0x38f9c60, pkt=0x466a3f0) at build/ARM/mem/bus.cc:566
Post by Samuel Hitz
#4
0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x38fa670,
pkt=0x466a3f0) at build/ARM/mem/bus.hh:105
Post by Samuel Hitz
#5 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x3813cf8, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#6 0x0000000001876d26 in
Bridge::BridgeSlavePort::recvAtomic (this=0x3813c38, pkt=0x466a3f0) at
build/ARM/mem/bridge.cc:413
Post by Samuel Hitz
#7 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x380be50, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#8 0x0000000001885564 in Bus::recvAtomic
(this=0x38125e0, pkt=0x466a3f0) at build/ARM/mem/bus.cc:566
Post by Samuel Hitz
#9
0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x36fc8e0,
pkt=0x466a3f0) at build/ARM/mem/bus.hh:105
Post by Samuel Hitz
#10 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x38f9140, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#11 0x0000000001969a2a in
Cache::atomicAccess (this=0x38a03f0, pkt=0x466a170) at
build/ARM/mem/cache/cache_impl.hh:675
Post by Samuel Hitz
#12 0x0000000001971b6c in
Cache::CpuSidePort::recvAtomic (this=0x38f8fc0, pkt=0x466a170) at
build/ARM/mem/cache/cache_impl.hh:1605
Post by Samuel Hitz
#13 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x38f9690, pkt=0x466a170) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#14 0x0000000001885564 in Bus::recvAtomic
(this=0x38f9490, pkt=0x466a170) at build/ARM/mem/bus.cc:566
Post by Samuel Hitz
#15
0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x38f9790,
pkt=0x466a170) at build/ARM/mem/bus.hh:105
Post by Samuel Hitz
#16 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x39f1f80, pkt=0x466a170) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#17 0x0000000001969a2a in
Cache::atomicAccess (this=0x399a180, pkt=0x7fffffffc6f0) at
build/ARM/mem/cache/cache_impl.hh:675
Post by Samuel Hitz
#18 0x0000000001971b6c in
Cache::CpuSidePort::recvAtomic (this=0x39f1df0, pkt=0x7fffffffc6f0) at
build/ARM/mem/cache/cache_impl.hh:1605
Post by Samuel Hitz
#19 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x39023d8, pkt=0x7fffffffc6f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
#20 0x000000000151ea11 in
AtomicSimpleCPU::writeMem (this=0x39020d0, data=0x7fffffffc84c "",
size=4, addr=4278190128, flags=163, res=0x0)
Post by Samuel Hitz
at
build/ARM/cpu/simple/atomic.cc:387
Post by Samuel Hitz
#21 0x00000000008e7938 in
writeMemTiming(xc=0x39020d0, traceData=0x0, mem=83890176,
addr=4278190128, flags=163, res=0x0)
Post by Samuel Hitz
at
build/ARM/arch/generic/memhelpers.hh:84
Post by Samuel Hitz
#22 0x00000000008e7851 in
writeMemAtomic(xc=0x39020d0, traceData=0x0, mem=@0x7fffffffc938:
83890176, addr=4278190128,
Post by Samuel Hitz
flags=163, res=0x0) at
build/ARM/arch/generic/memhelpers.hh:93
Post by Samuel Hitz
#23 0x000000000080532d in
ArmISAInst::STORE_IMM_AY_PN_SN_UN_WN_SZ4::execute (this=0x46a3200,
xc=0x39020d0, traceData=0x0)
Post by Samuel Hitz
at
build/ARM/arch/arm/generated/atomic_simple_cpu_exec.cc:27640
Post by Samuel Hitz
#24
0x000000000151f675 in AtomicSimpleCPU::tick (this=0x39020d0) at
build/ARM/cpu/simple/atomic.cc:494
Post by Samuel Hitz
#25 0x000000000151b028 in
AtomicSimpleCPU::TickEvent::process (this=0x3902360) at
build/ARM/cpu/simple/atomic.cc:72
Post by Samuel Hitz
#26 0x000000000145df30 in
EventQueue::serviceOne (this=0x28cc8c0) at build/ARM/sim/eventq.cc:204
Post by Samuel Hitz
#27 0x00000000014b2487 in simulate (num_cycles=9223372036854775807)
at build/ARM/sim/simulate.cc:73
Post by Samuel Hitz
It also doesn't work if I map in the
page containing the register as uncacheable.
Post by Samuel Hitz
Can someone with more
insight guess why this is happening? As I said with caches turned of the
same code works like a charm.
Post by Samuel Hitz
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
Samuel Hitz
2012-07-12 12:07:41 UTC
Permalink
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
Post by Samuel Hitz
**
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,
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-07-12 13:15:12 UTC
Permalink
Did one of them save/read it with caches disabled?

Ali

On
Post by Samuel Hitz
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
Post by Samuel Hitz
0x6401018
ldr r10, [pc, #16] ; 0x6401030
Post by Samuel Hitz
and this is whats at 0x6401030
0x6401030: 0x06427acc
Post by Samuel Hitz
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?
Post by Samuel Hitz
Best,
Samuel
On Thu, Jul 12,
Post by Ali Saidi
On
Post by Samuel Hitz
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
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
gem5.debug: build/ARM/dev/arm/rv_ctrl.cc:55: virtual
Tick RealViewCtrl::read(Packet*): Assertion `pkt->getSize() == 4'
failed.
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Here is a dump of the 'pkt' in question
(gdb) p/x
*pkt
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
$4 = {= {},= {_vptr.Printable = 0x2020d30}, static
PUBLIC_FLAGS = 0x0, static PRIVATE_FLAGS = 0x7f0f,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
static
COPY_FLAGS = 0xf, static SHARED = 0x1, static EXPRESS_SNOOP = 0x2,
static SUPPLY_EXCLUSIVE = 0x4, static MEM_INHIBIT = 0x8,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
static
VALID_ADDR = 0x100, static VALID_SIZE = 0x200, static VALID_SRC = 0x400,
static VALID_DST = 0x800, static STATIC_DATA = 0x1000,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
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 = {
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
static commandInfo =, cmd = 0x0}, bytesValidStart =
0x0, bytesValidEnd = 0x0, time = 0x2495f27114,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
finishTime =
0x2495f2e450, firstWordTime = 0x7fff000a6425, senderState = 0x0}
(gdb) p/x pkt->getAddr()
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
$5 = 0xff000000
(gdb) p/x
pkt->getSize()
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
$6 = 0x40
and a backtrace of whats
happening
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#0 RealViewCtrl::read (this=0x382c350,
pkt=0x466a3f0) at build/ARM/dev/arm/rv_ctrl.cc:54
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#1
0x0000000001788b16 in PioPort::recvAtomic (this=0x382c380,
pkt=0x466a3f0) at build/ARM/dev/io_device.cc:60
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#2
0x00000000018a1421 in MasterPort::sendAtomic (this=0x38f9f50,
pkt=0x466a3f0) at build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#3 0x0000000001885564
in Bus::recvAtomic (this=0x38f9c60, pkt=0x466a3f0) at
build/ARM/mem/bus.cc:566
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#4 0x000000000188b7ef in
Bus::BusSlavePort::recvAtomic (this=0x38fa670, pkt=0x466a3f0) at
build/ARM/mem/bus.hh:105
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#5 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x3813cf8, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#6 0x0000000001876d26 in
Bridge::BridgeSlavePort::recvAtomic (this=0x3813c38, pkt=0x466a3f0) at
build/ARM/mem/bridge.cc:413
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#7 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x380be50, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#8 0x0000000001885564 in Bus::recvAtomic
(this=0x38125e0, pkt=0x466a3f0) at build/ARM/mem/bus.cc:566
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#9
0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x36fc8e0,
pkt=0x466a3f0) at build/ARM/mem/bus.hh:105
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#10 0x00000000018a1421
in MasterPort::sendAtomic (this=0x38f9140, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#11 0x0000000001969a2a in
Cache::atomicAccess (this=0x38a03f0, pkt=0x466a170) at
build/ARM/mem/cache/cache_impl.hh:675
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#12 0x0000000001971b6c in
Cache::CpuSidePort::recvAtomic (this=0x38f8fc0, pkt=0x466a170) at
build/ARM/mem/cache/cache_impl.hh:1605
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#13 0x00000000018a1421
in MasterPort::sendAtomic (this=0x38f9690, pkt=0x466a170) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#14 0x0000000001885564 in Bus::recvAtomic
(this=0x38f9490, pkt=0x466a170) at build/ARM/mem/bus.cc:566
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#15
0x000000000188b7ef in Bus::BusSlavePort::recvAtomic (this=0x38f9790,
pkt=0x466a170) at build/ARM/mem/bus.hh:105
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#16 0x00000000018a1421
in MasterPort::sendAtomic (this=0x39f1f80, pkt=0x466a170) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#17 0x0000000001969a2a in
Cache::atomicAccess (this=0x399a180, pkt=0x7fffffffc6f0) at
build/ARM/mem/cache/cache_impl.hh:675
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#18 0x0000000001971b6c in
Cache::CpuSidePort::recvAtomic (this=0x39f1df0, pkt=0x7fffffffc6f0) at
build/ARM/mem/cache/cache_impl.hh:1605
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#19 0x00000000018a1421
in MasterPort::sendAtomic (this=0x39023d8, pkt=0x7fffffffc6f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#20 0x000000000151ea11 in
AtomicSimpleCPU::writeMem (this=0x39020d0, data=0x7fffffffc84c "",
size=4, addr=4278190128, flags=163, res=0x0)
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
at
build/ARM/cpu/simple/atomic.cc:387
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#21 0x00000000008e7938 in
writeMemTiming(xc=0x39020d0, traceData=0x0, mem=83890176,
addr=4278190128, flags=163, res=0x0)
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
at
build/ARM/arch/generic/memhelpers.hh:84
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#22 0x00000000008e7851 in
writeMemAtomic(xc=0x39020d0, traceData=0x0, mem=@0x7fffffffc938:
83890176, addr=4278190128,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
flags=163, res=0x0) at
build/ARM/arch/generic/memhelpers.hh:93
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#23 0x000000000080532d in
ArmISAInst::STORE_IMM_AY_PN_SN_UN_WN_SZ4::execute (this=0x46a3200,
xc=0x39020d0, traceData=0x0)
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
at
build/ARM/arch/arm/generated/atomic_simple_cpu_exec.cc:27640
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#24
0x000000000151f675 in AtomicSimpleCPU::tick (this=0x39020d0) at
build/ARM/cpu/simple/atomic.cc:494
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#25 0x000000000151b028 in
AtomicSimpleCPU::TickEvent::process (this=0x3902360) at
build/ARM/cpu/simple/atomic.cc:72
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#26 0x000000000145df30 in
EventQueue::serviceOne (this=0x28cc8c0) at build/ARM/sim/eventq.cc:204
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#27 0x00000000014b2487 in simulate (num_cycles=9223372036854775807)
at build/ARM/sim/simulate.cc:73
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
It also doesn't work if I map
in the page containing the register as uncacheable.
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Can someone
with more insight guess why this is happening? As I said with caches
turned of the same code works like a charm.
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
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?
Post by Samuel Hitz
Post by Ali Saidi
Thanks,
Ali
_______________________________________________
Post by Samuel Hitz
Post by Ali Saidi
gem5-users mailing
list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2]




Links:
------
[1] mailto:gem5-***@gem5.org
[2]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[3]
mailto:***@umich.edu
Samuel Hitz
2012-07-12 13:17:40 UTC
Permalink
Yes the newly booted core reads it before caches get enabled. Shouldn't it
be going to memory then instead?
Post by Ali Saidi
**
Did one of them save/read it with caches disabled?
Ali
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
Post by Samuel Hitz
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,
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Ali Saidi
2012-07-12 13:33:21 UTC
Permalink
that is an issue. One of them has the data in a core cache and the
other is going to DRAM to get it. There are two options.

(1) Map the
storage location as uncacheable, so both cores always go to DRAM.

(2)
Implement the addrBootUncacheable() function in your system class (I
assume you've got a BarrelFishArmSystem class). This class checks
certain known symbols and make them uncacheable until linux all caches
are enabled.

Ali
Post by Samuel Hitz
Yes the
newly booted core reads it before caches get enabled. Shouldn't it be
going to memory then instead?
Post by Samuel Hitz
On Thu, Jul 12, 2012 at 3:15 PM, Ali
Post by Ali Saidi
Did one of them save/read it
with caches disabled?
Post by Samuel Hitz
Post by Ali Saidi
Ali
On 12.07.2012 08:07, Samuel
Post by Samuel Hitz
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
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
0x6401018 ldr r10, [pc, #16] ;
0x6401030
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
and this is whats at 0x6401030
0x06427acc
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
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?
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Best,
Samuel
On Thu, Jul
Post by Ali Saidi
Post by Samuel Hitz
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
build/ARM/dev/arm/rv_ctrl.cc:55: virtual Tick
RealViewCtrl::read(Packet*): Assertion `pkt->getSize() == 4' failed.
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Here is a dump of the 'pkt' in question
(gdb) p/x
*pkt
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
$4 = {= {},= {_vptr.Printable = 0x2020d30}, static
PUBLIC_FLAGS = 0x0, static PRIVATE_FLAGS = 0x7f0f,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
static
COPY_FLAGS = 0xf, static SHARED = 0x1, static EXPRESS_SNOOP = 0x2,
static SUPPLY_EXCLUSIVE = 0x4, static MEM_INHIBIT = 0x8,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
static
VALID_ADDR = 0x100, static VALID_SIZE = 0x200, static VALID_SRC = 0x400,
static VALID_DST = 0x800, static STATIC_DATA = 0x1000,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
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 = {
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
static commandInfo =, cmd = 0x0}, bytesValidStart =
0x0, bytesValidEnd = 0x0, time = 0x2495f27114,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
finishTime
= 0x2495f2e450, firstWordTime = 0x7fff000a6425, senderState = 0x0}
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
(gdb) p/x pkt->getAddr()
$5 = 0xff000000
(gdb) p/x
pkt->getSize()
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
$6 = 0x40
and a backtrace of whats
happening
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#0 RealViewCtrl::read (this=0x382c350,
pkt=0x466a3f0) at build/ARM/dev/arm/rv_ctrl.cc:54
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#1
0x0000000001788b16 in PioPort::recvAtomic (this=0x382c380,
pkt=0x466a3f0) at build/ARM/dev/io_device.cc:60
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#2
0x00000000018a1421 in MasterPort::sendAtomic (this=0x38f9f50,
pkt=0x466a3f0) at build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#3 0x0000000001885564
in Bus::recvAtomic (this=0x38f9c60, pkt=0x466a3f0) at
build/ARM/mem/bus.cc:566
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#4 0x000000000188b7ef in
Bus::BusSlavePort::recvAtomic (this=0x38fa670, pkt=0x466a3f0) at
build/ARM/mem/bus.hh:105
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#5 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x3813cf8, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#6 0x0000000001876d26 in
Bridge::BridgeSlavePort::recvAtomic (this=0x3813c38, pkt=0x466a3f0) at
build/ARM/mem/bridge.cc:413
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#7 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x380be50, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#8 0x0000000001885564 in
Bus::recvAtomic (this=0x38125e0, pkt=0x466a3f0) at
build/ARM/mem/bus.cc:566
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#9 0x000000000188b7ef in
Bus::BusSlavePort::recvAtomic (this=0x36fc8e0, pkt=0x466a3f0) at
build/ARM/mem/bus.hh:105
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#10 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x38f9140, pkt=0x466a3f0) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#11 0x0000000001969a2a in
Cache::atomicAccess (this=0x38a03f0, pkt=0x466a170) at
build/ARM/mem/cache/cache_impl.hh:675
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#12 0x0000000001971b6c in
Cache::CpuSidePort::recvAtomic (this=0x38f8fc0, pkt=0x466a170) at
build/ARM/mem/cache/cache_impl.hh:1605
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#13
0x00000000018a1421 in MasterPort::sendAtomic (this=0x38f9690,
pkt=0x466a170) at build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#14
0x0000000001885564 in Bus::recvAtomic (this=0x38f9490, pkt=0x466a170) at
build/ARM/mem/bus.cc:566
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#15 0x000000000188b7ef in
Bus::BusSlavePort::recvAtomic (this=0x38f9790, pkt=0x466a170) at
build/ARM/mem/bus.hh:105
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#16 0x00000000018a1421 in
MasterPort::sendAtomic (this=0x39f1f80, pkt=0x466a170) at
build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#17 0x0000000001969a2a in
Cache::atomicAccess (this=0x399a180, pkt=0x7fffffffc6f0) at
build/ARM/mem/cache/cache_impl.hh:675
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#18 0x0000000001971b6c in
Cache::CpuSidePort::recvAtomic (this=0x39f1df0, pkt=0x7fffffffc6f0) at
build/ARM/mem/cache/cache_impl.hh:1605
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#19
0x00000000018a1421 in MasterPort::sendAtomic (this=0x39023d8,
pkt=0x7fffffffc6f0) at build/ARM/mem/port.cc:111
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#20
0x000000000151ea11 in AtomicSimpleCPU::writeMem (this=0x39020d0,
data=0x7fffffffc84c "", size=4, addr=4278190128, flags=163, res=0x0)
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
at build/ARM/cpu/simple/atomic.cc:387
#21
0x00000000008e7938 in writeMemTiming(xc=0x39020d0, traceData=0x0,
mem=83890176, addr=4278190128, flags=163, res=0x0)
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
at
build/ARM/arch/generic/memhelpers.hh:84
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#22 0x00000000008e7851 in
writeMemAtomic(xc=0x39020d0, traceData=0x0, mem=@0x7fffffffc938:
83890176, addr=4278190128,
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
flags=163, res=0x0) at
build/ARM/arch/generic/memhelpers.hh:93
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#23 0x000000000080532d in
ArmISAInst::STORE_IMM_AY_PN_SN_UN_WN_SZ4::execute (this=0x46a3200,
xc=0x39020d0, traceData=0x0)
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
at
build/ARM/arch/arm/generated/atomic_simple_cpu_exec.cc:27640
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#24
0x000000000151f675 in AtomicSimpleCPU::tick (this=0x39020d0) at
build/ARM/cpu/simple/atomic.cc:494
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#25 0x000000000151b028 in
AtomicSimpleCPU::TickEvent::process (this=0x3902360) at
build/ARM/cpu/simple/atomic.cc:72
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#26 0x000000000145df30 in
EventQueue::serviceOne (this=0x28cc8c0) at build/ARM/sim/eventq.cc:204
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
#27 0x00000000014b2487 in simulate
(num_cycles=9223372036854775807) at build/ARM/sim/simulate.cc:73
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
It also doesn't work if I map in the page containing the register
as uncacheable.
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Can someone with more insight guess why this is
happening? As I said with caches turned of the same code works like a
charm.
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
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?
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
Thanks,
Ali
_______________________________________________
Post by Samuel Hitz
Post by Ali Saidi
Post by Samuel Hitz
Post by Ali Saidi
gem5-users mailing
list
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [2]




Links:
------
[1] mailto:gem5-***@gem5.org
[2]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[3]
mailto:***@umich.edu
[4] mailto:***@umich.edu
Samuel Hitz
2012-07-12 13:44:11 UTC
Permalink
Shouldn't it just work (it doesn't I tried) if I enable the caches before
reading this location or is the cache virtually addressed?

The problem with approach 1) and 2) is that the kernel gets dynamically
loaded and relocated in memory so I don't know, which storage location I
should map as uncacheable respectively make the uncacheable with the
addrBootUncacheable() function (which would also not work if you try to run
this code on the PandaBoard for example).
**
that is an issue. One of them has the data in a core cache and the other
is going to DRAM to get it. There are two options.
(1) Map the storage location as uncacheable, so both cores always go to
DRAM.
(2) Implement the addrBootUncacheable() function in your system class (I
assume you've got a BarrelFishArmSystem class). This class checks certain
known symbols and make them uncacheable until linux all caches are enabled.
Ali
Yes the newly booted core reads it before caches get enabled. Shouldn't it
be going to memory then instead?
Post by Ali Saidi
Did one of them save/read it with caches disabled?
Ali
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
Post by Samuel Hitz
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,
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
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Loading...