How to run a virtual machine with qemu on an Ubuntu 18.04 x86_64 host system, when I want the guest system to be ARMv8 (Raspberry Pi 3, more specifically interested in the Cortex A53 processor)?
Background:
I want to compile a project for a real machine with ARMv8 on the mentioned host system. Currently, this is done with cross compile directly in the host system. For many different reasons, I want to set up a virtual machine which compiles binaries (virtually) native for the ARMv8. The binaries need to be runable on the real ARMv8 machine later.
Apart from Qemu and the right qemu-system-aarch64 to be installed on the host system, there is an image of the operating system needed. Ideally the same as the one running on the real ARMv8 device. The Ubuntu IoT Core 18.04 64-bit is available at https://ubuntu.com/download/raspberry-pi and I saved it to a local folder with the name ubuntu18045arm64rpi3.img.xz.
After extracting it, I got the extracted image 'ubuntu18045arm64rpi3.img'
To start a virtual machine with the given image and the wanted architecture, I type this:
sudo qemu-system-aarch64 -m 1024 -cpu cortex-a53 -M virt -drive if=none,file=ubuntu18045arm64rpi3.img,id=hd0
which gives me a window like that:
Now my main questions are:
I expected a virtual machine to boot up, where I can install the OS from the given image. What did I do wrong or how to achieve this goal?
Later on, I want to install a compiler (if not already there) on the guest ARMv8 machine and compile my project there. Afterwards I plan to transfer the compiled binaries to the real ARMv8 machine and expect them to run without difficulties. Is this possible with the current approach?
You can't just pass a disk image to the aarch64 QEMU and have it boot. You need to either pass a kernel to boot, or a BIOS (probably UEFI) image (which can then read a kernel off a disk image).
This blog post has an example of running Debian on QEMU; getting Ubuntu booting is probably similar.
https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
Your link is to a raspberry pi specific disk image -- since you are not asking QEMU to model a raspberry pi board I would recommend against using that. You want whatever Ubuntu provides as their most normal/generic aarch64 image. If you're going the "boot via UEFI" route then you want a disk image intended for SBSA/UEFI systems.
On your second question about portability of compiled binaries, this is the same as for any two Linux systems, really. If the two systems have the same OS/distro version (so they have the same library versions etc), and the same sets of runtime libraries installed, and you didn't tell the compiler to compile to use CPU features that the destination CPU doesn't have, then it should work.
Compiling inside this emulated setup is going to be significantly slower than either your current cross-compile setup or compiling the binaries directly on the real AArch64 hardware, incidentally.
Related
I have been developing code for an older device which has an NXP i.MX28 single core CPU which is ARM-based. The device runs Embedded Linux.
I am now upgrading to a better device which has an NXP i.MX6UL quad core processor, of course ARM-based also, and also running Embedded inux.
Is it normal that the same toolchain which I was using for the for building the code for the i.MX28 will also work for the i.MX6UL, even though the i.MX6UL is more advanced with more cores etc.?
I have built my code now for a test with the same compiler and even run it on a Rasberry Pi which seems to run ok. The Rasberry Pi uses a Broadcom BCM2711 SoC with an ARM Cortex-A72 processor which again is a different CPU.
I therefore must ask, will any ARM toolchain build code and be able to run on any type of ARM device regardless?
CPUs differ by the core architecture (incl. instruction set) and set of peripherals. Difference in the peripherals is solved by drivers and HALs. Difference in core arch is solved by the toolchain.
If the toolchain "knows" new arch it will emit the corresponding assembly code, that will run on the new CPU. So, compilers will not produdce the same assembly, but the same source code will run after rebuild, that's the idea of high-level languages.
Problems emerge when old code contains an inline assembly, or uses some specific DSP instructions or libraries
I have my TinkerBoard powered by an ARM-based Mali™-T764 GPU. I am running Debian linaro v2.0.8 strech.
I am looking for an OpenCL support, how can I enable the GPU MALI with OpenCL 1.2 FP?
If you can advice me to update it I would appreciate it.
You need to install the binary ARM Mali drivers. How you do that, depends on the distro you're using. On Odroids for example, it comes installed with their Ubuntu.
Once you have it installed, it either comes with OpenCL enabled, or you can simply enable it: create a file /etc/OpenCL/vendors/mali.icd and put inside that file the path to the driver, e.g. on my Odroid it's /usr/lib/arm-linux-gnueabihf/mali-egl/libmali.so
So first i'd ask on whatever communication channels Debian Linaro has, how to install the binary drivers.
Preface:
Linux and RT is a new realm of discovery, as I am mostly familiar with the Windows environment & Visual Studio C++ development.
Goal:
Execute a few sample 'C' programs on RTLinux, for analysis of deadlines and timing.
Method:
I do not currently have a "target" hardware device. However, I do have a PC with an Intel Core i5.
Questions:
Can I install in a dual boot configuration to preserve my every day
Windows 7 configuration? Will it work with Ubuntu? This is my biggest concern unless I purchase another PC.
Can RTLinux install and execute correctly? I do see it supports x86
but has this been done successfully on a PC configuration - and does it have a GUI to work with?
Are there are reliable simulators that can run on Windows, bypassing installing the OS, that will give good benchmarks of
timing, say of a context switch?
Any other options to run sample programs on RTLinux that I may not be
aware of ?
You can install Ubuntu on a PC with Windows 7 but you will need a separate disk partition and things can go wrong. I have different versions of Ubuntu and other Linux 32 bit and 64 bit distros installed on USB sticks, USB disks and an eSATA disk. The USB devices, at least for Ubuntu, all boot successfully on my desktops and laptops. Booting time and details of my Linux programs are in the following. All are compiled and run from command lines, where commands are provided with the source codes that are free to download.
http://www.roylongbottom.org.uk/linux%20benchmarks.htm
The distros are copied to bootable USB sticks or CDs/DVDs. At least older releases of Ubuntu were easily installed on USB devices or on an hard disk partition but bootable from USB. For later ones, I installed the distros on a laptop, with the disk drive disconnected. Then you can’t go wrong.
I believe that RTLinux uses the same GCC compiler as other Linuxes.
I am developing a project based on OpenCV. Currently I am working on Ubuntu 10.04 system with AMD turion processor. But project need to work as an embedded system. So I am using a readymade board based on ARM11 processor with SAMSUNG S3C6410 processor. It supprot Linux 2.6.28. It also support ubuntu. So how could I port my code from the host system to my embedded system.
Thanks
This is link for the board.
http://www.minidevs.com/
I think the best way to start, is to take a look at Angstrom/OpenEmbedded.
It's a framework for building OS images for various embedded platforms. You could take the precompiled-images, but I've realized that after a while it's not worth the hassle.
Just build the target image yourself (with OpenCV for the target platform, it definitely builds for S3C2440 (tested it myself a year ago or so) and for all OMAP3 platforms (BeagleBoard, EVM and the like).
Then, use OpenEmbedded to build the cross-compiler (there is a package name for that), install it on your host machine, and you should be ready to go.
If there is no support for S3C6410, just use any other ARM11 platform out there, and install the packages. It is likely your vendor-supplied OS was built using OpenEmbedded, it quickly becomes de-facto standard.
http://www.angstrom-distribution.org/
http://www.openembedded.org
Check Linaro if the processor you are looking for is ARM. It looks promising. http://www.linaro.org/
I am developing a 64 bit application. Is it possible to run the 64 bit application on a 32 bit OS?
Please note that the question is generic and not specific to Windows OS. Infact the application in itself is portable across OS.
(We'll assuming your talking about AMD64 (== EM64T == x86_64) and x86 for 64-bit and 32-bit respectively)
You can run AMD64 code on x86 processors only by emulation (e.g. qemu), or some kinds of virtualisation (I believe VMWare might support 64bit guest OS on 32bit host OS on 64
bit capable CPU). However this means running a 64-bit OS as a guest on emulation or virtualisation I believe.
As you're developing the application, it shouldn't be too hard to develop both 32-bit and 64-bit builds of your code.
For Mac you can ship a single binary that has both types of code in it, or Mac OSX can run your 64-bit binary on a 32-bit kernel (only on a x86_64 capable processor though). For Windows and Linux, you'll either have to ship separate installers, or ship some smart installer, that selects the correct binaries at install time. For Linux there is a project for add the ability to run AMD64 code on x86 kernel on AMD64 processor - http://linuxpae64.sourceforge.net/ - but it doesn't look like it's got very far into the mainline kernel.
Is there a particular reason you only want to produce 64-bit binaries?
If it's to access extra memory, then the 32-bit OS wouldn't be able to give you extra memory anyway.
If it's to avoid have to test 2 different versions, then just produce the 32-bit version, it'll work on Windows AMD64, and most Linux AMD64 distributions without problems.
On windows, only using a virtual machine.
On OS X, 64Bit apps run natively (thanks Stephen)
The other way around is fine, bit I dont think you can run a 64bit app on a 32bit OS, you may be able to using a virtual machine or some kind of virtualisation.
There's an easier solution than trying to run a 64-bit program on a 32-bit OS (including executing through an emulated or virtual 64-bit platform on top of the 32-bit OS): recompile it for the 32-bit OS.
When you said it's portable across different OSes, did you also mean non-64-bit OSes? I could not call something portable without qualifying "only 64-bit" if that was the case, and I think many (maybe even most?) programmers also expect that qualification, at least currently.
it is possible using qemu in soft emulation mode
No.
See Microsoft FAQ:
The terms 32-bit and 64-bit refer to
the way a computer's processor (also
called a CPU), handles information.
The 64-bit version of Windows handles
large amounts of random access memory
(RAM) more effectively than a 32-bit
system. For more details, go to A
description of the differences between
32-bit versions of Windows Vista and
64-bit versions of Windows Vista
online.
Understand the difference between 32-bit and 64-bit and you will see why it's not possible.
See this (assuming you're running Windows):
If the program is specifically designed for the 64-bit version of Windows, it won't work on the 32-bit version of Windows. (However, most programs designed for the 32-bit version of Windows will work on the 64-bit version of Windows.)
Device drivers designed for the 64-bit version of Windows won't work on computers running a 32-bit version of Windows. To learn how to check for drivers, see Update a driver for hardware that isn't working properly or go to the device manufacturer's website.
On Windows, no. On OS X, yes. I don't know what the state of affairs is on Linux.
In fact, Snow Leopard boots into a 32-bit kernel, but compiles applications 64-bit by default, so this is quite common on OS X.
A 64 bit application does not run on a 32 bit processor period
A 64 bit application uses a 64 bit wide register. It just plain won't fit.