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_ForumSo for my project in the following attachment, the EPCS64 memory is divided in a factory code and an application code,
when I would have modified the EPCS_boot_rom.hex to# define SOFTWARE_OFFSET 0x400000, with the remote update I could read the position of my FPGA config image with IORD(REMOTE_BASE, 0x4) that should be 0x400000 ? I hope I'm right- Altera_Forum
Still not sure you got it; please excuse me if I'm wrong, but I'll try to explain better.
You CAN definitely select a different image for FPGA configuration with remote update core. What you can't do is selecting a Nios boot image independently from FPGA configuration, since Nios bootloader is embedded in the specific configurated logic. Example: In epcs you have a base FPGA configuration at address 0, another one at address 0x20000 and a third one at address 0x40000 and possibly others at higher addresses. Upon power up the default base configuration at address 0 is loaded: this may or may not have a Nios system configurated inside it; if it does, the bootloader should also be implemented and will take care of loading Nios firmware. Let's now assume you need to reconfigure with the image at address 0x40000; you set the remote update address to point there and trigger the reconfiguration. At this point the FPGA is configured from the image stored at 0x40000; but this is only the hardware part: whether a Nios firmware is bootloaded and WHERE it has to be loaded from it's a specific information hardcoded into the newly loaded image. If you want the configuration at 0x40000 to be able to boot different Nios programs upon user request, or even select the Nios boot image position, you must provide a far more complex bootloader which test other system variables (for example input pins coming from dip switches) and proceed according to the user selection; remote update core is not involved in this part. - Altera_Forum
I had difficulties to understand but I think I get it, you've the remote update core that enables to select the FPGA image, this FPGA image can includes the Nios firmware position defined by the Nios bootloader code (EPCS_boot_rom.hex) that will load this Nios firmware itself, remote update core can't change this one because it's integrated in EPCS controller core itself, in EPCS you have a base FPGA configuration at address 0 and others address, the default one is 0 if the Nios bootloader isn't changed. So for example, if I have two FPGA Images each included a Nios system, one at address 0 and the other one at address 0x400000, if I select the second FPGA image with the remote update core upon power up the default base configuration at address 0 is loaded, so my second FPGA image is selected but runs Nios firmware in the first FPGA image and not the Nios firmware in my second FPGA image.
Hope I'm right, really sorry if I take time to understand that... - Altera_Forum
Ok. I think you got it.
Regarding Nios firmware I forgot to mention that the default bootloader will automatically go to address 0; it will hence scan up to the end of the FPGA image and then start loading the Nios firmware, which is supposed to reside just after the FPGA image. When you build a FPGA image that is supposed to be loaded at a non-null epcs address, you need to include a custom bootloader which performs a similar positioning operation from a different address offset. Or simply, like in the example I posted, define a conventional fixed address for firmware position: this somehow wastes some flash memory spaces between fpga and nios image, but makes bootloader much simpler. Moreover you maybe want to be able to update nios firmware while fpga is seldom changed: thus, if you align nios firmware image with one of epcs blocks, you can virtually erase and replace only the nios firmware image. - Altera_Forum
Ok, thanks a lot for your help cris72.
- Altera_Forum
Cris72, when I try to select my first FPGA image at 0 or my second one at 0x400000 with Remote Update core,
I still have this value 8 for the register 0x4 of the remote update core, IORD(REMOTE_UPDATE_CYCLONEIII_BASE, 0x4). Don't you any idea where can be the problem ? - Altera_Forum
I'm not sure, but you probably need to put read_source=01 in order to read the boot register content.
Try IORD(REMOTE_UPDATE_CYCLONEIII_BASE, 0xC) If this doesn't work either, I believe you have some error in remote update connection to your Nios system. Please note that Fmax for remote update core on CycloneIII devices is 40MHz which is lower than the common range of system frequency (50 to 100MHz). So you normally need a lower frequency clock and a clock bridge in your Nios system. - Altera_Forum
Ok cris72 for Frequency of the remote update core on Cyclone III it was already set under 40 Mhz in the SOPC builder ;
where do I put read_source=01 and what does it correspond to ? Is it in my Nios C code or somewehere else ? There is something strange that happens when I read register 0xC, at first it's still 0x8 even when I try to reconfigure to address 0x400000, but when I erase the byte at 0x400000 and do a reconfig then I have the value 0x400000 in my 0xC register ? - Altera_Forum
Frequency for remote update core is 25 MHz, at first register 0xC = 3, 0x4 = 0, after reconfig register 0xC = 8 and 0x4 = 8,
when I erase byte at address 0x400000, register 0xC = 0x400000, 0x4 = 0. In reality to read boot register which register do I have to read 0xC or 0x4 ? - Altera_Forum
read_source isn't it in the VHDL code source ?
