Nomore output is seen on the console after「booting the kernel」デバッグ情報が表示されます.
Another problem a user may encounter when booting the kernel, is that no further output after "booting the kernel"is seen on the console. For example:
This problem can be caused by a number of reasons. The most common reasons are listed below.
If the "console"boot parameter passed by the boot-loader to the kernel is incorrect then the above failure will be observed. This could be as simple as a typographical error. For example, by default the OMAP3 beagle-board displays console messages on the UART3 port and the default configuration of UART3 port is 115200 baud, 8-bit data, no parity and no flow control. Hence, viewing the u-boot boot arguments you should see something like the following:
The console parameter is case-sensitive and so make sure it is written correctly for the board you are using and there are no spaces. For example, "console=ttyS2, 115200n8"would not work.
The best way to avoid such errors is to use a script for your boot parameters. Sample Teraterm_Scripts are available. Similar scripts can be created for Linux Minicom users.
Linux does not allow you to boot a kernel built for one hardware platform on some other piece of hardware, even if the underlying processor is the same. There is no reason why you would ever want to! When the kernel starts, one of the first things it does is to check that the machine number passed by the boot-loader matches the machine number that the kernel was built for. If the machine numbers do not match the kernel will not boot. This is a good thing!
You can check by re-building your kernel with CONFIG_DEBUG_LL enabled. To enable this start the linux menuconfig utility (by executing "make menuconfig") and go to "Kernel hacking"and select "Kernel low-level debugging functions". For example, if you were to enable this option and attempt to boot an OMAP3 EVM kernel on an OMAP3 beagle-board the following message would be seen.
If the previous causes did not solve your problem, then there is a chance that a software change is breaking the kernel for the device you are building for. To get more information on exactly where the kernel is failing, it is recommended that you enable CONFIG_DEBUG_LL in the linux kernel configuration. This may print out more information after "booting the kernel"is seen and may help determine where the kernel is failing. Even if you are unable to make any further progress from here, providing as much information as you can will help others determine where the problem is.
## Booting kernel from Legacy Image at 80300000 ...
Image Name: Linux-2.6.31
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1750680 Bytes = 1.7 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................
................................................. done, booting the kernel.
This problem can be caused by a number of reasons. The most common reasons are listed below.
Cause #1 - The linux console boot parameter is incorrect
If the "console"boot parameter passed by the boot-loader to the kernel is incorrect then the above failure will be observed. This could be as simple as a typographical error. For example, by default the OMAP3 beagle-board displays console messages on the UART3 port and the default configuration of UART3 port is 115200 baud, 8-bit data, no parity and no flow control. Hence, viewing the u-boot boot arguments you should see something like the following:
OMAP3 beagleboard.org # printenv bootargs
bootargs=console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw rootwait
The console parameter is case-sensitive and so make sure it is written correctly for the board you are using and there are no spaces. For example, "console=ttyS2, 115200n8"would not work.
The best way to avoid such errors is to use a script for your boot parameters. Sample Teraterm_Scripts are available. Similar scripts can be created for Linux Minicom users.
Cause #2 - Mis-match between boot-loader and kernel machine numbers
Linux does not allow you to boot a kernel built for one hardware platform on some other piece of hardware, even if the underlying processor is the same. There is no reason why you would ever want to! When the kernel starts, one of the first things it does is to check that the machine number passed by the boot-loader matches the machine number that the kernel was built for. If the machine numbers do not match the kernel will not boot. This is a good thing!
You can check by re-building your kernel with CONFIG_DEBUG_LL enabled. To enable this start the linux menuconfig utility (by executing "make menuconfig") and go to "Kernel hacking"and select "Kernel low-level debugging functions". For example, if you were to enable this option and attempt to boot an OMAP3 EVM kernel on an OMAP3 beagle-board the following message would be seen.
Error: unrecognized/unsupported machine ID (r1 = 0x0000060a).
Available machine support:
ID (hex) NAME
000005ff OMAP3 EVM
Please check your kernel config and/or bootloader.
Cause #3 - A software bug
If the previous causes did not solve your problem, then there is a chance that a software change is breaking the kernel for the device you are building for. To get more information on exactly where the kernel is failing, it is recommended that you enable CONFIG_DEBUG_LL in the linux kernel configuration. This may print out more information after "booting the kernel"is seen and may help determine where the kernel is failing. Even if you are unable to make any further progress from here, providing as much information as you can will help others determine where the problem is.