Coverting/Combining SOF and ELF for EPCS

--- 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&#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

<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&#39;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&#39;ll probably stick with the same file/format, even though I&#39;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&#39;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&#39;s the old "flash your PC BIOS" problem - you&#39;d better hope it completes !

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

Alan

--- 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&#39;d see in the map file) and generates a map of the sections that can be read by the boot loader. If you&#39;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&#39;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&#39;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&#39;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&#39;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&#39;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&#39;d need some additional external logic to force a reboot. It&#39;s possible that other FPGA architectures have features to support a clean restart.

Andrew

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

--- Quote Start ---

Do you know if there&#39;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&#39;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

--- 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&#39;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&#39;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&#39;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