Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Boot NIOS from on-chip memory ONLY

I'm trying to use a NIOS on a custom board. As there is no JTAG interface, I need an alternative method for downloading my software to the NIOS once it is initialized.

Many of the examples out there I have seen utilize either the CFI or EPCS to take advantage of the on-board flash memory to store the software code. However, this board has no flash memory either, so it appears that I will have to rely solely on on-chip memory to accomplish this task.

I am thinking I will need to write a custom boot loader which will reside in some on-chip ROM to read the software code out of some other location in ROM and copy it over into RAM prior to jumping to the execution point in RAM.

First of all, does this sound like a valid approach to booting the NIOS?

If so, if I write a custom boot loader and compile it to and elf, how does one convert it to the proper hex format so it can be used to initialize the ROM?

Thanks in advance for your input!

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    All you should have to do is point the Nios II Reset Address at the start of that on chip memory, build your software (...maybe...generate and place your software in the QII project directory), compile your hardware in QII, and program the FPGA.

    Basically, there is no bootloader for onchip memory. The onchip memory just needs to be populated with your code.

    Cheers,

    slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Assuming your hardware project isn't changing much you could turn on rapid recompile or smart compile to re-incorporate the software contents into the .sof file (using slacker's instructions) faster.

    Just remember to compile your software before compiling the hardware image since you need the software image first before it can be shoved into the hardware image.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hmm well I am still missing something here then.

    I have been using 'elf2hex' to convert the software elf to an appropriate hex file, with the base and end addresses pointing to the on-chip ROM used to hold the software but to no avail.

    The CPU reset vector points to the on-chip ROM and the cpu relies on sdram for normal operation.

    Thanks again!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    the cpu relies on sdram for normal operation.

    --- Quote End ---

    What do you mean by that statement? If you've located code or data sections in the sdram, then you'll have to take care of loading/initializing them.

    slacker
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Ok sorry, that didn't really make that much sense. I think I was confused on what you meant.

    The planned architecture is to have the compiled software located in an on-chip ROM. The software will then need to be copied over from ROM and into RAM. This should allow me to reload the software in the event of a cpu reset.

    Based on this, I am thinking I will need to write a seperate boot loader which copies the code and then jumps to that location in RAM. Does this make sense? Or am I missing something?

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I would build the SOPC system and then generated the appropriate ROM based upon your code. Once you compile your code, you can then make targets for each of your memory components. After generating the initialization files for your software, you can then generate your programming file, which will contain your compiled program. If you want to change the contents of the code, then you will need to recompile your code and regenerate your program files.

    If you want to modify the program after it start, this will not acheive that goal. BTW, how do you plan to load the new program? Which interface will you use to get the data into the chip?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks for your reply. I've already fixed the issue.

    Turns out I was making the problem far to complicated. The key component I was missing was how to make the memory init file (using "make mem_init_install"). Once I found this, I was able to initialize my RAM and boot from that.

    Fortunately, I do not need to modify the program while it is running. Otherwise this would be far more complicated.