-
## Booting kernel from Legacy Image at 50000000 ...
-
Image Name:
-
Image Type: ARM Linux Kernel Image (uncompressed)
-
Data Size: 656144 Bytes = 640.8 KiB
-
Load Address: 80200000
-
Entry Point: 80200000
-
Verifying Checksum ... OK
-
## Flattened Device Tree blob at 42000000
-
Booting using the fdt blob at 0x42000000
-
Loading Kernel Image ... OK
-
OK
-
reserving fdt memory region: addr=42000000 size=9000
-
Using Device Tree in place at 42000000, end 4200bfff
-
Starting kernel ...
-
Xen 4.4-rc2
-
(XEN) Xen version 4.4-rc2 (uty@localdomain) (arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3) debug=y Tue Dec 16 22:03:20 CST 2014
-
(XEN) Latest ChangeSet: Thu Feb 6 12:20:48 2014 +0100 git:fee6163-dirty
-
(XEN) Console output is synchronous.
-
(XEN) Processor: 410fc0f4: "ARM Limited", variant: 0x0, part 0xc0f, rev 0x4
-
(XEN) 32-bit Execution:
-
(XEN) Processor Features: 00001031:00011011
-
(XEN) Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
-
(XEN) Extensions: GenericTimer Security
-
(XEN) Debug Features: 02010555
-
(XEN) Auxiliary Features: 00000000
-
(XEN) Memory Model Features: 10201105 20000000 01240000 02102211
-
(XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000
-
(XEN) Platform: SAMSUNG EXYNOS5
-
(XEN) Set SYSRAM to 00000000bfe0004c (0020004c)
-
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
-
(XEN) uty: in exynos5_init_time() !!!!!!!!!!!
-
(XEN) Using generic timer at 24000 KHz
-
(XEN) GIC initialization:
-
(XEN) gic_dist_addr=0000000010481000
-
(XEN) gic_cpu_addr=0000000010482000
-
(XEN) gic_hyp_addr=0000000010484000
-
(XEN) gic_vcpu_addr=0000000010486000
-
(XEN) gic_maintenance_irq=25
-
(XEN) GIC: 160 lines, 2 cpus, secure (IID 0200043b).
-
(XEN) Using scheduler: SMP Credit Scheduler (credit)
-
(XEN) Allocated console ring of 16 KiB.
-
(XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
-
(XEN) Bringing up CPU1
-
(XEN) CPU 1 booted.
-
(XEN) Brought up 2 CPUs
-
(XEN) *** LOADING DOMAIN 0 ***
-
(XEN) Populate P2M 0x80000000->0xa0000000 (1:1 mapping for dom0)
-
(XEN) uty: early_info.modules.nr_mods 2, MOD_KERNEL 2
-
(XEN) Loading kernel from boot module 2
-
(XEN) Loading zImage from 0000000060000000 to 0000000087c00000-0000000087fb95c4
-
(XEN) Loading dom0 DTB to 0x0000000088000000-0x0000000088008428
-
(XEN) Scrubbing Free RAM: ...............done.
-
(XEN) Initial low memory virq threshold set at 0x4000 pages.
-
(XEN) Std. Loglevel: All
-
(XEN) Guest Loglevel: All
-
(XEN) **********************************************
-
(XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
-
(XEN) ******* This option is intended to aid debugging of Xen by ensuring
-
(XEN) ******* that all output is synchronously delivered on the serial line.
-
(XEN) ******* However it can introduce SIGNIFICANT latencies and affect
-
(XEN) ******* timekeeping. It is NOT recommended for production use!
-
(XEN) **********************************************
-
(XEN) 3... 2... 1...
-
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen)
-
(XEN) Freed 264kB init memory.
-
(XEN) DOM0: Uncompressing Linux... done, booting the kernel.
-
(XEN) DOM0: <6>Initializing cgroup subsys cpu
-
(XEN) DOM0: <5>Linux version 3.0.31-g3370a7c-dirty (uty@localhost.localdomain) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #25
-
(XEN) DOM0: SMP PREEMPT Wed Dec 24 22:40:07 CST 2014
-
(XEN) DOM0: CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d
-
(XEN) DOM0: CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
-
(XEN) DOM0: <6>Machine: ARNDALE, model: Insignal Arndale evaluation board based on EXYNOS5250
-
(XEN) DOM0: uty: arm_add_memory start 0x80000000 size 0x20000000
-
(XEN) DOM0: <6>debug: ignoring loglevel setting.
-
(XEN) DOM0: Memory policy: ECC disabled, Data cache writealloc
-
(XEN) DOM0: uty: build_mem_type_table end
-
(XEN) DOM0: uty: build_mem_type_table end
-
(XEN) DOM0: uty: prepare_page_table end
-
(XEN) DOM0: uty: prepare_page_table end
-
(XEN) DOM0: uty: map_lowmem end
-
(XEN) DOM0: uty: map_lowmem end
-
(XEN) DOM0: uty:in devicemaps_init
-
(XEN) DOM0: uty:in devicemaps_init 2
-
(XEN) DOM0: uty: early_alloc for vectors_page OK
-
(XEN) DOM0: uty: addr=0xf6000000
-
(XEN) DOM0: uty: pmd=0xc0007d80
-
(XEN) DOM0: uty: addr=0xf6200000
-
(XEN) DOM0: uty: pmd=0xc0007d88
-
(XEN) DOM0: uty: addr=0xf6400000
-
(XEN) DOM0: uty: pmd=0xc0007d90
-
(XEN) DOM0: uty: addr=0xf6600000
-
(XEN) DOM0: uty: pmd=0xc0007d98
-
(XEN) DOM0: uty: addr=0xf6800000
-
(XEN) DOM0: uty: pmd=0xc0007da0
-
(XEN) DOM0: uty: addr=0xf6a00000
-
(XEN) DOM0: uty: pmd=0xc0007da8
-
(XEN) DOM0: uty: addr=0xf6c00000
-
(XEN) DOM0: uty: pmd=0xc0007db0
-
(XEN) DOM0: uty: addr=0xf6e00000
-
(XEN) DOM0: uty: pmd=0xc0007db8
-
(XEN) DOM0: uty: addr=0xf7000000
-
(XEN) DOM0: uty: pmd=0xc0007dc0
上次跑到这里
想看下xen的输出看看是不是内存访问时出错了,不过后来想0xc0007dc0这样的地址不是新页开始的地址,怎么会突然不能访问呢。然后想到0xf7000000这个地址还是有点特别的,会不会是这段地址里map了什么,导致early_printk不能输出了?
一开始觉得early_printk用的时板上UART的物理地址,不会受影响,但又一想,在kernel解压代码执行的时候没有开启分页,是用的物理内存访问,已经执行到现在这里了,怎样用物理内存访问啊,一定得把这段物理内存map了再用。所以又去看了下early_printk的流程,确实和想的一样。
在arch\arm\kernel\early_printk.c里实现的early_printk()
-
39 asmlinkage void early_printk(const char *fmt, ...)
-
40 {
-
41 char buf[512];
-
42 int n;
-
43 va_list ap;
-
44
-
45 va_start(ap, fmt);
-
46 n = vscnprintf(buf, sizeof(buf), fmt, ap);
-
47 early_write(buf, n);
-
48 va_end(ap);
-
49 }
-
17 static void early_write(const char *s, unsigned n)
-
18 {
-
19 while (n-- > 0) {
-
20 if (*s == '\n')
-
21 printch('\r');
-
22 printch(*s);
-
23 s++;
-
24 }
-
25 }
然后搜printch,实现在arch/arm/kernel/debug.S
-
107 #ifdef CONFIG_MMU
-
108 .macro addruart_current, rx, tmp1, tmp2
-
109 addruart \tmp1, \tmp2, \rx
-
110 mrc p15, 0, \rx, c1, c0
-
111 tst \rx, #1
-
112 moveq \rx, \tmp1
-
113 movne \rx, \tmp2
-
114 .endm
-
115
-
116 #else /* !CONFIG_MMU */
-
117 .macro addruart_current, rx, tmp1, tmp2
-
118 addruart \rx, \tmp1
-
119 .endm
-
120
-
121 #endif /* CONFIG_MMU */
-
122
-
123 /*
-
124 * Useful debugging routines
-
125 */
-
126 ENTRY(printhex8)
-
127 mov r1, #8
-
128 b printhex
-
129 ENDPROC(printhex8)
-
130
-
131 ENTRY(printhex4)
-
132 mov r1, #4
-
133 b printhex
-
134 ENDPROC(printhex4)
-
135
-
136 ENTRY(printhex2)
-
137 mov r1, #2
-
138 printhex: adr r2, hexbuf
-
139 add r3, r2, r1
-
140 mov r1, #0
-
141 strb r1, [r3]
-
142 1: and r1, r0, #15
-
143 mov r0, r0, lsr #4
-
144 cmp r1, #10
-
145 addlt r1, r1, #'0'
-
146 addge r1, r1, #'a' - 10
-
147 strb r1, [r3, #-1]!
-
148 teq r3, r2
-
149 bne 1b
-
150 mov r0, r2
-
151 b printascii
-
152 ENDPROC(printhex2)
-
153
-
154 hexbuf: .space 16
-
155
-
156 .ltorg
-
157
-
158 ENTRY(printascii)
-
159 addruart_current r3, r1, r2
-
160 b 2f
-
161 1: waituart r2, r3
-
162 senduart r1, r3
-
163 busyuart r2, r3
-
164 teq r1, #'\n'
-
165 moveq r1, #'\r'
-
166 beq 1b
-
167 2: teq r0, #0
-
168 ldrneb r1, [r0], #1
-
169 teqne r1, #0
-
170 bne 1b
-
171 mov pc, lr
-
172 ENDPROC(printascii)
-
173
-
174 ENTRY(printch)
-
175 addruart_current r3, r1, r2
-
176 mov r1, r0
-
177 mov r0, #0
-
178 b 1b
-
179 ENDPROC(printch)
ChinaUnix你够了啊,贴个代码贴出翔
因为不是用的CONFIG_DEBUG_ICEDCC所以关键的addruart是实现在mach-xxx/debug-macro.S里,但在addruart_current这个宏里,是对当前是否是进入页模式有判断的,如果是就用虚拟地址,如果不是就用物理地址
在arch/arm/mach
-exynos/
include/mach/debug
-macro.S里
-
1 /* linux/arch/arm/mach-exynos/include/mach/debug-macro.S
-
2 *
-
3 * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
-
4 * http://www.samsung.com
-
5 *
-
6 * Based on arch/arm/mach-s3c6400/include/mach/debug-macro.S
-
7 *
-
8 * This program is free software; you can redistribute it and/or modify
-
9 * it under the terms of the GNU General Public License version 2 as
-
10 * published by the Free Software Foundation.
-
11 */
-
12
-
13 /* pull in the relevant register and map files. */
-
14
-
15 #include <mach/map.h>
-
16
-
17 /* note, for the boot process to work we have to keep the UART
-
18 * virtual address aligned to an 1MiB boundary for the L1
-
19 * mapping the head code makes. We keep the UART virtual address
-
20 * aligned and add in the offset when we load the value here.
-
21 */
-
22
-
23 .macro addruart, rp, rv
-
24 ldr \rp, = S3C_PA_UART
-
25 ldr \rv, = S3C_VA_UART
-
26 #if CONFIG_DEBUG_S3C_UART != 0
-
27 add \rp, \rp, #(0x10000 * CONFIG_DEBUG_S3C_UART)
-
28 add \rv, \rv, #(0x10000 * CONFIG_DEBUG_S3C_UART)
-
29 #endif
-
30 .endm
-
31
-
32 #define fifo_full fifo_full_s5pv210
在arch/arm/mach-exynos/include/mach/map-exynos5.h中,找到了对应的定义。
286 #define S3C_PA_UART EXYNOS5_PA_UART
113 #define EXYNOS5_PA_UART 0x12C00000
在arch/arm/plat-samsung/include/plat/map-base.h中定义的VA地址
-
17 /* Fit all our registers in at 0xF6000000 upwards, trying to use as
-
18 * little of the VA space as possible so vmalloc and friends have a
-
19 * better chance of getting memory.
-
20 *
-
21 * we try to ensure stuff like the IRQ registers are available for
-
22 * an single MOVS instruction (ie, only 8 bits of set data)
-
23 */
-
24
-
25 #define S3C_ADDR_BASE 0xF6000000
-
26
-
27 #ifndef __ASSEMBLY__
-
28 #define S3C_ADDR(x) ((void __iomem __force *)S3C_ADDR_BASE + (x))
-
29 #else
-
30 #define S3C_ADDR(x) (S3C_ADDR_BASE + (x))
-
31 #endif
-
32
-
33 #define S3C_VA_IRQ S3C_ADDR(0x00000000) /* irq controller(s) */
-
34 #define S3C_VA_SYS S3C_ADDR(0x00100000) /* system control */
-
35 #define S3C_VA_MEM S3C_ADDR(0x00200000) /* memory control */
-
36 #define S3C_VA_TIMER S3C_ADDR(0x00300000) /* timer block */
-
37 #define S3C_VA_WATCHDOG S3C_ADDR(0x00400000) /* watchdog */
-
38 #define S3C_VA_HSOTG S3C_ADDR(0x00E00000) /* OTG */
-
39 #define S3C_VA_HSPHY S3C_ADDR(0x00F00000) /* OTG PHY */
-
40 #define S3C_VA_UART S3C_ADDR(0x01000000) /* UART */
-
41
-
42 /* This is used for the CPU specific mappings that may be needed, so that
-
43 * they do not need to directly used S3C_ADDR() and thus make it easier to
-
44 * modify the space for mapping.
-
45 */
-
46 #define S3C_ADDR_CPU(x) S3C_ADDR(0x00500000 + (x))
-
47
-
48 #endif /* __ASM_PLAT_MAP_H */
可以看到S3C_VA_UART正是在0xf7000000的位置。现在用的是2号UART所以是0xf7020000,这个地址段的pmd被清0后,当然early_printk就不能用了,这也回答了我前几天的疑问。
所以代码卡在这的原因是early_printk不显示了,而后面的初始化device map没有再初始化对UART部分的映射?
阅读(598) | 评论(0) | 转发(0) |