Honored Contributor
Honored Contributornice 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
