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?

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.

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.

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 ]

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

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.

NiosII booting from on-chip memory | Altera Community

18 Replies

Altera_Forum
Honored Contributor
11 years ago
--- 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
Honored Contributor
11 years ago
--- Quote Start ---
Could you provide an explicit link :D please ?
--- Quote End ---

http://www.alterawiki.com/wiki/timequest_user_guide
Altera_Forum
Honored Contributor
11 years ago
--- 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
Honored Contributor
10 years ago
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
Honored Contributor
10 years ago
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
Honored Contributor
10 years ago
--- 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
Honored Contributor
10 years ago
--- 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
Honored Contributor
10 years ago
Probably you can attached your Quartus Project/ Qsys system and I can take a quick look.

Forum Discussion

NiosII booting from on-chip memory

18 Replies

Recent Discussions

licensing.altera.com never worked

NiosV and juart-terminal

NIOS V/m dbg_reset_out signal (Q25.1 Std, MAX10)

JTAG_UART stuck in printf

Ashling IDE scripted project creation