Uncompressing Linux... done, booting the kernel

Today, we use the mainline Linux kernel to port to MINI6410. The mainline kernel 2.6.37.1 basically supports the MINI6410 board, so it is very simple to port to the stage where it can be started. However, a common problem still occurs during the porting:

1. MINI6410 # bootm 0x50008000

2. ## Booting kernel from Legacy Image at 50008000 ...

3. Image Name: Linux-2.6.37.1

4. Image Type: ARM Linux Kernel Image (uncompressed)

5. Data Size: 3800644 Bytes = 3.6 MiB

6. Load Address: 50008000

7. Entry Point: 50008040

8. Verifying Checksum ... OK

9. XIP Kernel Image ... OK

10. OK

11. Starting kernel ...

12. Uncompressing Linux... done, booting the kernel.

13. Stopped and didn't move~~~~~

This problem is quite common. Due to the limited output information, it is not easy to find the cause. It is also troublesome to track it in the code. When looking for the cause and solving this problem, I found some possible reasons, which are summarized here:

1. Machine type does not match

After the kernel self-decompression is completed, the kernel will first enter the bl __lookup_machine_type function (in arch/arm/kernel/head.S) to check whether the machine_type matches. If it does not match, it will jump to the __error_a function (in arch/arm/kernel/head-common.S), causing startup failure.

For example, arch/arm/mach-s3c64xx/mach-mini6410.c looks at the following structure:

1. MACHINE_START( MINI6410 , "MINI6410" )

2. /* Maintainer: Darius Augulis */

3. . boot_params    = S3C64XX_PA_SDRAM + 0x100,

4. . init_irq    = s3c6410_init_irq,

5. . map_io = mini6410_map_io,

6. . init_machine    = mini6410_machine_init,

7. . timer        = & s3c24xx_timer,

8. MACHINE_END

This macro is defined in arch/arm/include/asm/mach/arch.h

1. /*

2. * Set of macros to define architecture features. This is built into

3. * a table by the linker.

4. */

5. # define MACHINE_START( _type , _name)             /

6. static const struct machine_desc __mach_desc_# # _type    /

7. __used                            /

8. __attribute__( ( __section__( ".arch.info.init" ) ) ) = {     /

10. .nr        = MACH_TYPE_##_type,         /

12. . name        = _name,

13. 
    

14. # define MACHINE_END                /

15. } ;

The machine type after this macro definition is expanded becomes MACHINE_TYPE_MIN6410.

The macro MACHINE_TYPE_MIN6410 is defined in include/generated/mach-types.h

1. # define MACH_TYPE_MINI6410 2520

machine type在u-boot

Configuration in board/samsung/mini6410/mini6410.c

1. /*

2. * Miscellaneous platform dependent initialisations

3. */

4. 
   

5. int board_init( void )

6. {

7. s3c64xx_gpio * const gpio = s3c64xx_get_base_gpio( ) ;

8. 
   

9. . . . . .

10. 
    

11. gd- > bd- > bi_arch_number = MACH_TYPE ;

12. gd- > bd- > bi_boot_params = PHYS_SDRAM_1 + 0x100;

13. 
    

14. return 0;

15. }

This macro is defined in: include/configs/mini6410.h

1. /*

2. * Architecture magic and machine type

3. */

4. # define MACH_TYPE        2520

As long as these two numbers match, it's fine.

2. The serial port driver is not compiled into the kernel

I made this mistake when I was working on MINI6410, because there is no default configuration file for MINI6410, so I have to select this one myself. The location is in Device Drivers->Character devices->Serial drivers

1. <*> Samsung SoC serial support

2. [*] Support for console on Samsung SoC serial port

3. <*> Samsung S3C6400/S3C6410/S5P6440/S5P6450/S5PC100 Serial port support

3. Kernel startup parameter settings are incorrect

The same error can also be caused by errors in the kernel startup parameters.

For example, there is a configuration:

1. noinitrd root=/dev/mtdblock4 rootfstype=jffs2 rw console=ttySAC0,115200 init=/linuxrc mem=64M

The key is console=ttySAC0,115200. If ttySAC0 is wrong or the baud rate is incorrect, there will be problems.

The console of different CPUs may be different, for example, some may be ttyS0.