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
:):)

Sorted. Used the settings in my previous post but instead of doing a make on the bootloader did a make CODE_BASE=0x0.

Working now. :):)

Thanks all for your help.
Altera_Forum
Honored Contributor
13 years ago
--- Quote Start ---
You can probably just put the boot code into a user-defined internal memory block, and point the nios reset vector at it.
That would remove the problems of the sopc builder repeatedly substituting its own file.
After all, I presume that is what happens anyway.
It would also let you use TCM for the boot code (probably more useful for the JTAG block though since you are probably copying code to SDRAM and have an instruction cache anyway).
--- Quote End ---

Dsl,

I am following what you suggested. My problem is that the EPCS controller does not give me a transmit ready signal (when I read the status register)and the bootloader gets stuck in the loop waiting for the flash to be ready. If you look at the object file dump,

// Wait until controller is ready for a TX-char, then send it.
tx_ready_loop:
ldwio rf_temp, EPCS_STATUS_OFFSET (r_epcs_base_address)
d0: 92400237 ldwio r9,8(r18)
andi rf_temp, rf_temp, EPCS_STATUS_TRDY_MASK
d4: 4a40100c andi r9,r9,64
beq rf_temp, r_zero, tx_ready_loop
d8: 483ffd26 beq r9,zero,d0 <tx_ready_loop>

stwio r_epcs_tx_value, EPCS_TXDATA_OFFSET (r_epcs_base_address)
dc: 92c00135 stwio r11,4(r18)

It is here where I am not able to move forward. I never get reach address 0xdc.
Till this point I am fine.

This is my flow
I keep the bootloader on internal memory and upon finding that the boot is for application image, I load the bootloader to an on-chip ram.
I reset the nios control to the bootlader and let it run. When i am debugging the bootloader (i access the on-chip memory and put return instruction at various location to see how far the flow runs), I get stuck in the above loop shown.

Any help would be great.
Altera_Forum
Honored Contributor
13 years ago
Hi,Cris Could you please tell me how to generate my epcs_controller_boot_rom.hex with customized start address?
I only got *.elf files but not *.hex files by rebuilt boot_loader_sources directory using NIOS II command console tools, and the r_flash_ptr has already been set to my new start addrss.
Altera_Forum
Honored Contributor
13 years ago
Please take a look at the attached sample. This was for Cyclone III; you may need some changes to make it work on other fpga devices.
- unzip the files in a new directory
- open Nios II command shell and go there
- change EPCS_SRC_ADDR in boot_loader.h with desired boot address for Nios application
- build the custom bootloader, which generates a epcs_controller_boot_rom_A.hex file (simply type 'make')
- replace the existing epcs_controller_boot_rom.hex file in your Quartus project with the newly generated one (thus removing _A)
- select Quartus Processing menu, then Update Memory Initialization file
- select Quartus Processing menu, then Start -> Start Assembler
- the generated sof file will boot from the specified epcs address
boot_loader_epcs_bits.zip9 KB
Altera_Forum
Honored Contributor
13 years ago
Hi Chris,

To boot on the desired address for Nios application, I did exactly what you did
but unfortunately when I use your sample and I type 'make' I have the error :
"make *** [all] Error 2" ; whereas when I go to my directory where boot_loader.h
is defined and I modified the EPCS_SRC_ADDR like superior_100 I have only generation
of .elf files, where is the problem ?
Altera_Forum
Honored Contributor
13 years ago
Hi Chris,

To boot on the desired address for Nios application, I did exactly what you did
but unfortunately when I use your sample in typing 'make' I have the error :
"make *** [all] Error 2" ; whereas when I go to my directory where boot_loader.h
is defined and I modified the EPCS_SRC_ADDR like superior_100 I have only generation
of .elf files. Where is the problem ?
Altera_Forum
Honored Contributor
13 years ago
Hi Julien92,
You may try "make CODE_BASE=0x0".
A link is valuble, I think you will get what you want there: 3w.alterawiki.com/wiki/EPCS_bootloaders.
Good luck!
Altera_Forum
Honored Contributor
13 years ago
Thank you superior_100, it worked.
Just have another problem, when I want to Update Memory Initialization file
with Quartus processing menu, it doesn't to update the new Hex :
Error: Project contains unresolved partitions
Error: Unresolved partition "<Top partition>"
Error: Quartus II MIF/HEX Update was unsuccessful. 2 errors, 0 warnings
Altera_Forum
Honored Contributor
13 years ago
Ok I opened the new epcs_flash_boot_controller.hex file in quartus and
in Quartus process menu -> Update Memory file worked, however to start assembler
what do I have to do ? I have none idea !
Altera_Forum
Honored Contributor
13 years ago
Hi Julien_92,
I have already make it follow what Cris72 had said, I copy the steps below, besides, you can may some useful info at alterawiki & search EPCS bootloaders.
- unzip the files in a new directory
- open Nios II command shell and go there
- change EPCS_SRC_ADDR in boot_loader.h with desired boot address for Nios application
- build the custom bootloader, which generates a epcs_controller_boot_rom_A.hex file (simply type 'make')
- replace the existing epcs_controller_boot_rom.hex file in your Quartus project with the newly generated one (thus removing _A)
- select Quartus Processing menu, then Update Memory Initialization file
- select Quartus Processing menu, then Start -> Start Assembler
- the generated sof file will boot from the specified epcs address

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