How to set base address in Vitis / Vivado??

[asmi]

8. Programmed the application.elf at 0xA00000 as per the definition in step 4

Did you select "Convert ELF to bootloadable SREC format and program" checkbox while programming that file (see attached screenshot)? If so, please read back the flash contents into bin format and check with a binary editor what do you have at offset 0xA00000. You should see a bunch of human-readable lines starting from "S", here is example:

S02B0000443A2F416E647265792F50726F6A656374732F56697469732F53706172746135305F4D43555F5153C7
S30D00000000008000B0000008B802
S30D00000008008000B0F42008B8E6
S30D00000010008000B07C2C08B84A
S30D00000020008000B0AC0208B834
S31580000000018000B0D067A031018000B030624030FE
S315800000100C8000B088DD2030000000B0E001F4B92B

[Mario87]

Hey, yes I did select the tick box and I do have data programmed at 0x00A00000, see image attached....not sure what is happening??

Also added an image of how I have the QSPI IP configured. Slave device set to Spansion as the Nexys Video resource manual says...

The correct part to be set in the tools is s25fl256xxxxxx0 from the manufacturer Spansion®.

I have also noticed it is quite slow to load up the bootloader (20-30 seconds maybe), but that might be a separate issue to look at later, first need to figure out why it wont load the application.elf??

EDIT: ​

Right, so interestingly enough just after posting I found this thread... https://forum.digilent.com/topic/18106-srec-spi-bootloader-is-very-slow/?sortby=date

It points to an ELF bootloader on Github (https://github.com/henrikbrixandersen/elf-bootloader), I downloaded that and added it to my project (removing the SREC SPI loader) and it just works!!

I had a slight issue with Vitis where it simply would not let me flash a raw .elf file, it says its a valid file to use when flashing, but then it kept complaining about a missing .bin file, so as the ELF bootloader wants a raw elf file with the '.ELF' header in the hex code I simply took the application.elf file and renamed it to application.bin, then Vitis programmed the SPI flash with that file in the location requested and now it works!

It is also a bit smaller than the SREC loader (10kB with heap & stack vs 17-18kB with heap & stack). If I can get rid of the heapt & stack and have it still work I may even be able to reduce the BRAM on my MicroBlaze down to 8kB.

Something isnt right with either the SREC SPI Bootloader or in the way Vitis is converting the .elf into SREC it seems. I have noticed the SREC file is only ~634kB where as my ELF file is 1,134kB! Could it be something to do with that??

HOWEVER...it does still take 25-30 seconds from power on to configuration completing (config itself is very quick, its about 23-24 seconds before the bootloader even starts doing its job), is there any way to speed that up?

Also, when I reset the MicroBlaze using a push button the bootloader does not re-start and re-program the DDR memory with my application, so I need to reprogram the entire FPGA using the 'PROG' button the the Nexys Video. Any ideas on why the bootloader doesn't reset when I reset the MicroBlaze? I have noticed the reset works fine with my application on its own or with the SREC SPI Bootloader, just not with this ELF Bootloader I found??

[asmi]

HOWEVER...it does still take 25-30 seconds from power on to configuration completing (config itself is very quick, its about 23-24 seconds before the bootloader even starts doing its job), is there any way to speed that up?

Yes SREC is slow because it accepts binary in a text form (which is what you've seen in the flash dump), and then performs text-to-binary conversion, byte by byte. It was designed back in a day for small firmwares (on the order of perhaps tens of KB), so then it was acceptable.

Also, when I reset the MicroBlaze using a push button the bootloader does not re-start and re-program the DDR memory with my application, so I need to reprogram the entire FPGA using the 'PROG' button the the Nexys Video. Any ideas on why the bootloader doesn't reset when I reset the MicroBlaze? I have noticed the reset works fine with my application on its own or with the SREC SPI Bootloader, just not with this ELF Bootloader I found??

You've got to address that question to the author of that bootloader, I have no idea honestly.
-----
There is also a third way, which is to configure Quad SPI IP as XIP (eXecute-In-Place), which would map flash contents directly into CPU's address space as a read-only memory, and thus the CPU can execute this executable directly from flash, but for that you've got to make sure to map executable sections of your firmware appropriately - namely, read-only sections of your firmware needs to go to the XIP address space, while writable ones have to be mapped into DDR, and then you will still need some sort of shim in BRAM which would initialize Quad SPI IP (if neccessary) and jump to it. I haven't tried that approach myself yet (even though I've been meaning to do it for a long time), so if you want to give it a try - please let us all know if you can get it to work as I'd be curious myself.

[Mario87]

Yes SREC is slow because it accepts binary in a text form (which is what you've seen in the flash dump), and then performs text-to-binary conversion, byte by byte. It was designed back in a day for small firmwares (on the order of perhaps tens of KB), so then it was acceptable.

The bootloader I am using doesn't uses SREC, it uses the ELF file programmed directly onto the QSPI flash and loads that into RAM. It's not the loading of my application that is slow, it is the actual programming of the FPGA it seems that takes 25 seconds or so, as soon as the LEDs on the board come up (to indicate the FPGA is programmed) I can see the code executes almost immediately with this bootloader from the serial terminal.

Is there any way to speed up the FPGA programming from QSPI? I would have though it would be quicker than 25-30 seconds, no?

You've got to address that question to the author of that bootloader, I have no idea honestly.
-----
There is also a third way, which is to configure Quad SPI IP as XIP (eXecute-In-Place), which would map flash contents directly into CPU's address space as a read-only memory, and thus the CPU can execute this executable directly from flash, but for that you've got to make sure to map executable sections of your firmware appropriately - namely, read-only sections of your firmware needs to go to the XIP address space, while writable ones have to be mapped into DDR, and then you will still need some sort of shim in BRAM which would initialize Quad SPI IP (if neccessary) and jump to it. I haven't tried that approach myself yet (even though I've been meaning to do it for a long time), so if you want to give it a try - please let us all know if you can get it to work as I'd be curious myself.

I will try to reach out to them, but I did find the following thread: https://support.xilinx.com/s/question/0D52E00006hpSlnSAE/software-reset-of-mb-processor?language=en_US

It links to this support article for ISE & EDK, I need something similar but for Vivado & Vitis: https://support.xilinx.com/s/article/30878?language=en_US

I was going to ask, if you don't mind, can you test with the SREC QSPI bootloader, if you get your program running with the bootloader then use a button to reset the MicroBlaze, does it reset and start working from the bootloader again?

I am wondering if when the application is loaded into DDR it modifies the .data linker script and then on a reset you are stuck in limbo and hence it needs a full FPGA programming. That is basically what those links above describe and what I see with this bootloader I have, but I was wondering if you could test it out with the SREC QSPI Bootloader if its not too much hassle?

Running as XIP may be something I will look into, to be honest my program does not need to write any info to memory, it just reads the program and then sends commands to other parts of the FPGA to kick them off, once done it sits silently forever more unless a reset is initiated then I want it to just start over again and re-configure the hardware.

So that may be an easier implementation of XIP that could work, I will need to look into it.

Thanks for all your time and help so far, however. Hugely appreciated! Altho I would still be interesting in knowing why the SREC SPI Bootloader doesn't work?? Very odd.

[asmi]

The bootloader I am using doesn't uses SREC, it uses the ELF file programmed directly onto the QSPI flash and loads that into RAM. It's not the loading of my application that is slow, it is the actual programming of the FPGA it seems that takes 25 seconds or so, as soon as the LEDs on the board come up (to indicate the FPGA is programmed) I can see the code executes almost immediately with this bootloader from the serial terminal.

Is there any way to speed up the FPGA programming from QSPI? I would have though it would be quicker than 25-30 seconds, no?

Did you set config frequency higher than default (2 MHz if my memory serves me), and also enabled bitstream compression? If not, try to add the following lines to the end of your constraints file (*.xdc) and regenerate a bitstream:

Code: [Select]

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]
These constraints (1) enable bitstream compression, (2) enable 66 MHz config frequency (most half-modern QSPI flash devices can handle that kind of frequency, if not, try 50 or 33, note that this frequency has very large tolerance ±50%), and (3) set QSPI mode.

I was going to ask, if you don't mind, can you test with the SREC QSPI bootloader, if you get your program running with the bootloader then use a button to reset the MicroBlaze, does it reset and start working from the bootloader again?

I will give it another try when I have some more spare time.

[Mario87]

Did you set config frequency higher than default (2 MHz if my memory serves me), and also enabled bitstream compression? If not, try to add the following lines to the end of your constraints file (*.xdc) and regenerate a bitstream:

Code: [Select]

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
set_property BITSTREAM.CONFIG.CONFIGRATE 66 [current_design]
set_property CONFIG_MODE SPIx4 [current_design]

These constraints (1) enable bitstream compression, (2) enable 66 MHz config frequency (most half-modern QSPI flash devices can handle that kind of frequency, if not, try 50 or 33, note that this frequency has very large tolerance ±50%), and (3) set QSPI mode.

I added those to my constraints file, but seems to have not made a difference??

I will give it another try when I have some more spare time.

Thanks! Appreciate it! 

[asmi]

I added those to my constraints file, but seems to have not made a difference??

I assume you re-did export hardware and updated it in Vitis? If so - make sure that Vitis actually picked up the updated bitstream, in the past I had to do "Update Hardware" multiple times sometimes for the changes to be picked up. Check if the bitstream in /hw subfolder of your Vitis "platform" folder is the same as "<you_Vivado_project_name>.runs/impl_1/<diagram_name>_wrapper.bit", if not, repeat "Update hardware" until it is.
Also make sure that those lines are the very last lines of that constraints file. Since these are tcl commands, later commands which could possibly present in your file down the line can override those values.

[Mario87]

I assume you re-did export hardware and updated it in Vitis? If so - make sure that Vitis actually picked up the updated bitstream, in the past I had to do "Update Hardware" multiple times sometimes for the changes to be picked up. Check if the bitstream in /hw subfolder of your Vitis "platform" folder is the same as "<you_Vivado_project_name>.runs/impl_1/<diagram_name>_wrapper.bit", if not, repeat "Update hardware" until it is.
Also make sure that those lines are the very last lines of that constraints file. Since these are tcl commands, later commands which could possibly present in your file down the line can override those values.

Yes to all the above, made the changes, generated bitstream, exported, updated in Vitis, as you say had to do it a few times before the 'Created On:' date / time in Vitis updated to show it had taken the new hardware.

Rebuilt project, confirmed the bit & MMI are created recently before generating download.bit, then programmed to SPI flash and still the same.

They are also the very last lines in the .xdc constraints file

Still takes 25-30 seconds or so for the FPGA to load, then the bootloader and my application come online instantly within a second or 2.

[asmi]

Yes to all the above, made the changes, generated bitstream, exported, updated in Vitis, as you say had to do it a few times before the 'Created On:' date / time in Vitis updated to show it had taken the new hardware.

Rebuilt project, confirmed the bit & MMI are created recently before generating download.bit, then programmed to SPI flash and still the same.

They are also the very last lines in the .xdc constraints file

Still takes 25-30 seconds or so for the FPGA to load, then the bootloader and my application come online instantly within a second or 2.

That doesn't make any sense... Can you try removing compression, regenerate a bitstream and see if file size is any different?

[Mario87]

Just checked the bitstream size and I can confirm without doing anything else that the file size did not change when I added the following line....

Code: [Select]

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
It was 9,503kB before I added that to my constraints and having just checked the file is the same size after the line above has been added.

Looks like Vivado is ignoring it for some reason??

[asmi]

Just checked the bitstream size and I can confirm without doing anything else that the file size did not change when I added the following line....

Code: [Select]

set_property BITSTREAM.GENERAL.COMPRESS TRUE [current_design]
It was 9,503kB before I added that to my constraints and having just checked the file is the same size after the line above has been added.

Looks like Vivado is ignoring it for some reason??

Yeah, that is super-weird. Please right-click on your constraints file in a "Sources" tab, select "Source File Properties" and ensure that "Enabled", "Synthesis" and "Implementation" checkboxes are all set. If they are, I honestly don't really know what else to try. Unless you can post your design somewhere so I can download and take a look, there is nothing else I can think of at the moment.

[Mario87]

Yeah, that is super-weird. Please right-click on your constraints file in a "Sources" tab, select "Source File Properties" and ensure that "Enabled", "Synthesis" and "Implementation" checkboxes are all set. If they are, I honestly don't really know what else to try. Unless you can post your design somewhere so I can download and take a look, there is nothing else I can think of at the moment.

Yeah, that is all set already. In all fairness the Xilinx documentation does say that enabling compression does not guarantee a smaller file size (see snippet attached), but I think the stranger thing is that the config clock doesn't change anything.

The Xilinx docs state 3MHz is default and I have tried at 66, 33 and 50 (in that order) all to no avail, still takes 25-30 seconds and that is what doesn't make sense, more so than the compression.

[Mario87]

Ok, so I decided to edit device properties under implementation and make the configuration changes that way, then allow Vivado to update the constraints file as it wants instead of doing it manually (see page 38 in the link below) and now at 16MHz it works and flashes in 1 second or so with the following settings...

Code: [Select]

BITSTREAM.CONFIG.CONFIGRATE 16
BITSTREAM.GENERAL.COMPRESS TRUE

BITSTREAM.CONFIG.SPI_32BIT_ADDR
BITSTREAM.CONFIG.SPI_FALL_EDGE
Compression also seems to work properly now as the bitstream is down from 9,503kB to 4,673kB!

I will test at higher speeds also, but that is essentially 1 issue fixed, now I need to see if I can get the MicroBlaze to re-load the bootloader during a reset instead of doing what it does now and seemingly tries to load the main application but can't as it can't do that without the bootloader.

https://docs.xilinx.com/viewer/book-attachment/vbfPKhIJDzuHzAa46EWDIA/0tKFPiZS~Js8F29Ex2VsaQ

EDIT: Updated to 66MHz and the loading is near as makes no difference instant! 

[asmi]

Ok, so I decided to edit device properties under implementation and make the configuration changes that way, then allow Vivado to update the constraints file as it wants instead of doing it manually (see page 38 in the link below) and now at 16MHz it works and flashes in 1 second or so with the following settings...

That means you have more than one constraints file.

[Mario87]

That means you have more than one constraints file.

No I don’t, I only have the one and I can see the file Vivado made changes to is the same one I made changes to.

I suspect it was enabling these 2 extra settings that made the difference and fixed it.

Code: [Select]

BITSTREAM.CONFIG.SPI_32BIT_ADDR
BITSTREAM.CONFIG.SPI_FALL_EDGE