Coverting/Combining SOF and ELF for EPCS

Altera_Forum · ‎11-02-2005

I have developed a NIOS II module with some of my custom made components.

It synthesizes into a .sof file.

I develop some C code to run on this particular core. This is compiled into

an .elf file.

I want to be able to dynamically update the EPCS controller.

In order to do this I send data through the UART to reprogram with.

My questions are:

1.How do I combine my .sof and .elf file to form one binary file so I just

write bytes of data to the EPCS controller? What form should they take?

What do they need to be translated into?

2.Where on the EPCS controller do I write this data? What offset/address

should I use?

Any and all information helpful.

Thanks,

Trey

Altera_Forum · ‎11-03-2005

Trey,

Altera provides two converters: sof2flash and elf2flash. Creating a project in NIOS II IDE will generate a script file with appropriate parameters.

I've written a short programme in C to concatenate the resulting two S-records into one single binary file, which represents an EPCS image and can be used to update both FPGA configuration and booting firmware. You can add a call in a script file running in NIOS SDK shell. If you are interested, tell me where I can send it to.

Mike

Altera_Forum · ‎11-03-2005

Hi,

> Where on the EPCS controller do I write this data?

> What offset/address should I use?

The device configuration starts at offset zero. The (binary) flash contents

start immediately after the configuration data. If you want to look at some sample

code that shows how to find the end of the configuration data, take a look at the

epcs bootloader code (assembly) or the epcs code in u-boot ©.

Regards,

--Scott

Altera_Forum · ‎11-03-2005

--- Quote Start ---

originally posted by smcnutt@Nov 3 2005, 07:58 AM

hi,

> where on the epcs controller do i write this data?

> what offset/address should i use?

the device configuration starts at offset zero. the (binary) flash contents

start immediately after the configuration data. if you want to look at some sample

code that shows how to find the end of the configuration data, take a look at the

epcs bootloader code (assembly) or the epcs code in u-boot ©.

regards,

--scott

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=10769)

--- quote end ---

--- Quote End ---

Hey Scott,

Thanks for the information.

So I will figure out how to find the end of the configuration data by looking

at the epcs bootloader code.

I still have questions about what to write, and where to write it.

What comes right after the configuration data? The .elf or the .sof?

After that (.elf or .sof) is written what comes after that? Is it written immediatly one after the other?

Is there code to concatenate both the .elf and .sof into one image that gets

written after the configuration data?

Any and all information helpful.

Thanks,

Trey

P.S. It seems like enough people ask similar questions that there would be a

document spelling this out. Does such a document exist?

Altera_Forum · ‎11-04-2005

Hi Trey,

> What comes right after the configuration data? The .elf or the .sof?

When I refer to the "configuration data", I'm talking about the data contained in

the sof (or pof) that is used to program the FPGA (the logic you're downloading).

This data is contained in a data "packet" within the pof/sof file and ends up

getting programmed starting at offset zero in the epcs device. The length of this

data can be determined from header information contained in the data itself:

Here's a snippet from the u-boot sources. Assume that the fist 128 bytes

of the epcs memory were read into a buffer (buf), and that 'sz' is an

32-bit unsigned value. Also, assume that the bit-reversals have already been

performed.

/* Search for the starting 0x6a which is followed by the
 * 4-byte &#39;register&#39; and 4-byte bit-count.
 */
p = buf;
while (p < buf + sizeof(buf)-8) {
    if ( *p == 0x6a ) {
        /* Point to bit count and extract */
        p += 5;
        sz = *p++;
        sz |= *p++ << 8;
        sz |= *p++ << 16;
        sz |= *p++ << 24;
        /* Convert to byte count */
        sz += 7;
        sz >>= 3;
        break;
    } else if (*p == 0xff) {
        /* 0xff is ok ... just skip */
        p++;
        continue;
    } else {
        /* Not 0xff or 0x6a ... something&#39;s not
         * right ... report &#39;unknown&#39; (sz=0).
         */
        break;
    }
}
return (sz);

The 'elf' sections immediately follow the FPGA configuration data. So, if the size

of your configuration data is 0x1008c for example, the Nios-II elf sections start

at offset 0x1008c in the epcs device. NOTE: The Nios-II application is not stored

elf format ... it is insted, a sequence of length-address-data records so the loader

can load individual sections to the appropriate addresses. This conversion (from elf

to length-address-data) occurs during elf2flash.

> Is there code to concatenate both the .elf and .sof into one image that gets

> written after the configuration data?

If your goal continues to be a single binary file that contains both configuration and

Nios-II application data for run-time updates, I would recommend you discuss this

more with Mike -- and take him up on his code offer -- and his experience with

this -- I'm sure Mike can steer you away from alot of "gotchas".

Regards,

--Scott

Altera_Forum · ‎11-04-2005

Hey Scott,

I have further questions and they are detailed in red below.

Thanks again for the information, it is most helpful.

-Trey

Hi Trey,

> What comes right after the configuration data? The .elf or the .sof?

When I refer to the "configuration data", I'm talking about the data contained in

the sof (or pof) that is used to program the FPGA (the logic you're downloading).

This data is contained in a data "packet" within the pof/sof file and ends up

getting programmed starting at offset zero in the epcs device. The length of this

data can be determined from header information contained in the data itself:

So in the code below you are parsing data that is in the .sof

file and not the actual memory of the EPCS, correct?

If this is the case then have you run the .sof through sof2flash, or

something else?

Also you mention that I start programming the EPCS at offset 0.

Is offset 0 on the EPCS writable? I try and change its value and I always

read a value of 0x8A. I can change the value at other locations on the EPCS

flash so maybe I am missing something.

Here's a snippet from the u-boot sources. Assume that the fist 128 bytes

of the epcs memory were read into a buffer (buf), and that 'sz' is an

32-bit unsigned value. Also, assume that the bit-reversals have already been

performed.

/* Search for the starting 0x6a which is followed by the
 * 4-byte &#39;register&#39; and 4-byte bit-count.
 */
p = buf;
while (p < buf + sizeof(buf)-8) {
    if ( *p == 0x6a ) {
        /* Point to bit count and extract */
        p += 5;
        sz = *p++;
        sz |= *p++ << 8;
        sz |= *p++ << 16;
        sz |= *p++ << 24;
        /* Convert to byte count */
        sz += 7;
        sz >>= 3;
        break;
    } else if (*p == 0xff) {
        /* 0xff is ok ... just skip */
        p++;
        continue;
    } else {
        /* Not 0xff or 0x6a ... something&#39;s not
         * right ... report &#39;unknown&#39; (sz=0).
         */
        break;
    }
}
return (sz);

The 'elf' sections immediately follow the FPGA configuration data. So, if the size

of your configuration data is 0x1008c for example, the Nios-II elf sections start

at offset 0x1008c in the epcs device. NOTE: The Nios-II application is not stored

elf format ... it is insted, a sequence of length-address-data records so the loader

can load individual sections to the appropriate addresses. This conversion (from elf

to length-address-data) occurs during elf2flash.

So just to clear on this, the .elf data comes IMMEDIATELY after the .sof data.

Meaning the byte after the last byte of data of the .sof is .elf data, regardless

of boundries?

> Is there code to concatenate both the .elf and .sof into one image that gets

> written after the configuration data?

If your goal continues to be a single binary file that contains both configuration and

Nios-II application data for run-time updates, I would recommend you discuss this

more with Mike -- and take him up on his code offer -- and his experience with

this -- I'm sure Mike can steer you away from alot of "gotchas".

Regards,

--Scott

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=10791)</div>

Altera_Forum · ‎11-04-2005

Hi Trey,

> So in the code below you are parsing data that is in the .sof

> file and not the actual memory of the EPCS, correct?

No, it's parsing data that was read directly from the epcs device (after the necessary

bit reversal) into a buffer in the Nios-II memory space.

> Also you mention that I start programming the EPCS at offset 0.

> Is offset 0 on the EPCS writable?

Yes ... provided the sector is not protected.

> I try and change its value and I always read a value of 0x8A. I can change the

> value at other locations on the EPCS flash so maybe I am missing something.

You need to make sure the sector is not protected ... then erase the sector ... then

write your data. If you don't erase, you can only change a 1 to a 0.

> So just to clear on this, the .elf data comes IMMEDIATELY after the .sof data.

Yes

> Meaning the byte after the last byte of data of the .sof is .elf data, regardless

> of boundries?

Yes. The byte immediately following the sof data is the first byte of the length field.

Each record in the sequence is formatted as:

length - 4 bytes

address - 4 bytes

data - 'length' bytes of data

If the length is zero, the address is the entry point (target address of a JMP).

Take a look at boot_loader.S and boot_loader_epcs_bits.S in:

nios2\components\altera_nios2\sdk\src\boot_loader_sources to see how the

data is organized.

If you want to experiment with this you can use u-boot ... it has full command line

support for epcs read, write, protect, erase, programe etc ... and the 'epcs info' command provides the length of the configuration data. You can use u-boot's

kermit or tftp support to load your binary files onto your target ... or you can

just hoist some of the u-boot code to play with or just review.

Regards,

--Scott

Altera_Forum · ‎08-24-2006

--- Quote Start ---

originally posted by smcnutt@Nov 4 2005, 02:29 PM

...snip...

> so just to clear on this, the .elf data comes immediately after the .sof data.

...snip...

regards,

--scott

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=10806)

--- quote end ---

--- Quote End ---

This is all well and fine, but what if you want to control where the ELF is loaded?

Let's say you want to reserve some portion of the EPCS device for HW, and then have the SW start at the next sector past that - certainly, so that the beginning of the ELF (software) isn't in the same sector as the HW (configuration).

How do you...

a ) Control the offset in the EPCS (or any flash) where the software is placed. This is different from where it's going to be located once it's loaded into RAM - we don't care about that - we need to specify PUT THE SOFTWARE IN THE EPCS AT OFFSET BLAH.

b ) Tell the bootloader this offset.

c ) Be able to tell where in the EPCS the code is loaded from - from the application itself. If this is not possible, we could use the hard coded value from step "a", but it would be really nice to figure that out for step "a" and then have everything else just configure automagically.

This stuff is "cake factor infinite (facile)" for a traditional microcontroller based design, but seems quite obtuse in the Nios environment. I've looked for stuff on EPCS, flash in general, etc., and I completely grok how to write stuff to specific addresses in flash, how to get information about a flash device, etc., but finding ANYTHING that documents how to get the build process to put stuff at specific addresses in the EPCS.

Also, our rep tells us that for the part we have, there is some finite limit as to how big the hardware configuration can be, and that's not the same thing as the number of LEs, etc. This could be helpful in determining where we want to start putting code (like the sector after that). How do we find that out?

Thanks

Greg

Altera_Forum · ‎08-25-2006

--- Quote Start ---

originally posted by ghavenga@Aug 24 2006, 03:41 PM

a ) control the offset in the epcs (or any flash) where the software is placed. this is different from where it's going to be located once it's loaded into ram - we don't care about that - we need to specify put the software in the epcs at offset blah.

b ) tell the bootloader this offset.

c ) be able to tell where in the epcs the code is loaded from - from the application itself. if this is not possible, we could use the hard coded value from step "a", but it would be really nice to figure that out for step "a" and then have everything else just configure automagically.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17819)

--- quote end ---

--- Quote End ---

Greg, not sure why you want to do this - it would be easier to reserve space for whatever you want to do inside your firmware image or at the very end of everything. I'm assuming that you want to keep the FPGA config and some other data together in the EPCS and change the firmware image independently of those other two items.

Keep in mind that the EPCS is two things:

1) a magic device to load FPGA configuration. If I'm not mistaken the FPGA automatically loads from EPCS starting at offset 0 so you can regard that as a given

2) a general purpose serial flash device where you can write and read (using the HAL flash API) whatever you want following the FPGA config.

To address your questions:

a) I haven't tried this but you should be able to use the flash programmer to write any location in the EPCS, given the right command line options.

http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif The bootloader in question is part of your NIOS design. I think it's inside the EPCS component so you'd have to dig up the sources of the bootloader (e.g. components/altera_nios2/sdk/src/boot_loader_sources/boot_loader_epcs_bits.S) and modify it to boot from a specific address instead of directly after the FPGA config file. I could envision different ways of configuring that address but the simplest approach would be to write some additional bytes directly following the FPGA config bytes that say "skip n bytes to get to the beginning of the image."

If you haven't done so already, take a look at boot_loader_epcs_bits.S. I think this is the code that ends up in the EPCS component itself and is compiled into the FPGA configuration so that's where you'd have to add code to support the reserved gap you're after. I haven't looked at how the bootloader ends up inside the FPGA configuration image but it must be part of the SOPC compile process.

c) Once you've modified boot_loader_epcs_bits.S you should have some fixed location inside the EPCS component itself that you can read with normal I/O operations. Again, I haven't done this but I can't see why it shouldn't work.

Good luck and keep us posted,

Andrew

Altera_Forum · ‎08-28-2006

--- Quote Start ---

originally posted by queisser+aug 25 2006, 05:38 pm--><div class='quotetop'>quote (queisser @ aug 25 2006, 05:38 pm)</div>

--- quote start ---

<!--quotebegin-ghavenga@Aug 24 2006, 03:41 PM

a ) control the offset in the epcs (or any flash) where the software is placed. this is different from where it's going to be located once it's loaded into ram - we don't care about that - we need to specify put the software in the epcs at offset blah.

b ) tell the bootloader this offset.

c ) be able to tell where in the epcs the code is loaded from - from the application itself. if this is not possible, we could use the hard coded value from step "a", but it would be really nice to figure that out for step "a" and then have everything else just configure automagically.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17819)

--- quote end ---

--- Quote End ---

Greg, not sure why you want to do this - it would be easier to reserve space for whatever you want to do inside your firmware image or at the very end of everything. I'm assuming that you want to keep the FPGA config and some other data together in the EPCS and change the firmware image independently of those other two items.

Keep in mind that the EPCS is two things:

1) a magic device to load FPGA configuration. If I'm not mistaken the FPGA automatically loads from EPCS starting at offset 0 so you can regard that as a given

2) a general purpose serial flash device where you can write and read (using the HAL flash API) whatever you want following the FPGA config.

To address your questions:

a) I haven't tried this but you should be able to use the flash programmer to write any location in the EPCS, given the right command line options.

http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/cool.gif The bootloader in question is part of your NIOS design. I think it's inside the EPCS component so you'd have to dig up the sources of the bootloader (e.g. components/altera_nios2/sdk/src/boot_loader_sources/boot_loader_epcs_bits.S) and modify it to boot from a specific address instead of directly after the FPGA config file. I could envision different ways of configuring that address but the simplest approach would be to write some additional bytes directly following the FPGA config bytes that say "skip n bytes to get to the beginning of the image."

If you haven't done so already, take a look at boot_loader_epcs_bits.S. I think this is the code that ends up in the EPCS component itself and is compiled into the FPGA configuration so that's where you'd have to add code to support the reserved gap you're after. I haven't looked at how the bootloader ends up inside the FPGA configuration image but it must be part of the SOPC compile process.

c) Once you've modified boot_loader_epcs_bits.S you should have some fixed location inside the EPCS component itself that you can read with normal I/O operations. Again, I haven't done this but I can't see why it shouldn't work.

Good luck and keep us posted,

Andrew

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17847)</div>

[/b]

--- Quote End ---

I also want to programme EPCS from code already running from RAM (receiving the new code via a network interface). I'm not too worried about separating FPGA code and NIOS code, but I AM confused by the boot loader :

1. Is the boot loader code always the same ? (so doesnt vary with .elf section sizes and locations etc)

2. How does the boot loader code get programmed ? API ref says its read only at the first 256 words of the EPCS map - how are these accessible ? do they overlay the start of the "real" flash array ? The docs imply the bootloader lives in a ROM, which is part of the EPCS controller on the FPGA (not in the EPCS), however its clearly programmable, as the code file is a parameter to elf2flash....

3. So what I'm really asking is : if I want to re-programme FPGA code and/or NIOS ROM code from NIOS (RAM) code, what do I do about the boot loader to make sure my new code gets properly copied to RAM ?

AlanB

Altera_Forum · ‎08-28-2006

--- Quote Start ---

originally posted by alanball@Aug 28 2006, 07:22 AM

i also want to programme epcs from code already running from ram (receiving the new code via a network interface). i'm not too worried about separating fpga code and nios code, but i am confused by the boot loader :

1. is the boot loader code always the same ? (so doesnt vary with .elf section sizes and locations etc)

2. how does the boot loader code get programmed ? api ref says its read only at the first 256 words of the epcs map - how are these accessible ? do they overlay the start of the "real" flash array ? the docs imply the bootloader lives in a rom, which is part of the epcs controller on the fpga (not in the epcs), however its clearly programmable, as the code file is a parameter to elf2flash....

3. so what i'm really asking is : if i want to re-programme fpga code and/or nios rom code from nios (ram) code, what do i do about the boot loader to make sure my new code gets properly copied to ram ?

alanb

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17905)

--- quote end ---

--- Quote End ---

Hi Alan,

1) The boot loader is independent of the number of sections and sizes. It simply loops through the sections and copies them to where they are supposed to end up in ram. There are two boot loaders that come with the standard NIOS environment, one for EPCS and one for CFI flash.

Below is a comment snipped from boot_loader.S that explains the section headers used for copying:

// |
// | dvb2004: Each "program record" looks like so:
// |          4 bytes Length L
// |          4 bytes Address A
// |
// | Generally, the next L bytes are then shoveled out
// | of flash (cfi or epcs) and stashed at authentic
// | RAM address A.
// |
// | If L is zero, then A is an address to JUMP to for your
// | application to execute.
// |
// | If L is 0xffffFFFF, then we ignore A and halt. This lets
// | an erased flash memory behave safely, and allows an EPCS
// | to contain a sof file but no program (we&#39;ll write the four
// | bytes of F when we program the sof).
// |
//
// optimized by kds 2004.
// updated in prep for the new MMU addressing scheme, by kds 2004.

following that comment you can see the source for copying and jumping to the start address. There are some macros in uppercase that point to either EPCS or CFI routines, depending on your build options.

2) If you compile for EPCS you end up with the boot loader inside the EPCS component, e.g. in a "ROM" section inside the FPGA. I think, but haven't verified this, that the make files generate the rom code file that gets compiled into the FPGA. You can access those at the base address of the EPCS component.

3) This is a tricky question I've wondered about myself. If you really want to reprogram the FPGA from the NIOS itself I think you only have one option: burn your code into EPCS, reboot and cross your fingers. Since the intial FPGA load from EPCS is automatic you don't have to do anything at all but the flipside is that you have no way of selecting a "safe" configuration unless you have two EPCS chips or external logic to boot an alternative config, as in the NIOS dev board.

To address your question about the boot loader - if you have an FPGA configuration file with a valid EPCS controller you don't have to worry about the boot loader since it will already be part of the FPGA image. I'm assuming that your new FPGA image will be created externally by the standard NIOS tools and then somehow shuttled into your RAM from where the NIOS can program it into the EPCS chip. At that point you're done - the next reboot will start up the boot loader and the boot loader will attempt to copy your application program from wherever you set the reset vector - either EPCS following the FPGA image or some other address that points to a valid NIOS application (CFI, ROM, etc.)

I'm about to attempt just what you're describing as part of my current project so I should be able to write more about it shortly.

Andrew

Altera_Forum · ‎08-28-2006

--- Quote Start ---

originally posted by queisser+aug 28 2006, 04:06 pm--><div class='quotetop'>quote (queisser @ aug 28 2006, 04:06 pm)</div>

--- quote start ---

<!--quotebegin-alanball@Aug 28 2006, 07:22 AM

i also want to programme epcs from code already running from ram (receiving the new code via a network interface). i'm not too worried about separating fpga code and nios code, but i am confused by the boot loader :

1. is the boot loader code always the same ? (so doesnt vary with .elf section sizes and locations etc)

2. how does the boot loader code get programmed ? api ref says its read only at the first 256 words of the epcs map - how are these accessible ? do they overlay the start of the "real" flash array ? the docs imply the bootloader lives in a rom, which is part of the epcs controller on the fpga (not in the epcs), however its clearly programmable, as the code file is a parameter to elf2flash....

3. so what i'm really asking is : if i want to re-programme fpga code and/or nios rom code from nios (ram) code, what do i do about the boot loader to make sure my new code gets properly copied to ram ?

alanb

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17905)

--- quote end ---

--- Quote End ---

Hi Alan,

1) The boot loader is independent of the number of sections and sizes. It simply loops through the sections and copies them to where they are supposed to end up in ram. There are two boot loaders that come with the standard NIOS environment, one for EPCS and one for CFI flash.

Below is a comment snipped from boot_loader.S that explains the section headers used for copying:

// |
// | dvb2004: Each "program record" looks like so:
// |          4 bytes Length L
// |          4 bytes Address A
// |
// | Generally, the next L bytes are then shoveled out
// | of flash (cfi or epcs) and stashed at authentic
// | RAM address A.
// |
// | If L is zero, then A is an address to JUMP to for your
// | application to execute.
// |
// | If L is 0xffffFFFF, then we ignore A and halt. This lets
// | an erased flash memory behave safely, and allows an EPCS
// | to contain a sof file but no program (we&#39;ll write the four
// | bytes of F when we program the sof).
// |
//
// optimized by kds 2004.
// updated in prep for the new MMU addressing scheme, by kds 2004.

following that comment you can see the source for copying and jumping to the start address. There are some macros in uppercase that point to either EPCS or CFI routines, depending on your build options.

2) If you compile for EPCS you end up with the boot loader inside the EPCS component, e.g. in a "ROM" section inside the FPGA. I think, but haven't verified this, that the make files generate the rom code file that gets compiled into the FPGA. You can access those at the base address of the EPCS component.

3) This is a tricky question I've wondered about myself. If you really want to reprogram the FPGA from the NIOS itself I think you only have one option: burn your code into EPCS, reboot and cross your fingers. Since the intial FPGA load from EPCS is automatic you don't have to do anything at all but the flipside is that you have no way of selecting a "safe" configuration unless you have two EPCS chips or external logic to boot an alternative config, as in the NIOS dev board.

To address your question about the boot loader - if you have an FPGA configuration file with a valid EPCS controller you don't have to worry about the boot loader since it will already be part of the FPGA image. I'm assuming that your new FPGA image will be created externally by the standard NIOS tools and then somehow shuttled into your RAM from where the NIOS can program it into the EPCS chip. At that point you're done - the next reboot will start up the boot loader and the boot loader will attempt to copy your application program from wherever you set the reset vector - either EPCS following the FPGA image or some other address that points to a valid NIOS application (CFI, ROM, etc.)

I'm about to attempt just what you're describing as part of my current project so I should be able to write more about it shortly.

Andrew

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17908)</div>

[/b]

--- Quote End ---

Hi Andrew

Nice to see the forum is alive - even on a Public Holiday (in UK anyway) !

I think I'm convinced about the boot loader just being a fixed piece of code for each type of boot device (EPCS or CFI) - in my case there is a small file called "epcs_controller_boot_rom.hex" in the FPGA directory, which gets updated whenever the system is regenerated via SOPC builder. I assume this gets incorporated into the .sof/.pof file when the FPGA is recompiled and so ends up in the <FPGA_name>.flash file generated by sof2flash (I'll probably stick with the same file/format, even though I'm going to re-programme via software rather than flash programmer/JTAG). As you say, this means the boot loader is always present, and is sort of "off to one side" of the EPCS (or CFI) FLASH array, and is actually located in a ROM (i.e. RAM masquerading as ROM) in the FPGA device

The only confusion remaining (assuming all the above is true) is the flash programmer User Guide. This states "elf2flash also inserts a boot copier into the flash file if required.....it also translates the application code .elf file to a boot record for use by the boot copier.." If I read it right, all this only applies to CFI, not EPCS, so I propose to ignore it, and hope it goes away !

However, if the above IS true it implies that somehow the boot copier can be (MUST be) programmed from the contents of the flash file, but the boot copier area is read only !

I plan to continue to use sof2flash and elf2flash to generate .flash (S-record) files and then download these over Ethernet to code running on the NIOS which wil then simply programme them (via the EPCS HAL functions) to the addresses contained in the S-Records. Though somewhat inefficient, this should be safer/quicker to dev, since it will faithfully replicate any manipulation going on "behind the scenes" in elf2flash, which I might otherwise miss.

You're right about it being a little worrisome only having a single FPGA image to boot from, but at least it can be thoroughly read-back and checked by the software after an update - it's the old "flash your PC BIOS" problem - you'd better hope it completes !

Do you know if there's a way to initiate FPGA (re)configuration cleanly from software/firmware ? (alt_shoot_yourself_in_foot perhaps)

Alan

Altera_Forum · ‎08-28-2006

--- Quote Start ---

originally posted by alanball@Aug 28 2006, 11:12 AM

hi andrew

nice to see the forum is alive - even on a public holiday (in uk anyway) !

--- Quote End ---

Working day for us in the U.S. but we have next Monday off!

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

The only confusion remaining (assuming all the above is true) is the flash programmer User Guide. This states "elf2flash also inserts a boot copier into the flash file if required.....it also translates the application code .elf file to a boot record for use by the boot copier.." If I read it right, all this only applies to CFI, not EPCS, so I propose to ignore it, and hope it goes away !

However, if the above IS true it implies that somehow the boot copier can be (MUST be) programmed from the contents of the flash file, but the boot copier area is read only ![/b]

--- Quote End ---

The way I understand this is that elf2flash finds all the sections in your .elf file (the ones you'd see in the map file) and generates a map of the sections that can be read by the boot loader. If you're booting from CFI elf2flash prepends the boot loader code itself and when all that is done generates a S-Record file starting at offset 0 with the boot loader, boot record and the actual code itself. For EPCS booting only the boot record with the section addr/lengths is prepended.

We currently use a utility that converts the flash.flash file to a flat binary file (I think it's called srec_cat from the open-source SRecord project) and then I simply use the flash API to burn that into our CFI flash at offset 0. I've never seen it fail so that tells me the flash.flash is a faithful representation of what needs to be in flash at the time the NIOS boots.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

I plan to continue to use sof2flash and elf2flash to generate .flash (S-record) files and then download these over Ethernet to code running on the NIOS which wil then simply programme them (via the EPCS HAL functions) to the addresses contained in the S-Records. Though somewhat inefficient, this should be safer/quicker to dev, since it will faithfully replicate any manipulation going on "behind the scenes" in elf2flash, which I might otherwise miss.[/b]

--- Quote End ---

Yes, that's what I eventually want to do as well. Although transferring SRecords is less efficient it does have the advantage of lots of checksums and, as you say, the future possibility of placing records other places in flash. You could, for instance, put your program code and some fixed data elsewhere in flash and have all that in one S-Record file. Presently elf2flash doesn't seem to take advantage of that and simply generates one long contiguous stream starting at offset 0.

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Do you know if there's a way to initiate FPGA (re)configuration cleanly from software/firmware ? (alt_shoot_yourself_in_foot perhaps)[/b]

--- Quote End ---

Not as far as I know but I only know about the Cyclone FPGA series. On those chips external pins decide when and how to boot so you'd need some additional external logic to force a reboot. It's possible that other FPGA architectures have features to support a clean restart.

Andrew

Altera_Forum · ‎08-28-2006

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Do you know if there's a way to initiate FPGA (re)configuration cleanly from software/firmware ? (alt_shoot_yourself_in_foot perhaps)[/b]

--- Quote End ---

Most of the Altera designs do this by using the "reconfig_request" PIO. On the Altera boards, this pin is connected to a small design in an on-board Max device. Though I've not tried it, you should be able to do something similar by routing your nConfig pin to another I/O pin on your FPGA.

Cheers,

- slacker

Altera_Forum · ‎08-29-2006

--- Quote Start ---

originally posted by slacker@Aug 28 2006, 08:38 PM

<div class='quotetop'>quote

--- quote end ---

--- quote start ---

do you know if there's a way to initiate fpga (re)configuration cleanly from software/firmware ? (alt_shoot_yourself_in_foot perhaps)

--- Quote End ---

Most of the Altera designs do this by using the "reconfig_request" PIO. On the Altera boards, this pin is connected to a small design in an on-board Max device. Though I've not tried it, you should be able to do something similar by routing your nConfig pin to another I/O pin on your FPGA.

Cheers,

- slacker

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=17915)</div>

[/b]

--- Quote End ---

Well, to my (slight) surprise, and credit where credit is due, I got a very prompt and clear response from Altera on this (raised SR early yesterday), basically confirming everything Andrew says above - always nice to get the same answer from two sources. My confusion over the Flash Programmer User Guide is as much mis-reading as anything - it's not obvious throughout the doc that flashing the bootloader is only needed for CFI

Turns out the ability to re-configure "on demand" is present on Stratix/Stratix II/GX chips which have a dedicated remote config control block. Not much help to me with my already manufactured Cyclone II-based design, but hey-ho .....

Hey guys - thanks a LOT for the valuable help !

Alan