I have a working debian package that I'd like to backport to the current version of Raspberry Pi OS 64 bit (not 32-bit Raspbian).
Confusingly, while Debian itself seems to be robust about enabling cross-builds in their own package, there seems to be much less official documentation about how raspberry Pi OS (64 bit) packages are built¹.
Since I'm relatively certain this should be possible, I ask:
How to take a debian .dsc / debian rules, and build, on an x86_64, a 64 bit Raspberry Pi OS 64-bit compatible image
without using QEMU to actually build the image on arm64, without access to an actual RPi,
using an existing debian package that is known to work on sid on aarch64, and should be backportable,
making sure it's actually built against the correct set of Raspbian dependencies.
I'm guess this is a rather standard thing, I just don't know how to do it. I'm happy with using containers and similar technology, as I can easily integrate that with CI.
I do not plan to use an Arm64 VM, as the software in question takes about an hour to build and test, on an x86_64 server, natively.
¹I've talked to plugwash of Raspbian fame, and as earlier versions of this question showed: there's significant confusion about the heredity of Raspbian OS 64 bit: It's not Raspbian nor based on it. But people including Wikipedia and the RPi Foundation themselves conflate Raspberry Pi OS and Raspbian ("Raspberry Pi OS, formerly Raspbian"), which is 32 bit only.
RaspberryPi documentation here has explained how to build the x64 kernel from the source. What you want is in a way exactly like that.
Notice this line on the Kernel building page:
sudo apt install crossbuild-essential-arm64
This command on your Linux host machine installs a compiler that runs on an AMD64 machine but produces a binary that runs on an ARM machine.
And this line tells the compiler to actually build the source for that architecture:
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs
Image modules dtbs are specific to your project. they may differ.
As for your Debian package, there is no way that you can transform an AMD64 package into an ARM one. Your package for the RaspberryPi if doesn't exist in an official or some third-party repository, must be built from the source.
Find the source code of your package and build it very similarly to RaspberryOS.
If your Package has dependencies it gets a little more complicated. First, install the dependency on your RaspberryPi. Then you should set up a sysroot on your host machine which is basically a mirror image of the preinstalled packages on RaspberryPi. Then for compiling your package you should give the sysroot address to cross compiler so that it can find dependencies.
There is another way too, you can put the source code of your package on your RaspberryPi and build it locally which can take a very long time based on the source code. Just to have a sense, Qt source code without WebEngine module took 48h for me. But Qt is big.
In conclusion, if your package binary is not on any repository you must compile it from the source.
Cross-compilation of different projects and executables are very similar to each other. To have a clear understanding of the process it can be beneficial to look for some other projects that were ported to RaspberryPi OS. Things like Qt, TagLib for android, and ...
First, I would take a look here:
https://github.com/Truelite/qt5custom for inspiration. I checked and those scritps work. However, you might have problems going completely „qemuless”; e.g. in case of QT some libraries needed to be added to host machine sysroot and qemu was simply the easiest way to add them properly: it seems to me that multiarch Debian has some deficiencies in the field of cross-compilation and the simplest way to overcome them is to pretend it’s the native one.
Related
We’ve been trying to get SikuliX 2.0.5 to run on a RHEL 8 system, and not having much luck.
We went through the instructions on this webpage:
https://sikulix-2014.readthedocs.io/en/latest/newslinux.html#newslinux
We started on RHEL 7, but the OpenCV shared library required a newer version of GLIBC than is standard on RHEL 7 (version ‘GLIBC_2.27’ not found (required by ~/.Sikulix/SikuliLibs/libopencv_java430.so)), so we moved up to RHEL 8. We had to build OpenCV (v4.3.0) from source because we could not find a java companion package for RHEL 8, which required quite a few other dependencies, but in the end we got it built with most options enabled, and installed as root on the system. We also got Tesseract installed via a package, as well as xdotool and wmctrl.
We are setting LD_LIBRARY_PATH to ensure that the OpenCV libs are picked up, and when we run with the “-v -c” options to the IDE, there are no obvious problems reported. It seems to believe it is moving the mouse, though we can see that it is not, and when we try to capture a screenshot, the “canvas” from which to capture is either uninitialized/garbage frame buffer memory, or a totally black screen. On rare occasions we have seen the actual desktop, but most times we do not.
Originally the system had 2 monitors, but was subsequently reconfigured to a single display system. We were originally running remotely over NoMachine, but have also tried running locally and observed no difference in behavior.
Any pointers or suggestions would be most welcome. Given that no error messages are being reported, we are out of ideas for how to proceed in debugging the problem. It appears that more native support is provided for Debian-based systems, but we’re attempting to validate a product which only advertises support for RHEL systems, so we’d prefer to get it working in this environment if at all possible.
I am currently writing an OS based on ARMv8 processor. I want to find an emulator that acts like the processor so I can see my OS working or not and to check my work.
I am on windows 10. are there any emulators recommended ?
I searched SO but no answer. thanks.
Looks like QEMU version 2.1+ is what you want
the latest version of upstream QEMU (2.1) now includes full ARMv8 system emulation support. This means that users can use upstream QEMU to run a full 64-bit ARMv8-A kernel and filesystem, such as a 64-bit Ubuntu cloud image. This was no small endeavour as it involved emulating a completely new instruction set, exception model, CPU implementation, and more. The implementation was verified with a custom instruction verification tool (RISU) and was heavily reviewed upstream by an engaged and incredibly supportive upstream QEMU community.
source
So I will start off by saying that I do NOT want know how to setup or run QT on the pi. I am specifically trying to setup Qt Creator 4.0.3 (Based on Qt 5.7.0 (MSVC 2013, 32 bit)) to write and compile C++ and the run it on the Raspberry pi 2. I have found that running qt on the pi is far to slow.
I have searched for two days to find the right toolchain download for qt/raspberry and its corresponding qt configuration. Nothing seems to work. I have found what seems like a thousand dead ends searching the web. I can write and compile apps for windows console fine. But finding information to cross compile for raspberry seems to be an elusive Unicorn!
Does anyone have this working??? If so which of the many toolchains did you use? And please help me replicate your QT configuration. The closest I have come is using the GCC ARM Embedded toolchain but I cant seem to get the QT options set correctly and I believe that only gets me part of the way there. My ultimate goal is to control GPIO and use the RadioHead library.
Thanks in advance!
I also wanted to do that, and I actually achieved it, It's called "cross-compilation", you build on the Main PC and then compile it to the target.
Initially I wanted to use my main PC with windows 10, but I ended creating a linux partition on my pc to do it since I didn't found any way to do it with windows.
Qt has a very comprehensive tutorial with Qt5 and RaspberryPi2 (both with linux), the only problem is you need linux on your pc to do it. If you want to do this I would suggest following this steps:
Create a linux partition with the same os as in the pi (for example raspbian and debian) and name the username (in linux) "pi" and the password "raspberry". This will help you with external libraries.
Install Qt for Linux on your new partition
Follow Qt's tutorial on https://wiki.qt.io/RaspberryPi2EGLFS
The tutorial is really straightforward, I really recommend it.
Good Luck.
Can you use the CMSIS, HAL, TM libraries for STM32F407 discovery board with eclipse, without STM32Cube? According to this link http://www.carminenoviello.com/en/2015/06/04/stm32-applications-eclipse-gcc-stcube/ you can do it with eclipse & STM32Cube. But I wonder if you can do just same thing without the STM32Cube. Since I'm using OS X, it is impossible to install the STM32Cube, but in order to use the GPIO library I need to use CMSIS, HAL, TM libraries.
You might be able to used the older "Standard Peripheral Driver" model - which was a just a distributed set of driver files specific to the chip. These libraries are no longer supported and are replaced by STM32Cube which generates equivalent code - but with better support for hardware abstraction however they are still very useable.
Search "STM32F4xx_StdPeriph_Driver" to locate the libraries (which include the standard peripheral drivers and CMSIS).
You can download the libraries as a separate zip file
http://www.st.com/web/en/catalog/tools/PF259243
just unpack it and import whatever you need from it into your project. You can take an example project which is closest to your needs, and start developing your application from that. That's what I did in Linux.
There is the STM32CubeMX, which is the installable program you're referring to, and there are STM32CubeF4, STM32CubeL0, etc, which are the firmware package for the different controller families.
CubeMX now officially supports Mac and Linux. However here is an old post how to run it manually http://www.carminenoviello.com/2015/09/09/running-stm32cubemx-macos-finally/.
Regarding the HAL and SPL I'll add that there are really nice libraries in libopencm3 which are developed by community and are not so "buggy" as HAL or SPL.
I found an interesting instruction. You can install the STM32CubeMX on OS X. http://www.stm32duino.com/viewtopic.php?t=267
There is an Eclipse based IDE by OpenSTM32 community called SW4STM32. Available at OpenSTM32 community's site. System Workbench for STM32 installer has been released on the following platforms:
Microsoft Windows Vista and newer (32 bits or 64 bits)
Linux (32 bits or 64 bits)
Mac OSX 10.10 Yosemite and newer + Xcode 7
Java SE JRE 7 or newer
When creating a project you can choose which library you want want to use, SPL, HAL or baremetal.
STM32CubeMX is a initialization code generator. It definitely eases development, but you can write you code completely from the beginning.
STM32CubeMX uses HAL as its Library. You can download the HAL and Include the files that you need and write down the code from scratch. You just need to be aware of the APIs, which are documented in UM1725 Application Note.
But, now STM32CubeMX is also available for Linux and Mac.
I've compiled a cu program on my laptop, using NVIDIA CUDA 5 toolkit. A very basic interface, using only terminal output. Then I went on to test how it runs on my desktop PC (both have Ubuntu 12.04 LTS installed).
On the desktop PC I get this error message:
error while loading shared libraries: libcudart.so.5.0: cannot open shared object file: No such file or directory
Ok, I get it, some libs are not installed. But do I really need to install CUDA toolkit on every PC where I'd want my compiled code to run?
To deploy a CUDA runtime API application on linux you only need to do two things:
Make sure that the machine in question has a CUDA compatible card and a minimum driver version which matches the CUDA Toolkit you used to build the application (you can find information regarding both of these in the release notes of the toolkit)
Distribute the runtime library (so cudart.so) that you built the application against with the executable. If you used any other libraries from the toolkit (like CUBLAS, CUFFT, CUSPARSE, etc) you need to inlcude those too. The CUDA runtime library is versioned and you have to have the libraries which match the toolkit you are building with. You may need to use the LD_LIBRARY_PATH environment variable to ensure that the correct versions of the libraries are found by the link loader. Often a simple shell script which acts the canonical application, settings LD_LIBRARY_PATH variable and running the built executable is the best way to do this.
If you get those two things right, it should just work.