I'm using PIC32MZ2048EFG100, MPLAB X IDE(v5.00), Harmony(V2.06) and ICD 3 debugger.
In my project, I've configured the address 0x9D100000 (up to 432KBytes) for NVM operations to store some data.
To verify the NVM operation, I'm just doing NVM operation for the first block only. i.e address 0x9D100000.
I've erased(16KBytes) the 0th block(address 0x9D100000) and I read device memory and the result is correct. i.e all 0xFF values.
Now I'll write(2Kbytes) into this memory(address 0x9D100000) using 2Kbytes buffer which is set to value 0x55.
After writing, if I read device memory, only some of the addresses will be set with the value 0x55 and the rest of the memory will be set with the 0x00 value.
Why this memory is getting corrupted?
Please help me to know the details to resolve the issue.
Thank you
Related
I am trying to read/write a memory in EL2, but it doesn't return what I want.
I use kzalloc to get initialized space, then use str to write a number (0x12345678) in this space.
Next, I use __pa() to get the physical address(PA) of this space. I found PA=VA-0x80000000. I will send this PA to EL2 for reading, so I put it into one register(r1)
Third step is call hvc, after calling hvc it is in EL2. I have created a branch in hyp_stub_vectors (in arch/arm/kernel/hyp-stub.S, I am sure this file will handler hvc ), and used ldr to read this memory space to get my number.
But it failed.
I guess possible reasons are
I got a wrong physical address with __pa(). But I have walked the aarch32 stage-1 translation and got the same address, actually this space is a block, so it's OK to delete an offset to get the physical address.
in EL2 it still has address translation. But I checked some related system register and found the MMU in EL2 is disable. Possibly I checked a wrong register?
My device is Raspberry Pi 3B+, Cortex-A53
The problem may be related to cache incoherence. Given that your EL2 is running with MMU disabled, it also has data cache disabled, as stated in this paper. This means that to access a memory location in EL2 you need to get the value into RAM.
To achieve this, you can use the dc civac, x0 instruction, with x0 being a virtual address of the variable. This will flush the cache line with your variable and write the value into RAM.
P.S. To verify whether your PA is correct, read the value at __va(__pa(addr)) and make sure that it's the same.
I have an Intel FPGA PCIe endpoint. It shows up correctly in lspci and all of the lspci -vv information looks correct (memory map, IRQ, BAR0 size all look OK). I want to stream some data over BAR0 and read/write status registers inside of my IP. My host machine has an Intel x86_64 CPU and running a Debian OS.
What I"m currently doing is this:
open() call to /sys/class/uio/uio0/device/resource0 -> returns a file descriptor.
mmap 4 KB on that file descriptor with PROT_READ + PROT_WRITE protection, and MAP_SHARED flags. Offset is 0. --> returns a pointer.
In a loop, set offsets relative to the pointer to random numbers. Do this for ~1000 bytes, 4 bytes at a time. After each write to the pointer, call msync.
Read back the pointer one DWORD at a time.
Read back the pointer in bulk using memcpy.
The outcome of step #4 is that most of the data looks correct, but some is not (which is strange). The outcome of number 5 is that I get 0xffff_ffff for everything, which is even stranger.
If I try to replace step #3 with a single memset / msync sequence, the program hangs for a little while and then returns a bus error. After this, lspci states that BAR0 is disabled and I can no longer interact with it.
Any ideas what I'm doing wrong? It could be a HW issue, but the HW is really simple right now. I configured the FPGA to act purely as a slave device, with its read response being the registered write data coming across the BAR0 interface. The IP I am working with only has a read-response-valid line (no write response valid, somehow) which I have hard-coded to 1. Seems that burst sizes more than 1 cause some kinds of issues with the PCIe core as seen in the memcpy/memset issues, but I don't see why that would be the case.
EDIT/UPDATE:
I was able to work around this. Supposedly the MMIO is only for 32b, so writing a loop that access the pointer 32b at a time is the solution here.
I'm trying to find current flag count in KMines by using gdb. I know that I should look for memory mappings first to avoid non-existent memory locations. So I ran info proc mappings command to see the memory segments. I picked up a random memory gap (0xd27000-0x168b000) from the result and executed the find command like this: find 0x00d27000, 0x0168b000, 10
But I got the warning: Unable to access 1458 bytes of target memory at 0x168aa4f, halting search. error. Although the address 0x168aa4f is between 0xd27000 and 0x168b000, gdb says that it can't access to it. Why does this happen? What can I do to avoid this situation? Or is there a way to ignore unmapped/unaccessible memory locations?
Edit: I tried to set the value of the address 0x168aa4f to 1 and it works, so gdb can actually access that address but gives error when used with the find command. But why?
I guess I have solved my own problem, I can't believe how simple the solution was. The only thing I did was to decrease the 2nd parameter's value by one. So the code should be find 0x00d27000, 0x0168afff, 10 because linux allocates the memory by using maps in [x,y) format, so if the line in root/proc/pid/maps says something like this;
01a03000-0222a000 rw-p
The memory allocated includes 0x01a03000 but not 0x0222a000. Hope this silly mistake of mine helps someone :D
Edit: The root of the problem is the algorithm implemented in target.c(gdb's source code I mean) the algorithm reads and searches the memory as chunks at the size of 16000 bytes. So even if the last byte of the chunk is invalid, gdb will throw the entire chunk into the trash and won't even give any proper information about the invalid byte, it only reports the beginning of the current chunk.
I'm using Intel's Pin Tool to do some binary instrumentation, and was wondering if there an API to get the instruction byte code at a given address.
Something like:
instruction = getInstructionatAddr(addr);
where addr is the desired address.
I know the function Instruction (used in many of the simple/manual examples) given by Pin gets the instruction, but I need to know the instructions at other addresses. I perused the web with no avail. Any help would be appreciated!
CHEERS
wondering if there an API to get the instruction byte code at a given
address
Yes, it's possible but in a somewhat contrived way: with PIN you are usually interested in what is executed (or manipulated through the executed instructions), so everything outside the code / data flow is not of any interest for PIN.
PIN is using (and thus ships with) Intel XED which is an instruction encoder / decoder.
In your PIN installation you should have and \extra folder with two sub-directories: xed-ia32 and xed-intel64 (choose the one that suits your architecture). The main include file for XED is xed-interface.h located in the \include folder of the aforementioned directories.
In your Pintool, given any address in the virtual space of your pintooled program, use the PIN_SafeCopy function to read the program memory (and thus bytes at the given address). The advantage of PIN_SafeCopy is that it fails graciously even if it can't read the memory, and can read "shadowed" parts of the memory.
Use XED to decode the instruction bytes for you.
For an example of how to decode an instruction with XED, see the first example program.
As the small example uses an hardcoded buffer (namely itext in the example program), replace this hardcoded buffer with the destination buffer you used in PIN_SafeCopy.
Obviously, you should make sure that the memory you are reading really contains code.
AFAIK, it is not possible to get an INS type (the usual type describing an instruction in PIN) from an arbitrary address as only addresses in the code flow will "generate" an INS type.
As a side note:
I know the function Instruction (used in many of the simple/manual
examples) given by Pin gets the instruction
The Instruction routine used in many PIN example is called an "Instrumentation routine": its name is not relevant in itself.
Pin_SafeCopy may help you. This API could copy memory content from the address space of target process to one specified buffer.
This is question on JTAG.
I am trying to set a read/write breakpoint in a range of addresses.
Command I give in b.set window is as follows(and selecting read/write)
A:0x8500000..0xd300000
But when i list it(b.list) it shows as follows :
AN:0x0:0x8500000--0xd300000
Why is 0x0 getting appended? So, is my original range of addresses at which i wanted to put the breakpoint is altered?
Additional Information : I am using Lauterbach Trace 32. CPU is ARm Krait
Thank you.
0x00 is the space ID. It is 0 for complete kernel space. For User spaces this space id is the process ID. Space Id's are nothing but Address space identifiers, used by TLB to differentiate the pagetable ebtries.