Using zynq OCM with red pitaya with pavel-demin notes

gistfile1.txt

OCM: 256kb of on-chip memory

?I think? it's called ps7_ram_1_S_AXI_BASEADDR in the linker scripts, but that does not work.

on boot, dmesg has zynq-ocm f800c000.ocmc: ZYNQ OCM pool: 256 KiB @ 0x5e880000
This address works. un-segmented.

#define COMM_BASE 0x5e880000

app_cpu1:
int main(){
  int i;
  for (i = 0; i < 256; i = i+4){
    Xil_Out32(COMM_BASE+i, 0xFF00FF00);
  }
}

in linux:
./monitor 0x5e880000
0xff00ff00


notes&suff:
http://henryomd.blogspot.co.uk/2014/10/using-zynq-ocm-linux-device-driver.html

#############

red pitaya FPGA code interferes with the OCM:

root@red-pitaya:/# ./monitor 0x5e880000 // OCM loc
0x00000000
root@red-pitaya:/# ./monitor 0x5e880000 0xFF // is writable
root@red-pitaya:/# ./monitor 0x5e880000
0x000000ff
root@red-pitaya:/# cat red_pitaya_top.bin > /dev/xdevcfg// flash the def FPGA software
root@red-pitaya:/# ./monitor 0x5e880000
0x00000000
root@red-pitaya:/# ./monitor 0x5e880000 0xFF
root@red-pitaya:/# ./monitor 0x5e880000 // no longer writable
0x00000000
root@red-pitaya:/# 

######## update 11:00 03/sep

It is controled by the file written, not just by the act of reprogramming the fpga as if the bare_metal_test.bin file is written, monitor continues to be able to access the OCM.

possibly if we replaced the bootup fpga file, the new mem address would be visible in dmesg?
edit: NOPE. dmesg claims it's in the same place, but it is inaccessable.

############ REMAP

https://forums.xilinx.com/t5/Embedded-Processor-System-Design/Zynq-MMU-configuration-using-OCM/td-p/389487
the rp fpga does not use OCM, nor does anything else but it does scribble over its config?
just tell the mmu where to put it
do this in comms so setup for then the app_cpu1 wants it

###### the asm segfualts.
but found most of the OCM at 0xFFFF0000 - the defult. but small - oh well.
'''
Configures the MMU to disable cache for OCM accesses in the address range of
0xFFFF0000 to 0xFFFFFFFF. The address mapping of the OCM is untouched so OCM
exists at addresses 0x00000000 to 0x0002FFFF and addresses 0xFFFF0000 to
0xFFFFFFFF. Only the high 64 KB of OCM is used by this application note, so cache is
disabled on addresses 0xFFFF0000 to 0xFFFFFFFF.
''' - xapp1079

################

nope again, the red pitaya puts it some place else.
https://github.com/imrickysu/ZYNQ-Cookbook/blob/master/recipe/HowToRemapOCM.md use the sclr
https://github.com/Xilinx/linux-xlnx/blob/master/arch/arm/mach-zynq/slcr.c     like this?

################

It's at 0xFFFF0000 *shrug*
edits are being eat by the cache, and the xilinx flush routienes are not in the BSP so we flush the cache by reading it all. HACK BEYOND BELIEF