Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

Creating sof with NIOS code embedded

Altera_Forum
Honored Contributor II
1,727 Views

So, as title suggests, I have a NIOS system generated with SOPC and NIOS 

runs from Onchipmem RAM with memory init file my_fpga.hex. 

 

I generate the SOPC system. 

I build the NIOS code which generates my_fpga.elf 

I run from the NIOS console: 

elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x32000 my_fpga.hex 

I build the FPGA which generates the .sof 

I create .jic with the .sof 

I program .jic into the EPCS device. 

 

No worky. :( 

 

All of the code was working by programming .sof and then using  

Eclipse to download the .elf. 

 

A few words on: 

elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x32000 my_fpga.hex 

Width of Onchipmem RAM is 32 in SOPC 

Base address is 0x0 in SOPC. 

End address is 0x31FFF in SOPC 

(I should change 0x32000 to this I believe but Quartus build warning says it truncated 

anyhow so this should not be an issue). 

 

Anything obviously wrong here. 

 

Thanks in advance for any feedback, 

 

Cos
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
423 Views

Where is your Reset Address In Nios II settings inside SOPC Builder? 

- It should be pointed at the onchip memory. 

 

There should be a more automated way to do this....in the old IDE this HEX file was always generated automagically. In the new(er) SBT-based flow, there should be Makefile targets to take care of this... In my experience, typing "make help" gives you a list of targets/options. 

 

Cheers, 

 

slacker
0 Kudos
Altera_Forum
Honored Contributor II
423 Views

>>>Reset Address In Nios II settings inside SOPC Builder? 

Yup. This is set to 0x0 to correlate with base in which is same in SOPC for that mem: 

elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x32000 my_fpga.hex 

 

Agree on the automated comment. 

 

Anything you see wrong with my documented process or other suggests? 

 

Thanks! 

C
0 Kudos
Altera_Forum
Honored Contributor II
423 Views

So, done a bit more debugging with no success. 

 

I have included the onchip mem instantiation info from Quartus below. 

 

I have verified that the FPGA does in fact boot from the given .jic from power up 

as I can come in with Eclipse after and download and run the .elf code. 

So, problem must just be in the NIOS loading/running with the .sof/.jic used. 

 

I have fixed this: 

elf2hex my_fpga.elf --width=32 --base=0x0 --end=0x31FFF ../../my_fpga.hex 

 

Not sure if I am calling this correctly. There are a bunch of other options/flags for elf2hex. 

I am attaching the elf and output hex files. Does the hex look somewhat correct? 

I noticed all the bytes are pushed to the right side far column with 0x00's everywhere 

else. 

 

I have no idea how to debug this black box and could use a hand. 

 

Thx, 

 

Cos 

 

 

Info: Instantiated megafunction "my_fpga:my_fpga_inst|onchip_memory2_0:the_onchip_memory2_0|altsyncram:the_altsyncram" with the following parameter: 

Info: Parameter "byte_size" = "8" 

Info: Parameter "init_file" = "my_fpga.hex" 

Info: Parameter "lpm_type" = "altsyncram" 

Info: Parameter "maximum_depth" = "51200" 

Info: Parameter "numwords_a" = "51200" 

Info: Parameter "operation_mode" = "SINGLE_PORT" 

Info: Parameter "outdata_reg_a" = "UNREGISTERED" 

Info: Parameter "ram_block_type" = "AUTO" 

Info: Parameter "read_during_write_mode_mixed_ports" = "DONT_CARE" 

Info: Parameter "width_a" = "32" 

Info: Parameter "width_byteena_a" = "4" 

Info: Parameter "widthad_a" = "16"
0 Kudos
Altera_Forum
Honored Contributor II
423 Views

The attached hex file contains all zero data which is obviously wrong. 

 

If you are used the Altera SBT tools to generate your make files, you should be able to just run "make mem_init_install" to automatically generate the appropriate hex file. 

 

I think the main problem with your manual attempt is specifying the wrong base address in your elf2hex command line. The code looks like it starts at 0x11000000 in you ELF file, not 0x0 which you specified in your elf2hex command line.
0 Kudos
Altera_Forum
Honored Contributor II
423 Views

Makes sense. 

 

I just realized I had a bridge between NIOS and onchipmem. 

The mem is at 0x0 but the bridge is at [drum roll] 0x11000000. 

Long time since I worked on this. :oops: 

 

Like to know how you pulled the address 0x11000000 out of the elf. 

 

I will get that fixed. 

 

Lastly, is there a way to not have to build the whole FPGA whenever we just want 

to add different elf/hex NIOS code to the sof/jic? 

 

Thanks! 

 

Cos
0 Kudos
Altera_Forum
Honored Contributor II
423 Views

 

--- Quote Start ---  

Like to know how you pulled the address 0x11000000 out of the elf. 

--- Quote End ---  

nios2-elf-objdump -D my_fpga.elf | less 

 

There are probably many other ways as well. Using the above method I could also see if the proper code was at the rest address. If the BSP is setup incorrectly, it is possible for the ELF to run correctly when downloaded via JTAG but to fail when executed straight from block RAM. 

 

--- Quote Start ---  

Lastly, is there a way to not have to build the whole FPGA whenever we just want to add different elf/hex NIOS code to the sof/jic? 

--- Quote End ---  

To update the SOF, do the following in Quaruts: 

 

1. Processing -> Update Memory Initialization File 

2. Processing -> Start -> Start Assembler
0 Kudos
Altera_Forum
Honored Contributor II
423 Views

Thank-you for your help. 

 

All working now. 

 

Regards, 

 

Cos
0 Kudos
Reply