NiosII booting from on-chip memory

[Altera_Forum]

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?

[Altera_Forum]

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]

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]

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

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]

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

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]

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]

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

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.

[Altera_Forum]

--- Quote Start ---  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.  --- Quote End ---    Could you provide an explicit link :D please ?

[Altera_Forum]

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]

--- Quote Start ---  Could you provide an explicit link :D please ?  --- Quote End ---    http://www.alterawiki.com/wiki/timequest_user_guide

[Altera_Forum]

--- Quote Start ---  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.  --- Quote End ---    I did your suggestion. The same behaviour. The NiosII does not start when the *.sof is downloaded via JTAG. It just hangs.

[Altera_Forum]

Hello Terrazas, 

 Did you manage to solve your problem ? I am having the same problem. How did you convert your elf-file to a hex-file which could be included in Quartus. I use the following:  elf2hex --little-endian-mem --input="C_bootloader.elf" --output="C_bootloader.hex" --base=0 --width=32 --end=0x3fff --record=4 --lower  When I use SignalTap to look at the processor-signals I don't see any processor activity. It looks like it is still in reset.  Regards,  Wamor

[Altera_Forum]

Actually, you don't need to explicitly perform the elf2hex. You can just run "make mem_init_generate" at the app directory and the hex files will be generated for you under a mem_init folder. You should be able to find a QIP file inside the folder. In your Quartus GUI, you can just add the qip file as part of the Quartus project, re-compile in Quartus and the sof generated from the compilation should be able to run after FPGA is configured.

[Altera_Forum]

--- Quote Start ---  Actually, you don't need to explicitly perform the elf2hex. You can just run "make mem_init_generate" at the app directory and the hex files will be generated for you under a mem_init folder. You should be able to find a QIP file inside the folder. In your Quartus GUI, you can just add the qip file as part of the Quartus project, re-compile in Quartus and the sof generated from the compilation should be able to run after FPGA is configured.  --- Quote End ---    Did that. It still does not work. Any other ideas?  I also tried creating a .hex from the .elf, and setting that as the initialization file in qSys.  In either case the hardware is correct in the SOF, but the code is not there.

[Altera_Forum]

--- Quote Start ---  Did that. It still does not work. Any other ideas?  I also tried creating a .hex from the .elf, and setting that as the initialization file in qSys.  In either case the hardware is correct in the SOF, but the code is not there.  --- Quote End ---    Review the fitter report and the Quartus messages from your compile.  Does it say it is using your initialization file for that M9K memory?

[Altera_Forum]

Probably you can attached your Quartus Project/ Qsys system and I can take a quick look.