Forum Discussion
Remote update controller issue
Hi everyone,
I'm using the remote update controller (cyclone III) on my Cyclone IV GX dev board with a EPCS128 flash memory. I wish to have two firmwares in my EPCS (factory and application). Actually, I placed the firmware like this in the EPCS: 0x000000 Factory image (hw0 + sw0) 0x440000 Application image (hw1 + sw1) (I'm not using the flash programmer to load the image in flash memory) The nios II boots correctly on the factory image when I start the board. But when I try to reconfig the FPGA with the application image using the remote update controller, the Factory image is loaded... I write 0x110000 to the remote update controller, then start the reconfig for loading the application image. Is this address correct? I think my problem comes when I'm creating the application image. Here is my script to create the .flash: --- Quote Start --- java -jar C:\altera\11.0\nios2eds\bin\sof2flash.jar --epcs --input="..\..\2Dcam.sof" --output="2Dcam_sof.flash" --verbose java -jar C:\altera\11.0\nios2eds\bin\elf2flash.jar --epcs --after="2Dcam_sof.flash" --input="..\2DCam\2DCam.elf" --output="2DCam_elf.flash" --offset 0 rem merge the two files copy /b /y 2Dcam_sof.flash+2DCam_elf.flash 2DCam.flash --- Quote End --- I create factory and application image (.flash) with this script. And load the factory image at address 0x000000 and the application at address 0x440000 in EPCS. Do I have to make something different for the application image, because her address is not 0x000000? Has anyone the same problem? Best regards37 Replies
- Altera_Forum
Honored Contributor
In order to check which bootloader is used from your application program, you can check the hex files for the bootloaders and find a memory location that is different and test on this.
- Altera_Forum
Honored Contributor
Can you send me your customize bootloader (boot_loader_epcs_bits_sii_siii_ciii.S and epcs_controller_boot_rom.hex), please?
- Altera_Forum
Honored Contributor
Here is the file I modified in the boot loader program. I also included the original Altera code from Quartus 8.1. You must change the boot address to your application.
Note that there is a test on the Device ID in the code, so this code will for example not work for Stratix IV without modification. It may however work with cyclone IV. This test on Device ID has been removed in later versions of the boot code from Altera, and you can include my modifications in the new version. I also think you must modify the code if the lower 16 bits in the boot address is not 0. - Altera_Forum
Honored Contributor
Thanks for you reply! I found one different with my file, but it doesn't work.
I have two more questions: 1) --- Quote Start --- elf2hex --input="boot_loader_epcs_sii_siii_ciii.elf" --output="epcs_controller_boot_rom.hex" --base=0 --width=32 --end=1023 --record=4 --lower --- Quote End --- How did you choose the base address and the end address? 2) Is it correct that the bootloader point on the FPGA configuration image and not on the software image, placed just after FPGA configuration image? Thanks Regards - Altera_Forum
Honored Contributor
I have not worked on this for a while and I am not sure, but:
1) The size of the code is less than 1024 bytes (see comments in code) and probably it must fit to a 1024 byte boundary. 2) Yes, the bootloader shall point on the configuration image, not the software. - Altera_Forum
Honored Contributor
I found the problem. It becames when I generate the "epcs_controller_boot_rom.hex" file with the command:
--- Quote Start --- elf2hex --input="boot_loader_epcs_sii_siii_ciii.elf" --output="epcs_controller_boot_rom.hex" --base=0 --width=32 --end=1023 --record=4 --lower --- Quote End --- The "epcs_controller_boot_rom.hex" file was filled with 0. This was the problem. Thank you very much for your help! :) Regards - Altera_Forum
Honored Contributor
hallodu,I am facing the same problem you've described above.
Now, converting my elf file to a bigger hex file, lets say with option --end=10230, my boot hex file is filled with zero until address 0x0400, then starts the bootloader data. But if I try update this hex file on quartus it gets truncated and starts the on_chip_ram at EPCS controller base with 0s. How did you fix it? I am thinking in using the -no-zero-fill option on elf2flash program and editing the addresses and CRC for each line, but there have to be a easier way.. (?) :confused: Thank you in advance :-P - Altera_Forum
Honored Contributor
hallodu
I am also facing the same problem. When I use the following command --- Quote Start --- elf2hex --input="boot_loader_epcs_sii_siii_ciii.elf" --output="kernel_epcs_boot_rom_synth.hex" --base=0 --width=32 --end=1023 --record=4 --lower --- Quote End --- The .hex file is filled by 0. If I add --no-zero-fill option, the .hex file has only one line. Do you fix it? Thank you - Altera_Forum
Honored Contributor
Hi,
Attached is my solution. In the .zip, you have all the files needed for the .bat. 1) Enter your application address (IMAGE_START) in boot_loader_epcs_bits_sii_siii_ciii.S file 2) running this .bat 3) copy SOPC_2Dcam_epcs_flash_controller_0_boot_rom_synth.hex in your <project>/SOPC_folder/synthesis/submodules/ 4) In Quartus, Processing -> Update Memory Initialization File 5) In Quartus, Processing -> Start -> Start Assembler Be careful, the .bat is for Quartus v11.1, if you are using another version. Open the .bat file with a text editor and change all 11.1 with your version number. for example: --- Quote Start --- set PATH=%PATH%;C:\altera\11.1\quartus\bin; -> set PATH=%PATH%;C:\altera\12.0\quartus\bin; --- Quote End --- - Altera_Forum
Honored Contributor
--- Quote Start --- Hi, Attached is my solution. In the .zip, you have all the files needed for the .bat. 1) Enter your application address (IMAGE_START) in boot_loader_epcs_bits_sii_siii_ciii.S file 2) running this .bat 3) copy SOPC_2Dcam_epcs_flash_controller_0_boot_rom_synth.hex in your <project>/SOPC_folder/synthesis/submodules/ 4) In Quartus, Processing -> Update Memory Initialization File 5) In Quartus, Processing -> Start -> Start Assembler Be careful, the .bat is for Quartus v11.1, if you are using another version. Open the .bat file with a text editor and change all 11.1 with your version number. for example: --- Quote End --- Thank you for your reply! I just tried your code and got the correct .hex file. But now I am falling in another confusing issue. This afternoon I found another solution which is more complicate than yours. I just modified the "boot_loader_epcs_bits_sii_siii_ciii.S" file as st_f introduced in# 4 of this thread. After executing "make" command in Shell, I then used this command
to get the address information of the boot loader code. By checking the info.txt file, I found the boot loader codes start at address 0x1054, not 0x0. I have attached the info.txt file. I think that's why the commandnios2-elf-objdump -D boot_loader_epcs_sii_siii_ciii.elf > info.txt
will generate a .hex file with all 0. So I changed the command parameters to "--base=0x1054 --end=1453" and I got the correct boot loader code file(.hex file). I also opened your .bat file and found you use the elf2hex command with "--base=0". But your .bat file can generate the correct .hex file. I want know why this happen and what's the difference? -weielf2hex --input=obj\boot_loader_epcs_sii_siii_ciii.elf --output=kernel_epcs_boot_rom_synth.hex --width=32 --base=0 --end=0x3FF --record=4