06-04-2014 06:38 AM
I'm using both cpus on Zynq and I'd like to load data of the app running on cpu1 in the ocm.
I try to change the linker script to do it, but when I load my programm on the board, it's not working.
I've seen that the fsbl uses the ocm during the boot. And that fsbl loads elf files in ddr.
How can I overcome this to load the data section in ocm?
06-05-2014 05:29 AM
06-05-2014 08:20 AM
Thank you for your reply. I've already read that application note, but it doesn't help me resolving my problem. Indeed, in the application note, the ocm is used for communication between both cpus and is only written after the apps begin to run. When I use the ocm the same way, all is working fine.
But here, what I'd like to do is to store the data section of the ELF file of the app running on cpu1 in the ocm. I don't know if it's possible to do it or not. But if anyone has an idea, it will be useful for me.
06-12-2014 08:32 PM
It's definitly possible. Check the address map table in the Zynq Technical Reference Manual. There are a few options that can move OCM around and actually disable visability of the OCM.
After bootrom runs and while FSBL is running, the top 1/4 of OCM (64KB) is mapped high at 0xffff0000 and the lower 3/4 of OCM is mapped to 0x00000000 (where FSBL is running from).
Depending on the OS that you are running, the lowest 3/4 of OCM could get mapped high so you have the full 512KB at 0xfffc0000-0xffffffff. There is also an address filter bit that can map the DDR into the lower address space.
Also, the top of high OCM (somewhere around 0xffffff00-0xffffffff) is initialized by the bootrom to contain the wfe() loop and the bootrom sends cpu1 to the wfe loop.
So read the registers that tell you where the quarters of OCM are mapped (high or low) and make sure your linkerscript works within those ranges. Also make sure your app will not overwrite the running FSBL.