02-23-2018 08:09 PM
Hi,
I try to improve real-time performance of our Zynq-7000 system. The idea is to preload a (interrupt) routine into the L2-cache and lock it there.
The question is,
1:how to label the interrupt routine as code which needs preload?so the mmu can find it to be preload this part of code into L2 cache
I know the Tech Tip's Locking and Executing out of L2 Cache
but this tech tip just let me confused 。
is the vector table part in the lscript.ld of fsbl has the ability to put the interrupt routine as preload code?
.XVtable : {
_dataXVtableVMA_start = .;
*(XVtable)
_dataXVtableVMA_end = .;
} > ps7_ram_1_S_AXI_BASEADDR AT> FLASH
_dataXVtableLMA = LOADADDR(.XVtable);
02-23-2018 10:17 PM
@binbinyantai Why don't you create a BRAM region then place your ISR in there? It is cleaner than messing up with cache.
02-23-2018 11:17 PM
hi,
thanks ,but how to do that? how to put the code into the bram?
02-24-2018 12:37 AM
@binbinyantai OK so
1. create the BRAM as you normally do in the design.
2. Export the design to sdk
3. In the SDK you will have to regenerate the linker script, otherwise it will not be updated with the new BRAM you just created.
4. Edit the linker script and add something like this, where "axi_bram_ctrl_0_Mem0" is the bram memory name in the HDF file (it is also on the top of the linker list)
.bram : { KEEP( *(.bram)) } > axi_bram_ctrl_0_Mem0
And in your code, add the section attribute to your ISR - gcc will place that code in there
__attribute__((section(".bram"))) void printhello() { xil_printf("Hello World from CPU #1 address:%p\n\r", printhello ); }
and in your code you should see something like this
Hello World from CPU #1 address:40000000
Confirm that 0x40000000 is the address of your BRAM in the address editor.
02-25-2018 06:28 PM
thanks
if i have no enough space for bram. what should i do ?
i think the tech tip just tell me how to lock the whole application code into the l2 cache , but i just want to add some ISR routine into L2 cache ?
is there any other ideas