02-08-2018 06:42 AM
I have finished one design and it is time to save bitstream on flash. I am facing several problems because I think I dont understand correctly how to manage and create .bin file required for my board. I am using a Saturn board by Numato (Spartan6 LX45).
My design is composed of one Microblaze and a set of peripherals (created with XPS), and several VDHL cores (created by me through ISE DS). So I generate bitstream through ISE DS. From ISE, I generate .bin and .bit files.
.elf file from SDK with the code for Microblaze is added through ISE DS and it is automatically linked to my xmp (microblaze). So I understand that my bitstream, once generated by ISE DS, contains FPGA configuration and SW for Microblaze.
Well, on the other hand, as my code for Microblaze is quite big, it doesnt fit on block ram, so I have to create a bootloader to allow pass data from flash to LPDDR memory on the board. Code for bootloader is available on Numato web, but here start my doubts/problems.
1. Do I have to create two different bitstreams?? One with my design (Microblaze + peripherals + VHDL cores + code for microblaze) and other one with bootloader (composed by other Microblaze + SPI core + bootloader code (other .elf file))??
2. This situation involves having two different linker scripts, one for my design, and other one with bootloader design. How to configure the different linker scripts to dont be overlapped by each other.
3. How to combine all files (.bit/.bin generated by ISE DS with my design(code for my microblaze included) + .bit/.bin generated by data2mem tool with other Microblaze, and bootloader code for it, and bmm file required for bootloader) to generate a unique .bin file to be loaded in the flash??
Any help is really appreciated.
02-08-2018 03:37 PM
Look at AR47909, I believe this is what you had in mind.
02-08-2018 04:14 PM
That AR looks like it walks you through what you need to do.
To answer your questions:
1. Do I have to create two different bitstreams?? No. You will create one bitstream that includes ALL peripherals (including SPI) and the BRAM that the microblaze runs from will be populated with your bootloader. By default, microblaze starts running whatever code exists at address 0x00000000 after reset.
2. How to configure the different linker scripts to dont be overlapped by each other? The linkerscript for the bootloader will use the LMB bram at address 0x00000000 and this bootloader is what the microblaze will start running after reset. Once the 'bootloader' copies your application.bin/.mcs from SPI to DDR, then the microblaze will 'jump' from the bootloader code in LMB BRAM to your application in DDR. So the linker script for your application will use an address range within DDR.
3. How to combine all files (.bit/.bin generated by ISE DS with my design(code for my microblaze included) + .bit/.bin generated by data2mem tool with other Microblaze, and bootloader code for it, and bmm file required for bootloader) to generate a unique .bin file to be loaded in the flash?? Normally, flash will be programmed by a .mcs. The contents of that mcs will contain your application.bin and a .bit. You will create the bit by implementing the design in ISE, and then adding the bootloader.elf to the .bit. Data2mem needs to know where the LMB brams are within the .bit so that is why data2mem wants a .bmm. It's been a while since I used ISE but there is a command something like 'promgen' that will package the .bit and the app.elf(or.bin) into a .mcs. Then you program the flash with that mcs.
02-09-2018 02:02 AM
Thanks to both for your answers.
Now it is more clear. I will try to follow your steps John (if possible today).
So If I am right, these are the steps to follow:
a) Create bitstream through ISE DS with all my design(Microblaze and VHDL cores) + elf file added to Microblaze design (Microblaze must include SPI peripheral to control SPI flash by bootloader). Link all sections in linker script to LPDDR memory.
b) Create a new SDK workspace with the same HW platform but with bootloader code. Link all sections in linker script to BRAM.
c) Merge bitstream created in ISE DS with .elf created for bootloader with data2mem tool.
d) Use PROMGen tool to create a .bin file (is the extension required by the flash in Saturn board.
But..... one more doubt arises about linker scripts. What about reset, interrupt and exception vectors, because they are defined with the same adress (0x00, 0x08, 0x10, 0x20) in both linker scripts (the one of my application and the one for bootloader). Can this point be problematic?? Or Dont I have to worry about this??
Thanks for your support.
02-12-2018 06:12 AM
I have a new question about the correct process to create the bootloader correctly for my application.
If I add .elf file to ISE design as explained in post above, I face a new problem to pass .elf file used by my application to DDR memory because I dont know how bitstream is created, so I dont know where application code (.elf of my application added to ISE design) will be saved on flash. I understand that I require to know where is saved in flash (offset) to create my bootloader to pass this application .elf to DDR.
Is this process (add .elf file for my application in ISE design flow) forbidden if a bootloader is required??
Is there a way/tool to know how data is saved on bitstream?? I mean, where .elf file (the one for my application, not the one for bootloader) is saved to know the offset to be programmed in bootloader to pass all the code to LPDDR memory.??
Any suggestion is welcomed.
02-16-2018 08:51 AM
The bitstream will only contain the ISE design plus bootloader .elf. The bootloader .elf will populate the LMB bram.
You can then program this combined bitstream to flash. It is up to you to know what flash memory is still available. Then, you can program your application .elf to a different memory region of flash. It is this different address that you will need to assign in the bootloader.
Or, you can merge the above two steps into a single flash file that will contain content for two different memory regions. But during debug, it is probably easier to program bitstream and application to flash in two different steps.