I agree with Hoa that you're using virtual addresses, and those are
unrelated to the physical addresses you're trying to access. The second
method is probably moving an immediate constant into the register, and not
loading from a memory address. mmap-ing the physical pages you're
interested in woul
Hi Andreas,
My guess is that for Method 1, the pointer is of a virtual address so
there's a page fault there.
I'm not sure why the write() function wasn't invoked on Method 2. I got
into the same problem recently where I used mmap() to write to a physical
address, which should be handled by a Pio
Hi all,
I implemented a device using the BasicPioDevice class but I can't seem to get
the read() & write() calls to work.
I assigned a pioAddr=0x2 and a pioSize=4096 and I try to write to the
device directly using these two methods:
Method 1:
---
uint32_t inp_params2 = 14;
uin
Yes, I understood this is what you meant. The point I was trying to make
is I have not examined a trace to see what is actually happening (have you
gotten a trace to examine what's happening with the DataBlk value for this
request?). After digging in a little further, it appears that this line:
h
Hi Matt,
The following condition is missing in t_allocateTBE, but the corepair sends
a message with VicDirty - CoherenceRequestType.
if (in_msg.Type == CoherenceRequestType:VicDirty) {
tbe.DataBlk = in_msg.DataBlk;
}
P.S.: I am not sure whether the complete block should be replaced or just
par
(Resending to mailing list)
Hi Sampad,
There are lines directly below the one I pointed to that do potentially
overwrite the data there. But I am not 100% sure -- Brad and Matt P, CC'd
may know better or see something I'm missing.
Matt
On Sat, Oct 23, 2021 at 1:37 PM Sampad Mohapatra wrote:
I am not sure I understand completely what you're getting at, but it
appears the allocation of the TBE entry does store the data:
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm#878
Matt
On Thu, Oct 21, 2021 at 11:08 PM Sampad Mohapatra v
