I am working with QEMU 1.1.0, emulating Versatile Express board with ARM Cortex-A9. I have managed to launch simple "Hello World" example following this instructions:
http://balau82.wordpress.com/2012/03/31/compile-linux-kernel-3-2-for-arm-and-emulate-with-qemu/
but now I want to create filesystem by myself.
I decided to use buildroot, version 2012.05. and I've configured it to create toolchain, kernel and filesystem image for ARM Cortex-A9 target.
Kernel is of version 3.3.7 and for the filesystem I've selected to be cpio, non-compressed. The initrd argument in call to qemu-system-arm is pointing to
/output/images/rootfs.cpio
When I launch QEMU kernel boots, but then I get this message:
Initializing random number generator... done.
Starting network...
can't open /dev/ttyS0: No such device or address
can't open /dev/ttyS0: No such device or address
can't open /dev/ttyS0: No such device or address
...
All I can do is to terminate QEMU.
I have checked the contents of rootfs.cpio like this:
cpio -t < rootfs.cpio
and saw that there is /dev/ttyS0.
Have I missed something in configuring the filesystem? Or should I use filesystem in
/output/target
to somehow create device(s) there (Buildroot does not do that), and then rebuild the filesystem?
I'm new to Buildroot, so any hint or suggestion is more than welcome.
Extract rootfs and type ls -all /dev/ttyS0 and check it's major and minor number. Because if your major number is not the required one then it will not invoke respective kernel functionality and in that case it will only be a junk character device.
Also can you post the whole log file (copy all those dmesg and post those somewhere and give link here.)
And if you are sure that /dev/ttyS0 is there then do the following steps :
extract(unpack using cpio) rootfs
find out which init file kernel is using as parent process. If you are lucky then it would be lying in root directory. named init or initrc
open init file in your favorite editor.
starting few lines of your init would be like
::respawn:/sbin/getty -L 38400 tty1
::respawn:/sbin/getty -L 38400 tty2
::respawn:/sbin/getty -L 38400 tty3
::respawn:/sbin/getty -L 38400 tty4
add ::respawn:/sbin/ls -all /dev and save the file. (We have added list command to see what is there inside /dev directory)
reboot your system and check the dmesg. See if /dev/ttyS0 is really missing ?
Related
I have an embedded device with an emmc and a qspi-flash, both of which have an operating system on them.
From the OS running in the qspi-flash, I have a rootFS.ext4 file, the entire root filesystem for the OS on the emmc. From the qspi, I can see /dev/mmcblk1p3, which is the rootfs partition of the emmc.
I am trying to do
dd if=root.ext4 of=/dev/mmcblk1p3 bs=1M
Unfortunately when i then boot from the emmc, the kernel is complaining that it cannot mount to mmcblk1p3.
What is the correct way to completely erase the contents of the original filesystem and overlay the new filesystem image into the partition? Am I missing a step?
The mmc partitions are gpt.
The rootfs file I was using was incorrect.
I also needed to clear the exisiting filesystem by using mkfs.ext4.
Now the dd worked and the new rootfs was copied. I was able to successfully boot up from the emmc and see the new version of the rootfs.
I keep getting a weird error in OBS Studio while trying to enable my virtual camera, "format not support". This is after installing packages in Manjaro 19.0.2:
yay -S dkms linux56-headers
yay -S obs-v4l2sink v4l2loopback-dkms
Is this a OBS issue or a v4l2loopback one?
I found it. I forgot to run sudo modprobe v4l2loopback. It enables it I think.
Some stuff that help me figure out a similar issue:
Note that this issue can also arise from a video device that is not available e.g.
/dev/video1 when there is no active device /dev/video1 changing to another device e.g. /dev/video0 may resolve this error
list devices with:
ls /dev | grep video
you may be able to make additional devices available when you load the kernel module:
sudo modprobe v4l2loopback devices=2
See also:
https://github.com/CatxFish/obs-v4l2sink/issues/5
I was going through the doc https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-kdump-configuration-cli.html on configuring the coredump collector.
I have made the following to changes and have restarted the kdump with the command "service kdump restart".
On /etc/kdump.conf => I have enabled the path and the core-collector as below,
path /var/crash
core_collector makedumpfile -c
#default halt
And on /boot/grub/grub.conf
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-318.6.1.el5.20)
root (hd0,0)
kernel /vmlinuz-2.6.18-318.6.1.el5.20 ro root=/dev/Raid_vg/Root_lv crashkernel=256M#16M
initrd /initrd-2.6.18-318.6.1.el5.20.img
title Red Hat Enterprise Linux Server (2.6.18-110.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-110.el5 ro root=/dev/Raid_vg/Root_lv crashkernel=256M#16M
initrd /initrd-2.6.18-110.el5.img
I did the above to trigger the crash dump "cho c > /proc/sysrq-trigger". But after the reboot the core files are not present in the /var/crash.
Please help to identify why the core dump was not generated.
I see the config file of the kernel with the following enabled,
CONFIG_CRASH_DUMP=y but CONFIG_RELOCATABLE is not present in the config. Is it becoz of that the core dump didnt get generated.
I need to find a way to detect when a usb device is plugged in C on an old embedded Linux (CentOs 4).
libudev and libusb are not available so I'm a little clueless with my options here. There is dbus, however I cannot use udisks as the device I need to detect is not a storage device.
Thanks.
You can try to write a custom script and register it in /proc/sys/kernel/hotplug. When a uevent occurs, the kernel will invoke your script and pass the subsystem (usb in your case) as an argument. Then you will have to match the device (I don't know how to do that, that's probably the most tricky part).
Skeleton for your custom hotplug script that matches the USB subsystem:
$ cat my_hotplug.sh
#!/bin/sh
[ "$1" = usb ] || exit 0
echo "Do something here"
Registering your hotplug script as the uevent helper:
echo /path/to/my_hotplug.sh > /proc/sys/kernel/hotplug
I am trying to setup linux kernel module debugging, using two machines - target and host. On target machine, I have compiled and installed a 3.5.0 kernel with CONFIG_MAGIC_SYSRQ=y flag and other flags for over the serial console debugging.
When I want to break the kernel to attach remote gdb, I use
$ echo g > /proc/sysrq-trigger
But above command is not breaking the kernel.
$ cat /proc/sys/kernel/sysrq"
Above command is returning 1, hence magic sysrq keys are enabled. Even "echo b > /proc/sysrq-trigger" is working and rebooting the machine. Can anybody please point out what I may be missing?
Thanks
You have first configure your target kernel as follows
CONFIG_FRAME_POINTER=y
CONFIG_DEBUG_KERNEL=y
CONFIG_KGDB=y
CONFIG_DEBUG_INFO=y
CONFIG_KGDB_SERIAL_CONSOLE=y (here I am using serial port for kgdb)
CONFIG_MAGIC_SYSRQ= y (for sysrq functions).
Now compile kernel with imx6 configuration file.
Boot the target with this compiled kernel.You have to tell tell target which serial port you are going to use for kgdb pupose.In my case I am using the same console port for kgdb also.This settings you can do either through kernel parameters or via sysfs entry.For imx6 sabrelite board,I am using ttymxc1 for console.This will change depending on your target
1) As a kernel parameter
Add the following parameter to bootargs
kgdboc=/dev/ttymxc1,115200 to your arguments.
2) If you are using sysfs entry, do like this
echo /dev/ttymxc1,115200 > /sys/module/kgdboc/parameters/kgdboc
Since same serial port is used for both the console and debugging, we use agent proxy. Through agent proxy we get the target console as well as we do the debugging.
Source for compiling agentproxy is available at the following link
"https://kernel.googlesource.com/pub/scm/utils/kernel/kgdb/agent-proxy/+/agent-proxy-1.96"
After compiling for host pc ,run it as follows
sudo ./agent-proxy 5550^5551 0 /dev/ttyS0,15200
Now you can see target terminal through telnet with this agentproxy support
sudo telnet localhost 5550
(It is better to use this telnet instead of minicom where only this agent proxy support comes.)
When you want to start debugging, the target system has to enter debug mode from normal mode. We can do that in this way in target
echo g > /proc/sysrq-trigger
Now it will enter debugger mode.
Now from host side run gdb on vmlinux of the arm compiled kernel.
Go to the corresponding kernel source directory and do like this
arm-fsl-linux-gnueabi-gdb ./vmlinux
Now it will show gdb terminal .From there you have to connect to target for kgdb,
$target remote /dev/ttyS0
In my case my host serial port is /dev/ttyS0.
Now it will get connected to target. Here after you can use gdb commands to debug the kernel.
You try this way.