I have an embedded Linux application running on an i.MX51 board. The way I update the kernel is to run an update Kernel.. command during the boot process. There is plenty of output during the boot process that shows up in my serial port terminal.
During the boot process there is an error with my sound but if I search for the string in the kernel I can't find it. This makes me believe that the debugging output I am seeing during the boot process is not coming from the kernel.
So I am not sure if it is possible but what I would like to do is add a print statement in my kernel code that will show up on the serial port terminal to help me with debugging this driver. How might I go about doing that?
Related
how do i make my Go program supervised by some kind of systemd in linux, the requirement are :
restart on crash
start on boot
and my Go Program also has Administrator access (via manifest file), so is there any way to do that ?
For your first question, you could consider using a library like https://github.com/kardianos/service
I have my own embedded Linux system on PocketBeagle board. I have developed a simple gpio application in C that issues an on/off command to one of the pins of the connectors of the board. The application is called gpio_aa6 and located at /root.
The first challenge was to find a way to launch my application automatically after booting the board. I found two ways to do that; the first was to add an entry to etc/rcS directory. This entry is a simple script file that launches my application. The second way was to edit /etc/inittab file and add an entry to that file (::respawn:/root/gpio_aa6). In both these ways my application was launched successfully: but I am still not sure if this is the right way to launch my application automatically.
Then I came to the second challenge, how can I stop my running application, as the respawn re-launches the application if it's terminated?
I am communicating with the board in two ways; via a serial communication (using screen terminal) and via web sever (root#192.168.42.2). I have tried to use Ctrl+C, Ctrl+Z, Ctrl+\, but couldn't stop the program from being continue running. Then I used command "killall" with killsignals -9 or -15, it seems that the program is interrupted but it's launched again directly after that.
My application is to run infinitely, but I need to stop it sometimes to update it and re-launch it again.
Is there any suggestion how to overcome this problem?
Thanks.
Both solutions you have used are correct. I personally prefer the option of adding an init script to /etc/init.d though.
I believe the behavior that you observe that you apparently can't kill the program is because you are starting your program from inittab, with the respawn keyword, which precisely tells the init program to restart your application when it exits. If you actually check the PID of your application, you will see that it changes everytime you kill it.
Therefore, I would recommend you to use an init script instead, with which you can implement start and stop actions. See ./package/lldpd/S60lldpd for a basic example in Buildroot.
I have tried to run qemu-arm with a complied linux kernel (Version 4.9)
and with an initfs that i have created with a sample program.
This is was based on an excellent post from here.
This is the command that i have executed:
qemu-system-arm -M vexpress-a9 -kernel linux-4.9/arch/arm/boot/zImage -initrd initramfs -append "console=tty1"
then, qemu shows me these errors and its graphical window is getting stuck:
pulseaudio: set_sink_input_volume() failed
pulseaudio: Reason: Invalid argument
pulseaudio: set_sink_input_mute() failed
pulseaudio: Reason: Invalid argument
Even when I run it without the -initrd parameter, for just loading the kernel - nothing happens.
When I tried run it with a vmlinuz-3.2.0-4-vexpress image in this example, it worked for me.
Does someone have clue what may be the problem? Something with the fact that it is a zImage? Is there a way to debug it?
Thanks!
"QEMU sits there and prints nothing" is quite a common symptom, and it almost always means "the guest kernel crashed before being able to print anything, because it wasn't configured correctly". This is pretty much the same effect you get if you try to boot a wrongly configured kernel on real hardware, and the process for debugging it is about the same:
check the obvious kernel config options are set correctly: in particular, that you have built it to support the ARM board and CPU that you're trying to run it on, and that you've enabled support for whatever devices you're trying to use for console output
give yourself the maximum chance of being able to see something, by configuring QEMU to output serial port information, and configuring the guest to send its console output to serial, and enabling any earlycon/earlyprintk options you can (serial output happens much earlier than graphics output, and the Linux kernel earlycon/earlyprintk options mean the kernel will start printing output earlier than it defaults to)
if you have a kernel that works, and one that doesn't, look at the differences between the kernel configs to see if one is missing something
if all else fails, you have to break out the debugger to find out what's going on
Nothing about this is particularly QEMU specific -- it's the same sort of pain you have to go through if you're trying to do kernel bringup on hardware.
PS: my first guess is that the kernel is crashing because it doesn't have enough memory -- you haven't passed QEMU a '-m' option, so it is defaulting to 128MB; the vexpress-a9 board can handle up to 1GB. earlycon would probably be sufficient debug output to identify this issue. You also aren't passing a device tree blob via -dtb, which may be an issue for newer kernels (older kernels would happily boot without one).
hi :
i was building kernel for my gentoo linux . when i start the kernel , i
got this message , and can't going on.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
non-volatile memory driver v1.3
i don't know how to solve this problem . and i need help . thanks .
Why don't you try to disable pci hotplug support in kernel (if I recall correctly is in main config menu / PCI support)? You probably don't need this.
I'm going to have to disagree with those voting to close, because I think there really is a question here, and the question is "How to debug this?"
I'm going to propose two approaches:
1) Studious approach: Learn about mechanisms intended for handling boot problems. See if you can increase the kernel debug message level. Disable un-needed drivers as Quizzo suggested.
2) Cowboy approach: grep the kernel sources for strings seen in the final messages, and start shotgunning all possibly relevant bits of code with your own "still alive at" printk messages. Once you know where it's hanging, figure out why and either remove that mechanism or fix it.
At an extreme there's also a tool for debugging the kernel - kgdb - which you could set up if you have a second machine available.
If you already have linux running on this box, see if there's a config.gz in /proc or in a boot folder which you can extract and compare to the configuration you are trying to compile. It might not be a bad idea to first recompile and test exactly the same version and configuration as you have running, and then make desired changes one by one.
Also you might see if there's odd hardware in your system you could temporarily remove. For example, an older PC I have has a bios that hangs during drive enumeration if I have a large USB external drive plugged in during boot.
i have solved the problem by enable all pci hotplug flag in kernel config file.
thinks all.
I am porting an application which runs as a background service in windows at startup, we are porting the application to linux(SUSE Enterprise server), I'am completely new to linux. Can somebody help me on how to proceed with this. Like
Should I build the linux executable
After builiding the binary, what changes should I make to linux startup files to run this executable
How my service can register call back function to modify or change or send commands to my service while it is running
Yes, you should build a Linux binary. You may want to rephrase your question since I doubt this is the answer you want :-)
You should generally create what is known as an "init" file, which lives in /etc/init.d. Novell has a guide online which you can use to author the file. Note that while the init file is common, the exact method of letting the operating system use it varies depending on the distribution.
This is going to be a marked change for you. If you are doing simple actions such as re-loading a configuration file, you can use the signals functionality, especially the SIGHUP/HUP signal which is generally used for this purpose. If you require extended communication with your daemon, you can use a UNIX domain socket (think of it as a named pipe) or a network socket.
Another task you are going to need to accomplish is to daemonize your application. Generally this is done by first fork()ing your process, then redirecting the stdin/stdout pipes in the child. There are more details which can be answered by reading this document
See how-to-migrate-a-net-windows-service-application-to-linux-using-mono.
Under Linux, deamons are simple background processes. No special control methods (e.g start(), stop()) are used as in Windows. Build your service as a simple (console) application, and run it in the background. You can use a tool like daemonize to run a program as a Unix daemon.