I was trying to play with several tiny operating systems in an emulator but got stuck with Contiki in QEMU. Ideally the compiled executable should be run as a kernel in QEMU. For all OS's I was playing with I used this simple command to run executables in QEMU:
qemu-system-platform -nographic -kernel compiled_executable
In the case of Contiki, QEMU freezes regardless of any target platform the executables are compiled for, even for target platform "native", which according to the documentation, is built with "x86 gcc".
I also tried ARM-based platforms with the same freezing issues. If I specify a correct CPU model (e.g. cortex-m3 for cc2538dk), I received a segmentation fault instead.
I am wondering if I was missing any steps to cause the QEMU to freeze. Does it mean that the compiled executable cannot be treated as kernels (yet), unless I provide some QEMU-specific codes to initialize QEMU as a "board" for Contiki?
The native platform is used to build a "natively" (i.e. on Linux or other OS) executable image of Contiki - an userland app, rather than an OS kernel.
Related
I followed a blog titled Creating an Electron Application for the Raspberry Pi, regarding starting an Electron app in Raspberry Pi using the Buster OS and got it to compile.
But when it came to building the application, using the electron-builder, I keep getting the error of cannot execute... after running the command electron-builder --dir --armv7l --linux deb and can't figure what the issue is. I've attached the error
Sorry to be 6 months late to the party, but I also just tried to create an Electron app to run on the Raspberry Pi.
It turns out that while Electron runs fine on Arm processors, there are a bunch of problems with building an Electron app via electron-builder on an Arm processor.
The error that you are seeing is just the opening of the rabbit-hole.
Most of the issues appear to be due to electron-builder having apparently been implemented on an x86 machine, with no real care having been taken to make sure that it works on any other architecture - x86 is just pretty-much assumed.
So, for me, the answer was to build the Arm target on an x86 Linux machine, using exactly the same command-line that you used.
So far, I have found that I can build for OS X and Windows on OS X, for Linux x86, Linux Arm, OS X, and Windows on Linux x86. I don't have Windows machine, so I'm not sure what actually works there.
Code signing is yet another rabbit hole....
I am getting the following error when running the emulator like this:
emulator: ERROR: x86 emulation currently requires hardware acceleration!
Please Ensure Intel HAXM is properly installed and usable.
CPU acceleration status: HAX kernel module is not installed!
And here I use AMD processors, is there any solution ?
Intel HAXM only runs on certain Intel processors that support Virtualization and ND bit. There are other alternative emulators to the built in one - like GenyMotion
I have HD7690M XT (an overclocked version of 6770M) and Android emulator (sdk tool rev.20) for ICS failed to start hardware OpenGL ES emulation with the following error message:
emulator: ERROR: Could not load OpenGLES emulation library: Could not load DLL!
emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.
and with software renderer I got really bad color resolution (please see the attached screenshots). I suspect that this is due to the software renderer (no such problem in emulating earlier versions of Android). Have someone who can run hardware emulation seen this problem?
What graphic cards can hardware GPU emulation run on? (You can see detailed debug messages by executing $ emulator -avd your_avd_name -verbose)
I had the same problem on my Windows 7 (64-bit) machine. The reason was that the libOpenglRender.DLL could not be located. I added C:\Program Files (x86)\Android\android-sdk\tools\lib to the PATH variable and can start the emulator now without error message. However, I don't see a difference in quality of the graphics compared to your screenshot.
Copy the file below from SDK\tools\lib to SDK\tools.
libEGL_translator.dll
libGLES_CM_translator.dll
libGLES_V2_translator.dll
libOpenglRender.dll
Copy all the dll files from tools\lib to tools.
Add toos\lib to PATH works, the only thing you need to remember is to add it in the HEAD of the PATH, not the end.
Check this post:
https://code.google.com/p/android/issues/detail?id=33336
We've inherited some legacy software that we need to run quite urgently. It was written in Lisp and we don't have the source code (developer is dead), only runs on Mac OS 9 (some bug seems to prevent it running on anything newer) and requires a license dongle to run.
We have an old machine that will run the software, but it is a dinosaur. Ideally, the solution would also provide for remote access as well.
My first thought was to use some kind of emulator on a newer machine, or even a VPS. But I have concerns about how these will work with the USB dongle. Can anyone suggest a solution better than accepting that working with old code sucks and getting on with it?
The most recent hardware I can think is a PowerPC Macintosh, with Mac OS X 10.4 (Tiger). It is the last version of Mac OS X to have the Classic Environment, that will let you run this legacy software.
Alternatively, if you don't have a PowerPC Mac in house, you can look into SheepShaver, a PowerPC emulator, however you'll need a Mac OS install CD.
I am running the Android SDK inside a Windows XP VM in VMWare. As such, the Android Emulator takes forever to boot...
I have recently heard of another emulator -- the MotoDev. For those of you who tried both, could you tell if the MotoDev has any speed advantage over the standard Android Emulator?
I'm the Product Manager for MOTODEV Studio. There is not a separate emulator inside Studio, but rather another view of the existing emulator process that is displayed inside an Eclipse View. It's no faster than what you already have and depending on which transfer mechanism you use (native window vs. VNC), it could be up to 20% slower (native window is faster for Windows and Linux).
Now, as for why your emulator is taking forever...
The first time you start an emulator image (i.e. "AVD"), it has to recreate the entire target filesystem on your local disk. Subsequent launches will take less time.
If I understand correctly, you're letting the Android emulator pretend it's running its' file system through QEMU (Arm Emulator) inside a Windows XP pseudo-file system (VMWare Disk Image) that's running on whatever host operating system you have (your OS). That's a lot of file system manipulation going on. If you can reduce the file system mapping, you're going to see speed improvements. Can you map the Windows Android SDK into a real folder on your native file system? Removing that layer of abstraction is going to speed things up.
Good luck!
Eric