I am trying to run qemu with code that my teacher provided so that we are able to work on our assignment.
This is being run in Ubuntu 18.04
LIBPATH=/usr/lib/gcc/arm-none-eabi/6.3.1/
arm-none-eabi-as -mcpu=arm926ej-s -g ts.s -o ts.o
arm-none-eabi-gcc -c -mcpu=arm926ej-s -g t.c -o t.o
arm-none-eabi-ld -T t.ld ts.o t.o -o t.elf
arm-none-eabi-ld -T t.ld -L $LIBPATH ts.o t.o -o t.elf -lgcc #-lstr
arm-none-eabi-objcopy -O binary t.elf t.bin
rm *.o *.elf
echo ready to go?
read dummy
qemu-system-arm -M realview-pbx-a9 -m 128M -kernel t.bin \
-serial mon:stdio -serial /dev/pts/2 -serial /dev/pts/2 -serial /dev/pts/2
And the numbers in the last line `-serial /dev/pts/#' are from running ps in the terminal and grabbing the number. All of this is in an executable file, and when I run the file the qemu screen does display, but when I press enter again I recieve this error message
unknown keycodes `(unnamed)', please report to qemu-devel#nongnu.org
I cannot seem to find any clear answer on how to solve this problem. I have tried uninstalling and reinstalling qemu a couple of time.
QEMU's "unknown keycodes" message is about key handling in its graphics window, and means that the host keyboard mapping you're using has some odd setup that it doesn't entirely understand. Usually this means that a few keys won't work right in the graphics window, and you can ignore it unless you're actually having a problem with them. The whole keycode system was completely rewritten in a newer version of QEMU, and this message doesn't even exist any more.
If your test program isn't expecting to use the graphical screen, then you can definitely ignore the message (indeed you could turn off the graphics screen entirely with -display none).
The command line options to QEMU you're using for the serial port look really odd -- you seem to be trying to connect multiple serial ports to the same host tty, which I'm pretty sure won't work right. Unless you're actually using serial ports 1 through 3, just drop those and use the serial port 0 that is set up with "-serial mon:stdio".
Related
Good day,
So I am following this coreboot v3 + OpenBIOS tutorial Here .
In the instructions I have the following...
mkdir foo
cd foo
wget http://www.coreboot.org/images/9/9d/Qemu_coreboot_openbios.zip
wget http://www.coreboot.org/images/0/0d/Vgabios-cirrus.zip
unzip Qemu_coreboot_openbios.zip
unzip Vgabios-cirrus.zip
mv qemu_coreboot_openbios.bin bios.bin
cd ..
qemu -L foo -hda /dev/zero -serial stdio
I noticed that qemu has been replace or is implemented with qemu-system.
command I am running
qemu-x86_64 -L foo -hda /dev/zero -serial stdio
When I run the command, I see just qemu run it's typical and not find a disk.(which I expect since the disk switch points to /dev/zero) but none of the payloads run as I would expect from the tutorial.
What am I doing incorrectly?
Should I use a different version of qemu?
Should I create a dummy disk for this?
Qemu seems to be ignoring the files in the foo directory.
The examples are not up to date, as you have noticed by the renaming of qemu to qemu-system-x86_64.
I managed to get the examples to work using only the cirrus video card, and by renaming the outputs of the zips (bin - bios files to bios-256k.bin). I did this because by adding the -L option I specify the bios location and qemu will look for a file called bios-256k.bin as the bios. The command to run the bios with cirrus (all done while in the foo directory) was
qemu-system-x86_64 -L . -vga cirrus -serial stdio
Both machine types pc and q35 worked.
Background:
I'm trying to figure out how to use ConfigFS to set up an HID device on BeagleBoneBlack.
I found the following example (www.isticktoit.net/?p=1383) on the web and tried it. The sample runs on a Raspberry Pi Zero. However, the sample does not work on my BBB. The following is the script that I wrote and which is executed as root. The script attempts to define a keyboard hid device.
#!/bin/bash
cd /sys/kernel/config/usb_gadget/
modprobe libcomposite
modprobe usb_f_hid
mkdir -p isticktoit
cd isticktoit
echo 0x1d6b > idVendor # Linux Foundation
echo 0x0104 > idProduct # Multifunction Composite Gadget
echo 0x0100 > bcdDevice # v1.0.0
echo 0x0200 > bcdUSB # USB2
mkdir -p strings/0x409
echo "fedcba9876543210" > strings/0x409/serialnumber
echo "Tobias Girstmair" > strings/0x409/manufacturer
echo "iSticktoit.net USB Device" > strings/0x409/product
mkdir -p configs/c.1/strings/0x409
echo "Config 1: ECM network" > configs/c.1/strings/0x409/configuration
echo 250 > configs/c.1/MaxPower
# Add functions here
pwd
mkdir -p functions/hid.xyz
echo 1 > functions/hid.xyz/protocol
echo 1 > functions/hid.xyz/subclass
echo 8 > functions/hid.xyz/report_length
echo -ne \\x05\\x01\\x09\\x06\\xa1\\x01\\x05\\x07\\x19\\xe0\\x29\\xe7\\x15\\x00\\x25\\x01\\x75\\x01\\x95\\x08\\x81\\x02\\x95\\x01\\x75\\x08\\x81\\x03\\x95\\x05\\x75\\x01\\x05\\x08\\x19\\x01\\x29\\x05\\x91\\x02\\x95\\x01\\x75\\x03\\x91\\x03\\x95\\x06\\x75\\x08\\x15\\x00\\x25\\x65\\x05\\x07\\x19\\x00\\x29\\x65\\x81\\x00\\xc0 > functions/hid.xyz/report_desc
ln -s functions/hid.xyz configs/c.1/
# End functions
ls /sys/class/udc > UDC
The error that I get is "ls: write error: Devicew or resource busy".
I am running Debian Jessie - Linux version 4.4.9-ti-r25
I did an lsmod and libcomposite and usb_f_hid are loaded.
The usb device controller, musb-hdrc-0.auto, is loaded.
Questions:
How can I tell which device is busy?
Where can I find the USB configfs defect bug list for BBB.
Is there a logging file and enabling parameter that would give me a clue as to what is happening?
Thanks for any help
David Glaser
The problem you are likely having with the beaglebone black is the cdc_acm driver. It is difficult to remove (well, not really now that I KNOW how to do it) if you don't know how because the steps aren't just laid out to find anywhere yet. I found this: https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/DEFCON-23-Phil-Polstra-One-device-to-Pwn-them-all.pdf
which led me to the following solution
#!/usr/bin/env bash
function checkModule(){
MODULE="$1"
if lsmod | grep "$MODULE" &> /dev/null ; then
echo "$MODULE" found.
return 0
else
echo "$MODULE" not found.
return 1
fi
}
if which 'systemctl' | grep "systemctl" &> /dev/null ; then
systemctl stop serial-getty#ttyGS0.service >/dev/null
fi
if checkModule "g_serial" == 0; then
modprobe -r g_serial
fi
if checkModule "usb_f_acm" == 0; then
modprobe -r usb_f_acm
fi
if ! checkModule "libcomposite" == 0; then
modprobe libcomposite
fi
basically, it stops the serial-getty service which allows you to remove the g_serial device and then this allows you to remove usb_f_acm. This in turn removes the libcomposite device, which you actually want to keep. Once this is done, you can likely do all the things you needed to do. I got a nice HID keyboard working this way (well, okay I guess its a KeygleBone Black now)... It is pretty dirt simple once you understand ALL of the pieces, but I'm having a little trouble tearing my device back down. I might not need to eventually, but I'd like to be able to do that and it seems that certain directories cannot be removed (namely the "strings" directories that I've created). This means I can't really fully tear down the device, but maybe I only need to:
echo "" > /sys/kernel/config/usb_gadget/my_gadget/UDC
to actually tear it down. I haven't worked that part out yet. There are also some C libraries, but I've got a bunch of python scripts that I want to use and I don't yet have python wrappers for those. But that probably isn't too much work.
I didn't want to forget to mention, that I tried to throw the above script into rc.local so the beaglebone black I am using would be "HID ready" on boot. There are probably better locations and methods to do this, but I just wanted to use rc.local because the above is a script, rc.local is a script, it should run on boot... But it doesn't... You have to make sure to make rc.local runable ( chmod 755 /etc/rc.local ) as well as modifying the default shell it wants to run (well, it always runs bash, but its method for running bash is the "POSIX" method, and that doesn't seem to work, so you have to force it to run bash in non-POSIX mode with:
#!/usr/bin/bash
Again, there are probably other better methods (I was lazy here and, well, I'm just old school), especially if your device is going to be an IoT device or anything linked to the net, so you might want to consider something else if you need this script to run on boot.
I did stupidly leave out one thing: I made sure the beaglebone black doesn't present its usual "disk" portion as well. I would put the details here, but frankly, those I'd have to track back down. I basically googled around for how to disable the beaglebone black disk. It isn't hard and amounted to me moving some file to another name so it doesn't find the "USB disk" configuration on boot. You can also change a line in the uboot config somewhere I believe, but I didn't really want to do that.
Found the file: /var/local/bb_usb_mass_storage.img
Well, it might be bbg_usb_mass_storage.img if it is a beaglebone green, but I just moved this file so it wouldn't present the mass storage device. That should allow you to do what you want.
I compiled the Linux kernel (version 2.6.32) using the Emdebian ARM toolchain. Downloaded the initrd from Aurel's personal FTP server hosted on Debian here.
The ran qemu like so:
qemu-system-arm -M versatilepb -kernel zImage -hda hda.img -initrd initrd_versatile.gz -append "root=/dev/ram" -m 1024
Yet it fails with qemu reporting:
mount: mouting none of /run failed invalid argument.
Keen to hear if someone has something to say about this. As I search for it, could someone also let me know if it is possible to use an off the shelf initrd or is it related to the kernel version being run?
I was able to run the machine by cross compiling busybox, creating a cpio archive image and then using it like so:
qemu-system-arm -M versatilepb -m 128M -kernel zImage -initrd rootfs.img -append "root=/dev/ram rdinit=/bin/sh console=tty1"
Now that Ive got it working Ill investigate what those arguments actually mean.
I'm trying to automate some things on remote Linux machines with bash scripting on Linux machine and have a working command (the braces are a relict from cmd concatenations):
(ssh -i /path/to/private_key user#remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"')
But if an ampersand is concatenated to execute it in background, it seems to execute, but no output is printed, neither on stdout, nor on stderr, and even a redirection to a file (inside the braces) does not work...:
(ssh -i /path/to/private_key user#remoteHost 'sh -c "echo 1; echo 2; echo 3; uname -a"') &
By the way, I'm running the ssh client dropbear v0.52 in BusyBox v1.17.4 on Linux 2.4.37.10 (TomatoUSB build on a WRT54G).
Is there a way to get the output either? What's the reason for this behaviour?
EDIT:
For convenience, here's the plain ssh help output (on my TomatoUSB):
Dropbear client v0.52
Usage: ssh [options] [user#]host[/port][,[user#]host/port],...] [command]
Options are:
-p <remoteport>
-l <username>
-t Allocate a pty
-T Don't allocate a pty
-N Don't run a remote command
-f Run in background after auth
-y Always accept remote host key if unknown
-s Request a subsystem (use for sftp)
-i <identityfile> (multiple allowed)
-L <listenport:remotehost:remoteport> Local port forwarding
-g Allow remote hosts to connect to forwarded ports
-R <listenport:remotehost:remoteport> Remote port forwarding
-W <receive_window_buffer> (default 12288, larger may be faster, max 1MB)
-K <keepalive> (0 is never, default 0)
-I <idle_timeout> (0 is never, default 0)
-B <endhost:endport> Netcat-alike forwarding
-J <proxy_program> Use program pipe rather than TCP connection
Amendment after 1 day:
The braces do not hurt, with and without its the same result. I wanted to put the ssh authentication to background, so the -f option is not a solution. Interesting side note: if an unexpected option is specified (like -v), the error message WARNING: Ignoring unknown argument '-v' is displayed - even when put in background, so getting output from background processes generally works in my environment.
I tried on x86 Ubuntu regular ssh client: it works. I also tried dbclient on x86 Ubuntu: works, too. So this problem seems to be specific to the TomatoUSB build - or inside the "dropbear v0.52" was an unknown fix between the build in TomatoUSB and the one Ubuntu provides (difference in help output is just the double-sized default receive window buffer on Ubuntu)... how can a process know if it was put in background? Is there a solution to the problem?
I had the similar problem on my OpenWRT router. Dropbear SSH client does not write anything to output if there is no stdin, e.g. when run by cron. I presume that & has the same effect on process stdin (no input).
I found some workaround on author's bugtracker. Try to redirect input from /dev/zero.
Like:
ssh -i yourkey user#remotehost "echo 123" </dev/zero &
It worked for me as I tried to describe at my blog page.
Do you think it's possible to compile ssh using the Intel compiler? I don't really know where to start and there's not much info on google, so I thought I'd ask the community.
I really want to take advantage of the compression performance improvements. My idea is to set up an unencrypted ssh tunnel (but with maximum compression) as follows:
ssh -N -g -f -C -o CompressionLevel=9 -o Cipher=none eamorr#172.16.1.218 -L 6999:172.16.1.218:3129
Any advice greatly appreciated,
Build instructions for OpenSSH can be found here: http://unixwiz.net/techtips/openssh.html.
When you do the ./configure steps you'll want to do something like ./configure CC=icc CXX=icpc in order to use the ICC compiler rather than gcc.
If you've done it right then when you subsequently do a make you should see during the build that the compile lines will start with icc ... or icpc ... rather than gcc ... or g++ ....