Forum Discussion
Linux development environment
Does anyone know if the Nios II port of uClinux is available as a simple tarball (i.e. tar.gz or .tgz) that can be downloaded to a Linux machine and configured and built using the nios2-elf-gcc cross compiler?
I am actively attempting to rebuild the nios2-gnutools on my Linux box so I can develop the kernel and user applications on it. I will post the results if I am successful. However, if someone has already accomplished this I would be very interested in getting the source.26 Replies
- Altera_Forum
Honored Contributor
Yes,
I am building all of these tools under Redhat 9. - Altera_Forum
Honored Contributor
But where can download the nios2-gnutools. And if install successfully, which OS can we use for nios2.
- Altera_Forum
Honored Contributor
I have extracted the source code for the elf2flt utility that was part of the Nios II IDE installation.
I found it in the altera/kits/nios2/examples/software/linux/utils directory. I moved this directory over to my Linux machine and ran dos2unix on all the files. I've been trying to get it configured and build properly, but I'm running into a problem with an "undefined reference to '__getreent' " error. The README for the elf2flt utility only discusses the inclusion of the libbfd.a and the libiberty.a libraries. I think I've pointed to the correct location for these, but the __getreent symbol is still not found. The interesting thing is that non of the elf2flt c files actually call the __getreent function. The errors point to the fprintf function. It must be using the __getreent. Does anyone know how to resolve this error? - Altera_Forum
Honored Contributor
I successfully compiled the elf2flt utility under Linux.
Now I am having a problem using the elf2flt utility. I have the same problem under my Cygwin environment under Windows. If I use nios2-elf-gcc to compile a simple program (e.g. nios2-elf-gcc hello.c -o hello) and try to use the elf2flt utility to convert the format to flat, it gives me the following error: hello: Input file contains no relocation info The hello file is the executable that was created directly from the nios2-elf-gcc compiler. If I try to run the hello file directly on my uKit Nios II development board, then I get the format errors described a couple replies back. WHAT AM I MISSING HERE? - Altera_Forum
Honored Contributor
hi trk_golf,
<div class='quotetop'>QUOTE </div> --- Quote Start --- If I use nios2-elf-gcc to compile a simple program (e.g. nios2-elf-gcc hello.c -o hello) and try to use the elf2flt utility to convert the format to flat...[/b] --- Quote End --- If you want to run hello on uClinux, you have to compile it with uClibc, not the default newlib. Therefore, here you must explicitly specify the crt0.o and libc.a from uClibc. (we do this because the tool chain is not built against uclibc, but newlib). You also need to tell the linker to generate relocatable outputs, so that elf2flt can convert them. This is done by passing "-r -d" to the linker. (You could also try "-q" to do a final link and keep the relocation records, but it was broken when I tried about half year ago). For details, please refer to the file Rules.mak for building userland applications on Cygwin. Regards, wentao Microtronix - Altera_Forum
Honored Contributor
Thanks for all your advice. I'm moving forward, but I'm still running into problems with converting the file to a flat binary.
I have used the Rules.mak file as a reference. It is located at "altera/kits/nios2/bin/eclipse/plugins/com.microtronix.nios2linux.application_0.1.0/templates" on my Windows machine. I have also tried using the elf2flt.ld linker script located at "com.microtronix.nios2linux.application_0.1.0/scripts". No matter what I try, I keep getting an error from nios2-elf-elf2flt that states "cpuload.elf: Input file contains no relocation info". However, if I perform a "nios2-elf-objdump -f cpuload.elf", then I get the following results: cpuload.elf: file format elf32-littlenios2 architecture: nios2, flags 0x00000011: HAS_RELOC, HAS_SYMS start address 0x00000000 Doesn't the output from objdump indicate that the elf image does indeed have relocation information? Did I compile elf2flt improperly on my Linux machine? Any other suggestions? - Altera_Forum
Honored Contributor
It sounds like the elf2flt is not built correctly. In the elf2flt src directory are there some libraries (libbfd.a and libiberty.a), which are from the building of the nios2 toolchain under Cygwin, you are supposed to replace them with those you built under Linux.
I dont know if you have done this. wentao - Altera_Forum
Honored Contributor
I'm getting closer...
I have rebuilt elf2flt, but I still get an error. Here are the steps I took to rebuild the elf2flt tool: I copied nios2-gnutools/src/binutils-build/bfd/bfd.h nios2-gnutools/src/binutils-build/bfd/libbfd.a nios2-gnutools/src/binutils-build/libiberty/libiberty.a into my elf2flt directory. I then ran the following configure command: ./configure --target=nios2-elf --with-bfd-include-dir=. --with-libbfd=./libbfd.a --with-libiberty=./libiberty.a This configures without errors. I then run make. This succeeds. If I use the resulting elf2flt binary to try and convert the cpuload.elf file I created, it provides the following error? ERROR: text=0xaf0 overlaps data=0x0 ? Does this have something to do with the linker script? I apologize for my ignorance. I've never dealt with an elf image and linkers that much until now. I am grateful for your help. - Altera_Forum
Honored Contributor
Here is the output from nios2-elf-readelf -S cpuload.elf
I see that the .text section has a size of 0x0af0 and is at offset 0x38. That's about all that I can relate to the error. It would appear that this fits in without overlapping anything. Any idea what the error might be related to? <div class='quotetop'>QUOTE </div> --- Quote Start --- There are 27 section headers, starting at offset 0x54d8: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 00000000 000038 000af0 00 AX 0 0 8 [ 2] .rela.text RELA 00000000 005910 000318 0c 25 1 4 [ 3] .rodata PROGBITS 00000000 000b28 000010 00 A 0 0 4 [ 4] .data PROGBITS 00000000 000b38 000018 00 WA 0 0 4 [ 5] .sdata PROGBITS 00000000 000b50 000018 00 WAp 0 0 4 [ 6] .sbss NOBITS 00000000 000b68 000004 00 WAp 0 0 4 [ 7] .bss NOBITS 00000000 000b68 000000 00 WA 0 0 1 [ 8] .comment PROGBITS 00000000 000b68 000160 00 0 0 1 [ 9] .debug_aranges PROGBITS 00000000 000cc8 0000c0 00 0 0 1 [10] .rela.debug_arang RELA 00000000 005c28 000090 0c 25 9 4 [11] .debug_pubnames PROGBITS 00000000 000d88 0000ee 00 0 0 1 [12] .rela.debug_pubna RELA 00000000 005cb8 000054 0c 25 b 4 [13] .debug_info PROGBITS 00000000 000e76 0017ca 00 0 0 1 [14] .rela.debug_info RELA 00000000 005d0c 001758 0c 25 d 4 [15] .debug_abbrev PROGBITS 00000000 002640 000a9d 00 0 0 1 [16] .debug_line PROGBITS 00000000 0030dd 000d15 00 0 0 1 [17] .rela.debug_line RELA 00000000 007464 000cc0 0c 25 10 4 [18] .debug_frame PROGBITS 00000000 003df4 0001ec 00 0 0 4 [19] .rela.debug_frame RELA 00000000 008124 0000c0 0c 25 12 4 [20] .debug_str PROGBITS 00000000 003fe0 001322 01 MS 0 0 1 [21] .ctors PROGBITS 00001324 005304 000014 00 WAX 0 0 4 [22] .dtors PROGBITS 00001338 005318 000014 00 WAX 0 0 4 [23] .debug_ranges PROGBITS 0000134c 00532c 0000c8 00 0 0 1 [24] .shstrtab STRTAB 00000000 0053f4 0000e1 00 0 0 1 [25] .symtab SYMTAB 00000000 0081e4 000860 10 26 39 4 [26] .strtab STRTAB 00000000 008a44 0005e1 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific)[/b] --- Quote End --- - Altera_Forum
Honored Contributor
I've been looking at the source code for the elf2flt utility.
I also ran it in verbose mode. With the -v option, its output is the following: TEXT -> vma=0x0 len=0xaf0 DATA -> vma=0x0 len=0x18 ERROR: text=0xaf0 overlaps data=0x0 ? I would think that it would us the offset information, not the address to determine if something is overlapping. Isn't this the point in having relocatable code, it uses offsets instead of fixed addresses ? Perhaps I've done something wrong or the linker script isn't correct. I'll keep digging around. If you have any suggestions, feel free to let me know.