I am trying to insert a .ko kernel module into the linux running in arm processor. I built a .ko file in my desk PC which is a x86 one. How do I cross compile it to arm specs. I am new to this field.
Thanks in advance
For that you need to download the ARM compilers first. I suggest you download the compiler from http://www.linaro.org/downloads/ then set the CROSS_COMPILE environment variable to arm-linux-gcc.
set the bin directory path in PATH variable.You can do it by export PATH=$PATH:/path/to/arm/binaries/
Finally compile the code then run in ARM.
use file <filename> whether it is ARM executable or not.
For this you have to do the following steps.
Check you have cross compiler tool chain or not.
If you don't have cross compiler tool chain
you can download from one of the free ARM cross compiler from net.
You can generate your own cross tool chain using Buildroot tool. below you can get the link of Buildroot user manual.
http://buildroot.uclibc.org/downloads/manual/manual.html#_using_buildroot
Install cross tool chain in your host PC.
Export the cross tool chain path in your host PC using export command.
Change the make file of the kernel module to set the compiler as CROSS_COMPILE.
Do make.
Move the .ko file to target and insert it.
Related
Advice on working with Buildroot cross compilation would be helpful.
I am currently using customer specific buildroot and trying to cross compile our applications using the provided toolchain. The toolchain provided by customer is in dir [...]/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin. The toolchain from buildroot is in buildroot/output/host/usr/bin.
Previously I have worked with Yocto Project and in yocto before using cross compilation we need to install the toolchain/sdk which is generated by bitbake -c populate_sdk <image recipe> and then each time we wish to use the toolchain we need to source the environment script. Do we have similar things in buildroot? Do we need to source any environment script? And also do I need to modify anything in menuconfig? Currently the toolchain set in menuconfig is "Linaro ARM 2018.05".
Can anyone please let me know how to continue with Buildroot? My end goal is to cross-compile and generate binaries using this toolchain.
Your help will be much appreciated.
Thanks in advance.
My understanding is that you want to use an external toolchain for building BSP.
In the buildroot menuconfig navigate to Toolchain and use below settings -
Toolchain type - External Toolchain
Toolchain - Custom toolchain
Toolchain origin - Pre-installed Toolchain
Toolchain Path - here you can choose the path [...]/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin
and make necessary settings for remaining toolchain settings and build.
snapshot
I am trying to update our cross compiler toolchain from crosstool to crosstool-ng. We are using an old kernel and build machine. I could install and configure crosstool-ng-1.0.0 on the server and build the toolchain.
One difference that I have noticed between the output of crosstool and crosstool-ng is that the crosstool-ng is missing some of library under output folder. For example libcrypt.a, libdl.a, libnss_dns.so, libpthread.so and so on.
I have noticed that while building with crosstool we are setting KERNELCONFIG to a specific kernel configuration file. In that configuration file we have configurations like:
CONFIG_CRYPTO=y
CONFIG_CRYPTO_HMAC=ycryp
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_DES=y
Is this the reason that libraries like libcrypt are missing. In that case is there a way to set KERNELCONFIG in crosstool-ng for example as a build parameter?
All the libraries you mention are part of glibc, and the glibc build does not depend on the kernel configuration at all. You should check if you have enabled building glibc at all.
I am trying to build a cross compiler for PowerPC e500mc with target powerpc-e500mc-eabi. As some websites mentioned, i built an bootstrap compiler first. and then tried to compile newlib with it. But i got some error like,
/bin/sh: powerpc-e500mc-eabi-cc: command not found
I want to know, can we directly compile GCC cross compiler without newLib. Also, can anyone tell me the exact pre-requisites for powerpc e500mc architecture. I have GMP, MPC, MPFR, BinUtils not sure whether newLib required or not.
You can build gcc without any C library, there is no need for newlib. Please find a list of dependencies from a crosstool-ng build below.
1. Alternatives
You can build everything manually, what you obviously attempted to do. This is possible but there are various constraints to keep in mind, for instance builds might fail if your filesystem is not case sensitive or if you build inside your source directory. Besides all the dependencies and their versions.
You let crosstool-ng build your cross toolchain. Crosstool-ng is mostly self-contained with few external dependencies. It will download and build all dependencies in the right versions for you, and it comes with various sample configurations. It will check for obstacles like a case insensitive filesystem. It lets you configure your cross toolchain in a similar way you configure a Linux kernel. I've built various cross toolchains by means of it for several years on several host systems without trouble, including Linux, OS X (homebrew) and Windows (cygwin). You find it here: http://crosstool-ng.org/.
I'm going to line out the steps that it takes to build a cross toolchain by means of crosstool-ng. I tested this setup on Windows (cygwin) today with the crosstool-ng from git.
2. Download crosstool-ng, build and install it.
Follow the steps in
docs/2 - Installing crosstool-NG.txt.
3. Configure your cross toolchain.
Follow the steps in
docs/3 - Configuring a toolchain.txt.
4. Example
mkdir powerpc-e500v2-eabi
cd powerpc-e500v2-eabi
ct-ng powerpc-e500v2-linux-gnuspe
The last step will create a configuration from a sample which I thought is similar enough to what you want. In the next step, we will adapt this configuration, the criteria are
no operating system
no C library
EABI
you want e500mc, the sample is e500v2. I leave it up to you to adapt the configuration to it.
4.1. Configuration
ct-ng menuconfig
Operating System
Target OS
Select bare-metal
C-library
C library
Select none
Target options
ABI
Select EABI
C-Compiler
gcc version
Select 5.1.0 (the sample configured a gcc 4.6.4
here)
Deselect C++ (since you do not want a C library
either and it'd pull extra dependencies)
Debug facilities
Deselect gdb (unless you want it, can pull extra dependencies)
4.2. Build
ct-ng build.4
Crosstool-ng will download and build the following dependencies.
gmp-6.0.0a
mpfr-3.1.2
isl-0.14
mpc-1.0.2
binutils-2.25
gcc-5.1.0
It will install the cross toolchain in
${HOME}/x-tools/powerpc-e500v2-eabi.
You can specify a different install prefix in the configuration.
This build issue can be fixed by creating a symlink powerpc-e500mc-eabi-cc pointing to powerpc-e500mc-eabi-gcc.
I build a cross compile toolchain on OSX with:
binutils-2.23.52
gcc-4.6.4
gcc-core-4.6.4
gcc-g++-4.6.4
gdb-7.6.1
gmp-4.3.2
mpc-1.0.1
mpfr-2.4.2
newlib-2.0.0
for the target EFM32 wich is a ARM Cortex-m3, so the gcc target is arm-none-eabi.
All compiled fine.
But making programs with this toolchain like blink.c don't actually run on the EFM32 board.
I checked the blink.bin I did with a binary created with a IAR commercial toolchain delivered in the demos from energymicro, also gcc based and the they look very different internally (as expected :).
So has my toolchain wrong libs/versions or is it simply a matter of gcc/ld/ar switches wrong and what would be the steps to systematicly analyse this?
I have a following setup. Although my working setup deals with ARM compiler Real View Developer Suite (RVDS) 3.2 on a Windows host, the situation could be generic for any other C compiler on any host.
I build a ARM library (static library - .a file) of C code using RVDS 3.2 compiler toolchain on Windows host. Then I link this library with an application using an ARM-Linux compiler toolchain on a Linux host, to get a ARM executable. Now when I try to debug this generated ARM executable on Linux using gdb, by trying to put a breakpoint in some function which is present in the library that is linked, gdb is not able to put breakpoint there citing source not found. So I manually copied all the source files(*.c) used to create the library in the Linux folder where the executable file is present. Still gdb fails to put a breakpoint.
So now I started thinking:
How can I do source level debugging of this library which I create on Windows using a different compiler chain by launching the executable which is generated by linking this library to an application, in gdb. Is it possible? How can I do it? Is there any compiler option in RVDS compiler toolchain to enable this library source level debug?
Do I need to copy the source files to linux in exactly same folder structure as that is present in windows for those source files?
You could try to see if mimicking the exact same directory structure works. If you're not sure what directory structure the compiler annotated in the debug info in the executable, you can always look at it with dwarfdump (on linux).
First, GDB does not need any source to put breakpoints on functions; so your description of what is actually happening is probably inaccurate. I would start by verifying that the function you want to break on is actually there in the binary:
nm /path/to/app | grep function_desired
Second, to do source level debugging, GDB needs debug info in a format GDB understands. On Linux this generally means DWARF or STABS. It is quite possible that your RVDS compiler does not emit such debug info; if so, source level debugging will not be possible.
Did you build the library with debugging enabled (-g option)? Without that, there would be difficulties identifying lines etc.
I've found that -fPIC will cause this sort of issue, but the only work around I've found is to not use -fPIC when I want to debug.