Linux kernel porting (eight)-porting a Samsung-ported kernel

8.21

1: Prepare for the transplant

Get Samsung ported kernel, create Si project, add to virtual machine, modify makefile Arch and cross_compile modify results as follows

ARCH = Arm

Cross_compile =/usr/local/arm/arm-2009q3/bin/arm-none-linux-gnueabi-

Then try to configure, (in arch/configs/to find the closest to their own development board, here is the choice of smdkv210_android_defconfig) to get the. config file, and make menuconfig, because there is no migration yet , so there is no configuration, direct make-j4 to compile. and download the compiled zimage to the Development Board, try to run it,

2: The result of the operation is as follows

And did not see

Self-extracting information printed after the code is run

Kernel Run the first sentence of the printed message

Analysis:

(1) kernel run only get starting kernel ... And did not see the self-extracting code after the run of the printing information, indicating that kernel is not run at all, so the problem is to extract the relevant parts

(2) Further analysis, because the self-extracting code is hardware-independent, so the self-extracting code is not error, so the problem in the decompression, before the run, that is, after the decompression kernel was placed to run the place.

(3) inside the kernel can set the future decompression after the code is put to where, if the address is not set, the kernel may not be able to run up, so this kernel configuration of the decompression address must be the same as our link address, so this time need to determine the kernel's link address and the kernel is configured in the decompression address is how many

(4) There is another problem: the kernel's link address is a virtual address, and the self-extracting code to extract the kernel requires a physical address (because the self-extracting code runs when the kernel is not running, the MMU is not open), so said above equals, in fact, the virtual address of the link address is equal to the physical address of the decompression address

(5) at head. The two addresses are defined in S.

0xc0008000 and 0x30008000, respectively. Then the decompression address of the self-extracting code configuration should be 30008000.

(6) Workaround: Self-extracting code corresponding to the self-extracting address in the Mach/makefile.boot file. In which to modify, add two lines:

# Override for SMDKV210

zreladdr-$ (config_mach_smdkv210): = 0x30008000

params_phys-$ (config_mach_smdkv210): = 0x30000100

(7) Synchronize the code, and compile, get the zimage copy to/tftpboot, and then re-download the run to view the results.

3: The result is:

It's still not working, but it works. Self-extracting Code decompression printing information has come out. But the kernel hasn't been shipped yet.

Analysis:

The self-extracting code has already been printed, indicating that the self-extracting has been completed, so the problem should be in the place where the code runs and see head. The Physical Address macro definition in S

Here PHYS_OFFSET this macro is set at 2000000 this address, and we uboot in the memory configuration at the beginning of the 30000000

Workaround: Change the macro definition for physical address 20000000 to 30000000

The result of the re-burn operation is as follows

The kernel has started, but it will restart after 5 seconds, indicating that the kernel is booting or has a problem

Analysis:

Description Machine code Check Pass

That means uboot.

Where the error occurred, the kernel encountered a wild pointer,

Continue down the analysis

The PGD here is related to memory management, and our transplant is not off

Internel Error: Internal errors

Oops: Fatal message of kernel error, see Oops at startup indicates that the kernel is dead, and the death message is around here.

PC is at dev_driver_string+0xc/0x44

LR is at max8698_pmic_probe+0x150/0x32c

From the value of the PC and LR in the error message above, it is possible to make an error when the program executes to dev_driver_string or max8698_pmic_probe (both functions or symbols in the assembly). We go from these two symbols to find and think about possible mistakes and then try to solve them.

Analysis:

(1) Max8698_pmic_probe look at the name is max8698 this power management IC driver installation function part of the error, should be in our Development Board system configured to support this power management IC, so start to load his driver, The result driver was oops in the process of loading execution.

(2) combined with our X210 Development Board hardware actual situation to analyze: We X210 the Development Board there is no max8698 this power management IC, since the hardware is not driven to execute a certain error.

(3) Recall from the Samsung version of Uboot at the time of the transplant, in Uboot's lowlevel_init. s also has a call to the Power Management IC initialization function (Pmic_init), and then the solution is to block out the function of the call, Uboot successfully run down.

Workaround: Use the Menuconfig configuration panel to configure, cancel the max8698 configuration so that it will not be compiled (using the search/Ribbon to locate the configured path, then go to configure)

Compiling run Results

The cause of the error is that the root file system is not mounted

Analysis:

(1) We do not mount the root file system, so the error here is normal

(2) The kernel boot to the root file system mount, stating that the previous initialization configuration is correct.

Linux kernel porting (eight)-porting a Samsung-ported kernel