| 标题 | 阅读 | 评论 | 转发 | 发布日期 | |
|---|---|---|---|---|---|
| fedora 升级内核无法登录问题解决 | 4192 | 0 | 0 | 2011-05-30 | |
| 安装g++ 及 svn add .so | 1935 | 0 | 0 | 2011-05-27 | |
| svn Changelists | 2205 | 0 | 0 | 2011-05-26 | |
| Linux cut命令 | 1061 | 0 | 0 | 2011-05-24 | |
| iptables limit 參數備忘 | 795 | 0 | 0 | 2011-05-24 | |
| 对比objdump与readelf | 2122 | 2 | 1 | 2011-05-22 | |
| Linux下库函数动态链接过程分析－结合glibc-2.11源码 | 2443 | 0 | 1 | 2011-05-22 | |
| 使用gmail的高级搜索 | 2044 | 0 | 1 | 2011-05-10 | |
| rpm知识 | 678 | 0 | 1 | 2011-05-05 | |
| 【推荐】 printf 打印signed char 与unsigned char 之区别 | 22944 | 8 | 1 | 2011-05-05 |
redglass2008-09-10 13:12
我做2440系统的移植的时候发现这样的问题 在一开始进行到setup_processor这个函数的时候(arch/arm/kernel/setup.c)跟踪看了一下list = lookup_processor_type();得到的指针是null，跟踪进去看汇编，就是head.s中的那个__lookup_processor_type函数，代码如下，其中把各个寄存器的值都打出来了，看了都没什么问题，在1：后答应看到的r3,r4,r9都能和arch/arm/mm/proc-arm920.s对应上（后面有代码），应该能正常的到2:,但是怎么在c里面的那个语句获得不到该得到的值呢？请知道的话帮我解释一下吧。谢谢了 __lookup_processor_type: adr r3, 3f ldmda r3, {r5, r6, r9} sub r3, r3, r9 @ get offset between virt&phys add r5, r5, r3 @ convert virt addresses to add r6, r6, r3 @ physical address space mrc p15, 0, r9, c0, c0 @ get processor id 1: ldmia r5, {r3, r4} @ value, mask and r4, r4, r9 @ mask wanted bits teq r3, r4 beq 2f add r5, r5, #PROC_INFO_SZ @ sizeof(proc_info_list) cmp r5, r6 blo 1b mov r5, #0 @ unknown processor 2: mov pc, lr __arm920_proc_info: .long 0x41009200 .long 0xff00fff0 .long PMD_TYPE_SECT | \ PMD_SECT_BUFFERABLE | \ PMD_SECT_CACHEABLE | \ PMD_BIT4 | \ PMD_SECT_AP_WRITE | \ PMD_SECT_AP_READ b __arm920_setup .long cpu_arch_name .long cpu_elf_name .long HWCAP_SWP | HWCAP_HALF | HWCAP_THUMB .long cpu_arm920_name .long arm920_processor_functions .long v4wbi_tlb_fns .long v4wb_user_fns #ifndef CONFIG_CPU_DCACHE_WRITETHROUGH .long arm920_cache_fns #else .long v4wt_cache_fns #endif .size __arm920_proc_info, . - __arm920_proc_info
