Shared memory problem in a software AMP configuration
I believe this is not the right forum to discuss this issue, but since the problem is interesting to share (and I think will be a good read for the geeks) as well as just to get some ideas as I have ran just out of ideas. I am having issue in reading the shared memory in a software amp configuration. Given is my system,
Its an embedded board PowerPC architecture having a dual core P1022 process (e500 cores – P1022RDK – 512 MB shared memory). I am running the system in soft AMP configuration. I am loading one linux kernel on core 0 and another linux kernel on core 1. All the hardware is perfectly partitioned among both cores. I have allocated initial some MBs of memory to core 0 and rest of some MBs to core 1 kernel, and small portion of memory is shared among both cores for IPC.
Now my problem is when I write (a simple c code which mmap shared memory to userspace) say a simple string from core 1 and read at core 0 and it get what it is supposed to get from core 1 over shared memory. But when I write from core 0 and read from core 1 it did not get what it should, but just empty / garbage memory.
In the above situation I have verified some things which makes this problem more interesting. 1: With core 0 running linux, and core 1 running baremetal application and with the help of probe I have verified core 0 is writing to correct shared memory area as I can see my string in the shared memory from core 1 (probe debugging the core1). So the problem is at reading end of the core 1. 2: My same application (the reader / writer) works perfect on another dev kit of the same processor (& cores – P1022DS – 2GB total memory) in the same amp configuration. 3: The ‘M’ bit of page data is also set at both ends (to ensure memory coherency)4: I also did a sync instruction just after write operation from core 0 just to make sure processor writes it to memory when it should but #1 confirms this also as it has written to the shared memory. 5: I think this is confirmed that the problem lies in the core 1 kernel and after looking into many things I am clueless where the problem can be (i.e in which area of the kernel).
Please share with me any idea came to your mind26 days agoLike CommentFollow Flag More5 comments Follow VijayVijay Anand • You could use a JTAG debugger (EJTAG for MIPS, don’t know the equivalent for PowerPC) to check if core0 write is visible .25 days ago• Like Follow FarrukhFarrukh Arshad • Yes, I have verified with CodeWarrior USB Tap core0 write is visible on the shared memory from core 1, but in this case I am running baremetal application on core 1 and not the linux kernel. So far I am unable to debug the Core1 linux kernel with the probe as the booting of both kernels in this AMP configuration is does not seems to be supported by the probe initialization as well as CodeWarrior IDE.24 days ago• Like Follow VijayVijay Anand • if i understand correctly, when core1 is loaded with bare metal app , core1 is able to view the core0 updates to shared memory , but when core1 is loaded with linux(instead of baremetal app) it is not able to view the core0 updates. if this is correct, then there could be a problem with the shared memory address being referred in the linux side. The mmap maynot be pointing to the correct physical address offset.22 days ago• Like Follow FarrukhFarrukh Arshad • Yes you got it right, and thats my conclusion as well so far.22 days ago• Like Follow Pradeep kumarPradeep kumar Nallimelli • What happens the other way around i.e. core 1 writes and core 0 reads. If this not works, we can get a data point that shared memory is actually not shared atleast the addresses being used.. (references are not correct). I assume when you say shared memory that is the bootmem allocated by the bootloader upfront before the linux comes up. How is the addressing happens here (something like XKPHYS in MIPS for the global memory…). Make use virt_to_phys and phys_to_virt mappings being happened at right places..