02-23-2015 04:30 AM
I am wanting to implement a bootloader for the Microblaze. I have read various application notes regarding bootloading the Microblaze. Most bootloader documentation details a bootloader that exists in BRAM in the FPGA. The bootloader loads the run time application from an external non-volatile device (such as a flash) into an external volatile memory (such as SRAM or DDR SDRAM). The Microblaze then runs on the external memory.
I have the following constraints:
1) The FPGA doesn't have access to external memory.
2) The programming of the run time application software must be fast. Combining an ELF with an FPGA bit file and programming an external flash device takes too long.
3) The run time application will be a standalone application (in other words, a standard microcontroller, not a Linux kernal) and the run time application will typically be fairly small.
I have included a PDF of what I am proposing. I plan to use a fairly large amount of BRAM in the FPGA (128KB). There will be a small bootloader application residing at the lower address space. This will form part of the FPGA boot image. I will convert the run time application ELF file into a BIN file using mb_objcopy. This BIN file will be received by the bootloader over FSL and programmed into the upper address space of the BRAM. Using a trick detailed by Xilinx in an application note, the Program Counter will then jump to the run time application instruction code in the upper address space of the BRAM. There will need to be some work in the bootloader to handle the interrupts and exceptions of the run time application. But I am hoping to always put the run time application at the same address in the BRAM and so this should make it easier.
I have a couple of questions:
1) Has anyone tried this? Is there something I am missing?
2) I am concerned about the locations of the heap and stack in the BRAM (both of the bootloader and the run time application). How do I find out where these will be located? I need to make sure that my run time application instruction code will not overlap the address space for the heap and stack.
3) Will the bootloader software be able to write to the upper address space in the BRAM to program in the run time application instruction code? Or is the BRAM address space 'protected'?
4) Will mb_objcopy generate the raw BIN file that I need or will I need to do any post processing before programming into the BRAM (such as swapping bytes, endian swaps, etc).
Any advice would be greatly appreciated!
I am using ISE/EDK version 13.4. This is for a Virtex 6 XC6VSX315T-1FF1156C.
02-24-2015 12:15 AM
I have been able to answer some of my own questions:
1) Usg mb-objdump -h <filename> in SDK to see the sizes of the different sections in the ELF file.
2) Microblaze can read and write BRAM directly using XIo_In, XIo_Out.
3) I am using two separate BRAMs. A smaller one (16K) contains the bootloader and forms part of the FPGA bit file. A larger one (128K) will contain the real-time programmed application software.
I am about to test in hardware and will give further updates for anyone who is interested.
02-24-2015 02:39 AM
It is working. Execution successfully jumps to the run time loaded application code in the second larger BRAM.
Only thing I am still trying to sort out is what to do with the reset, interrupt and exception vectors as these are still located at the start of the boot BRAM and not part of the loaded application code.
02-24-2015 05:33 AM
OK the final piece of the puzzle is in place.
I extract the exception/interrupt/reset vector code from the ELF of my run time application. Then when I program in the run time loaded application code, I overwrite the exception/interrupt/reset vector code of the bootloader.
The result is that when an interrupt or reset happens in the run time application, the right piece of code is now executed (instead of the original bootloader code).
This works because my bootloader is very simple and doesn't use interrupts.
Everything is now working.
12-02-2015 08:38 AM
Interesting topic. I'm looking to implement exacly the same architecture on a spartan6 device.
Can you elaborate on how you managed to get the bin file in the correct format into the bram's ?
12-02-2015 12:18 PM