I'm about to start learning PowerPC architecture and as an example of I've downloaded some reference manuals from NXP website as well as theirs SDK so I can build even bareboard applications. To be precise I'm using virtual host environment. I don't have any board with PowerPC processor on it so I would like to use a simulator for debugging.
At this step I'm a little confused. So, I've built an bareboard application (a 'Hello World' one). And now I'd like to run it with simulator. I've tried to use a command like this: qemu-system-ppc -machine ppce500 -cpu e500v2 -nographic -kernel ./a.out and saw nothing. The qemu just loads host CPU. ./a.out is the binary built with command $CC -static ./tst.c. So, now I don't even know how to deal with qemu.
For those, who would like to help: I'm using Virtual Host environment for Freescale P1010 processor with e500v2 core, the binary was built with theirs fsl-* utilities.
The source compiled was:
$ cat ./tst.c
#include <unistd.h>
#define STRING "This is a test.\n"
int main(void) {
write(1, STRING, sizeof(STRING) - 1);
return 0;
}
Compilation took place like:
$ echo $CC
powerpc-fsl-linux-gnuspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double --sysroot=/opt/fsl-qoriq/1.9/sysroots/ppce500v2-fsl-linux-gnuspe
$ $CC -static -o tst.bin ./tst.c
$ file ./tst.bin
./tst.bin: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=63b307e7afe9de0b2781f2f92b5f1b3a803f850d, not stripped
Other than using a simulator, Why don't you ask for a real free virtual machine to do development/learning? From what you say, it should work better.
You can ask a VM in the following sites:
[Brazil] http://openpower.ic.unicamp.br/minicloud/
[China] https://dashboard.ptopenlab.com
You're not seeing anything as you're asking qemu-system-powerpc to run a userspace binary rather than a kernel.
If you're just wanting to poke at userspace programming, try the qemu-ppc binary instead, as that will run 32bit PowerPC userspace by doing things like translating syscalls.
Another option, if you want to program the bare metal, is to start writing your own tiny OS to a specific machine type (i.e. you're going to have to implement that write() call you're calling).
Related
My development environment consists of a Teensy 3.5, PlatformIO, and CLion. How can I make use of the standard Arduino Keyboard library?
I'm working on a project to convert a previously RS422-based device to USB. Earlier on, I used the (sadly rather horrible) Arduino IDE so I know that my code for when to send which keystrokes should work; the problem is getting the new IDE and compiler to understand the dependencies.
All along, I've been using the Serial interface to provide debug output, so I know that Serial works just fine. Ditto for using the Keyboard library from within the Arduino IDE.
However, after switching to CLion and adapting to the PlatformIO framework, I ran into problems when it came time to include the Keyboard library.
The line
#include <Arduino.h>
resolves to the file ~/.platformio/packages/framework-arduinoteensy/cores/teensy3/Arduino.h which itself seems to simply be a shim for ~/.platformio/packages/framework-arduinoteensy/cores/teensy3/WProgram.h which implements the expected Arduino functionality.
However, the line
#include <Keyboard.h>
resolves to the file ~/.platformio/packages/framework-arduinoteensy/cores/teensy3/Keyboard.h which quite frankly states that it is an empty Keyboard.h file, for compability with Arduino's Keyboard examples and does not implement anything.
I have been trying to find ways of importing the original Arduino library (by way of platformio.ini, but it seems to depend on HID and PluggableUSB that I simply cannot find.
Here is my current platformio.ini file:
[env:teensy35]
platform = teensy
board = teensy35
framework = arduino
; Avoid the Teensy loader gui app
upload_protocol = teensy-cli
lib_deps =
Keyboard
and this is the build output I am getting:
====================[ Build | Production | teensy35 ]===========================
~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/223.8617.54/bin/cmake/linux/x64/bin/cmake --build ~/code/teensy-axial/cmake-build-teensy35 --target Production -j 6
[1/1] cd ~/code/teensy-axial && platformio -c clion run -eteensy35
FAILED: CMakeFiles/Production ~/code/teensy-axial/cmake-build-teensy35/CMakeFiles/Production
cd ~/code/teensy-axial && platformio -c clion run -eteensy35
Processing teensy35 (platform: teensy; board: teensy35; framework: arduino)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/teensy/teensy35.html
PLATFORM: Teensy (4.17.0) > Teensy 3.5
HARDWARE: MK64FX512 120MHz, 255.99KB RAM, 512KB Flash
DEBUG: Current (jlink) External (jlink)
PACKAGES:
- framework-arduinoteensy # 1.157.220801 (1.57)
- toolchain-gccarmnoneeabi # 1.50401.190816 (5.4.1)
LDF: Library Dependency Finder -> [redacted for StackExchange]
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 94 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Keyboard # 1.0.4
Building in release mode
Compiling .pio/build/teensy35/src/AxialKeyboard.cpp.o
Compiling .pio/build/teensy35/src/main.cpp.o
Compiling .pio/build/teensy35/lib882/Keyboard/Keyboard.cpp.o
Compiling .pio/build/teensy35/lib882/Keyboard/KeyboardLayout_da_DK.cpp.o
Compiling .pio/build/teensy35/lib882/Keyboard/KeyboardLayout_de_DE.cpp.o
In file included from .pio/libdeps/teensy35/Keyboard/src/Keyboard.cpp:22:0:
.pio/libdeps/teensy35/Keyboard/src/Keyboard.h:25:17: fatal error: HID.h: No such file or directory
*************************************************************
* Looking for HID.h dependency? Check our library registry!
*
* CLI > platformio lib search "header:HID.h"
* Web > https://registry.platformio.org/search?q=header:HID.h
*
*************************************************************
compilation terminated.
[...]
I have obviously visited the registry as suggested and tried to implement both mitchman631/HID and levi--g/USBLibrarySTM32 but still I end up missing either HID or PluggableUSB dependencies, and I cannot find a PluggableUSB.h file anywhere. Surely, there must be something fundamental I am not seeing?
Amending platformio.ini with the path to the Arduino libraries did not resolve the error.
lib_extra_dirs =
/usr/share/arduino/libraries
so I removed these lines again.
I have also tried enabling the --verbose option by copying the command from the above output:
~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/223.8617.54/bin/cmake/linux/x64/bin/cmake --verbose --build ~/code/teensy-axial/cmake-build-teensy35
but oddly that results in
CMake Error: Unknown argument --build
even though it should know it:
~/.local/share/JetBrains/Toolbox/apps/CLion/ch-0/223.8617.54/bin/cmake/linux/x64/bin/cmake --help | grep build
cmake [options] <path-to-existing-build>
cmake [options] -S <path-to-source> -B <path-to-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
-B <path-to-build> = Explicitly specify a build directory.
-G <generator-name> = Specify a build system generator.
--build <dir> = Build a CMake-generated project binary tree.
I suspect my question is similar to this one, although my problem is with adding any library.
Many questions in this forum start with "why does my code not run..." For a change, this one is "why does my code run..."
I develop on Ubuntu 18.04 running as a VM machine on a laptop (windows x86).
The following program compiled and linked with gcc runs fine and displays a 64 bit address.
char *s = "Hello\n"; printf ("Hello at address: %p\n", s);
My assumption is that arm-none-eabi targets a system bare metal. Of course I am not trying to run the above program on a bare metal. But I am trying to understand how cross compilation works.
The same program compiled and linked with arm-none-eabi-gcc (installed from Ubuntu) indicates a lot of missing references (_exit ...etc.) - normal. The code created is ARM assembly language, I verified with arm-none-eabi-objdump.
Adding the option --specs=nosys.specs at load time solves the missing references - as expected. When I run it on Ubuntu, QEMU is automatically called and has a segmentation fault. I am not surprised about the segmentation fault but the automatic launch of QEMU was unexpected.
Changing the option to --spec=rdimon.specs also solves the missing references - as expected. But despite the assembly code created is arm, it runs on Ubuntu (x86). The address displayed is 32 bits.
I know that rdimon.specs relates to semi-hosting, but I thought this was only activated when the program runs on the target (arm processor) and communicates with the host running gdb. Apparently I am wrong.
Sorry about this long preamble...simple question: how is it that my arm code runs on x86?
This is a result of the binfmt mechanism. When qemu is installed, it registers itself to run non-native executables, and is transparently invoked when a non-native ELF is executed. When semihosting is enabled using rdimon specs, it links a suitable set of libc stubs which cooperate with the host environment.
this is my first Stackoverflow question :-)
My background:
2 years Python experience
2 months crystal-lang experience ( websites running with Amber framework )
1 month into C, C++ , assembly
Facts:
- crystal-lang is compiling and running without any problem
- running on x86_64
Please be nice, as i don't have much low-level language knowledge yet.
From my understanding, when we compile and run a basic hello.c file using LLVM, it goes as follow:
hello.c :
#include
int main() {
printf("hello world\n");
return 0;
}
shell :
$ clang -O3 -emit-llvm hello.c -c -o hello.bc
$ llc hello.bc -o hello.s
$ gcc hello.s -o hello.native
$ ./hello.native
this comes from the LLVM examples )
My point is that we can produce a pretty short hello.bc file (128 lines) that can be run in a slower way using:
$ lli hello.bc
but when I tried to generate a similar hello.bc from a hello.cr file and run it like i did with the hello.c file:
hello.cr :
puts "hello world"
shell :
$ crystal build hello.cr --emit llvm-bc --release
$ llc hello.bc -o hello.s
what i noticed:
This hello.bc file is much much bigger than the one generating from the c file (43'624 lines)
This hello.bc can't be run using "lli" as it generates an:
"LLVM ERROR: Program used external function 'pcre_malloc' which could not be resolved!
I can't even compile from hello.s to hello.native
Same problem if i try to use generate and hello.ll file
As i understood, LLVM is portable , and that all front-end languages would produce an intermediate *.bc that can then be compiled to any architecture.
My questions are:
Why are the hello.bc not similar in both cases ?
Am I doing something wrong in the crystal procedure ?
Thank you!
Everything is just as it is supposed to be. Crystal has a runtime library that is always present even if you didn't include anything. This is required to run the Crystal program.
The C example pretty much doesn't contain anything else than a syscall to printf. That's why the compiled ASM is also really tiny.
Crystal's simple puts call has a much more behind it. It is based on libraries for handling asynchronous IO, concurrency, signal handling, garbage collection and more. Some of these libraries are completely implemented in the Crystal standard library, some use other libraries that are either directly embedded into the binary (libgc) or still require dynamic libraries from the system (libpcre, libpthread).
Any Crystal program comes with this runtime library by default. Even an empty program. This usually goes completely unnoticed because larger programs will eventually need those things anyway and the compiled binary size of the runtime library is less than 500 KB (in release mode).
Such a small program like yours doesn't really need all of this just to print a string. But these libraries are required for the Crystal runtime.
NOTE: You can compile a Crystal program without these default libraries. But this means you can't use anything from the Crystal stdlib and you have to essentially write C code with Crystal syntax (or implement your own stdlib):
require "lib_c"
require "c/stdio"
LibC.printf pointerof("hello world".#c)
This can be compiled with --prelude=empty option and it will generate a substantially smaller ASM, roughly similar to the C example.
From what I've read, there is a llvm program that converts java bytecode to llvm's intermediate form called class2llvm. My question is, how do I access this. What front end do I have to install in order to access this.
VMkit is their implementation of a JVM, but I am looking for how to compile the java source code with llvm, not how to run it.
The Java frontend translates Java bytecode (.class files) into LLVM
bytecode. Take a look at this link:
https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt
You may take a look at dragonegg, which enables llvm to use gcc's frontends. As gcc already has a frontend for java, called gcj, perhaps llvm can use it to compile java code. But I'm not sure how well llvm interfaces with the gcc frontend, so this may not work.
I have executed a java class using vmkit ( http://vmkit.llvm.org/ ) based on LLVM. It uses LLVM for compiling and optimizing high-level languages to machine code. J3 is an implementation of a JVM with VMKit.
[NOTE: From November 2015 it is no longer open source, so this hack is mostly useless.]
RoboVM might become the solution you're looking for. It's open source and compiles JVM bytecode (.class files) to machine code.
I assume they do it using something like class2llvm.
Unfortunately, it's still in alpha. I just tested it on HelloWorld.java. It gave 5x speed up of load time running on a single core. (Most of the run time is load time.)
echo Hello World! : <1 ms : 31K (/usr/bin/echo binary)
java HelloWorld : ~70 ms : 0.4K (HelloWorld.class JVM bytecode)
./HelloWorld : ~13 ms : 9.4MB (9.3MB binary + 57K robovm-rt.jar)
Note that java calls a 32MB $JAVA_HOME/lib/rt.jar file (and maybe more). Searching in such a large file must be part of the reason java is so slow to load. If RoboVM gets smarter, perhaps it can throw out most of the 9.3MB binary for an even faster load?
The website mentions iOS, but I think that's because they're selling their add-on UI libraries. RoboVM compiled fine for me on a flavor of Ubuntu. Just make sure to do
$ sudo apt-get install g++-multilib
first (and maybe install libpthread-stubs0-dev and libpthread-workqueue0...don't know if they mattered).
I'm trying to build an application from source in windows that requires some Unix tools. I think it's the apparently standard ./configure; make; make install (there's no INSTALL file). First I tried MinGW but got confused that there was no bash, autoconf, m4, or automake exes in \bin. I'm sure I missed something obvious but I installed Cygwin anyways just to move forward. For some reason when I run
sh configure.sh
I get:
platform unix
compiler cc
configuration directory ./builds/unix
configuration rules ./builds/unix/unix.mk
My OS has identity problems. Obviously the makefile is all wrong since I'm not on unix but win32. Why would the configure script think this? I assume it has something to do with Cygwin but if I remove that I can't build it at all. Please help; I'm very confused.
Also is it possible to build using MinGW? What's the command for bash and is mingw32-make the same as make? I noticed they're different sizes.
Everything is fine. When you are inside CygWin, you are basically emulating an UNIX. sh runs inside CygWin, and thus identifies the OS correctly as Unix.
Have a look at GCW - The Gnu C compiler for Windows
Also, you might be interested in this help page, that goes into some detail about the minimal system (MSYS), such as how to install, configure et. c.
That should help you get bash, configure and the rest to work for MinGW as well.
From the Cygwin home page
Cygwin is a Linux-like environment for Windows. It consists of two parts:
A DLL (cygwin1.dll) which acts as a Linux API emulation layer providing substantial Linux API functionality.
A collection of tools which provide Linux look and feel.
Since configure is using the Cygwin environment, it is interacting against the emulation layer and so it is just like it's working on a Unix environment.
Have you tried building the application and seeing if it works?