Booting u-boot in Mac OS X's qemu - gcc

I'm trying to build u-boot, and run it in qemu on Mac OS X.
I found this site, and followed the instructions:
http://imvoid.wordpress.com/2013/05/17/booting-uboot-in-qemu/
For cross compilation on Mac OS X, I could build the tools - How to make ARM cross compilation on Mac OS X (error: invalid listing option `r' - cross compiling error)
For u-boot, I tried the newest edition (2014) that causes core dump, and some earlier version (2010) that doesn't compile, so I used the 2013/10 version (https://dl.dropboxusercontent.com/u/1234/2014/u-boot-2013.10.tar.bz2) to get the uboot.bin.
However, when I run the binary with qemu-system-arm -M versatilepb -m 128M -nographic -kernel u-boot.bin;, there is no crash, but I see nothing from the screen.
What might be wrong? I uploaded the binary.
https://dl.dropboxusercontent.com/u/1234/2014/u-boot.bin
And the 2014 version that crashes.
https://dl.dropboxusercontent.com/u/1234/2014/u-boot_2014.bin

Try using the ELF format file u-boot, instead of u-boot.bin.
$ qemu-system-arm -M versatilepb -m 128M -nographic -kernel u-boot
U-Boot 2014.10-rc2-00312-g9169305 (Oct 06 2014 - 20:43:26)
DRAM: 128 MiB
WARNING: Caches not enabled
Flash: Flash protect error at address 37ec0000
Flash protect error at address 37fc0000
64 MiB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Net: SMC91111-0
Warning: SMC91111-0 using MAC address from net device
Warning: Your board does not use generic board. Please read
doc/README.generic-board and take action. Boards not
upgraded by the late 2014 may break or be removed.
VersatilePB #
I built u-boot commit 91693055995733e268874ae75568ae316233e116 on my OS X 10.9.5 system. I used the ARM toolchain binaries available here. Untar gcc-arm-none-eabi-4_8-2014q3-20140805-mac.tar.bz2 anywhere (e.g. $HOME)
$ git clone http://git.denx.de/u-boot.git
$ cd u-boot
$ make versatilepb_config
$ make CROSS_COMPILE=~/gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-
I used Qemu from Homebrew.
$ qemu-system-arm --version
QEMU emulator version 2.1.2, Copyright (c) 2003-2008 Fabrice Bellard

Related

Issue of "Compiler lacks asm-goto support" with CentOS8+gcc 8.3.1

I have installed CentOS 8.2.2004 minimal onto my PC, using a USB stick.
This PC which has no Internet connection, only has a TP-LINK TL-WN725N USB WiFi dongle , so I have to install linux driver for it. I went to TP-LINK website and downloaded the linux driver(https://static.tp-link.com/2018/201802/20180227/TL-WN725N_V3_Linux.zip) wants to compile/build/install it so make my PC can connect to Internet by this Wifi dongle. However, i met below compiler error:
arch/x86/Makefile:184: *** Compiler lacks asm-goto support.. Stop.
make: *** [Makefile:1367: modules] Error 2
Original CentOS 8.2.2004 minimal has no gcc/make/kernel dev installed, so I have to install them separately by rpm, below are what I have installed:
rpm -qa|grep kernel
kernel-tools-libs-4.18.0-193.el8.x86_64
kernel-modules-4.18.0-193.el8.x86_64
kernel-tools-4.18.0-193.el8.x86_64
kernel-4.18.0-193.el8.x86_64
kernel-core-4.18.0-193.el8.x86_64
kernel-devel-4.18.0-193.el8.x86_64
rpm -qa|grep gcc
gcc-8.3.1-5.el8.0.2.x86_64
gcc-toolset-9-runtime-9.0-4.el8.x86_64
libgcc-8.3.1-5.el8.0.2.x86_64
gcc-c++-8.3.1-5.el8.0.2.x86_64
rpm -qa|grep make
cmake-3.11.4-7.el8.x86_64
automake-1.16.1-6.el8.noarch
make-4.2.1-10.el8.x86_64
as --version
GNU assembler version 2.30-73.el8
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-redhat-linux'.
uname -r
4.18.0-193.el8.x86_64
cat /proc/version
Linux vrsion 4.18.0-193.el8.x86_64(mockbuild#kbuilder.bsys.centos.org)(gcc version 8.3.1 20191121(Red Hat 8.3.1-5)(GCC))#1 SMP Fri May 8 10:59:10 UTC 2020
What's wrong?
Hoping someone can help me out.
Thanks
You are probably missing the elfutils-libelf-devel package.
This package is from the baseos but isn't always needed. You will likely need it for out of tree kernel modules compilation.

gdb 8.2 can't recognized executable file on macOS Mojave 10.14

I get gdb by brew install gdb.
The source file content is:
#include <cstdio>
int main(){
int a = 10;
for(int i = 0; i< 10; i++){
a += i;
}
printf("%d\n",a);
return 0;
}
Here is the executable file named 'demo':
https://pan.baidu.com/s/1wg-ffGCYzPGDI77pRxhyaw
I compile the source file like this:
c++ -g -o demo demo.cpp
And run gdb
gdb ./demo
But, it can't work. It can't recognized the executable file.
GNU gdb (GDB) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin18.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
BFD: /Users/xxx/Codes/demo: unknown load command 0x32
BFD: /Users/xxx/Codes/demo: unknown load command 0x32
"/Users/xxx/Codes/demo": not in executable format: file format not recognized
I use file demo,its ouput is demo: Mach-O 64-bit executable x86_64
I use file ./demo,its output is ./demo: Mach-O 64-bit executable x86_64
Type c++ -v, output is :
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
run ./demo,its output is 55
type show configuration in gdb,it shows:
This GDB was configured as follows:
configure --host=x86_64-apple-darwin18.0.0 --target=x86_64-apple-darwin18.0.0
--with-auto-load-dir=:${prefix}/share/auto-load
--with-auto-load-safe-path=:${prefix}/share/auto-load
--with-expat
--with-gdb-datadir=/usr/local/Cellar/gdb/8.2/share/gdb (relocatable)
--with-jit-reader-dir=/usr/local/Cellar/gdb/8.2/lib/gdb (relocatable)
--without-libunwind-ia64
--without-lzma
--without-babeltrace
--without-intel-pt
--disable-libmcheck
--without-mpfr
--with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
--without-guile
--with-separate-debug-dir=/usr/local/Cellar/gdb/8.2/lib/debug (relocatable)
Who can help me ? Thank you very much !!!
The problem is that clang-1000.11.45.2 distributed with Apple LLVM version 10.0.0 adds a new load command to o-mach executables named LC_BUILD_VERSION.
$ otool -l test.o
...
Load command 1
cmd LC_BUILD_VERSION
cmdsize 24
platform macos
sdk n/a
minos 10.14
ntools 0
...
From the apple source:
/*
* The build_version_command contains the min OS version on which this
* binary was built to run for its platform. The list of known platforms and
* tool values following it.
*/
So currently bfd (the program used by gdb to manipulate executables) is not able to interpret this command and returns the error.
As a temporary solution, you can edit the bfd sources code provides with gdb.
First, download gdb-8.0.1 sources from mirrors. Then add to gdb-8.0.1/bfd/mach-o.c the following code at line 4649 :
case BFD_MACH_O_LC_BUILD_VERSION:
break;
Finally inside gdb-8.0.1/include/mach-o/loader.h at line 189:
BFD_MACH_O_LC_BUILD_VERSION = 0x32
Don't forget to add a , at the end of the line 188 after BFD_MACH_O_LC_VERSION_MIN_WATCHOS = 0x30).
Then process a classic gdb compilation following instructions from the README :
run the ``configure'' script here, e.g.:
./configure
make
To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
make install
Don't forget to sign gdb as explain here.
If you still get the (os/kern) failure (0x5) error, just run sudo gdb.
This is a temporary solution in order to wait for a fix from GNU team.
EDIT
Binutils-gdb has been updated, these changes are now implemented in commit fc7b364.
Hope It will be helpful.
I published a temporary brew formula that seems to work, while awaiting for official brew formula to be updated:
brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb
Upgrade to GDB version 8.3. Also see Issue 23728, binutils fail on macOS 10.14 (Mojave) due to unimpl in the Binutils bug tracker.
From the bug report:
I've found the root of the issue. binutils does not handle load
command 0x32 LC_BUILD_VERSION (nor 0x31 LC_NOTE, actually). They are
defined in recent LLVM versions: see
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/BinaryFormat/MachO.def#L77
Looking at the output of objdump -private-headers there is one clear
difference:
## -56,16 +56,18 ## attributes NO_TOC STRIP_STATIC_SYMS LIVE
reserved1 0
reserved2 0
Load command 1
- cmd LC_VERSION_MIN_MACOSX
- cmdsize 16
- version 10.13
- sdk n/a
+ cmd LC_BUILD_VERSION
+ cmdsize 24
+ platform macos
+ sdk n/a
+ minos 10.14
+ ntools 0
Load command 2
cmd LC_SYMTAB
cmdsize 24
LC_VERSION_MIN_MACOSX is implemented in binutils, while
LC_BUILD_VERSION is not. It is apparently new in Mojave.
I have got a good solution for me from stack overflow and I do not know why it works.
Here is the link.
I am new to macOS, and I do the following:
Codesign gdb 8.0.1 in high Sierra
Update to Mojave
gdb 8.0.1 died with BFD: /Users/xxx/Codes/demo: unknown load command 0x32
Change to gdb 8.2.1 and come across Keychain error Unknown Error -2,147,414,007.
Solve this by getting the certificate in Login then export it and import it into System(Delete it from Login if unable to import).
Finally, because of some kind of errors it still does not work and it comes with ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Unable to find Mach task port for process-id 1510: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8)), according to how to undo codesign, something wrong still exist and the answer tells me to brew reinstall gdb, but it still does not work, I called it a day yesterday.
Finally I come across that link, I AM HAPPYY, now I am able to debug!
Hope my solution can help.
I got gdb working on Mojave by:
a) getting the latest gdb source archive (at time of writing, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz) - amongst other things, it adds handling for recognizing executables on Mac.
b) build gdb. I got errors for variable shadowing in darwin-nat.c so I edited the file and rebuilt.
c) follow steps in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html
Voila.
(source: GDB on Mac/Mojave: During startup program terminated with signal ?, Unknown signal)
gdb 8.2 installed from Homebrew is not compatible with Mac mojave.
I have upgrade to 8.2.1. The issue should be resolved.
The answer by timotheecour above did work for me:
brew install https://raw.githubusercontent.com/timotheecour/homebrew-timutil/master/gdb_tim.rb
Then I had to generate a generate a self-signed certificate as in
https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/
I got past this issue on Mojave by thinning the app. GDB does not understand universal binaries. So if file myapp tells you myapp is a universal binary, try this:
lipo -thin x86_64 -output myapp-x86_64 myapp
And then
gdb myapp-x86_64

Booting Custom 64 bit Kernel for RPI 3 on QEMU

I have compiled a 64 bit kernel for Raspberry pi 3 to use with raspbian.
I did it following this tutorial
https://devsidestory.com/build-a-64-bit-kernel-for-your-raspberry-pi-3/.
As I finished, I ended up with a raspberry image which supposedly used a 64 bit kernel, and the kernel Image.
However, when I run
> qemu-system-aarch64 -kernel Image -cpu cortex-a53 -m 512 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda raspbian64.img
Nothing happens, its like it cant find the kernel.
Is there a way to debug QEMU ? Should I use versatiblepb or something else?
This is an incorrect command line. The 'versatilepb' board is an old development board for 32-bit ARM -- it has no support at all for 64-bit CPUs, and passing -cpu cortex-a53 with -M versatilepb is like trying to jam a Core2Duo CPU into the socket on an i386 motherboard.
You need to build a kernel which will work with one of the 64-bit ARM boards that QEMU emulates (currently 'virt', 'xlnx-ep108' or 'xlnx-zcu102', but I strongly recommend 'virt') and use that board and kernel together. Mismatching board and kernel will not work.

Exec format error 32-bit executable Windows Subsystem for Linux?

When I try to execute a 32-bit file compiled with gcc -m32 main.c -o main on Windows Subsystem for Linux, I get the following error: bash: ./main: cannot execute binary file: Exec format error.
If I compile it without -m32 it runs.
Any solution for running 32-bit executable on WSL?
QEMU and binfmt support light the way :)
https://github.com/microsoft/wsl/issues/2468#issuecomment-374904520
After reading that the WSLInterop between WSL and Windows processes used binfmt, I was tinkering with QEMU to try some ARM development, and incidentally discovered how to get 32-bit support working.
Edit: requires "Fall Creators Update", 1709, build 16299 or newer
Install qemu and binfmt config:
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
You'll need to reactivate binfmt support every time you start WSL:
sudo service binfmt-support start
Enable i386 architecture packages:
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install gcc:i386
Try it out:
$ file /usr/bin/gcc-5
/usr/bin/gcc-5: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=2637bb7cb85f8f12b40f03cd015d404930c3c790, stripped
$ /usr/bin/gcc-5 --version
gcc-5 (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc helloworld.c -o helloworld
$ ./helloworld
Hello, world!
$ file helloworld
helloworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3a0c7be5c6a8d45613e4ef2b7b3474df6224a5da, not stripped
And to prove it really was working, disable i386 support and try again:
$ sudo service binfmt-support stop
* Disabling additional executable binary formats binfmt-support [ OK ]
$ ./helloworld
-bash: ./helloworld: cannot execute binary file: Exec format error
32-bit ELF support isn't provided by WSL (yet). There doesn't seem to be any progress since the UserVoice was raised - you are out luck.
See UserVoice: Please add 32 bit ELF support to the kernel and Support for 32-bit i386 ELF binaries.
If possible, switch to a real Linux ;-)
Since this was originally posted, the support has been available on WSL2 which does support real Linux kernel! So that should be the preferred way.
As noted in the linked github issue, there's also qemu-user which can be used if WSL1 is still used.
WSL2 runs in a real virtual machine using a real Linux kernel, therefore it's actually possible to do anything a Linux VM can do, including running 32-bit code. Just install 32-bit libs by running
sudo dpkg --add-architecture i386
sudo apt-get update
For more information read
Announcing WSL 2
WSL 2 FAQ

FTDI library error on ARMv7

I have a router Asus RT-AC68R with 32GB memory pen mounted to /opt. On it is installed entware including all the tools to build programs natively on the platform ARMv7. Router use TomatoUSB firmware.
I wrote a program to support the module based on the chip FT245 connected via USB to the router. The program compiled on Linux x86_64 and it works correctly on a standard Linux PC. It was - of course - necessary installing library supplied by the manufacturer (FTDI). The manufacturer provides these libraries for various platforms, including the ARMv7 versions soft and hard float. On router I installed library hard float.
These libraries are HERE
So I'm trying to compile the program, prior to the installation of the pen FTDI libraries, according to the documentation. Unfortunately, after starting the program an library error occurs.
Below the way I compile this program (named arco) and the result of running this program on my ARMv7 based router.
root#asus:/opt# gcc -Wl,-rpath=/opt/usr/local/lib -Wl,--dynamic-linker=/opt/lib/ld-linux.so.3 -L/opt/usr/local/lib -O2 -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -mfloat-abi=soft -l ftd2xx arco.c -o arco
root#asus:/opt# ./arco
./arco: error while loading shared libraries: /opt/usr/local/lib/libftd2xx.so: internal error
Additional information about my dev environment:
root#asus:/opt/FTDI# echo $PATH
/opt/bin:/opt/sbin:/opt/bin:/opt/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/home/root:/mmc/sbin:/mmc/bin:/mmc/usr/sbin:/mmc/usr/bin:/opt/sbin:/opt/bin:/opt/usr/sbin:/opt/usr/bin:
root#asus:/opt/FTDI# echo $LD_LIBRARY_PATH
/lib:/usr/lib:/usr/local/lib:/opt/lib:/opt/usr/lib:/opt/include
root#asus:/opt/FTDI# opkg list-installed|grep gcc
gcc - 5.4.0-1
libgcc - 5.4.0-5
root#asus:/opt# uname -a
Linux asus 2.6.36.4brcmarm #5 SMP PREEMPT Tue Aug 16 22:49:47 CEST 2016 armv7l GNU/Linux
I am fairly new when it comes to platform ARMv7 but maybe there is something in compilation options I use:
-mfloat-abi=soft
a library installed is hard-float. I do not know if this could be the reason so expect council colleagues.
Thank you in advance for your answers!

Resources