Forum Discussion

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

NiosII booting from on-chip memory

I am trying to boot a NiosII (HAL only, no other bigger OS) on a Cyclone IV directly from the on-chip memory. I have initialized the memory .hex file and included it in my project. I then recompiled the project again. I downloaded the *.sof file to the FPGA. However, the NiosII is not booting.

I want to be able that when I download the *.sof file to the FPGA, the processor should boot by itself (without me having to manually download the software from Eclipse)

Would anyone have any suggestions for me?

18 Replies

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

    If you have the nios JTAG debugger enabled I think it 'steals' the reset vector.

    Try removing it.

    ISTR problems with the JTAG debugger when downloading over PCIe (which is what we do).

    I think there is a separate JTAG to avalon master that can be used to access memory - useful for debug.

    With the nios soft-reset exposed that could be used for software download.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Is the data and instruction master set to On-Chip Memory, have you assigned the clock correctly, does the jtag-uart slave is connected to the data master of the nios along with the interrupt. Check for Qsys system correctness. No warnings or errors.

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

    I found this information from the user erics96 in one of his posts for memory initialization files. I checked and I was getting the same warning as him [Warning: Width of data items in "*.hex" is greater than the memory width. Wrapping data items to subsequent addresses.] I have not got it working so far. Any suggestions?

    I used Elf2Hex to convert my elf file into the hex file(s). The format of the .hex file was (spaces added by me to separate the fields):

    :20 aaaa 00 dd..dd cc

    :20 aaab 00 dd..dd cc

    Where aaaa == an address, dd..dd is 32 hex bytes of data, and cc is the checksum. aaab is a different address which happens to be 8 more than aaaa. For example, if aaaa was 1230, then aaab would be 1238.

    There were two key things that helped me figure it out.

    1. Really figuring out what the warning said "is too wide to fit in one memory word"... The key phrase was "one memory word". A memory word in my system is 32-bits, which is why when I had 32 hex bytes, it only increased the address by 8 (one for each 4 byte group).

    2. Looking at a default memory file created by the sopc system:

    :04 aaaa 00 dd..dd cc

    :04 aaab 00 dd..dd cc

    Where aaab - aaaa is only 1, and dd..dd is only 4 hex bytes.

    So, the key is that the Quartus tools want to have only one memory word (32-bits or 4 hex bytes in my system) PER LINE of the .hex file.

    In the elf2hex converter, there is an option called "--record=<length>" where you can set the maximum number of words per line. The default apparently is 20 (for me at least). Changing my makefiles to use --record=4 created a .hex file that had only 4 bytes per line and produced no warnings.

    The original post can be found at [ http://www.alteraforum.com/forum/showthread.php?t=6286 ]
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Is the data and instruction master set to On-Chip Memory, have you assigned the clock correctly, does the jtag-uart slave is connected to the data master of the nios along with the interrupt. Check for Qsys system correctness. No warnings or errors.

    --- Quote End ---

    Yes, I have a Qsys that is correctness compliant. All the points that you are mentioning are properly connected. 0 errors and 0 warnings.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Either you didn't correctly configure the NIOS to boot from that RAM (reset/exception vector memory locations), or the software in the RAM is buggy.

    Double check your Qsys NIOS parameters.

    Check your Quartus reports to see that the RAM is correctly initialized from the .hex you thought it should be.

    After the system boots, look at the RAM and see if the contents match expected.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Either you didn't correctly configure the NIOS to boot from that RAM (reset/exception vector memory locations), or the software in the RAM is buggy.

    Double check your Qsys NIOS parameters.

    Check your Quartus reports to see that the RAM is correctly initialized from the .hex you thought it should be.

    After the system boots, look at the RAM and see if the contents match expected.

    --- Quote End ---

    The reset/exception vector memory locations are ok. The processor vectors are pointing to the on-chip memory.

    I noticed that the Eclipse GUI apparently had some bugs while preparing the *.hex memory initialization file. However, I used the command line to craft my own initialization as:

    elf2hex --input=terrazas.elf --width=32 --base=0x10000 --end=0x19fff --record=4 --little-endian-mem --output=terrazas.hex

    I got a *.hex file that looks like this when you open it in notepad:

    :020000020000FC

    :040000000040007448

    :0400010008408B1414

    :040002000800683A50

    :0400030000000000F9

    :0400040000000000F8

    :0400050000000000F7

    :0400060000000000F6

    :0400070000000000F5

    ...

    after this there are no warnings in the Quartus re-compilation

    Finally, I am still not able to boot the processor. Any ideas of why is this going on?

    Just to make it more clear, I want to be able that when I download the *.sof file to the FPGA, the processor should boot by itself (without me having to manually download the software from Eclipse)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    I got it working by using the serial passive programming. Now, my problem is when the processor is programmed by JTAG, the microprocessor does not start. Any ideas for this?

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

    If you are using nios2-download to download software then you might have a look at the -g and -r options, and also at how the debug reset output is connected in QSYS. Otherwise if you are using nios2-configure-sof to configure the hardware then its harder to guess at the cause. Is the design constrained in timequest?

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

    --- Quote Start ---

    If you are using nios2-download to download software then you might have a look at the -g and -r options, and also at how the debug reset output is connected in QSYS. Otherwise if you are using nios2-configure-sof to configure the hardware then its harder to guess at the cause. Is the design constrained in timequest?

    --- Quote End ---

    I prepared the *.hex file so that it become part of the *.sof file. I assume that by you only downloading the *.sof the NiosII should start running. I got it working if I do serial passive programming, but no when only using QuartusII programmer in the JTAG mode.

    The NiosII reset I have it connected to Vcc all the time.

    Regarding timequest no. I have not tinkered with it at the moment.

    Any suggestions?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    A timing unconstrained design can lead to inconsistent results from one compile to the next. I have personnaly benefitted from the time quest users guide posted by user rysc on the altera wiki.