The problem
We are trying to compile the spi_slave code on a raspberry pi. We used the native gcc compiler and the compile runs without any errors.
The problem is when I try to run the output:
/home/pi/spi_slave# ./build/output.elf
Segmentation fault
/home/pi/spi_slave# ./build/kernel.img
bash: ./build/kernel.img: cannot execute binary file
Tried to download the arm-none-eabi compiler from cambridge but it wont run:
/home/pi/spi_slave# ../arm-2008q3/bin/arm-none-eabi-gcc
bash: ../arm-2008q3/bin/arm-none-eabi-gcc: cannot execute binary file
Sourcecode
The code we are trying to compile is: http://tylernichols.me/wp-content/uploads/2012/11/raspberry_pi_bare_metal_spi_slave.zip
The only change we did was in the makefile, added a # in front of the ARMGNU var
#ARMGNU = arm-none-eabi
Environement
# uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
What am I doing wrong?
We have tried to find answers on google and stackoverflow for hours now without success. :/
arm-none-eabi is a non-linux compiler. It is for bare-metal applications. The difference is in the C library. However, gcc is intimately linked to the C library for normal compiles.
Then there is the code. It is not written for Linux. It is written for a bare-metal application. You need to load and run the code from the Raspberry-Pi boot loader (berryboot?) without Linux.
You can use the ARM Linux compiler to create code for a bare-metal application. However, it is probably easier for you to find a newlib compiler that is targeted for the Raspberry Pi. You can search for one on the web or try to build one yourself.
See: How to build gcc for Raspberry Pi and Bare-metal gcc.
Related
I am trying to do profiling of the code written in C++ with the target Architecture RISC-V. The code has been cross-compiled using RISC-V GNU Toolchain. My executable is unit_tests "ELF 64-bit LSB executable, UCB RISC-V, version 1 (GNU/Linux), dynamically linked,nterpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, with debug_info, not stripped" this information is retrieved using the file command.
What I am trying to do is the profiling of this using gprof. But to do the gprof gmon.out needs to be generated, to generate gmon.out the executable should be run first. I cannot run the binary elf of other architecture in some different architecture. I need a suggestion for this on which emulator or simulator does this for me or I can run on?
I have tried installing qemu using the follwing link:
https://www.google.com/url?q=https://risc-v-getting-started-guide.readthedocs.io/en/latest/linux-qemu.html&sa=D&source=hangouts&ust=1597422417473000&usg=AFQjCNERr6pHYmj0SU6an3WkBRGQI52aTw
but not able to successfully install it.
Also have tried with spike but got "bad synccall" error. Any leads how can I resolve this issue.
I solved this issue using qemu in user mode. Following the instructions in the below link:
Manual-qemu-user
Where I could run the binary elf generated for target RISC-V, which I could run on x86 Linux machine.
I have a noob question. I have a minimal system(a headless linux) on my Raspberry Pi 3. I wanted to compile a C program. However I do not see the gcc binary. All I see is the libgcc_s.so library. How can I proceed with compilation. What do I need to "get" the gcc into the system.
Thanks.
I've recently installed a mips-linux-gnu-gcc crosstool in my linux machine which is based on i686. When I want to compile some codes, it showed me that error.
Every installing step was followed by http://developer.mips.com/tools/compilers/open-source-toolchain-linux/
After I installed the crosstool, I wrote a simple helloworld C file like this:
#include<stdio.h>
int main(void)
{
printf("Hello World!\n");
return 0;
}
But when I run:
/mips-linux-gnu-gcc hello.c -o hello -static
The compiler just print error:
bash: ./mips-linux-gnu-gcc: cannot execute binary file
I'm wondering maybe I've made some mistakes in some steps, but I can't figure it out.
Maybe some of you can help me, I'm confused by the problem.
The compiler you downloaded from MIPS is a 64-bit executable. Are you running a 32-bit host?
If you need a cross compiler for a 32-bit host targeting MIPS GNU/Linux, consider using the Sourcery CodeBench Lite compiler for MIPS GNU/Linux targets:
Sourcery CodeBench Lite for MIPS GNU/Linux
The link to the Sourcery CodeBench tools above comes from the MIPS pages just one level up from the link you provided:
MIPS Compilers Page
It looks like the mips-linux-gnu-gcc binary does not match the architecture of the machine you are trying to run it on. This might be something like a 32/64 bit mismatch.
Try using the free Mentor/Codesourcery MIPS gnu/gcc cross compilation tool chain instead. You can download from here.
I have set up target fs on
/home/myself/filesys/bin..etc//
GCC
compile:
host $ arm_v5t_le-gcc hello.c -o hello
run:
target $ cd /opt/hello
target $./hello
I have installed opencv2.3 on host ubuntu machine now I want opencv to be ported to DM6446
so i follow
uncompress opencv2.3 tarball
sudo cmake OpenCV-2.3.1
sudo make ARCH=arm CROSS_COMPILE=arm_v5t_le-
but when I run the sample test from bin it runs on x86 machine which was made for ARM
I think I am not following the correct procedure to make opencv.
Is there anything I have to do to make opencv for ARM architecture,
what are the steps to follow in cross compiling?
The 2nd command you executed should provide a clue as to whether you are cross-compiling or not. If you look closely it would have shown that it was building for the i686 and not for the ARM platform.
This blog discusses how to Cross Compile using cmake.
cmake uses different environment variables from standard make (so don't use ARCH, and CROSS-COMPILE).
Using MacPorts i have just installed arm-elf-gcc on to my MacBook Pro. This worked flawlessly and all seems to run fine.
However, after compiling a simple hello world test program in C and C++ and trying to run either on the target board (an ARM9 based board running Debian Linux) they immediately seg fault.
I'm a bit stuck as how to go about debugging this, as the target board has limited tools available and no gdb. I have successfully built and run other code using a Linux hosted cross compiler so it should work.
Any ideas?
Following the suggestion I have built and run gdbserver, I get the following in gdb on the host:
Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
I thought it may be a problem with the standard c libs so I removed any calls and have just an empty main that return 0, it is compiled with -Wall -g hello-arm.cpp -static. As a test I compiled the same source with a Linux hosted cross compiler and it runs and exits fine. The only difference I can see is the that Linux compiled version is over twice the size and the difference in output from the file command:
arm-elf-gcc: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
arm-*-linux: ELF 32-bit LSB executable, ARM, version 1, statically linked, for GNU/Linux 2.4.18, not stripped
The usual method of debugging in this situation is to run gdbserver on the target board, and connect to it (via ethernet) with gdb running on a host computer.
Alternately, you could try comparing the assembly in a Mac-compiled "Hello World" program and a (working) Linux-compiled one to see what's different.
After digging around for a couple of days I am starting to understand a bit more about embedded compilers. I wasn't really sure of the difference between arm-elf-gcc installed via MacPorts and the arm-unknown-linux toolchain I had installed on my Linux box. I just came across a pdf titled "An introduction to the GNU compiler" which contains the following paragraph:
Important: Using the GNU Compiler to
create your executable is not quite
the same as using the GNU Linker,
arm-elf-ld, yourself. The reason is
that the GNU Compiler automatically
links a number of standard system
libraries into your executable. These
libraries allow your program to
interact with an operating system, to
use the standard C library functions,
to use certain language features and
operations (such as division), and so
on. If you wish to see exactly which
libraries are being linked into the
executable, you should pass the
verbose flag
-v to the compiler.
This has important implications for
embedded systems! Such systems do not
usually have an operating system.
This means that linking in the system
libraries is almost always
meaningless: if there is no operating
system, for example, then calling the
standard printf function does not make
much sense.
So when I get back to my dev machine later I will determine the libraries linked in with the Linux build and add them to the arm-elf-gcc build.
I'll update this when I have more information but I just want to document my findings in case any one else has these problems.