We are using the Cyclone 10CX220Y device with a Nios II CPU in our design, and want to boot it from QSPI (device MT25QU512).
So far, we are able to only start the .sof file from QSPI at power on, and not able to boot the Nios from QSPI.
We have followed chapter 5. Nios II Configuration and Booting Solutions from the Embedded Design Handbook (2018.11.12). Specifically, 126.96.36.199, QSPI boot using Boot Copier.
Our .sof file is ~9.2MB. We want to put the .sof file to offset 0x0, and the .hex file for the Nios to offset 0x00A0.0000 (10MB).
In our Quartus design (version 18.1) , we set the Nios Reset vector to 0x00A0.0000.
Reset vector memory is set to config_flash, our targeted QSPI device.
In the BSP editor, we uncheck all the Advanced.hal.linker boxes as the manual describes. Also, we set all linker sections to onchip_ram.
We then generate our BSP, and use the mem_init_generate make target to generate the .hex file.
Then we create a .jic file with the following content:
File/Data area Properties Start address
Flash Loader 10CX220Y
Boot info 0x00000000
SOF data Page_0 <auto>
Hex data absolute address 0x00A0.0000
Two differences we have here with the manual are:
If we select 0x0 for SOF start address like the manual describes, we run into a Quartus error, saying this overlaps with the option bits from 0x0 to 0x1F.
Since the manual describes the QSPI boot only for MAX 10 devices, and refers to EPCQ programming for other devices, our own design flow differs from the screenshots.
After programming the generated .jic file to flash, after a power cycle we can see the .sof file has loaded and is running, but the Nios has not started.
Could you please comment on our procedure?
Could you advise what steps we should take to debug this problem?
Actually you are facing many issues, Let's answer one by one
First please share with me the linker script settings you've edit and check the following KDB which will show you how to solve the overlap error.
Below I have added a capture of our linker adjustments in the BSP editor. The device we want to boot the .sof/.hex combination from is called 'config_flash'. Please note there is another device called 'boot_spi', but this component is used to boot a different subsystem so please do not get confused by the name. Is there any additional (generated) data you need as input? p.s. I did not know about the KDB article you mentioned, I will check what these changes do to our system.
This is incorrect:
What I understand that you need to program the QSPI flash with the SOF and HEX so you will boot the NIOS from there (you can copy the code or execute in place "XIP"). I have a CV soc Kit and created an example to show you how to set the BSP and how to program the QSPI flash via jic file "JTAG Indirect Configuration"
The example is an execute in place "XIP".
Please check the attachment and let me know:
Today I have managed to boot the Nios using the Boot Copier method as originally intended.
In the end the only adjustment made to my original setup is that we changed the exception vector memory from ocram to ddr.
I'm not sure why this change was required in order for my system to boot, but for now the situation is workable.