Coverting/Combining SOF and ELF for EPCS

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

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

--- 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?

Hi Trey,

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

When I refer to the "configuration data", I&#39;m talking about the data contained in

the sof (or pof) that is used to program the FPGA (the logic you&#39;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&#39;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 &#39;sz&#39; 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 'register' 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 &#39;elf&#39; 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&#39;m sure Mike can steer you away from alot of "gotchas".

Regards,

--Scott

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&#39;m talking about the data contained in

the sof (or pof) that is used to program the FPGA (the logic you&#39;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&#39;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 &#39;sz&#39; 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 'register' 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 &#39;elf&#39; 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&#39;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>

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&#39;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&#39;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 - &#39;length&#39; 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 &#39;epcs info&#39; command provides the length of the configuration data. You can use u-boot&#39;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

--- 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&#39;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&#39;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&#39;s going to be located once it&#39;s loaded into RAM - we don&#39;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&#39;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&#39;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

--- 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&#39;s going to be located once it&#39;s loaded into ram - we don&#39;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&#39;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&#39;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&#39;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&#39;s inside the EPCS component so you&#39;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&#39;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&#39;s where you&#39;d have to add code to support the reserved gap you&#39;re after. I haven&#39;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&#39;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&#39;t done this but I can&#39;t see why it shouldn&#39;t work.

Good luck and keep us posted,

Andrew

--- 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&#39;s going to be located once it&#39;s loaded into ram - we don&#39;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&#39;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&#39;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&#39;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&#39;s inside the EPCS component so you&#39;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&#39;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&#39;s where you&#39;d have to add code to support the reserved gap you&#39;re after. I haven&#39;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&#39;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&#39;t done this but I can&#39;t see why it shouldn&#39;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&#39;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&#39;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

--- 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&#39;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&#39;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'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&#39;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&#39;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&#39;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&#39;t have to worry about the boot loader since it will already be part of the FPGA image. I&#39;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&#39;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&#39;m about to attempt just what you&#39;re describing as part of my current project so I should be able to write more about it shortly.

Andrew