Have spent several days now searching and reading and think I am nearly there... but not quite. I am using the NIOS II core with SOPC builder. I use Quartus II for the FPGA image. This is a project I have inherited which kept the FPGA image in a ECPS64 and the software image in CFI. I have combined the two and keep them in the EPCS64. Works OK. I have been trying to get the remote update controller to work. I have put it into the core via SOPC and can read and write its registers via NIOS. I can also make it do a reconfig but it always seems to use the factory image. Has any one got a working example using the Cyclone III and NIOS II? I use the following to read 2 of the registers... ParamValue = IORD( REMOTE_UPDATE_CYCLONEIII_0_BASE, 0x4); ParamValue = IORD( REMOTE_UPDATE_CYCLONEIII_0_BASE, 0x0); After power on both registers read 0. After reconfig command, register 0 = 1 and register 4 = 8 Any ideas please? Brain is starting to hurt!

Do you have one or two firmware (sof) images in the EPCS? Do you have one or two software images in the EPCS? When you reconfigure using the remote update core, you need to tell the core where the firmware image is located that you want to use next instead of the one at the beginning of the EPCS. If you have 3 or more firmware images that you need to go between, you will need to have provisions in the firmware image at 0 to decide which one to use. Assume you have 3 firmware images at addresses 0, X and Y. The firmware at 0 boots, decides to reconfigure to X. When the firmware at X is loaded, if it attempts to reconfigure it will always load the firmware at 0.

Hi yes. I have 2 sof and 2 elf files (hopefully). I use sof2flash and elf2flash, convert to bin, join together (cat) and then convert to hex. I then use Quartus Programmer to convert hex to pof and program. I do the same for the second image but set to relative address and put in an offset and reprogram, hopefully leaving the first pof in the bottom of the EPCS64. Does this make sense?

That does indeed seem to be the case! The 2nd FGPA image is loaded but it still runs the 1st software image. How do I overcome this?

What is happening is the bootloader in your second sof is pointing to the firmware at 0. The bootloader will look for the size of the firmware (sof) and search for the start of the elf just after it. I have dealt with this problem before, but I don't have a great solution for you. I normally place my second firmware/software at a fixed address location well beyond my first firmware/software pair. After this, I modify a copy of the bootloader code to search for this new offset instead of starting at 0. When compiled, it will generate a new .hex file. This file needs to replace the one that your second firmware image is using to boot the software. The stock bootloader software is located in your quartus install directory. Search for boot_loader.S and you should find it. (there is a makefile you can use with the NIOS II command console app if I remember right. I wish I knew how do make this process easier. If anyone else knows of an easier way, I'd be interested too.

Kosh is right, you need to change the bootloader, because the default one assumes Nios firmware is located just after fpga configuration data starting at address 0; then you load new fpga configuration, but the old nios firmware. You need to replace the epcs_controller_boot_rom.hex file in Quartus directory with the customized bootloader image and then rebuild the fpga project. Pay attention that sopc builder overwrites this file with the default bootloader whenever you regenerate the sopc system! Then you must backup your custom hex image and replace it every time you rebuild sopc. What kosh suggested is indeed the standard solution for generating a remote update firmware image. AFAIK there's no way to automate the procedure and make it easier. Anyway it is not that difficult. Consider that the primary fimware (usually referred to as factory firmware image) is seldom changed, so the fixed address location for the updated firmware is not a great problem: normally you only need to generate the special bootloader once.

NIOS II and Cyclone III Remote Update | Altera Community

69 Replies

Altera_Forum
Honored Contributor
13 years ago
Yes I followed these steps and it worked,
however I don't know if I have to open
a specific file from my quartus project before
to do start assembler or settle a parameter in
quartus II ?
Altera_Forum
Honored Contributor
13 years ago
I don't know whether this is necessary, but I just do like this:
-rename epcs_controller_boot_rom_A.hex to kernel_epcs_flash_controller_0_boot_rom_synth.hex;
-replace the system generated kernel_epcs_flash_controller_0_boot_rom_synth.hex with mine;
-copy my kernel_epcs_flash_controller_0_boot_rom_synth.hex to the root direction of my project, and add it to the project;
-then Processing->Update Memory Initialization file;
-Processing->Start -> Start Assembler;
now the .sof file is updated, and it is right file.
Altera_Forum
Honored Contributor
13 years ago
Just had to remove db and incremental db folders in my quartus project to run fitter without problems and start assembler after.
Thank you
Altera_Forum
Honored Contributor
13 years ago
just have another question : why after reconfig command register 4(boot adress) = IORD(REMOTE_UPDATE_BASE, 0x04) = 8 ?
while the bootloader in my second sof is pointing to the firmware at 0 if I use the original bootloader code without modification.
So my register 4 shouldn't contain the value 0 ?
Altera_Forum
Honored Contributor
13 years ago
Could somebody could explain me please, because I don't really understand what is happening ?
Altera_Forum
Honored Contributor
13 years ago
Hi Julien
I believe you are missing a point: the boot address in remote update core and the address of bootloader code are unrelated.
Remote update boot address ONLY refers to the position of FPGA configuration image. The Nios firmware position is included in this FPGA configuration itself, i.e. it is defined by the bootloader code you assigned to epcs device with the hex memory initialization file.
I don't know why you read 8 from the remote update address register; if FPGA reconfigures correctly probably it's only a trivial read error.
Anyway, according to what I said above, you should read here the address of the currently loaded fpga image, not that of Nios firmware.
Altera_Forum
Honored Contributor
13 years ago
Just to be sure I well understand, in the remote update core you've the boot address
(using IORD to read remote update register like 0x04 to read the boot address) that only
refers where the address of FPGA configuration image is situated by default 0. Address of FPGA
configuration image that can be changed with the bootloader code (EPCS_boot_rom.hex) ?
Altera_Forum
Honored Contributor
13 years ago
Sorry if I look lost...
Altera_Forum
Honored Contributor
13 years ago
Remote update core is something related to FPGA hardware and it doesn't know anything about Nios or whatever is implemented inside FPGA.
You could have implemented another processor instead of Nios, and this would have a different bootloading method: then, the uP bootloader is only a matter of the specific FPGA configuration and remote update core has no effect on it.
In the case of the epcs controller for Nios system, the Nios bootloader is embedded in the controller core itself: this means the bootloader is encapsulated in epcs controller hw logic (sort of PROM bits) when the core is generated and fitted into the fpga image.
That's why you need to assign the firmware position before generating the fpga image and you can't change it by simply modifying the remote update settings.

Please let me know if you got it clearly or if you need futher explanation.
Altera_Forum
Honored Contributor
13 years ago
So the remote update only enables to read position of FPGA configuration image and can't change it ! if I well understand

Forum Discussion

NIOS II and Cyclone III Remote Update

69 Replies

Recent Discussions

Marking codes of CY10CL040YF484

Unable to scan JTAG chain, TCK only 2V

Cyclone 10 LP Bitstream Compression Failing

Updated .brd file for Stratix 10 GX dev kit

Agilex 5 D-Series HVIO IOPLL runtime reconfiguration: C0 write succeeds, but output remains 100 MHz