Coverting/Combining SOF and ELF for EPCS

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