Does the 'remote update' block actually work on Cyclone V?

[Altera_Forum]

I'm trying to get the 'remote update' (ie the reload the fpga from EPCQ) block to work on a cyclone V using quartos 14.1. 

 I've managed to expose the epcq pins to 'user' logic and can successfully update the epcq from a .pof file. (If you add the 'JTAG to EPCQ bridge' you get an option to expose the pins that generates a 'test_sfl' component.)  I've also instanciated the 'remote update' block and linked it to an avalon slave. If I then try to read any of the 'parameters' (aka registers) I get 1s for all the defined bits and 0s for the others (so parameter 0 (reset reason) returns 0x1f). Writes to 'page select' are ignored (reads back 0xffffff).  Looking inside the remote update block there is a 'CYCLONEV_RUBLOCK' block. With signaltap I can see some serialised accesses to the block - including my write data, but the output bitstream is always 1s.  I've not tried to force a reconfig - I want to know I've set the base address first.  Anyone any ideas?   David  FWIW: Getting factory/user images to be useful is going to be 'interesting' since we are (effectively) a PCIe card. We may load the 'user' image on request from the Linux kernel - when we can reprobe the PCIe bus.

[Altera_Forum]

Are you reading the boot address during in factory image or in application image? Typically you should the boot address during in application image.

[Altera_Forum]

I have used the remote update block successfully in a couple Cyclone-V projects, so it does seem to work.

[Altera_Forum]

Yes, the Remote Update Block works fine in Quartus 14.1 

I use the new Altera Serial Flash Loader whereby is much easier to handle Factory and Application images for FPGA configuration and Nios firmware. AN-736 (2015.05.26) is strongly recommended!  My testsystem is a Cyclone 5 (5CEFA7) custom hardware with a EPCQ256 (Micron N25Q256A, x4 mode) serial flash device. With QSYS I created a factory and an application design (ru_sopc.jpg). Within the systems are the Serial Flash Loader and the Remopte Update block. For read and write parameters of the Remopte Update block I use an avalon slave (custom hardware). Factory and application design distinguish in nios reset vector and system ID (not necessary). (reset_vect.jpg)  factory reset vector offset 0x410000 application reset vector offset 0x810000  Furthermore two nios eclipse projects whith different BSPs are needed. In the linker script tab of BSP editor you will see the appropriate reset addresses. (offset is added to the base address of SFLs avl_mem). (ru_bsp.jpg)  In the factory project I set the start address for application image (writing 0x570000 to page select parameter at "100") and the AnF Bit to "1" (param "101") Reconfiguration starts with '1' at reconfig input of Remote Update block. (refer Altera Remote Update IP Core User Guide, 2015.06.15) The application project read the system ID and the reconfiguration trigger parameter to verify that the right image was booted.  Compile the projects and generate the .hex files with Make Targets -> Build -> mem_init_generate (refer AN-736).  After creating and fit/compile the projects a .jic file for programming the EPCQ is needed. With Quartus Convert Programming Files utility you can put both images into one file. After adding the flash loader device (5CEFA7) you put the factory .sof in Page_0, start address 0x0 and add the factory .hex file (<SFL-qsys-name>.hex). Create a new SOF page_1 at and choose the start address of application FPGA configuration, in my case 0x570000. Then add the .hex file for application image. The resulting .map file is:  BLOCK START ADDRESS END ADDRESS  Page_0 0x00000000 0x0026CB73 epcs_controller.hex 0x00410000 0x00421F73 Page_1 0x00570000 0x007DB248 epcs_controller.hex 0x00810000 0x00821F0F  (jic_for_C5_remote.jpg)  After programming the .jic and powercycling the hardware I get following messages at my RS232 terminal:  Nios2 Factory Image with SYS ID 0xFF Boot Status 0x0 AnF Bit 0x0 Reconfig Address 0x570000 Nios2 Application Image with SYS ID 0xAA Boot Status 0x4 AnF Bit 0x1  First the factory image is loaded from EPCQ then reconfiguration with application image is done.  Best regards Jens

[Altera_Forum]

DSL, 

 I have to usleep() before I can read back the page select parameter. Without sleep I read 0x0.  Jens

[Altera_Forum]

Ok, at least it isn't completely hosed. 

 Note that I'm not interested in how to write the EPCQ, I've got all that working nicely directly from a host application over PCIe to a custom Avalon slave that will bit-bang 8 nibbles for a 32bit transfer. Updates are dominated by the erase times (even allowing for the pedestrian speed of the reads for verify).  What I'm completely failing to do is get the fpga to reconfigure. The remote update logic (there is a chunk of verilog accessed through a vhdl wrapper) is all present and seems to 'do things' in response to read and write requests (from signaltap), but the whole block seems to be connected to a black hole.  I can't get a sensible value read back from any parameter - I see all 1 bits for the width of the parameter. So I always see 0xffffff for 'page select' and 0x1f for 'reconfig trigger conditions'. Requests to reconfigure are ignored.  Thinks.... I wonder ... In order to access the EPCQ pins we've enabled the 'JTAG to EPCQ' bridge (I've forgotten its proper name) that allows the JTAG interface be used to write the EPCQ while a user image is loaded. I wonder if that has hijacked the 'remote update' logic so that the JTAG interface can request a reconfiguration?

[Altera_Forum]

I'm using remote update block in an embedded device wich is connected to a host PC via Gb-Ethernet. The EPCS contains the factory an application image for Hard- and Firmware. 

Over Ethernet we can update both and trigger a reconfiguration. The access to the rsu block is realized by an avalon slave. The vhdl code is attached. To get the RSU for Cyclone 5 running I used this Wiki: http://www.alterawiki.com/wiki/remote_update_for_cyclone_v  Jens

[Altera_Forum]

Sorry, I'm using Serial Flash Controller (not the loader). So that was wrong in the Post above ... 

 Jens

[Altera_Forum]

I think the vhdl I have is much the same as that referred to by the wiki page. 

Certainly my avalon slave does much the same as the referenced code. I have a bit of nasty logic to divide the Avalon clock down by a factor of 4 (from 62.5MHz to just over 15) but I don't think that is causing grief. (It uses the falling edge to generate a mask for the clock, so removes three of every 4 clock pulses.)

[Altera_Forum]

For the Serial Flash Controller, the RSU block and the Avalon slave I'm using 25 MHz. The rest of QSYS (including Nios2) is clocked by 100 MHz which are generated from the 25 via PLL. 

Clock crossing logic is done by QSYS.

[Altera_Forum]

dsl, Were you able to resolve your issue here? I am having the exact same problem. 

 Edit: I was able to resolve the issue. You must make sure that the Device Configuration mode is set to 'Remote' in the Quartus II software. Doing so allows the Remote Update component to be read/written.

[Altera_Forum]

Just for memo. In case someone have the same problem. 

 For CYCLONE V GX  1.If the nSTATUS pin was clamped up to VCC by external MCU, you would expect to see remote update not working, just hang up/freeze. 2.If you use non-official EPCQ such as N25Q256A, for your AS configuration device, and forget to pull up pin 3(RSTn), your FPGA will not function properly, even not be accessible by JTAG some times. 3.If you select QUAD rather than STANDARD in ALTERA SERIAL FLASH CONTROLLER with those non-official EPCQs, you will not be able to program anything into it by NIOS ii software, but .JIC will be OK, and remote update will be functional.  MT25QL512ABB has different command set with EPCQ512, but working well expect QUAD programming by NIOSii. N25Q256A has the same command set with EPCQ256 but, still not working in QUAD programming by NIOSii.