The start_kernel() function is not calling after decompressing the kernel image (uImage) on an ARM board:
Why is the start_kernel() function is not calling? I know it should call from file arch/arm/kernel/head.s.
What are sequences happening after decompressing uImage and calling start_kernel()?
The most common cause of boot stopping after "Uncompressing Linux… Ok, booting the kernel" is that the console device in your kernel command line is not correct. For example, after upgrading from 2.6.35 to 3.19.5, the console device name could have changed from /dev/ttyAM0 to /dev/ttyAMA0 (on the i.MX23/28). You should also check that the serial port settings, if there are any, following the console device name in the kernel command line are correct.
Check that you are passing a valid ATAG array or device tree (*.dtb) file via your boot loader.
Another possible cause is incorrect entry point.
Try search engine phrase "ARM boot hangs after 'Uncompressing Linux....done, booting the kernel'"
The boot of Linux on embedded is done in 3 steps:
Bootloader
Low-level hardware initialization
Loads the Linux kernel in RAM and passes control to Linux
Bootstrap loader (inside the Linux kernel image):
Decompress and relocate the kernel
Pass control to it
Linux kernel:
Boot the system by running start_kernel() which, in the end, spawns the init process
Your output is between step 2 and step 3 (i.e., kernel decompressed).
You've probably not set all the things to have a working console:
Compile the target Linux kernel enabling through make menuconfig the serial console in
Device Drivers -> Character Devices -> Serial Drivers
Enable the specific driver for serial communications in the kernel configuration (i.e., through make menuconfig)
Set Linux console on the right device by setting option console=device,baudrate in the bootargs variable of U-Boot.
Related
I have an external serial peripheral that needs to be setup on Linux boot, on an embedded system.
What I need is sending a short configuration string as early as possible during system boot, so my procedure is simply
Set port to 115200 bps
Send a string, like "ABCDE\r\n"
I see that recent kernels support an early-on serial console, but what I need is not a console (my peripheral can also send meaningless data in that phase, plus I'll be showing a splash screen in graphic mode), just a fast initialization for the the peripheral.
How can it be done?
The answer to this will be subjective depending on what you mean by as early as possible. I will provide few possibilities I am aware of which might help you
In case your embedded platform uses any form of bootloader (ex: U-Boot) then you can do the serial(UART) initialization as part of the bootloader (Usually this will be done for the target platform alone so that we can see how far the boot is happening). You can try initializing your external serial peripheral in bootloader itself. As bootloader will execute before the linux kernel gets loaded you can achieve this easily.
If your platform doesn't use any form of bootloader then the possibility of initializing the external serial peripheral is via kernel driver (or) system init process.
I have been using PSplash program which uses the basic frame buffer driver for the boot progress. If interested check the following repo
PSplash
i am trying to build a custom Linux kernel for the Intel nuc board.
first of all i have installed clearlinux(a Linux distribution) on bare metal. Im trying to install the custom Linux alongside the clearlinux by placing the kernel in /efi/boot and the added a entry in /efi/loader/entries . Im using systemd as my default boot loader.
Im getting kernel panic while im trying to boot the custom linux. The problem is i couldn't see the entire message in my console.
is there any way that i could load the message in to a file and viewenter code here or could add some options to the kernel parameters so that i can navigate through the entire kernel panic text
here is my kernel entry
title customoslinux
linux /EFI/custom/bzImage
options root=PARTUUID=0de21747-3184-47eb-a415-720247c9abc6 quiet console=tty0 console=ttyS0,115200n8 init=/usr/bin/initra-desktop
You may add "vga=ask" to your kernel commandline and before kernel start it will ask you for screen resolution. Just choose some big resolution and start the kernel.
I have a arm board, I connect it with my linux (host) system via a wire. I insert sd card with vmlinux.uimg in the arm processor and use minicom on host system. Now I want to debug vmlinux on arm board using gdb. What all thing I need to do? I tried using gdbserver on minicom and gdb on host. But I don't know how exactly it work... Where should I copy vmlinux and how should I debug...
Complete answers depend on your Linux version, development and target setup. Here are some research links,
gdb kernel debugging
kgdb, kgdb docbook or formatted docbook
You need to configure your kernel with KGDB support and you can use the console as a link to control KGDB from your development machine. You need copies of the vmlinux object files on the development machine; easy if it is also the build machine. There are script for GDB to access handy information in the kernel. This is the info in the GDB kernel debugging link.
You do not use gdbserver; this is for user space linux processes. The tool for debugging the kernel is kgdb and this requires code to be put into the kernel. Normally the program gdbserver is using kernel facilities to control a process. This won't work for the kernel itself.
It is possible that not all serial ports will support kgdb. Some versions of Linux allowed kgdb over the network. However, it is not present in as many kernels as the serial port. You can activate kgdb over serial with a kernel parameter kdbgoc, sysfs or magic sysreq. Some devices (and Linux versions) may have support for JTAG type kgdb.
I had this doubt because , i know that u-boot has the uart driver which helps to see the debug logs from start of u-boot while booting the kernel (where kernels driver will not be in action) ,my question is
after u-boot handovers the control to kernel , what happens to the drivers of uart , ethernet from u-boot's side after kernel gets booted ?
2.kernel will be also having such driver which will comes to action after kernel booted?
i can see the boot logs from u-boot to kernel, after kernel gets booted i can use the prompt which is through the driver of u-boot or kernel ?
4.if it is from kernel side , at what point it gets switched from u-boot's uart driver ?
First of all you need to understand that the drivers are different(although, same functionality) in the u-boot stage and in the kernel stage. For example, the U-Boot uses its own uart driver to show you its console. Once it hands over the control to the kernel, the kernel loads its own uart driver(as per the board), initializes it, and finally gets you the console.
Now, answering your questions one by one :
U-Boot resides completely in RAM. Thus, all of its drivers resides in the RAM itself. Once U-Boot transfers the control to the kernel, the kernel sets up its own environment in the RAM, and hence all of the boot loader's data is gone(including the drivers). The U-Boot's driver is no longer alive once the kernel boots up!
Exactly. The kernel has its own drivers to access the devices. It is much more feature rich than the one provided by the boot loader. Typically, extra features including interrupt handling and possibly DMA. The u-boot driver is generally a simple polling driver. If requested the Linux kernel's uart may use a polling mode during early boot but with different code than the u-boot driver.
It is through the driver of the kernel. The last message printed by the uart driver of U-Boot is "Starting kernel ...". After this message, all the console messages that you see are printed by using the kernel driver. Thus the first message printed by the kernel's driver is "Uncompressing Linux... done, booting the kernel"
I hope the answer to the third question answers this one as well!
I'm working on an embedded Linux system with a display panel. The system is setup to output boot messages through the serial port on the system /dev/ttyS1. I'm trying to get these messages to show up on the display,tty1, and I'm looking for suggestions on how I go about doing this.
I tried changing the kernel command line from console=ttyS1 to console=tty1; this has no effect. Even with the change above boot messages are sent only to the serial port. I verified that the change to the kernel command line did take effect by querying cat /proc/cmdline
The last step of the boot process spawns getty to tty1 and the login screen does appear on the panel. The panel itself is initialized much earlier in the boot sequence.
EDIT: #artless noise pointed out that sending the console to the virtual terminal requires a change in the kernel config. And indeed it does. Follow the steps below to enable console output on virtual terminal
make menuconfig
and from the displayed GUI select the following
Device Drivers -> Character devices -> Support for console in virtual terminal
When invoking make you may need to provide additional options (ARCH, CROSS_COMPILE etc.) depending on the target you're building for.
Command line options can be provided either by the bootloader (e.g., u-boot bootargs) or hardcoded when configuring the kernel.
I know that on some older versions of the Linxu kernel, hard-coded options erroneously overwrote bootloader options.
So, have a look at the .config file and see if the wrong console has been set there.