I am new to MPI. I am trying to get my x86 laptop and and a raspberry pi to "work together" via mpi. However I am having a hard time setting it up for the two to work together. I made a machinefile to store IP addresses. When I am running on the raspberry pi with only its IP in the machine file everything runs as expected, it is the same with the laptop. However when I have both IPs in the machine file nothing happens, I have to use ctrl+c to kill the command. On the laptop I am running slackware and on the raspberry pi raspbian.
Here is what I get when i run mpiexec --version
# raspberry pi###############
HYDRA build details:
Version: 3.4.1
Release Date: Fri Jan 22 14:17:48 CST 2021
CC: gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/build/mpich-a7gXGS/mpich-3.4.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro
Configure options: '--with-hwloc-prefix=/usr' '--with-device=ch3' 'FFLAGS=-O2 -ffile-prefix-map=/build/mpich-a7gXGS/mpich-3.4.1=. -fstack-protector-strong -fallow-invalid-boz -fallow-argument-mismatch' '--prefix=/usr' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/mpich-a7gXGS/mpich-3.4.1=. -fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
Process Manager: pmi
Launchers available: ssh rsh fork slurm ll lsf sge manual persist
Topology libraries available:
Resource management kernels available: user slurm ll lsf sge pbs cobalt
Demux engines available: poll select
# Slackware
mpiexec (OpenRTE) 4.1.0
Report bugs to http://www.open-mpi.org/community/help/
the command I am running, on slackware, is
mpirun --hostfile machinefile -np 2 hostname
I want the laptop to be like a head for multiple raspberrys. I Imagined that since mpi is a standard I would be able to get these two versions to communicate without much of a hassle. Is there something I need to configure to get these two computers to work?
Thanks for your time
Related
I installed the ST-Link GDB server from the ST webpage (link)
ST created "ST-Link Server" (link) which bridges the architecture gap and enables us to comfortably monitor and debug the "running binary" (arm architecture) on our workstation PC (x86 or x86_64 architercture) using the "GDB" debugger.
To install the "ST-Link Server" I first download it's .zip file that I can get on the bottom of the page that i linked in the previous paragraph:
Then I uncompress it and run the .msi file that can be found in the compressed file structure. Note that installation wizard will install a command line tool stlinkserver.exe inside the folder:
/mnt/c/Program\ Files\ \(x86\)/STMicroelectronics/stlink_server/
So I move inside and prompt for help:
ziga#EN3310278:~$ cd /mnt/c/Program\ Files\ \(x86\)/STMicroelectronics/stlink_server/
ziga#EN3310278:stlink_server$ ./stlinkserver.exe --help
stlink-server
--help | -h display this help
--version | -v display STLinkserver version
--port | -p set tcp listening port
--debug | -d set debug level <0-5> (incremental, 0: Error, 1:Info, 2:Warning, 3:STlink, 4:Debug, 5:Usb)
--auto-exit | -a exit() when there is no more client
--log_output | -l redirect log output to file <name>
There are very little parameters listed! Weird... Also useless... This seemed weird to me so I investigated further.
"ST-Link Server" has a nice documentation "UM2576" (link). But in the documentation there are more parameters listed than stlinkserver.exe returns to us.
At this point I was so confused that I tried executing one parameter i.e. -g listed in the "UM2576" and application really failed to recognize the parameter:
ziga#EN3310278:stlink_server$ ./stlinkserver.exe -g
stlinkserver.exe: unknown option -- g
Info : default port : 7184
Info : 127.0.0.1:7184
Info : ctrl_handler 0
Ctrl-C event
What is going on with ST? Why doesn't the "ST-Link GDB server" work? How do you use it? I am really confused... And most importantly... I can not connect to my board?
Should I just throw in the towel and use J-Link or OpenOCD???
ST-link server and ST-link GDB server are two different pieces of software.
ST-link server is a tool for sharing a debug adaptor between multiple programs, for example an IDE debugger and command-line programmer. It owns the USB connection and other programs connect to it over sockets.
ST-link GDB server is the server portion of the GNU debugger, configured to use an ST-link adaptor.
If you read the documentation for one and install the other I would expect the arguments not to match up!
I'm using buildroot to compile a minimalistic linux with a 4.19-rt kernel. It is supposed to run on a raspberry pi 3b (arm processor). Additionally I want to run it on a x86_64 linux computer and found qemu as an emulation solution for that.
Building linux and kernel and running it on the raspi works. It boots, I can login and use it.
To test qemu I followed this instruction [1]. A recent raspbian with 4.19 kernel is booting fine so qemu seems to be installed correctly.
sudo qemu-system-arm -kernel ./qemu-rpi-kernel/kernel-qemu-4.19.50-buster -hda 2019-09-26-raspbian-buster-lite.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -dtb qemu-rpi-kernel/versatile-pb.dtb
Bringing 1. and 2. together fails. When I try to emulate any self build linux, qemu only shows a black screen and one CPU is using 100%.
I used the same sdcard.img that works on the real hardware. I also tried to recompile the whole system with a normal 4.19 kernel (without real time). And I tried to build a versatile system (make qemu_arm_versatile_defconfig && make). None of it works.
Command to start the emulation:
sudo qemu-system-arm -kernel zImage -drive format=raw,file=sdcard.img -cpu arm1176 -m 256 -M versatilepb -no-reboot -append "root=/dev/mmcblk0p2 panic=1 rootfstype=ext4 rw" -serial stdio
My main problem is, that there is absolutly no useful output. The command outputs the following
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused
sdl: SDL_OpenAudio failed
sdl: Reason: ALSA: Couldn't open audio device: Connection refused
audio: Failed to create voice `lm4549.out'
and opens a window for the graphics output (that does not show anything). The message also appears when emulating raspbian so it does not seem to be the reason.
When I run qemu with the prebuild raspbian but without the -dtb argument, I get a message like "Error: invalid dtb and unrecognized/unsupported machine ID". I would at least expect something like this with my self build code. But because there is no output I'm out of ideas what even to google for.
Does someone maybe have an idea what I'm doing wrong or how I get qemu to provide me any useful information on what went wrong?
[1] https://blog.agchapman.com/using-qemu-to-emulate-a-raspberry-pi/
The problem is that a kernel will only boot on a piece of Arm hardware if it is compiled for that hardware. Otherwise it will generally fail, usually by crashing before it is able to output anything useful.
In particular, the QEMU 'versatilepb' machine is completely different to the Raspberry Pi. Any working set of instructions that use that machine type are really running a kernel built to work with the versatilepb board and a raspi userspace/filesystem on top of that. You're trying to build a kernel that has support for only the raspi on a machine that isn't a raspi, which won't work.
It is possible to build a kernel that works on more than one piece of Arm hardware, if you compile in the support for both board types (all the device drivers for both, etc). If you want to go down that path, I would suggest looking at the differences between the kernel config for the kernel that works and your one, and add plausible looking missing things until you find out what is actually required.
Your attempt to boot on QEMU directly from sdcard.img will not work, because QEMU's versatilepb board model does not support direct boot from sdcard (this would require us to run some kind of BIOS/firmware image in the guest, which we don't have). For versatilepb you need to supply directly to QEMU the kernel, possibly an initrd, and definitely the correct dtb for the versatilepb.
You might instead try looking at QEMU's "raspi2" and "raspi3" board models, which really do model the hardware of Raspberry Pis. The disadvantages however are that these models are missing some features and are not very actively developed, so often newer kernels don't boot on them, and also since there is no USB controller model there is no way to get networking. (This is why most blog posts etc suggest using the 'versatilepb' -- userspace doesn't often really care about exactly what hardware it's running on, so unless you're trying to do kernel development you can just run a versatilepb kernel and take advantage of the features like networking that that QEMU model has.)
Advanced Linux Sound Architecture (ALSA) tries to open audio interface device . you must provide audio device in qemu . Because the kernel is compiled with ALSA audio driver and you have compiled sdl library in Buildroot.
Inside a Lubuntu VirtualBox VM (macOS host) I'm running QEMU with a U-Boot kernel (?) to load my compiled ARM assembly code (using tftp addr *.bin and go addr).
My problem is that QEMU uses 100% of the CPU. I'm following an Assembly programming course and was told that it wasn't normal (that's also why I'm using a VM)…
I'm not sure where does the problem come from, is it a config issue with VirtualBox (Guest additions are installed) or with QEMU?
QEMU is launched with the following arguments:
export QEMU_AUDIO_DRV=none
qemu-arm/arm-softmmu/qemu-system-arm -s -localtime -m 256 -M reptar -kernel u-boot-arm/u-boot -tftp . -serial mon:stdio -nographic
Version is:
$ qemu-arm/arm-softmmu/qemu-system-arm --version
QEMU emulator version 2.4.1 (qemu-linaro from git), Copyright (c) 2003-2008 Fabrice Bellard
Boot output:
reptar-sp6-emul: sp6_emul_init
sp6_emul_init: failed to connect to SP6 server
sp6_emul_init: terminate thread
U-Boot 2016.09 (Sep 26 2018 - 17:19:23 +0200)
OMAP35XX-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
REDS Reptar board + LPDDR/NAND
I2C: ready
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
Using default environment
Net: smc911x-0
Reptar #
QEMU will use host CPU when the guest CPU is doing something, even if that "something" is "spin around in a tight loop". If the guest code uses the CPU instruction WFI ("wait for interrupt") in its idle loop, QEMU will handle that by stopping until a guest interrupt occurs. (WFI is an Arm instruction; for other guest architectures there is generally an equivalent instruction, like x86's HLT.)
So whether QEMU uses 100% CPU when the guest is "idle" depends on what exactly the guest's idle loop does. The idle loop in a "real OS" like Linux will use WFI (which on real hardware is useful for reducing power consumption) and so will idle at very low host CPU usage. CPU usage sitting at a u-boot prompt will depend on how u-boot is coded; CPU usage in your assembly code will depend on what it does.
You can use cpulimit with -l flag, to limit processor time for particular process. For example:
cpulimit -l 20 -- qemu-system-x86_64 -bios ./u-boot.rom
will limit qemu cpu usage by 20% of one core.
Also, more tricky way on native hardware (probably will not work in virtualbox): if you've got multicore processor, you may dedicate 1 cpu core for qemu, and limit it's clock frequency to lowest possible value, to save energy and keep it cool. Example on my Ryzen 4650u cpu:
install cpupower and tasksel: apt install linux-cpupower tasksel
get lowest possible core clock: cpupower -c 0 frequency-info -l
set core 0 clock frequency to lowest possible value: cpupower -c 0 frequency-set -u clock_freq 1400Mhz
run u-boot in qemu, assign process to core 0: qemu-system-x86_64 -bios ./u-boot.rom & taskset -cp 0 $!
I want to create i386 environment with QEMU and chroot on Raspberry Pi.
I am using Raspberry Pi ver B, but I guess it should not matter much which version is used.
So far I did:
apt-get install qemu qemu-user qemu-user-static binfmt-support debootstrap binutils
Then I mounted chroot directory to /tmp/mnt and ran:
sudo debootstrap --foreign --arch i386 buster ./ http://deb.debian.org/debian/
Then I mounted:
mount -t sysfs /sys /tmp/mnt/sys/
mount -t proc /proc /tmp/mnt/proc/
mount –bind /dev /tmp/mnt/dev/
mount –bind /dev/pts /tmp/mnt/dev/pts/
mount –bind /dev/shm /tmp/mnt/dev/shm/
Now when I try to run second stage of debootstrap:
sudo chroot ./ ./debootstrap/debootstrap --second-stage
I get the following error message:
W: Failure trying to run: /sbin/ldconfig
W: See //debootstrap/debootstrap.log for details
I checked the debootstrap/debootstrap.log:
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
Indeed when I try sudo chroot ./ ./sbin/ldconfig I get same Seg fault.
But when I try sudo chroot ./ ./bin/bash it works.
I am not sure what should be my next step.
I guess it is something related to my qemu config or verison (I am using version 2.8.1(Debian 1:2.8+dfsg-6+deb9u4)). I checked many threads about similar issues, but I could not find one which would help me to find the solution.
OK, I think I figured it out.
It works when I select stretch as Debian version in debootstrap command.
sudo debootstrap --foreign --arch i386 stretch ./ http://deb.debian.org/debian/
Now when I think about it more, it makes sense. I guess running i386 Debian in chroot does not provide full separation from host OS (I mounted proc, sys, etc.).
I had the exact same problem running Raspbian Buster; the problem went away when chrooting Debian Stretch.
So somehow ldconfig from the i386 repository is not working with the qemu-i386-static emulator on buster, but it IS working on stretch!
Has nothing to do with the host system....
The operating system is CentOS 6.5, we could use the following commands for hardware information:
cat /proc/cpuinfo
cat /proc/meminfo
lspci
lsusb
And, how could I get the drivers of these hardware and their versions? Does it need root access? Thank you!
UPDATED