Loading SRAM,SDRAM or FLASH on DE1, using Linux, without Qsys, SOPC or NIOS

Hi Andy,

The way a processor normally deals with this boot-strapping issue is;

1) The processor has a memory map. The memory map can contain; on-board RAM/ROM, external Flash, SRAM, SDRAM, etc.

2) When the processor boots, it fetches its first instructions from the reset vector. In your case, the reset vector could be located in on-chip ROM or off-chip flash.

3) The power-on or bootloader, or crt0.s (c runtime setup), code then sets up the system. On a microcontroller, this might mean setting up PLLs and peripherals, but with an FPGA, these can be designed to power-up in sane states. For you, its mainly setting up the processor registers, and relocating code from Flash to SRAM/SDRAM.

Your processor would copy code and data from Flash over to on-board SRAM, or external SRAM or external SDRAM.

Once the code is copied over, the boot code can setup the stack pointer (if your 8-bit micro has one), and then jump into your 'main' application.

Your micro's code will have a linker map telling it where to place read-only variables, read/write variables and data. You compiler will generate assembly instructions with relative offsets referencing the addresses in those locations. This is how the code looks after you have copied it from flash.

--- Quote Start ---

As the flash has 70ns access time, I may need to add wait states to the CPU

--- Quote End ---

The processor core most definitely needs some way to force wait-states

(unless you plan on running it at a few kHz clock rate).

The simplest system for you to design would be to create a wrapper to convert the processor into an Avalon-MM master. Then you can drop it into an SOPC or Qsys System. I know, it looks like a daunting amount of information to absorb, but the benefit is that you get the Flash, SRAM, and DDR controllers provided to you. You can also drop a NIOS or OpenRISC processor into your system and check that it works. That'll help in debugging.

--- Quote Start ---

Being able to preload SDRAM is for bonus points really, as it would give me a way to preload much larger "disc" content.

But I'm actually wondering how practical this might be, due to the need for continual refresh.

--- Quote End ---

Refreshing the DDR is the job of the DDR controller, not your CPU. So, as long as you use a provided DDR controller, you don't have to think about it (once you've figured out how to get it working).

Cheers,

Dave