Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 329 subscribers
  • Views 2419 views
  • Users 0 members are here
Related

Writing to OCM through the Xilinx OCM driver

henry10210

Hello everyone, thanks in advance for reading my question on how to access OCM in a userspace Linux app.  Please excuse any ignorance derived questions.  I am having problem writing to OCM.

My kernel creates the OCM driver during bootup, as I see this line in dmesg:

zynq-ocm f800c000.ps7-ocmc: ZYNQ OCM pool: 256 KiB @ 0xe0880000

The OCM controller registers are at f800c000, but the OCM itself will be either at either 0x0 or 0xFFFC0000 (physical address mapping) depending on whether OCM_CFG[RAM_HI] is 0 or 1 (0 on PoR according to Zynq TRM chapter 29 and OCM_CFG register detail).  The Xilinx driver dmesg output is a bit confusing because 0xe0880000 is the kernel virtual address (result of ioremap).  I am opening /dev/mem and then mmap() the whole 256 KB, but I don't know what address I should pass to mmap.

I tried 0x0: program hangs.  I would guess that I have overwritten ISR vectors!?

I tried 0xe0880000, and the program prints:

Unhandled fault: external abort on non-linefetch (0x818) at 0xb6c06000
Bus error

I tried 0xFFFC0000, and the program usually succeeds (what I read matches what I wrote).

I somehow doubt that the OCM is at 0xFFFC000 (but I can check tomorrow by modifying the OCM driver verbosity).  But even if it is at that address, how can I actually check that what I wrote wound up at the OCM?  I was thinking about reading the memory in the JTAG debugger, but how do I really know that it is the OCM?

Parents
  • 0

    Hi Henry,

    I believe that each of the four OCM blocks get mapped to the upper memory space once Linux is up and running but I recommend reading Chapter 29 of UG585 to understand the memory model for the OCM.

    http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

    Depending upon the MMU settings for that area of memory space, you may be limited by the instructions that you can perform upon that space.  See this thread for further details:

    http://archlinuxarm.org/forum/viewtopic.php?f=23&t=7571

    This kernel document also has a brief explanation for the OCM driver:

    Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocm.txt

    However, this forum post and the response from milosoftware suggests simply accessing the OCM space like you were trying to do is the best way to access OCM:

    http://forums.xilinx.com/t5/Embedded-Linux/How-to-enable-cache-for-OCM-on-Zynq-LINUX/td-p/329123

    Regards,

    -Kevin

  • 0 in reply to zedhed

    Hi Kevin, I am trying to test the OCM in an AMP configuration.  I was stupid for not testing that the OCM can be read/written across CPU boundaries before.  I wrote a bunch of integers from bare metal C++ code on CPU1, starting at 0xFFFC0000, and I see what I wrote in the Xilinx system (JTAG) debugger memory view, but I don't see the same thing using a pointer returned to me after an open(/dev/mem) followed by mmap.  You told me before that you think I am on the right track, but I can't figure out why I seem to be looking at a completely random RAM area, rather than the OCM I just wrote to.  Do you have any thoughts?

        l_memf = open("/dev/mem"
                , O_RDWR /*| O_SYNC*/); //do I want cacheing?
        Q_ASSERT(l_memf > 0);

        //A mapping created using /dev/mem will be uncached if it's above
        //the top of RAM.  Also, Zynq OCM driver mapped this memory as non-cached
    #define OCM_PHYSICAL_ADDR 0xFFFC0000
    #define OCM_SIZE (4*64*1024)
        l_ocm = (char*)mmap(NULL,//Tried specifying OCM_LOC, no luck
                            OCM_SIZE, PROT_READ | PROT_WRITE,
                            MAP_SHARED /*| MAP_LOCKED*/,
                            l_memf, OCM_PHYSICAL_ADDR);//0xe0080000);//

  • 0 in reply to henry10210

    By stepping back to a simpler code that writes integer and reads integer, I established that the Linux side sees the right number for the most part, but there are holes.  For example, a hole suddenly appears in a completely linear sequence of numbers:

    ...
    fffcfef0:     3fbc     3fbd     3fbe     3fbf
    fffcff00:        0        0        0        0
    fffcff10:        0        0        0        0
    fffcff20:     3fc8     3fc9     3fca     3fcb
    ...

    This pattern gets worse and worse as I approach the end of the OCM, which becomes mostly garbage.  But when I look at the OCM in JTAG debugger, the numbers are completely correct!

    What's even stranger is that when I insert asm("DMB" ::: "memory") after writing each integer, the holes ALMOST go away (but not quite).  This makes NO sense because L1 should not even be involved for the memory address above 0x20000000 (512MB DDR).  Even if it were involved somehow, I cannot see why L1 would screw up like this.

    Very confused...

  • 0 in reply to henry10210

    I got things to work by turning off cache altogether on OCM.  I assumed all along that even if cache was turned on, the HW would correctly flush the cache to the physical OCM upon invalidation or explicit memory access before and after DMB barrier.  Now I see that DMB is NOT the same as cache invalidation.

    I don't think I really understand cache after all.  I keep reading ARM reference on DMB, and articles written by cache design gurus, and it's still hard to clarify this simple question between cache invalidation and DMB...

Reply
  • 0 in reply to henry10210

    I got things to work by turning off cache altogether on OCM.  I assumed all along that even if cache was turned on, the HW would correctly flush the cache to the physical OCM upon invalidation or explicit memory access before and after DMB barrier.  Now I see that DMB is NOT the same as cache invalidation.

    I don't think I really understand cache after all.  I keep reading ARM reference on DMB, and articles written by cache design gurus, and it's still hard to clarify this simple question between cache invalidation and DMB...

Children
No Data