Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

NIOS II and Cyclone III Remote Update

Altera_Forum
Honored Contributor II
8,289 Views

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! 

0 Kudos
69 Replies
Altera_Forum
Honored Contributor II
683 Views

:):) 

 

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.
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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 ?
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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 ?
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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!
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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 !
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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 ?
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

Just had to remove db and incremental db folders in my quartus project to run fitter without problems and start assembler after. 

Thank you
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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 ?
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

Could somebody could explain me please, because I don't really understand what is happening ?

0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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) ?
0 Kudos
Altera_Forum
Honored Contributor II
683 Views

Sorry if I look lost...

0 Kudos
Altera_Forum
Honored Contributor II
683 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
672 Views

So the remote update only enables to read position of FPGA configuration image and can't change it ! if I well understand

0 Kudos
Altera_Forum
Honored Contributor II
672 Views

So 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
0 Kudos
Reply