(Sorry, a few days ago when writing too panic, missed an important detail, is about the compilation must let the mach-ok6410.c file compiled in, otherwise the kernel compilation will run, that is, when you modify kconfig, you also need to modify the corresponding makefile. I have added it to the corresponding location)
For Embedded Linux, I basically belong to a class that is not streaming, and I didn't plan to transplant the Linux kernel myself. After all, it takes a lot of time to basically transplant the Linux kernel and get all the drivers transplanted, however, I was speechless because of alicloud's after-sales technical customer service. when I bought the Development Board, alicloud officially gave the Linux 2.6.28 kernel, which was quite good at the time, at least meet the requirements of my nfs_root mounting and startup, so it is easy to develop. I have no intention to see that the ok6410 Linux Kernel on the official website was updated to linux2.6.36 a few days ago, so I can try it. But I know that NFS cannot be started successfully, on the Apsara stack forum, I asked no technical personnel to handle the problem. I can't help it. Forget it. I 'd like to play it on my own. Well, it's a lot more about wild cotton. Let's get started.
The development environment remains the same as the previous uboot porting, and remains unchanged.
1. Windows XP SP3 laptop host system
2. The virtual machine uses the VMware Workstation ace version.
3. the Linux system used in the virtual machine is ubuntu10.10.
4. The cross-compilation tool is cross_compile4.2.2.
For Linux kernel porting, just like uboot porting, You need to obtain the source code first. The source code URL is too good. So you have selected the latest linux2.6.39.2 to open the knife. After you have just completed the linux2.6.39.3 patch.
For Linux kernel transplantation, the method is the same as that of uboot. We can perform the migration step by step with the goal of thinking and thinking. In this way, we can be aware of it. Don't be blind. Well, let's get started, started.
Linux, you cannot proceed without source code.
The first step, and the previous uboot porting ideas the same, everything is as simple as possible, so or CD linux-2.6.39.2 into, to see a file architecture layout, do a few in mind: root @ hewenqiang-Ubuntu: /share/linux-2.6.39.2 # ls
Arch documentation init lib samples USR
Block drivers IPC maintainers readme scripts virt
Copying firmware kbuild makefile reporting-bugs Security
Credits FS kconfig mm sound
Crypto include kernel net tools
Here, of course we should first set our own cross-compiler. We can see no makefile under the root directory,
Export kbuild_buildhost: =$ (subarch)
# Arch? = $ (Subarch)
# Cross_compile? = $ (Config_cross_compile: "%" = %)
Arch? = Arm
Cross_compile? =/Usr/local/ARM/4.2.2-Eabi/usr/bin/ARM-Linux-
Watch the marked red and write your own compiler location, which is the cross_compile option.
Okay, that's easy. This is the first step. After the cross compiler environment is set up, the Development Board will be transplanted.
Step 2, you can see all the folders under the root directory. One of the main files related to the migration target is the arch directory, and then the CD arch will see
Root @ hewenqiang-Ubuntu:/share/linux-2.6.39.2/arch # ls
Alpha Cris kconfig MIPS s390 tile xtensa
Arm frv m32r mn10300 score um
Avr32 h8300 m68k parisc sh unicore32
Blackfin IA64 microblaze PowerPC iSCSI x86
The CPU system architecture related to our transplantation is in the arm directory, so we still need to CD arm, we will see the boot mach-h720x Mach-MXs mach-s5p 6442mm
Common Mach-IMX Mach-netx mach-s5p64x0 nwfpe
Configs Mach-integrator Mach-nomadik mach-s5pc100 oprofile
Include mach-iop13xx mach-ns9xxx mach-s5pv210 Plat-IOP
Kconfig mach-iop32x mach-nuc93x mach-sa1100 Plat-mxc
Kconfig. debug mach-iop33x mach-omap1 Mach-shark Plat-nomadik
Kconfig-nommu mach-ixp2000 mach-omap2 Mach-shmobile Plat-OMAP
Kernel mach-ixp23xx mach-orion5x mach-spear3xx Plat-Orion
Lib mach-ixp4xx mach-pnx4008 mach-spear6xx Plat-PXA
Mach-at91 Mach-kirkwood Mach-PXA mach-stmp378x plat-s3c24xx
Mach-bcmring mach-ks8695 Mach-realview mach-stmp37xx plat-s5p
Mach-clps711x mach-l7200 Mach-RPC mach-tcc8k Plat-Samsung
Mach-cns3xxx (Mach-Loki) mach-s3c2400 (Mach-tegra Plat-Spear)
Mach-DaVinci mach-lpc32xx mach-s3c2410 mach-u300 plat-stmp3xxx
Mach-dove Mach-MMP mach-s3c2412 mach-ux500 Plat-TCC
Mach-ebsa110 Mach-MSM mach-s3c2416 Mach-versatile Plat-versatile
Mach-ep93xx mach-mv78xx0 mach-s3c2440 Mach-vexpress tools
Mach-exynos4 mach-mx3 mach-s3c2443 mach-vt8500 VFP
Mach-footbridge mach-mx5 mach-s3c24a0 mach-w90x900
Mach-Gemini mach-mxc91231 mach-s3c64xx makefile
For the above folder, you need to know that Mach is the path of the code of the cpu_soc target board, while plat is the path of the public code of the relevant platform, here we are porting ok6410 board, belonging to soc6410, so it must be a CD mach-s3c64xx, and then we will see clock. c IRQ. c mach-smartq5.c. c
CPU. c irq-eint.c mach-smartq7.c setup-fb-24bpp.c
Cpufreq. c irq-pm.c mach-smartq.c setup-i2c0.c
Dev-audio.c kconfig mach-smartq.h setup-i2c1.c
Dev-onenand1.c mach-anw6410.c mach-smdk6400.c setup-ide.c
Dev-spi.c mach-hmt.c mach-smdk6410.c setup-keypad.c
Dev-uart.c mach-mini6410.c makefile setup-sdhci.c
DMA. c mach-ncp.c makefile. Boot setup-sdhci-gpio.c
Gpiolib. c pm. c sleep. s
Include mach-real6410.c. c
I finally saw the board-level file. As I mentioned in the Article porting uboot, board-level transplantation is not very technical, and we do not need to destroy other people's code, so we just made a prototype with the most similar board of our own development board. We can try another one. We can't see it. Now, we have added many 6410soc board pieces in the Linux kernel version, so it's easier for our ok6410 board. I didn't select smdk6410 or smdk6400 here. I feel that the hardware resources on our development board are quite different, we can see that dm9000 and LCD support have been added to the card file of mini6410, so we chose mini6410 as the prototype, So we directly CP
Mach-mini6410.c mach-ok6410.c, copy a piece of code, remember, this is not enough, must be again the mach-ok6410.c file involved in the mini6410 name also changed, of course, don't change it is no problem, however, let's just try again, right? In fact, it is certainly okay to compile mini6410 directly. It can also be run on your ok6410 board, since I was based on the official flying Ling uboot1.16 to experiment, so you need to modify the mach-ok6410.c file inside
Struct mtd_partition ok6410_nand_part [] = {
{
. Name = "bootloader ",
. Offset = 0,
. Size = (1 * sz_1m ),
. Mask_flags = mtd_cap_nandflash,
},
{
. Name = "kernel ",
. Offset = (1 * sz_1m ),
. Size = (5 * sz_1m ),
. Mask_flags = mtd_cap_nandflash,
},
{
. Name = "user ",
. Offset = (6 * sz_1m ),
. Size = (120 * sz_1m ),
},
{
. Name = "File System ",
. Offset = mtdpart_ofs_append,
. Size = mtdpart_siz_full,
}
};
In fact, this is a NAND file partition information on your development board. You just need to remember that the download location of the file system is closely related to this. You have at least two (nfs_root is required) items. After all, the first is the uboot code area, the second is the Linux kernel area, and the third and fourth are the same as you, however, there are usually at least three files. After all, the file system still needs to be written to the NAND for convenience!
Step 3: do not compile the template-level file CP after it is ready, you will find that we cannot find the ok6410 in create. Why? Because the configuration file still needs to be modified. Haha, well, then we can see that the kconfig file is not in the directory. This is the configuration file, gedit kconfig
Config mach_mini6410
Bool "mini6410"
Select cpu_89c6410
Select initi_dev_hsmmc
Select s3_dev_hsmmc1
Select s364xx_setup_sdhci
Select initi_dev_usb_host
Select initi_dev_nand
Select initi_dev_fb
Select s364xx_setup_fb_24bpp
Select samsung_dev_adc
Select samsung_dev_ts
Help
Machine support for the friendlyarm mini6410
Config mach_ok6410
Bool "ok6410"
Select cpu_89c6410
Select initi_dev_hsmmc
Select s3_dev_hsmmc1
Select s364xx_setup_sdhci
Select initi_dev_usb_host
Select initi_dev_nand
Select initi_dev_fb
Select s364xx_setup_fb_24bpp
Select samsung_dev_adc
Select samsung_dev_ts
Help
Machine support for the feilin ok6410
We only need to copy an ok6410 segment according to the configuration of mini6410. Of course, the Select here is not completely for ok6410. When we add a new driver in the future, you also need to add it here, or you won't be able to see it during make menuconfig, so you won't be able to choose it. Well, save kconfig and match it accordingly, then, find the MAKEFILE file in the same directory and add obj-$ (config_mach_ok6410) + = mach-ok6410.o anywhere under # machine support to ensure that the kconfig file is consistent with the MAKEFILE file, in this way, it can be compiled during compilation.
Step 4: If you compile the modified ok6410 kernel, you will find that the compilation fails. Why? Because we have created a board-level file not available in the original official Linux kernel, and for the newly added board-level file, we need to send an email to the Linux kernel development team. After confirmation and approval, they will add it to the new Linux kernel so that the compilation will be allowed, in the final analysis, there is no Mach-type matching the ok6410 Board added in the Linux kernel. Modify the Mach-types file under 2.6.39.2/ARCH/ARM/tools, add at the end of the file
Ok6410 mach_ok6410 ok6410 3425. Of course, the machine code here is provided by us. It is not officially provided. The purpose is just to let the compilation pass, and it does not mean to intentionally destroy the source code!
In fact, this step has basically ended, but the NFS file system of linux2.6.38 and later versions has undergone great changes, resulting in failure to mount the NFS file system, even if NFS is configured in make menuconfig, mounting fails. In fact, this is a bug. Here we provide two solutions for you to choose from, of course, you do not need to modify this file before linux2.6.38, and an nfsroot file under linux2.6.39.2/fs/nfs. c gedit nfsroot. c. Find
/* Default nfsroot mount options .*/
# Define nfs_def_options "UDP"
1. Modify # define nfs_def_options "TCP" (by default, NFS adopts the UDP protocol and is changed to the TCP protocol)
Or 2, modify # define nfs_def_options "vers = 2, UDP, rsize = 4096, wsize = 4096"
After the file is modified, when NFS is mounted
Freeing init memory: 128 K
NFS: Server 192.168.0.103 not responding, still trying
NFS: Server 192.168.0.103 OK.
Okay, at this step, the migration of the ok6410 linux2.6.39.2 version is basically completed. It is said that it is a transplant. In fact, we have not done anything. After all, it is CP mini6410. Of course, after the migration is successful, the dm9000 Nic works properly. The LCD (4.3-inch, 8-inch screen supported in this version) is displayed normally. NFS mounting is enabled, and the NAND file system is enabled normally, for some drivers such as touch screens in the future, you need to do it by yourself. I am a very lazy person, haha, so the same is true for transplantation, there are off-the-shelf official mini6410 board-level files not needed, so it is willing to shorten the transplant cycle
! Because it will be lost, I don't know what's going on. paste it directly.
Mmc1: mmc_rescan_try_freq: Trying to init card at 100000Hz
Dm9000 dm9000: eth0: link down
IP-config: complete:
Device = eth0, ADDR = 192.168.0.103, mask = 255.255.255.0, GW = 192.168.0.233,
Host = dm9000b, domain =, Nis-domain = (none ),
Bootserver = 192.168.0.104, rootserver = 192.168.0.104, rootpath =
Dm9000 dm9000: eth0: link up, 100 Mbps, full-duplex, LPA 0x4de1
VFS: mounted root (NFS filesystem) on device 0: 11.
Freeing init memory: 128 K
Hwclock: Can't open '/dev/rtc': no such file or directory
*************************************
Http://www.witech.com.cn
*************************************
Mkdir: cannot create directory '/mnt/disk': file exists
Mount: mounting/dev/mtdblock3 on/mnt/disk failed: no such device
Try to bring eth0 interface up... ifconfig: siocsifhwaddr: device or resource busy
Done
Starting qtopia, please waiting...
Please press enter to activate this console. Touch...
[Root @ forlinx6410/] #
This is the NFS mounting and root startup information.
You can see that the ok6410 option is also available, of course. It is okay to start the NAND file system. Just make sure that the corresponding NAND location of the file system is consistent with the partition information mentioned above.
Well, someone may ask how to configure the kernel when making menuconfig. Here, you can configure the kernel based on the default configuration of in configs/. It will be simple. Here, I have provided my ok6410_config configuration file directly, because it cannot be uploaded. If you have friends who need it, please download it in my space. The same log can only be uploaded to the space, you only need to right-click the image in the same log to download it, and change the suffix to RAR. decompress the package to get ok6410_config. below is the space address of my log.
Http://user.qzone.qq.com/1057481936/infocenter
, You only need to copy to the root directory of linux2.6.39.2, CP ok6410_config. config and directly make zimage or make uimage (the premise is to have the uboot makeaimage tool in the/bin/directory). If you need other configurations, just make menuconfig.