thank you for read my problem.
I'm going to debug mips assembly on QEMU environment.
But I was confronted some problem.
I typed this command
qemu-system-mipsel -M malta -kernel vmlinux-2.6.32-5-5kc-malta -hda debian_squeeze_mipsel_standard.qcow2 -append "root=/dev/sda1" -redir tcp:4444::4444 -nographic
And qemu-system-mipsel said me an error
-redir tcp:4444::4444: The -redir option is deprecated. Please use '-netdev user,hostfwd=...' instead.
If -redir option is deprecated, how change my command using by -netdev option???
What's more strange is qemu-system-mipsel -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda debian_wheezy_mipsel_standard.qcow2 -append "root=/dev/sda1" -redir tcp:4444::4444 -nographic command is successful on debian_wheezy_mipsel environment!
Is this only debian_squeeze_mipsel problem?
But I can't use debian_wheezy_mipsel... this version couldn't operate apt-get package well. So, I couldn't debug mips binary using by gdb or gcc.
Thank you:)
The QEMU project documents the replacements for deprecated-and-then-removed features in https://wiki.qemu.org/Features/RemovedFeatures -- in this case it says:
The -redir [tcp|udp]:hostport:[guestaddr]:guestport argument is replaced by either -netdev user,id=x,hostfwd=[tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport (for pluggable NICs, accompanied with -device …,netdev=x) or -nic user,hostfwd=[tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport (for embedded NICs). The new syntax allows different settings to be provided per NIC.
The feature was deprecated in QEMU v2.6.0 and dropped entirely in v3.1.0. So QEMU versions before 2.6 will not complain; QEMU between 2.6 and 3.0 will produce the deprecation warning but work the same as older versions; and 3.1 and later will refuse to start because they don't recognize the option.
In your case I think the malta board uses a pluggable 'pcnet' PCI card, which would imply that you want the "-netdev user,id=x,hostfwd=... -device pcnet,netdev=x" of the two options above. If that doesn't work, try the other instead.
Related
I was trying to write a "hello world" x86_64 OS with GNU-EFI according to an article:https://wiki.osdev.org/GNU-EFI, but I ran into some problem.
When I boot the img using following command
sudo qemu-system-x86_64 -drive file=$(BUILD_DIR)/$(OSNAME).img -m 256M -cpu qemu64 \
-drive if=pflash,format=raw,unit=0,file="$(OVMF_DIR)/OVMF_CODE.fd",readonly=on \
-drive if=pflash,format=raw,unit=1,file="$(OVMF_DIR)/OVMF_VARS.fd" \
-net none
Qemu hangs after printing Found bootloader on fs0:
I can't find out what cause it.
I suspect I made some mistakes in the Makefile.
Heres the code repo:https://github.com/xubury/myos for reproduce.
BTW, you may need to specify path to gnu-efi and ovmf in the Makefile.
I ran the code under OS: Arch Linux x86_64 and Kernel: 5.11.1-arch1-1
Many thanks in advance!
So, apparently the problem goes away when I put -lgnuefi -lefi at the end of the linkage. But I don't know excatly why. Also, the gnu-efi function should be called using uefi_call_warpper for some ABI compatibility issues.
I am debugging the Linux Kernel (latest version) using GDB and QEMU.
I have set DEBUG_INFO to yes in the configuration file.
Here is how I call QEMU:
$> qemu-system-x86_64 -snapshot -m 4G -serial stdio -kernel ~/Documents/kernel/arch/x86_64/boot/bzImage -initrd ~/D\
ocuments/kernel/initrd/initrd_x86_64.gz -append "root=/dev/sda1 ignore_loglevel" -s
And GDB of course:
$> gdb vmlinux
Then inside gdb:
(gdb)> target remote :1234
So nothing amazing.
It stops QEMU. I set my breakpoints, which seems to work as usual, and I type "continue". The QEMU execution resumes.
But then, even if my function is reached (I see the kernel message printk I set inside the function), gdb does not stop.
$> qemu-system-x86_64 --version
QEMU emulator version 2.12.0 (Debian 1:2.12+dfsg-3)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
And
$> gdb --version
GNU gdb (Debian 8.1-4) 8.1
I don't know what to try next.
Any help would be appreciated.
PS: for information, I am writing a keylogger as a Linux driver. So I am registering a new keyboard notifier, and this is the keyboard notifier that is failing.
PS2: I also tried what they recommend here stack overflow question about setting hardware breakpoints instead, but it did not change anything, same problem.
Thank you.
Julien
I compiled my custom kernel with different configs and images like u,zImages. But when I try to run qemu with my image, qemu showing only black screen.
Also I looked at this post but it didn't help me.
EDIT
I just tried to compile kernel with these commands.
make ARCH=arm distclean
make ARCH=arm integrator_defconfig
make ARCH=arm menuconfig
NOTE: I used default menuconfig.
make ARCH=arm CROSS_COMPILE=arm-none-eabi- zImage
qemu-system-arm -M integratorcp -kernel arch/arm/boot/zImage
And last i tried this command;
qemu-system-arm -M integratorcp -kernel arch/arm/boot/zImage -append 'console=ttyAMA0 earlyprintk=ttyAMA0' -serial stdio
NOTE: when i try to use -dtb, qemu giving to me "Unable to copy device tree in memory." error.
"QEMU does nothing with a black screen" almost always means "QEMU is running fine, but the guest code crashed or stopped early in the boot process without sending any output". Almost certainly either your kernel is misconfigured, or your QEMU command line is wrong. You don't give enough information to say which. You need to tell us at least:
what the kernel is you're running and what machine you've configured it for
what the QEMU command line you're using is
Given your updated question with a command line, some suggestions:
tell your guest to use the serial port (use the QEMU option -append 'console=ttyAMA0' to set the guest kernel command line)
either check the serial output view in the GUI, or send it to stdout with -nographic or -serial stdio
enable any earlyprintk or earlycon options in the guest config that you can and on the guest command line, so if the guest fails early you have more chance to catch it
pass the device tree for the kernel with -dtb integratorcp.dtb (use the one from your kernel tree; you'll probably have to tell the kernel makefiles to build it for you)
PS: integratorcp is an absolutely ancient development board -- why do you want to use it?
I am facing problem with interrupt in guest OS runing in qemu-2.3.0.
I am loading windriver (Linux kernel-2.6.34.12-grsec) in -nographic mode in Qemu emulator on Ubuntu 14.04 host.
Host details:
>$ uname -a
>$ Linux my-qemu-host 3.13.0-52-generic #86-Ubuntu SMP Mon May 4 04:32:59 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
my command line is:
>$ qemu-system-x86_64 -enable-kvm -nographic -k en-us -kernel ${KERNEL} -cpu kvm64 -smp 4 -m 1G ${NETCFG} -gdb tcp::1234 -append "console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=${NFSROOT}" -hda /home/hda
I am getting following logs in /var/log/kern.log
kernel: serial8250: too much work for irq4
I searched to get rid of this but so many people are suggesting to increase PASS_LIMIT in /serial/8250.c file. this workaround is just avoiding error messages in kern.log file.
Any one having idea how to stop or slow down interrupt frequency?
What exactly are you running i.e. what sort of build? It appears that some hefty serial work is going on (which is expected with embedded).
I just googled how to disable the kernel module for the serial8250 to see if that would help and happened upon this:
http://www.spinics.net/lists/linux-serial/msg12360.html
Another thought, seeing as windriver (if it's this: http://www.windriver.com/products/linux/) then I wouldn't be shocked if a "serial console" is automatically enabled. This too could drive s/w interrupt watchdogs to blacklist them as the can spam quite a bit of info depending on what they're set to output.
Sorry, it's just totally a random guess, but I'm going by pure experience with embedded serial device fun (MIPS) and (ARM) past experiences with generic distros
I understand that main is not a starting point in Linux kernel, as kernel developers are experienced enough to customize the starting point.
Consider the following:
qemu-system-arm -M versatilepb -m 128M -kernel arch/arm/boot/uImage -initrd rootfs.img -append "root=/dev/ram rdinit=/sbin/init" -dtb "versatile-pb.dtb"
Above, I supplied the kernel image, device tree, rootfs.img as the input to the mainline kernel, so now which file in kernel is executed first. If it is an initialization file, someone would be triggering that initialization code within the kernel image. If yes, which file does that? Please advice.
Note: looking for a clear answer, i.e. exact file in arm architecture.
Entry point of Linux kernel, just like any other ELF binary, is _start. For ARM, it is defined in arch/arm/boot/bootp/init.S