05-29-2018 09:27 AM
I am using SDK 2017.4 and have a ddrless zynq board. I have followed this example: http://www.wiki.xilinx.com/Zynq-7000+AP+SoC+Boot+-+Booting+and+Running+Without+External+Memory+Tech+Tip, as well as this post: https://forums.xilinx.com/t5/Embedded-Boot-and-Configuration/Can-t-flash-QSPI/td-p/813536. I am able to successfully program the QSPI flash as well as boot from flash. If my application uses interrupts, in my case the private timer (IRQ 29), it will cause the bootloader to restart and reboot the system once the interrupt occurs. It also seems to call the interrupt exception handler in the FSBL because a "IRQ_HANDLER" is outputted to the terminal. This will loop on forever. I have gone with the l2 cache approach in the first link for my design. I'm not sure exactly if the FSBL irq_handler is called because I have recompiled and rebuilt after modifying the print statement, yet the original "IRQ_HANDLER" message is print. Not sure what is going on, but I think it may have something to do with where the vector table is stored in memory. Any suggestions would help a lot.
05-29-2018 02:55 PM
I have used the Tool Tip's linker script for my application and have the copy function added to my main.
05-29-2018 03:52 PM
it looks like if an interrupt gets fired the code jumps at address 0x0 instead of address 0xFC0008C0 where the vector table is.
To work around this problem, here is a suggestion:
Define the following (see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0433b/CIHHDAIH.html for more details)
#define WRITE_VEC_BASE_ADDR(value) \ mtcp(XREG_CP15_VEC_BASE_ADDR,value) #define READ_VEC_BASE_ADDR(value) \ value = mfcp(XREG_CP15_VEC_BASE_ADDR)
And in your main() call this after init_platform();
WRITE_VEC_BASE_ADDR(0xfc0008c0); READ_VEC_BASE_ADDR(value); xil_printf("READ_VEC_BASE_ADDR %x\n\r",value);
0xfc0008c0 is the address where the vector table is.
I tried a simple UART with IRQ test and looks like it is working.
05-30-2018 09:51 AM
I meant the main function in your application SW.
05-30-2018 09:58 AM
I tried FC0008C0, it hangs at the interrupt. I tried FC0028C0 because in my bif I am starting at a offset of 0x2000, and it tries to reboot but without the IRQ_HANDLER exception and gets stuck saying there is "FSBL Warning !!!Bitstream not loaded into PL". I also tried 0x0002FF00 just to follow the tool tip's linker script and that hangs as well.
05-31-2018 09:20 AM
So, is it a different issue? Can I see the full log, please?
06-01-2018 10:30 AM
On the 0xFC0028c0, it looks like the interrupt re-triggers the FSBL and loads partition 1 again.
Are you placing your image at 0xFC002000 ?
The code I suggested is for the SW apps (after FSBL) and it should move the vector table to the address where you apps is.
If you dump your app.elf, does it show you where the vector table is?
06-01-2018 10:57 AM
My FSBL is placed at FC002000, my bit file is placed at FC200000, and my app is placed at FC700000. Not sure what you mean by dumping my app.elf.
06-04-2018 08:07 AM
I was referring to the objdump.
The vector table for you application should be around FC700000 but you need to find the proper spot.
06-08-2018 08:56 AM
If you have the XSDK project, double click on the .elf and it should show you the "dump":