Running multiple images from EPCS (Factory & User)

Jens, thanks for that, I think i now understand better how the system should work. I have a couple more questions if thats ok..

I've realised the main problem is that my Factory image does not properly initiate the altremote_update reconfiguration into the user image. I've spent the last few hours trying to work out how it should work and reading various manuals but can't get my head round it.

My quartus project for the Factory image is set to configuration scheme "Active Serial" and configuration mode "Remote", the User image is set to "Active Serial" and "Standard". Is this correct? I'm using the SOPC component linked in my previous post from jakobjones which provides a wrapper for the altremote_update block. I have set the altremote_update to use the operation mode "Active_Serial_Remote". This block contains a collection of functions for reading/writing from the block from the C code but i don't really know what they do.

I don't really understand how the various status registers of the remote_update block work

In the post you linked to you say:

--- Quote Start ---

To boot the application image we use the alt_remote_update function. The safe firmware image reads the remote_update status register. In case of power on (status = 0) the remote_update block is configured with the EPCS page address where the application configuration is stored and the watchdog activated. Then the reconfigure input is set to '1'.

--- Quote End ---

This is what i need to do. Could you show me your code for doing these things (setting the EPCS page address, setting the watchdog, initiating reset etc)?

Thanks again,

Andy

Andy, I think it is better when the user image also uses the altremote_update function. You can switsh betweeen the images. In case of a functional error in your user firmware you can fallback to the factory image. I'm using Active Serial and Remote in booth images.

I don't know how your altremote wrapper works. My wrapper has an Avalon Slave Interface which allows to access the altremote register (they called parameter in altremote userguide) and to control the reconfig port.

The only thing what to do is to write the sector address of your user fpga image (not user firmware) on parameter 0x100. When your image is at address 0x300000 then you have to write the sector numer 48 to that parameter. (refer 3. Serial Configuration Devices EPCS1,EPCS4, EPCS16, EPCS64, and EPCS128 Data Sheet, table 3-4 in case of EPCS64).

After parametrizing the sector to boot from you must assert a '1' to the reconfig pin of altremote_update block (this should be done by your wrapper hardware).

Here is the component instantiation in the wrapper. The component was generated with MegaWizard.

	COMPONENT ru_rmtupdt_i7q
	PORT (
			reconfig	: IN STD_LOGIC ;
			param	: IN STD_LOGIC_VECTOR (2 DOWNTO 0);
			reset_timer	: IN STD_LOGIC ;
			read_param	: IN STD_LOGIC ;
			reset	: IN STD_LOGIC ;
			data_in	: IN STD_LOGIC_VECTOR (11 DOWNTO 0);
			busy	: OUT STD_LOGIC ;
			clock	: IN STD_LOGIC ;
			data_out	: OUT STD_LOGIC_VECTOR (11 DOWNTO 0);
			pgmout	: OUT STD_LOGIC_VECTOR (2 DOWNTO 0);
			write_param	: IN STD_LOGIC 
	);
	END COMPONENT;

And here is a little piece of firmware code:

    switch (ulImage) 
    {
        case 0:
        //select factory image
        IOWR_32DIRECT( pParam->Fpga.ulpSOPCBaseAddress, RU_PAGESEL_OFFSET*4, EPCS64_FACT_SECT );
        usleep(100);  
        ulTempReg = IORD_32DIRECT( pParam->Fpga.ulpSOPCBaseAddress, RU_PAGESEL_OFFSET * 4 );
        usleep(100);
        if(ulTempReg != EPCS64_FACT_SECT)
        {
            ulMessageOut( "ReloadFPGA with Factory failed (wrong sector)!\n" );
            return 1;
        }
        //reconfigure
        IOWR_32DIRECT(pParam->Fpga.ulpSOPCBaseAddress, RU_CONFIGURE_OFFSET*4, 0x1);
        usleep(100);
        break;
        case 1:
        //select application image
        IOWR_32DIRECT(pParam->Fpga.ulpSOPCBaseAddress, RU_PAGESEL_OFFSET*4, EPCS64_APP_SECT);
        usleep(100);  
        ulTempReg = IORD_32DIRECT(pParam->Fpga.ulpSOPCBaseAddress, RU_PAGESEL_OFFSET*4);
        usleep(100);
        if(ulTempReg != EPCS64_APP_SECT)
        {
            ulMessageOut( "ReloadFPGA with Application failed (wrong sector)!\n" );
            return 1;
        }
        //reconfigure
        IOWR_32DIRECT(pParam->Fpga.ulpSOPCBaseAddress, RU_CONFIGURE_OFFSET*4, 0x1);
        usleep(100);
    }

Jens

Thanks for that, I think i get it!

I think i may however have run into a more serious problem. Reading the manual "7.Configuring StratixII and StratixIIGX Devices" I see that the MSEL input pins have to be set accordingly to run remote system upgrade. Table 7-1 says that for Remote system upgrade with AS the value of MSEL[3:0] should be 1110.

The problem is the custom board I am using (not designed by me) does not have any jumpers or switches to configure the input to the MSEL pins. All it has is a three pin header with a jumper which when placed over the leftmost two pins is AS and the rightmost two pins PS. I assume that this is driving a single bit of the MSEL signal with the rest appropriately hardwired to support the modes AS and PS. I know that you cannot see the board but does this sound a reasonable conclusion?

I assume therefore that without being able to correctly set all 4 pins of the MSEL input i won't be able to correctly use the remote update circuitry. Is this correct? Are there any alternative methods I could consider?

Thanks,

Andy

Sorry, what will really help me?

Andy

Or, if you are lucky, it might be 0110 PS with RU and 1110 AS with RU.

- Hippo

Andy, it would really helpful if you can organize the schematic of the board. Then you are able to determine on which MSEL pins you can get access. For example by removing some pullups or changing to pulldowns. May be you must scratch some PCB tracks or sold a new wire from the jumper to GND or VCC ...

For example, if the bord supports the AS (standard, 20MHz) then the MSEL[3..0] are 1101. If you can toggle MSEL0 and MSEL1 then you have the remote mode (1110).

Jens

Hello Jeans,

im using your bootloader sources but I'm getting this msg when I'm trying to compile it:

# 2010.07.21.15.51.27 --- Compiling to obj/boot_loader_epcs.elf

/cygdrive/c/altera/90/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/bin/../lib/gc

c/nios2-elf/3.4.6/../../../../nios2-elf/bin/ld: warning: cannot find entry symbo

l _start; defaulting to 00040000

Is it correct?

And what is the CODE_BASE paramter? Is the offset of the fpga image on the EPCS?

Thanks.

Yes, it seems to be o.k. See attachment with the compile messages in my case.

I don't use the CODE_BASE Parameter. Does the bootloader run on your hardware?

Jens

Hi Jens,

I dont know why its not working for me . Does this bootloader works to Cyclone III?

I'm doing as you said. I'm just using the command "make" without any parameter then I replace the hex file on my Quartus project and recompile it.

To create my bin files I'm doing the following steps:

"$SOPC_KIT_NIOS2/bin/sof2flash" --epcs --compress --input="../../../cloro_gvce.sof" --output="ferro_aport.flash" # Creating .flash file for the project

echo ------------------------------------------------

echo Creating safe and application flash files ...

echo ------------------------------------------------

echo

"$SOPC_KIT_NIOS2/bin/elf2flash" --epcs --input="Cloro_boot.elf" --output="Cloro_boot.flash"

"nios2-elf-objcopy" -I srec -O binary Cloro_boot.flash Cloro_boot.bin

"nios2-elf-objcopy" -I srec -O binary ferro_aport.flash ferro_aport.bin

cat ferro_aport.bin Cloro_boot.bin > fpgaboot.bin

I'm using the flash programmer to program the EPCS.

ferro_aport.bin - offset 0x0 (FPGA IMAGE)

Cloro_boot.bin - offset 0x100000 (EPCS_SRC_ADDR is equal)

When I turn on my board the fpga is configured correctly but is not jumping to my app.

Any idea?

Thanks.

Hi lehagen,

this bootloader is tested just with Stratix2 (S15, S30) devices. I don't know if it works also for Cyclone3. Furthermore I used uncompressed bitstreams. Try this.

In the header (boot_loader.h) are two defines:

in your case, should be correct

# define EPCS_SRC_ADDR 0x100000

in my design EPCS_CONTROLLER is at 0x21000 in the SOPC, 0x400 offset for accessing the registers in the epcs controller

# define EPCS_REGS_BASE 0x00021400

Please verify that.

You should also verify if the nios program is stored correct at 0x100000 in EPCS.

Some additonal informations and example for alternative boot methods you get in AN458.

(http://www.altera.com/literature/lit-an.jsp)

Jens