I need to implement a system with a third party device using a Raspberry Pi.
The device is connected using USB, and the manufacturer has provided a few software implementation demos, and the driver library includes a C++ header file and a C shared object file compiled for i386.
I need to be able to run this driver library on the RPi. My idea is to build a C++ program I can use to get the data from the device, compile for i386, and run it with qemu-i386. I have tried to execute this idea, but have run into some problems relating to the linking, like the executable looking for ld-linux.so.2, which my RPi doesn't have.
How can I get this to work?
It's a bad idea to run it for QEMU, instead install box86, link, it'll automatically take over when it detects a 32bit x86 executable and should work great for your use case
Related
I am trying to compile C code on a Mac (M2), with as target windows. I have tried this in the past on linux, with success, but there doesn't seem to be a straightforward way on Mac.
On the linux machine I was able to get a whole range of cross compilers from GNU, they had the system headers built in, so it was really really simple, something like
gcc-...-mingw main.c -o main.exe
would create a simple windows executable. From there it was as simple as moving the main.exe file to a usb drive or cloud to and transfer it to a windows machine to run it. Really simple!
For Mac I have found some resources about Clang, but you need to provide the system headers yourself, which I have no idea how to do. And there is more setting up, which I don't want to get into if there is a solution as simple as the one I just showed.
My question: What is the way to compile a C program on a Mac with the target system being windows, or even Linux?
Thanks for the help!
Visual Stdio Code has support for various C compilers native for M2. It isn’t a full IDE, simply a code editor with extensions.
You should be able to download the plugins/extensions you need via the GUI interface and let it manage the environment.
I have cross-compiled a kernel, in an autodidactic manner, on a raspberry pi twice in the past.
This kind of things can sometimes a pain in the ... But fortunately there are some step-by-step tutorials.
So I am wondering whether there are general steps that have to be taken and that are the same on all the embedded systems (rpi, beaglebone, atmega controllers, etc...) in order to successfully cross-compile the kernel and make everything work?
My guess:
1) download the kernel source code
2) generate a .config file (which seems necessary)
3) get into the blue screen to do additional adjustements
with e.g.: make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- menuconfig
4) compile the kernel:
make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi-
5) put it on the SD card or anything else
Would this be a correct general scheme for any cross-compilation on an embedded system?
Sorry for my ignorance, as I mentioned above I learned it by myself.
I would like to be able to setup a kernel on any embedded device.
Any more information or explanation would be more than welcome! As it seems this kind of things can always be done in multiple manners, it gets me confused.
I'd say your first two steps haven't much to do with cross-compiling. In fact it just comes down to having a cross toolchain targeting your platform correctly installed on your system.
The CROSS_COMPILE make variable of the kernel doesn't do anything other than prepending the string it is set to to any toolchain command (like e.g. gcc for compiling), so if your cross toolchain is installed in your search path, it would be enough to set it to just the desired target triplet with added hyphen, e.g. in your case CROSS_COMPILE=arm-linux-gnueabi-. This would lead to using the command arm-linux-gnueabi-gcc for compiling and so on.
For other embedded devices, you might need different cross toolchains (depending on their architecture), but the general process would indeed stay the same.
how to make an application in built(like top, vi , etc ) so that they can be put inside the /system/bin automatically on flashing the kernel and can be accessed from the command prompt.
I tried modifying the Makefile for the my application by looking at the example of top utility but could not find it under /system/bin .
I am not sure if I have included the sources of the file in the Makefile correctly.
You need to start with something that the manufacturer provided. Presumably it's a devKit or something. Most modern dev kits ship with either a MFG provided development environment, kernel, sources, etc. Many are based on Yocto Linux.
You can't just compile a binary locally on your PC with whatever version of GCC you have and have it work on an embedded environment. Chances are it's a different architecture (ARM or Freescale or something). There are ways to cross-compile but is some setup involved. Read about cross compiling here: http://en.wikipedia.org/wiki/Cross_compiler
There are development and packaging environments that have been developed by the community but it's not for the faint of heart. In short, start reading: https://www.yoctoproject.org/
I need to write a xinput driver for a virtual device, e.g. http://cgit.freedesktop.org/~whot/xf86-input-random. The device is connected to a LAN. The client for this device is written in C++. Is it possible to use C++ code in this driver or must the whole project be C only?
An Xorg driver is just an ELF shared object plugin following some documented convention. In principle, how you obtain that .so is your own business (you could in theory write it manually bit by bit if you have centuries of your time to lose).
In principle, you could link the libstdc++.so to your shared object (since one can link shared objects to other ones). I guess that you would compile and link your plugin with g++ and perhaps explicitly need to link with -lstdc++
However, I guess that it might be unsafe. Perhaps C++ ABI requires some specific things to be executed by the crt0.
So you might try, but I won't be surprised if something does not work as you want (e.g. exception handling). It could depend upon the version of the C++ library and the version of the C library and the version of the compiler.... I guess that it might work better with recent g++, recent libc, recent libstdc++ ....
Read Drupper's paper: How to Write Shared Libraries
Make your driver free software, and publish very quickly its source code, so you could get some help from the Xorg community (even when your driver is incomplete). Use probably a recent Xorg....
I'm trying to build my own toolchain for an Raspberry-Pi.
I know there are plenty of prebuilt Toolchains. This work is for educational reasons.
I'm following the embedded arm linux from scratch book.
And succeeded in building a gcc and uClib so far.
I'm building for the target arm-unknown-linux-eabi.
Now that it comes to preparing a bootable filesystem i'm questioning myself about the bootloader build.
The part about the bootloader for this System seems to be incomplete.
Now I'm questioning myself how do I build a uboot for this System with my arm-unknown-linux-eabi toolchain.
Do I need to build a toolchain which doesn't depend on linux kernel calls.
My first reasearch lead me to the point that there are separate kind of tool chain
the OS dependent (linux kernel sys-calls etc...) and the ones which don't need to have a kernel underneath. Sometimes refered to as "Bare-Metal" toolchain or "standalone" toolchain.
Some sources mention that it would be possible to build an U-Boot with the linux toolchain.
If this is true why and how should this work?
And if I have to build a second toolchain for "Bare Metal" Toolchain where can I find informations about the difference between these two. Do I need another libstdc?
You can built U-Boot with the same cross-toolchain used to build the kernel - and most probably the rest of the user-space of the system.
A bootloader is - by definition - self-contained and doesn't care about your choice of C-runtime library because it doesn't use it. Therefore the issue of sys-calls doesn't come into it.
A toolchain is always going to need to be hosted by a fully functioning development system - invariably not your target system. Whatever references you see to a 'bare-metal toolchain' are not referring to the compiler's use of sys-calls (it relies heavily on the operating system for I/O). What is important when building bootloaders and kernels is that compiler and linker are configured to produce statically linked code that can run at specific memory address.
In almost all possible ways, there is no difference between the embedded and the Linux toolchain. But there is one exception.
That exception is __clear_cache - a function that can be generated by the compiler and in a "Linux"-toolchain includes a system call to synchronize instruction and data caches. (See http://blogs.arm.com/software-enablement/141-caches-and-self-modifying-code/ for more information about that bit.)
Now, unless you explicitly add a call to that function, the only way I know for it to be invoked is by writing nested functions in C (a GCC extension that should be avoided).
But it is a difference.