Forum Discussion
Honored ContributorNIOS II and Cyclone III Remote Update
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!69 Replies
Altera_ForumDo 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.- Altera_Forum
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?
- Altera_Forum
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?
- Altera_Forum
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. - Altera_Forum
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. - Altera_Forum
Just to make sure I understand this correctly... My 1st pof (combined sof and elf) will have the default Altera bootloader in it. This will search for the elf, starting at address 0, and load it into RAM. My 2nd pof, sitting at address 0x200000, is started when I send a reconfig command via NIOS code. I assume this has it's own copy of the default Altera bootloader in it, so it also searches from address 0 for the elf. So I am assuming what I need is the default bootloader in the 1st pof (as it is now) and a modified bootloader in the 2nd pof which starts looking for the elf at address 0x200000.
Does this sound about right? - Altera_Forum
Yes, you got it
- Altera_Forum
Whoopieeeee!!! They don't make it easy, do they? I'll have a go at this then and report back. Thanks you guys. :)
- Altera_Forum
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). - Altera_Forum
I guess the bootloader becomes part of the .sof file. Is that correct?
