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

[HELP]question about loading different sof+elf files in remote upgrade

Altera_Forum
Honored Contributor II
3,876 Views

hello: 

I've completed the things about loading application sof file in remote upgrade and that is successful.Now I want to load the sof+elf file.How could i do?Can i use the ide flash programmer to write sof+elf files to different address of epcs?And if i can't use the ide flash programmer,how could i write them to the epcs?The requirement of the form of the location of sof+elf files in epcs? 

 

thanks
0 Kudos
29 Replies
Altera_Forum
Honored Contributor II
1,778 Views

First ... have you read this..? 

http://www.altera.com/literature/an/an458.pdf 

 

Here are some things to know: 

1 - The bootloader will expect to see a valid FPGA image at the beginning of the flash. It will read some bits within the FPGA image to determine how long it is. It then jumps to the end of the FPGA image where it expects to see a valid NIOS software image. 

2 - The flash programmer programs the FPGA image into flash. It then calculates how long the image is and programs the software file (ELF) at the address immediately following the FPGA image. 

 

The problem is that the bootloader truly only works at the base address of the flash (first image location). So you've got two problems you need to solve... 

 

1 - How are you going to load multiple SOF+ELF images at different addresses in the EPCS flash? 

2 - Once you've got those images loaded, how are you going to select from and boot them? 

 

. I'll work backwards starting with the bootloader issue. I had to modify the existing bootloader to get it to do what I needed it to do. Since you are going to have to modify the bootloader you can kind of choose how you want things to work. For example, you could completely move away from the scheme where the ELF image follows the SOF image in memory and you could place the ELF images somewhere else in the flash. 

 

. What I chose to do was leave the SOF+ELF files combined and simply change the address of where the bootloader begins looking for the images depending on which image I was running. I only one application image and one safe image. 

 

. The source code for the EPCS bootloader can be found in: 

C:\altera\81\nios2eds\components\altera_nios2\boot_loader_sources 

 

Once you've modified and compiled your new bootloader, you can go into Quartus and override the memory initialization file for the boot RAM inside the EPCS module inside your SoPC system and make it use your compiled MIF instead. 

 

Now on to the file creation. You can use the IDE but I think that's going to be more difficult. It's easier to script things. Here are snippets from my scripts: 

# Creating .flash file for the FPGA configuration echo Creating firmware flash file ... "$SOPC_KIT_NIOS2/bin/sof2flash" --epcs --compress --input="../altera/top.sof" --output="firmware.flash" # Creating .flash file for software code echo Creating safe and application flash files ... "$SOPC_KIT_NIOS2/bin/elf2flash" --epcs --after="firmware.flash" --input="../software/top/Release/top.elf" --output="app.flash" # Convert to binary echo Converting flash files to binary ... nios2-elf-objcopy -I srec -O binary firmware.flash firmware.bin nios2-elf-objcopy -I srec -O binary app.flash app.bin # Concatenate echo Concatenating binary files to create final programming file ... cat firmware.bin app.bin > app_image.bin  

 

The final file "app_image.bin" is simply a binary file. You can then program this file into any location in the EPCS flash. You can use the IDE flash programmer to do this or whatever means you are providing in your application to remote download. 

 

Sorry, I know this is probably a rough overview of a lot of information but I hope it points you in the right direction. Read the referenced document. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Thank u very much.I want to load multiple SOF+ELF images in remote upgrade mode.With your help,now I can write the combined binary file into any location in the EPCS flash.But only the SOF image can be reload.ELF image has no effect.

0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Yes, As I said before, you have to modify the existing bootloader or write your own to be able to boot a different software file. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Thank u,and i have a another question that is if i modify the boot location of the existing bootloader.That is meant that when the system power on,the FPGA always load the application sw image?How is the protection of faliure about load?

0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Use the watchdog timer in the remote update core to handle an application load failure. If the timer expires, the safe image will automatically be reloaded. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Good idea!!!! 

You are a clever man!!!! 

I adore u for your smart!!!! 

Is that meant that the remote update mode is designed only for the sof file not for nios code?
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

The remote update core is only for loading the FPGA image. It has no knowledge about the NIOS processor. That is why you need to create your own bootloader to handle the software aspect of your design.

0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

# Creating .flash file for the FPGA configuration echo Creating firmware flash file ... "$SOPC_KIT_NIOS2/bin/sof2flash" --epcs --compress --input="../altera/top.sof" --output="firmware.flash"# Creating .flash file for software code echo Creating safe and application flash files ... "$SOPC_KIT_NIOS2/bin/elf2flash" --epcs --after="firmware.flash" --input="../software/top/Release/top.elf" --output="app.flash"# Convert to binary echo Converting flash files to binary ... nios2-elf-objcopy -I srec -O binary firmware.flash firmware.bin nios2-elf-objcopy -I srec -O binary app.flash app.bin# Concatenate echo Concatenating binary files to create final programming file ... cat firmware.bin app.bin > app_image.bin  

 

 

jakobjones, 

 

Sorry for the newbie question but, how do you run your script file? 

 

If I open a Nios II Command Shell and type everything in manually, it works. But, I can't figure out how to automate this script.
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

The Nios II command Shell is a cygwin bash shell. So you create and run scripts like any linux shell script. Put the commands into a file with a ".sh" extension. At the very top of the file put a comment like this: 

 

#!/bin/sh 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Thanks Jake! 

 

It's working now. However, I have a couple more questions for you. 

 

Currently we are able to update our firmware (on Cyclone II board) like this: 

1. make the bin file using a script like your's 

2. send the .bin file to the board via TCP/IP using a custom app on the PC 

3. Nios writes the new FW image into EPCS 

4. we hit the reset button to start the new FW 

 

Is there a way to have the board reset and use the new firmware without the user having to hit the reset button? 

 

Also, for production we're looking for a way to write the FW to EPCS via JTAG but w/o the full suite of Quartus/Nios IDE installed. I've read the documentation on using the stand-alone programmer but I'm a little confused about how to get it running. Since the IDE won't be installed, we will not have the NiosII Command Shell. To use the stand-alone programmer, do we need to install a Linux command shell (bash/cygwin?). I'm afraid I just don't know much about Linux (it's "all Windows - all the time" around here). Could you give me some pointers on how get this going? 

 

Thanks
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

1 - You can use the remote update core to trigger a reconfiguration. 

 

2 - What I do for production ... 

. a - Install the Quartus II standalone programmer on the production PC. 

. b - Copy the following files from your development PC and package them with your programming files... 

. nios2-flash-programmer.exe 

. cygwin1.dll 

. jtag_atlantic.dll 

 

This should be all you need to run the nios2 flash programmer on the production PC. It's a whole lot faster than using the jtag indirect method with the quartus II programmer. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Hi Jake, could you please share your modified boot loader? I change the boot_loader_epcs_bits_sii_siii_ciii.S under C:\altera\81\nios2eds\components\altera_nios2\boot_loader_sources, make the boot loader, convert boot_loader_epcs_bits_sii_siii_ciii.elf to hex and then update the SOF but my application image never booted. 

 

I used Cyclone III, EPCS16, factory sof + sw image is at offset 0 of the EPCS while the application sof and its sw image is at offset 0x100000 of the EPCS. 

 

I change line 99 of the assemble code from 

movi r_flash_ptr, 0 

 

to 

movi r_flash_ptr, 0x100000 

 

TIA
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

I will reply to this later today. 

 

Jake 

 

 

--- Quote Start ---  

Hi Jake, could you please share your modified boot loader? I change the boot_loader_epcs_bits_sii_siii_ciii.S under C:\altera\81\nios2eds\components\altera_nios2\boot_loader_sources, make the boot loader, convert boot_loader_epcs_bits_sii_siii_ciii.elf to hex and then update the SOF but my application image never booted. 

 

I used Cyclone III, EPCS16, factory sof + sw image is at offset 0 of the EPCS while the application sof and its sw image is at offset 0x100000 of the EPCS. 

 

I change line 99 of the assemble code from 

movi r_flash_ptr, 0 

 

to 

movi r_flash_ptr, 0x100000 

 

TIA 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Have you or anyone tried to read the Remote Update hardware in the boot loader to get the starting address of the config/software? It seems to me this would make the boot loader generic for anyone using the Remote update allowing the image to be stored at any address in flash and allowing either EPCS or CFI flash to work. 

 

Bill
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

OK, so I made the change (quite simple) to use the Remote Update boot address to boot from. How do I get the new SREC file into the SOF file? I see no options to add a file to the EPCS component. 

 

Bill
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Okay sorry it's taken me so long to respond. So here is the way I do it: 

 

1 - Modify the existing epcs bootloader and compile it. Then create a HEX file out of it (using elf2hex). 

2 - In Quartus, use the assignment editor to override the "INIT_FILE" parameter of the RAM block located inside the EPCS controller. Give it the name of the HEX file you created that contains your bootloader. 

 

So from within Quartus: 

Assignments->Assignment Editor. 

 

The assignment type is "parameter". The parameter name is "INIT_FILE". Here is what an example from one of my QSF files looks like: 

 

set_parameter -name INIT_FILE trio_boot_loader_epcs.hex -to "trio_sopc:trio_sopc_inst|epcs_controller:the_epcs_controller|altsyncram:the_boot_copier_rom"  

 

As far as an example of how to modify the bootloader, I've attached one of mine to this post but I'm afraid I don't have time to explain it and it's not documented. But feel free to ask questions. This specific one is for a Stratix II GX part and works in conjunction with my own remote_update core found here:  

http://www.alteraforum.com/forum/showthread.php?t=3658&referrerid=2226 

I've tried to optimize it for my application so I've stripped out all the code that searched the SOF image looking for a device ID. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Thanks Jake, 

 

I don't understand the usage of the TRIO_USER_IMAGE_PAGE and TRIO_SAFE_IMAGE_PAGE in your bootloader. 

 

And about the reconfig status, let me confirm as following. Am I correct? 

 

0x00: Load factory configuration image upon device power-up 

0x01: Reload factory configuration image upon core nCONFIG assertion 

0x02: Reload factory configuration image upon watchdog timer time out in application configuration image 

0x04: Reload factory configuration image upon nSTATUS assertion in application configuration image 

0x08: Reload factory configuration image upon configuration CRC error during application configuration 

0x10: Reload factory configuration image upon external nCONFIG assertion in application configuration image 

 

 

--- Quote Start ---  

 

// Here is the drill ... 

// If the status word contains a 0x00, or a 0x04, we will load the safe image, 

// If the status word contains a 0x01, 0x02, 0x08, or 0x10, we stay in factory and load 

// the factory software 

 

--- Quote End ---  

I don't understand why we load the safe image if the status word contains a 0x00, or a 0x04?
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

Okay well the bootloader you are looking at was designed to allow me to have two FPGA images in FLASH (safe and user) along with two software images (safe and user). Basically whenever the board first powers up, the safe image is loaded. What we want to do is get the user image up and running as fast as possible. However, there is the possibility that the user image is corrupt. If the user image is corrupt, we want to stay in safe mode and load the safe software. This provides enough functionality so the user can download a new user image to the board. 

 

Now remember this is a stratix II so the registers are not the same as a cyclone III. Here is what the status register bits are for stratix II: 

0x00 - Normal configuration (first boot). 

0x01 - Configuration occured due to a CRC error (we tried to configure and failed). 

0x02 - nStatus caused the reconfiguration (I don't remember what this means. I think this is the case when it was programmed via JTAG). 

0x04 - Core nCONFIG caused the reconfiguration. This is when we triggered the configuration. In other words, I told the FPGA to reconfigure. 

0x08 - nConfig caused the reconfiguration. 

0x10 - A watchdog timeout caused the reconfiguration. 

 

In addition the the status register bits, the Stratix II reconfig core also has a control register with a "AnF" bit that tells whether we're in factory or application mode. 

 

So here is the sequence: 

1 - boot 

2 - Are we in application or factory mode? 

2a - If we are in application (user) mode, we go ahead and load the user software. 

2b - If we are in factory (safe) mode, we continue on. 

3 - Why are we in factory mode? 

3a - If we are in factory mode because of a first boot or because we explicitly triggered a reconfig (like new user code was downloaded), we try to reboot using the application (user) image. 

3b - If we are in factory image because of a failure (watchdog timeout, CRC error, etc.) then we assume that we must have tried to boot the application image but it failed. So we load the factory software image and we're done. It's up to the user to download a new valid application image and try again. 

 

So it looks like there is a typo in my comments and they should read: 

 

--- Quote Start ---  

// If the status word contains a 0x00, or a 0x04, we will load the USER image, 

--- Quote End ---  

 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,778 Views

It's clear now. Thank you very much, Jake.

0 Kudos
Altera_Forum
Honored Contributor II
1,676 Views

avtx30, did you get this going? I'm having trouble reconfiguring and knowing in that load that I'm not in factory mode. Param 0 is always reading 0, not 1 after a reconfigure. Are you having any better luck than I am? 

 

Bill
0 Kudos
Reply