I got a simple program written for freeRTOS (implements a timer).
I want to run this program in an empty virtual machine (VirtualBox, or QEMU, or something else).
I need to make a binary file that can run in and empty VM.
Any advice or direction of how can i do this?
I checked many stuff on freeRTOS homepage but couldn't find something useful.
For virtual box, you will need a binary of freeRTOS that is x86 or amd64 compatible. Check if this is of any benefit for you.
You can check this link, as I understand it's a simulator for freeRTOS which may enable you to test it without a virtual machine.
For QEMU, check this link
Emm..., if you need run just binary file without any OS started you can use qemu for that. Just pass your binary through option '-bios' into qemu. And after qemu will start it to run. Also use '-S -s' options in for enabling gdb server in qemu. After you can connect to qemu with gdb client and debug you binary step by step.
Related
I recently started playing with an ESP8266 and wanted to try uploading to it using WSL. I found the Arduino-CLI command and followed some tutorials but couldn't figure out how to upload to the board. The command I tried running is arduino-cli upload -p /dev/ttyS5 --fqbn esp8266:esp8266:arduino-esp8266 Testing because I know that the board is an ESP8266 and the is connected to COM5 on the Windows Arduino app. The code compiles and attempts to connect to the board, but cannot get past that part.
This is the code I was trying to upload.
void setup() {
pinMode(0, OUTPUT);
}
void loop() {
digitalWrite(0, HIGH);
delay(1000);
digitalWrite(0, LOW);
delay(1000);
}
When I execute arduino-cli board list, it shows this.
Port Protocol Type Board Name FQBN Core
serial Unknown
I'm using Windows Terminal for Ubuntu 20.04 and just installed Arduino-CLI.
I also am not sure how to ask stuff cuz it's my first time using StackOverflow, so pls tell me if I'm doing something wrong :)
Edit: So it turns out that I was uploading using the wrong core. I ended up trying every single core listed by arduino-cli board listall esp8266 and it eventually worked with esp8266:esp8266:nodemcuv2 instead of esp8266:esp8266:arduino-esp8266.
Just educated guesses here from my understanding of WSL rather than Arduino.
I'm assuming that you are using WSL2, which doesn't have access to most Windows hardware, including the serial ports.
If that's the case, two options that you might try:
WSL1 does have some better direct hardware access, at the expense of some kernel compatibility (since it attempts to translate syscalls rather than virtualize them). You can try converting the distribution to WSL1 via:
wsl -l -v
# Confirm distribution name
wsl --set-version <distro_name> 1
You might want to back it up first with wsl --export <distro_name> backup.tar.
As mentioned in the comments, you should be able to use the Windows toolchain. You can even run this under WSL2, since Windows commands can be executed there through interop (and would have hardware access). Remember to use the full executable, like /mnt/c/arduino-cli/arduino-cli.exe. And also you'll need to convert any Linux/WSL paths to their Windows equivalent with wslpath.
Backgournd
There is a lot of documentation about using QEMU for simulating a system of particular architecture (a "platform").
For example, x86, ARM or RISCV system.
The first step is to configure QEMU target-list, for example ./configure --target-list=riscv32-softmmu.
It's also possible to provide multiple targets in the target-list, but apparently that builds an independent simulation for each specified platform.
My goal, however, is to simulate a system with mixed targets: an x86 machine which also hosts a RISCV embedded processor over PCI.
Obviously I need to implement a QEMU PCI device which would host the RISCV device on the x86 platform, and
I have a good idea how to implement a generic PCI device.
However, I'm not sure about the best approach to simulate both x86 and RISCV together on the same QEMU simulation.
One approach is to run two instances of QEMU (as two separate processes) and use some sort of IPC for communicating between the x86 and the RISCV simulation.
Another possible (?) approach could be to build RISCV QEMU as a loadable library and load it from x86 QEMU.
Perhaps it's even possible to have a single QEMU application that simulates both x86 and RISCV?
Yet another approach is not to use QEMU for simulating the RISCV device. I could implement a QEMU PCI device that completely encapsulates a RISCV simulation such as tiny-emu, but I would rather use QEMU for both x86 and RISCV.
My questions are:
Are there some guidelines or examples for a mixed-target QEMU project?
I've searched for examples but only found references to using QEMU as a single platform simulation, where first you choose which platform you would like to run.
What would be the best approach for simulating a mixed platform in QEMU? Separate QEMU processes with IPC? Or is there a way to configure QEMU in such a way that it could simulates a mixed platform?
Related
https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg01969.html
QEMU does not support running multiple target architectures in the same QEMU process. (This is something we would in theory like to be able to do, but it would require a lot of reworking of core parts of QEMU which assume that the target architecture is known at compile time. So far nobody has felt it important enough to put in the significant development effort needed.)
So if you want to do this you'll need to somehow stitch together a QEMU process for the primary architecture with some other process to do the secondary architecture (QEMU or otherwise). This has been done (for instance Xilinx have an out-of-tree QEMU-based system that does this kind of thing with multiple QEMU processes) but I'm not aware of any easy off-the-shelf frameworks or setups to do it. I suspect that figuring out how time/clocks interact between the two simulations is one of the tricky aspects.
There is another option
you can start 2 QEMU processes and connect them through socket
Then you can create run script that start both of them in your order
its less "clock" accurate but good enough for virtual your HW
The other option is https://wiki.qemu.org/Features/MultiProcessQEMU
but you will need some hacking this experimental code
Use renode. It not only provides easy multi cpu simulation, but also hdl and multimachine simulation synchronozed in a single process.
Currently, I have two machines, one with Ubuntu in the company and one with Mac OS at home. Sometimes I would like to work at home while accessing the Ubuntu machine in the company. I can ssh into the Ubuntu machine and navigate and compile there. However, when I actually want to edit some cpp source codes, I realize that the editor (VS code) is actually opened in the Ubuntu machine, so I cannot view it from Mac. What should I do if want to edit files remotely on my Mac through VS code?
Though many of the answers mention using version control tools like git, it can be hard to use in my specific case. The problem is that the building environment of my company is Linux, so most of the building tools I have can only run on Linux. This means that I can only compile my source codes in Linux. If I use git, then every time I want to compile and debug my codes, I have to commit and push with my Mac, and then pull and test on Linux. This can be time consuming if want to incrementally modify, test and debug my codes.
Use some version control system like git. Then you might edit and compile at home (provided your code is portable between Linux & MacOSX, e.g. because it is POSIX compliant).
You could install some X11 server on your Mac and use ssh -X to access the remote Ubuntu machine (then run a GUI or editor remotely, e.g. ssh -X remotelinuxhost.company.com emacs). However, that requires good bandwidth and latency between your home computer and the remote one.
BTW, you might use some other source code editor, like emacs (it is capable of remote editing) or vim.
Since Linux and MacOSX are both POSIX systems, it is usually (but not always) easy to port source code from Linux to MacOSX and write source code compilable on both systems. BTW, many Linux frameworks (e.g. Qt, GTK, POCO, Boost, etc...) and build systems are usable and ported to MacOSX. Some Linux system calls (listed in syscalls(2)) are not available on MacOSX (e.g. signalfd(2)...)
Of course you could install Linux (perhaps inside some VM) on your Apple laptop.
I started learning xv6 recently and was trying to implement a shutdown mechanism in xv6 and i was able to kill all the process running gracefully and wait for some of them to finish and then terminate them. But i am not able to close qemu from the shutdown process.
Could someone suggest how to close qemu from a a xv6 process?
I googled and found out someone used 'outb' and 'outw' commands but both of them don't work.
I don't know if I fully understood your question, but to close the xv6 process running with qemu I use the key combination CTRL + A--> C
It then should show you the (qemu) terminal line that you can close with the command "q".
I am running xv6 in ubuntu OS, for me to close qemu following command worked "control+a, release both keys and type x".
In QEMU, "exit the QEMU process" happens when the guest powers down the emulated hardware. So your guest OS 'shutdown' needs to work by doing the correct hardware operations to power down. (How that is done depends on what hardware QEMU is emulating -- for instance some Arm boards don't have any mechanism for software controlled powerdown at all. Check the documentation for the relevant hardware.)
I am developing on a Windows machine but I have to test it on a PowerPC running QNX. I don't have constant access to the PowerPC, and I just can use it for some test. I was wondering if I could debug my code on a QNX virtual machine on QEMU emulating the PowerPC.
I have found the QEMU binaries for Windows here but I can not find the QNX VM for QEMU. Has anyone done this before?
You don't want your target platform to be PPC all the time. Build your software for x86, test it and recompile it for PPC when you have access to the device. Just make sure your code is portable.
Use VMWare Player or Workstation to install QNX and configure your tools to use the virtual machine for build and debug. That will speed up your development process dramatically!