XXX
分类: LINUX
2013-03-26 10:26:00
原文地址:linux内核的移植与遭遇问题的解决 作者:Ares.sigma
tar xjvf linux-2.6.20.3.tar.bz2 cd linux-2.6.20.3 |
vi Makefile 找到如下变量,并按照下述修改 ARCH =arm CROSS_COMPILE =arm-linux- |
a.分区信息设置 static struct mtd_partition smdk_default_nand_part[] = { [0] = {//建立bootloader 分区 .name = "U-Boot-1.2.0", .size = SZ_128K, .offset = 0, }, [1] = {//建立u-boot参数分区 .name = "U-Boot Parameter", .offset = SZ_128K, .size = SZ_64K, }, [2] = {//建立linux内核分区 .name = "Linux2.6.20.3", .offset = SZ_128K+SZ_64K, .size = SZ_4M+(SZ_1M-SZ_128K-SZ_64K), }, [3] = {//建立根文件分区(实际用nfs,该部分用作debug内核) .name = "Rootfs", .offset = SZ_1M * 5, .size = SZ_1M * 5, }, [4] = {//用户自定义分区 .name = "Userfs", .offset = SZ_1M * 10, .size = SZ_1M * 55, } }; b.设置flash硬件特性 static struct s3c2410_platform_nand smdk_nand_info = { .tacls = 0, .twrph0 = 30, .twrph1 = 0, .nr_sets = ARRAY_SIZE(smdk_nand_sets), .sets = smdk_nand_sets, }; |
chip->ecc.mode = NAND_ECC_NONE; |
make zImage |
|
setenv bootcmd tftp 0x30008000 zImage.img;bootm setenv bootargs console=ttySAC0,115200 mem=64M saveenv |
Uncompressing Linux............................................................. |
adr r0, str_p1 bl printascii str_p1:.asciz"\nError: unrecognized/unsupported processor variant.\n" |
ldr r1, =0x56000010 ldr r2, =0x154000 str r2, [r1] ldr r1, =0x56000018 mov r2, #0x00000000 str r2, [r1] ldr r1, =0x56000014 mov r2, #0x00000000 str r2, [r1] b . /*因为改变了寄存器值会影响系统随后的启动,因此在此进入死循环*/ |
__INIT .type stext, %function ENTRY(stext) msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode @ and irqs disabled mrc p15, 0, r9, c0, c0 @ get processor id bl __lookup_processor_type @ r5=procinfo r9=cpuid movs r10, r5 @ invalid processor (r5=0)? beq __error_p @ yes, error 'p' bl __lookup_machine_type @ r5=machinfo movs r8, r5 @ invalid machine (r5=0)? beq __error_a @ yes, error 'a' bl __create_page_tables ldr r13, __switch_data @ address to jump to after @ mmu has been enabled adr lr, __enable_mmu @ return (PIC) address add pc, r10, #PROCINFO_INITFUNC .type __enable_mmu, %function __enable_mmu: #ifdef CONFIG_ALIGNMENT_TRAP orr r0, r0, #CR_A #else bic r0, r0, #CR_A #endif #ifdef CONFIG_CPU_DCACHE_DISABLE bic r0, r0, #CR_C #endif #ifdef CONFIG_CPU_BPREDICT_DISABLE bic r0, r0, #CR_Z #endif #ifdef CONFIG_CPU_ICACHE_DISABLE bic r0, r0, #CR_I #endif mov r5, #(domain_val(DOMAIN_USER, DOMAIN_MANAGER) | \ domain_val(DOMAIN_KERNEL, DOMAIN_MANAGER) | \ domain_val(DOMAIN_TABLE, DOMAIN_MANAGER) | \ domain_val(DOMAIN_IO, DOMAIN_CLIENT)) mcr p15, 0, r5, c3, c0, 0 @ load domain access register mcr p15, 0, r4, c2, c0, 0 @ load page table pointer b __turn_mmu_on .align 5 .type __turn_mmu_on, %function __turn_mmu_on: mov r0, r0 mcr p15, 0, r0, c1, c0, 0 @ write control reg mrc p15, 0, r3, c0, c0, 0 @ read id reg mov r3, r3 mov r3, r3 mov pc, r13 |
|
.type __create_page_tables, %function __create_page_tables: 代码略. |
|
#define PROCINFO_INITFUNC 16 /* offsetof(struct proc_info_list, __cpu_flush) @ */ |
struct proc_info_list { unsigned int cpu_val; unsigned int cpu_mask; unsigned long __cpu_mm_mmu_flags;/*used by head.S */ unsigned long __cpu_io_mmu_flags;/*used by head.S */ unsigned long __cpu_flush; /* used by head.S */ const char *arch_name; const char *elf_name; unsigned int elf_hwcap; const char *cpu_name; struct processor *proc; struct cpu_tlb_fns *tlb; struct cpu_user_fns *user; struct cpu_cache_fns *cache; }; |
__arm9tdmi_proc_info: .long 0x41009900 .long 0xfff8ff00 .long 0 .long 0 b __arm9tdmi_setup .long cpu_arch_name .long cpu_elf_name .long HWCAP_SWP | HWCAP_THUMB | HWCAP_26BIT .long cpu_arm9tdmi_name .long arm9tdmi_processor_functions .long 0 .long 0 .long v4_cache_fns .size __arm9tdmi_proc_info, . - __arm9dmi_proc_info |
2.6. When I trace kernel in head.S I found problems that may be caused by __turn_mmu_on. Any idea ?
[5 April 2004 - ] Please read the comment in head.S: /* * Enable the MMU. This completely changes the structure of the visible * memory space. You will not be able to trace execution through this. * If you have an enquiry about this, *please* check the linux-arm-kernel * mailing list archives BEFORE sending another post to the list. */It's been asked soo many times that it really is a frequently asked question. The above comment is supposed to head off further questions, but alas... Hopefully this FAQ entry will do the job. [11 January 2002 - ] The number 1 problem is that people just do not realise what "enabling the MMU" means. It means that _all_ of the addressable memory _will_ change, and this normally means various regions you'd like to write to no longer exist - in other words, if you have debugging code present that doesn't cater for a complete change in the memory structure, then your debugging code is buggy. (Side note: I've even had people insist that their debugging code is perfect, even after mentioning the above, and then we've gone through several mails, ended up having the debugging code posted, and it turns out to buggy, assuming that the LEDs at some random address are still accessible.) The best advice is if you're using your own debugging code, remove it. Use the debugging printascii() stuff for your platform in arch/arm/kernel/debug-armv.S (enabled by CONFIG_DEBUG_LL) and drop a printascii() into printk() (kernel/printk.c) just after the vsprintf() call, and monitor the relevant serial port. |
extern void printascii(const char*);//kernel/printk.c 516行 printascii(printk_buf);////kernel/printk.c 539行 |
.type __switch_data, %object __switch_data: .long __mmap_switched .long __data_loc @ r4 .long __data_start @ r5 .long __bss_start @ r6 .long _end @ r7 .long processor_id @ r4 .long __machine_arch_type @ r5 .long cr_alignment @ r6 .long init_thread_union + THREAD_START_SP @ sp |