FL2440-based 3.6.6 kernel porting appears uncompressing Linux ... done, booting the kernel.

• Specific questions
• Reference Solutions
• Solution Ideas
• Deep solution

1. Specific questions:

After porting the kernel of 3.6.6, download the startup card to die, specifically the serial printing information stuck in "uncompressing Linux ... done, booting the kernel."

2. Reference Solution:

According to the online statement to ensure that the following conditions:

• 2.1 Core clock frequency is correct
• 2.2 Boot and Kerel configuration-consistent mach_type, which is the board machine ID
• 2.3 Serial Port driver configuration is OK
  In the kernel configuration device Drivers->character devices->serial
  <*> Samsung SoC Serial Support
  [*] Support for console on Samsung SoC serial port
• 2.4. Startup parameters are set to normal
  Console ttySAC0, baud rate 115200 corresponds to correct

3. Solution Ideas

Check that the previous three items are OK, just beginning to think that the kernel can not start, and later will show that the driver after the successful migration (other unchanged) downloaded to the Development Board, found that the boot information also can not be printed through the serial port to minicom or other DNW window, but on the Development Board LCD print out the kernel boot information. So I know that the kernel transplant is successful, but not through the serial port print out, that is the serial port settings is not correct, you can check the console to find bootloader These settings are right, suddenly think of the kernel can also set the startup parameters, tried to succeed (in the boot options Default kernel command string, fill in the console=ttysac0,115200 and other startup parameters on the line)

4. In-depth solutions

Since the previous migration of 2.6.35 kernel, when changing the startup parameters are set from the bootloader and ignored the kernel can also set the startup parameters, then 2.6.35 the previous version does not need to set here, and I change the NFS boot when the kernel set parameters do not work, I think this is useless, so I did not test Considering this, the actual reason is that the 2.6.35 kernel configuration should always be checked with the default ... This is OK, because the bootloader in the flying Ling cured some of the startup parameters, that is, whether you set in the bootloader, it is essentially set up, so the kernel is covered by the default startup parameters. However, the 3.6.6 version may be improved in this regard, and the following kernel command line type can be seen in the kernel boot option configuration:

        Useif available                 ( ) Extend bootloader kernel arguments                     usedefaultstring

There is only one option available in the 2.6.35 version Always use the default kernel command string , so there is a real improvement
, so it may be that my bootloader and kernel are having problems passing the startup parameters (the address of the bootloader startup parameter is not set in the kernel), which prevents the parameters set in the bootloader from being passed to the kernel. Cause the kernel cannot find the correct serial port to print kernel information, so the kernel does not get the available parameters from the bootloader to use the kernel settings of the boot parameters. After testing, no matter how I change the bootloader in the boot parameters are not effective, should be the kernel of the bootloader parameter address settings have problems, if you can not set from the bootloader every time the replacement to compile the kernel, too cumbersome, there is no solution?
First understand the next kernel start parameter delivery method
Understanding kernel Boot parameters can be consulted
Article 1
Article 2
or self-Baidu
So I understand that there are two types of kernel boot parameters, one is through the kernel setting curing to the boot parameters, one is to read from a certain memory in order to replace the kernel boot parameters (and this setting is set by the bootloader and saved in a pre-agreed with the kernel memory address), at startup if the "Kernel command line Type" Selected is the first item, first to look for this memory to see if there are parameters, not directly using the kernel boot parameters, there is the kernel to overwrite the settings.
So how does the kernel know where bootloader will save the startup parameters?
Look at the next 2.6. Version 35 /arch/arm/mach-s3c24xx/mach-smdk2440.c in the final machine_start in the last one boot_params , good guess is it, but in the 3.6.6 added will prompt error, it should be changed the name, first look for the definition of Machine_start in the file
In ARCH/ARM/INCLUDE/ASM/MACH/ARCH.H

structMACHINE_DESC {+---4lines:note! The first four elements is used--------------------------------------------------------unsigned intNr/ * Architecture number * /    unsigned intPhys_io;/ * start of physical IO * /    unsigned intIO_PG_OFFST;/ * byte offset for IO * page tabe entry */    Const Char*name;/ * Architecture name * /    unsigned LongBoot_params;/ * Tagged list * /    unsigned intVideo_start;/ * start of video RAM * /    unsigned intVideo_end;/ * End of video RAM * /    unsigned intRESERVE_LP0:1;/ * never has lp0 * /    unsigned intRESERVE_LP1:1;/ * never has LP1 * /    unsigned intRESERVE_LP2:1;/ * never has LP2 * /    unsigned intSoft_reboot:1;/ * Soft reboot * /    void(*fixup) (structMachine_desc *,structTag *,Char**,structMeminfo *);void(*map_io) (void);/ * IO mapping function * /    void(*INIT_IRQ) (void);structSys_timer *timer;/ * System TICK Timer * /    void(*init_machine) (void);};

Can see boot_params; /* tagged list */ that we go to 3.6.6 version to see, sure enough replaced the following

structMachine_desc {unsigned intNr/ * Architecture number * /    Const Char*name;/ * Architecture name * /    unsigned LongAtag_offset;/* Tagged list (relative) */    Const Char*Const*dt_compat;/ * Array of Device tree * ' compatible ' strings * /    unsigned intNr_irqs;/* Number of IRQs * /#ifdef CONFIG_ZONE_DMA    unsigned LongDma_zone_size;/ * Size of dma-able area * /#endif    unsigned intVideo_start;/ * start of video RAM * /    unsigned intVideo_end;/ * End of video RAM * /    unsigned CharRESERVE_LP0:1;/ * never has lp0 * /    unsigned CharRESERVE_LP1:1;/ * never has LP1 * /    unsigned CharRESERVE_LP2:1;/ * never has LP2 * /    CharRestart_mode;/ * Default restart mode * /    void(*fixup) (structTag *,Char**,structMeminfo *);void(*reserve) (void);/ * Reserve MEM blocks * /    void(*map_io) (void);/ * IO mapping function * /    void(*init_early) (void);void(*INIT_IRQ) (void);structSys_timer *timer;/ * System TICK Timer * /    void(*init_machine) (void);void(*init_late) (void);#ifdef Config_multi_irq_handler    void(*HANDLE_IRQ) (structPt_regs *);#endif    void(*restart) (Char,Const Char*);};

, OK, try to modify this parameter for S3C2410_SDRAM_PA + 0x100 (the original value is 0x100) compiled download unexpectedly can't start, stuck in uncompressing Linux ... done, booting the Kernel. This step, change back to the original value, look for the arch/arm/kernel/setup.c setup_machine_tags function that has been issued now

    if (__atags_pointer)        = phys_to_virt(__atags_pointer);    elseif (mdesc->atag_offset)        = (void*+ mdesc->atag_offset);//实际是进入这一步，

Unlike the 2.6.35,

 if  (__atags_pointer) {         PRINTK ( "using __atags_pointer to get tags.\n" );     tags =  phys_to_virt (__atags_pointer); } else  if  (Mdesc-  boot_params) {tags =  phys_to_virt (mdesc-& gt;  Boot_params); //different points  printk ( "using Mdesc->boot_params to get tags. The tags is 0x%08x\n ", tags); //anzyelay  printk ( "Tags->hdr.tag = 0x%08x\n" ,tags->  hdr     tag ); }

So I directly print out the results found Mdesc->boot_params result is not 0x30000100 (S3c2410_sdram_pa + 0x100) but
mdesc->boot_params=0xc0000100(why??) Do not know, I did not know, I saw the next bootloader source is also 0x30000100 this address ah, too lazy to follow, anyway, the old version passed over is this value. ）
And the 3.6.6 version of the arch/arm/mach-s3c24xx/mach-smdk2440.c from the 0x0100 plus Page_offset (0xc000000 is just 0xc0000100, so you change Machine_ In the start. __atag_offset There will be errors. So the conclusion is that the address is set correctly.
Now, since it is not the kernel and the bootloader address error this reason what to do? I compare two version analysis debug the next Setup_machine_tags function, found that the CONFIG_DEPRECATED_PARAM_STRUCT macro has no definition of the problem, resulting in the subsequent kernel read the parameter address tags is wrong (not 0xc0000100).
First, the path to the kernel setting parameter is in the MAIN.C function, start_kernel–>setup_arch (&command_line)–> setup_command_ Line (command_line);
The focus is on the Setup_arch function, which is located in Arch/arm/kernel/setup.c, as follows

void__init Setup_arch (Char**cmdline_p) {structMachine_desc *mdesc;    Setup_processor (); Mdesc = SETUP_MACHINE_FDT (__atags_pointer);//Because the __atags_pointer is empty, jump out directly,    //This parameter is given in the R2 register, you can see the head-common.s in the __mmap_switched    if(!mdesc) Mdesc = Setup_machine_tags (Machine_arch_type);//Then enter here,        //Can be compared under 2.6.35,3.6.6 here optimized below. The main reason for this error is in this function.Machine_desc = Mdesc;    Machine_Name = mdesc->name; Setup_dma_zone (MDESC);if(Mdesc->restart_mode) Reboot_setup (&mdesc->restart_mode); Init_mm.start_code = (unsignedLong) _text; Init_mm.end_code = (unsignedLong) _etext; Init_mm.end_data = (unsignedLong) _edata; INIT_MM.BRK = (unsignedLong) _end;/ * Populate Cmd_line too for later use, preserving boot_command_line * /strlcpy (Cmd_line, Boot_command_line, command_line_size); *cmdline_p = Cmd_line;//Get to Startup ParametersParse_early_param (); Sort (&meminfo.bank, meminfo.nr_banks,sizeof(meminfo.bank[0]), meminfo_cmp, NULL);    Sanity_check_meminfo ();    Arm_memblock_init (&meminfo, Mdesc);    Paging_init (MDESC); Request_standard_resources (MDESC);if(mdesc->restart) Arm_pm_restart = mdesc->restart; Unflatten_device_tree ();#ifdef CONFIG_SMP    if(IS_SMP ()) Smp_init_cpus ();#endif Reserve_crashkernel (); Tcm_init ();#ifdef Config_multi_irq_handlerHANDLE_ARCH_IRQ = mdesc->handle_irq;#endif #ifdef CONFIG_VT#if defined (config_vga_console)CONSWITCHP = &vga_con;#elif defined (config_dummy_console)CONSWITCHP = &dummy_con;#endif #endif     if(mdesc->init_early) mdesc->init_early ();}

Let's see setup_machine_tags this function, in the same file

Static structMachine_desc * __init setup_machine_tags (unsignedintNR) {structTag *tags = (structTag *) &init_tags;structMachine_desc *mdesc = NULL, *p;Char* from= Default_command_line;//boot Options configured when compiling the kernelInit_tags.mem.start = Phys_offset;/ * * Locate machine in the list of supported machines. * Here is based on your Machine_start (ARG1,ARG2) given to the ARG1=NR to find out * corresponding device description structure p, so if you do not set the correct arg1, or your arg1 * corresponding machine ID (in the file Arch/arm /tools/mach-types in the wrong *, it will also appear stuck in uncompres ... This error. You will see the cause of the error when you open the * early print in kernel hacking. (This is the reason why the so-called machine code causes the card to die.) ) * /For_each_machine_desc (P)if(nr = = P->nr) {PRINTK ("machine:%s\n", p->name); Mdesc = p; Break; }if(!MDESC) {Early_print ("\nerror:unrecognized/unsupported machine ID"            "(r1 = 0x%08x). \ n", nr); Dump_machine_table ();/ * does not return * /}if(__atags_pointer) tags = phys_to_virt (__atags_pointer);/* said this parameter is empty, directly passing by, with reference to the article 2 said what * Set the bootloader parameters directly get over some wrong, may be with me * with the bootloader, if you use uboot estimate from here into it, I did not * There are people who make uboot, hope to know the next * *    Else if(mdesc->atag_offset) tags = (void*) (Page_offset + mdesc->atag_offset);//We are entering here,        //The Atag_offset in the configuration file is 0x0100, don't change it. tags=0xc0000100    /*2.6.35 version of this is not the following macro, which directly skipped the convert_to_tag_list this step * cause the tags value changes in the back, at present my bootloader is the old style, so this step * can not be saved. This is done in the kernel feature of the kernel configuration by selecting provide old means to * pass kernel parameters. */#if defined (config_deprecated_param_struct)    / * * If we have the old style parameters, convert them to * a tag list. */    if(Tags->hdr.tag! = Atag_core) convert_to_tag_list (tags);#endif     if(Tags->hdr.tag! = Atag_core) {#if defined (config_of)        / * * If config_of is set and then assume this is a reasonably * modern system, should pass boot param Eters * *Early_print ("Warning:neither atags nor DTB found\n");#endif tags = (structTag *) &init_tags; }//Come here tags=0xc0000100 still, if changed it certainly is wrong (I am tracking here not to find the problem in the above step). //At the same time Tags->hdr.tag = = Atag_core (0x54410001),    if(mdesc->fixup) Mdesc->fixup (tags, & from, &meminfo);if(Tags->hdr.tag = = Atag_core) {if(Meminfo.nr_banks! =0) squash_mem_tags (tags);        Save_atags (tags);    Parse_tags (tags); }/ * Parse_early_param needs a boot_command_line * /strlcpy (Boot_command_line, from, command_line_size);returnMdesc;}

Well, according to the above statement, make Menuconfig hook on kernel feature provide old way to pass kernel parameters, made zimage, download start, normal through Bootloade R sets the start parameter.

Additional question: I use arm-linux-gcc-4.9.4 compile has successfully ported the 2.6.35 kernel also appear to stay here phenomenon, switch back to other versions of the compiler and can start normally (only a compiler, the other has not made any changes). Began to think that is 4.9.4 compiler has the problem, today used to compile the next 3.6.6 kernel is actually possible, so it should be 2.6.35 kernel porting There is a problem is not compatible with the GCC 4.9.4, specifically do not know why!!!!

FL2440-based 3.6.6 kernel porting appears uncompressing Linux ... done, booting the kernel.