关于DMA zone的疑问

chishanmingshen

3G到3G+8M是内核映像，3G到3G+16M是dma区间。

（只考虑简单的32位系统，可以仅考虑UP。）

这个理解对么？请大家指点。谢谢！

embeddedlwp

回复 1# chishanmingshen


dmesg 的信息

[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   Normal   [mem 0x01000000-0x37bfdfff]
[    0.000000]   HighMem  [mem 0x37bfe000-0x3e5fffff]


[    0.000000] virtual kernel memory layout:
[    0.000000]     fixmap  : 0xfff14000 - 0xfffff000   ( 940 kB)
[    0.000000]     pkmap   : 0xffc00000 - 0xffe00000   (2048 kB)
[    0.000000]     vmalloc : 0xf83fe000 - 0xffbfe000   ( 120 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xf7bfe000   ( 891 MB)
[    0.000000]       .init : 0xc190c000 - 0xc19d7000   ( 812 kB)
[    0.000000]       .data : 0xc1612e9c - 0xc190b140   (3040 kB)
[    0.000000]       .text : 0xc1000000 - 0xc1612e9c   (6219 kB)


   

embeddedlwp

内核镜像所占的内存没有释放给buddy system，但是建立direct mapping的时候已经包含了内核镜像部分，所以内核代码自己还是可以访问的，就是之后不会被buddy system进行释放，分配什么的。

chishanmingshen

回复 2# embeddedlwp


    回复 1# chishanmingshen


dmesg 的信息

[    0.000000]     lowmem  : 0xc0000000 - 0xf7bfe000   ( 891 MB)
[    0.000000]       .init : 0xc190c000 - 0xc19d7000   ( 812 kB)
[    0.000000]       .data : 0xc1612e9c - 0xc190b140   (3040 kB)
[    0.000000]       .text : 0xc1000000 - 0xc1612e9c   (6219 kB)

理解，我想知道那DMA内存在3G到4G的哪里啊？

   

junnyg

回复 4# chishanmingshen
在C0001000 - C0FFFFFF吧，物理内存的前16M（除起始的0x1000之外）作为DMA区域，一一映射后就到C0000000之后的16M位置了，但内核使用它的方式不是访问这块虚拟地址，而是基于ZONE_DMA的页分配进行管理的，而且除了一些ISA设备需要使用这块内存作为DMA内存，现在的设备一般都支持全地址的DMA访问


   

chishanmingshen

刚看错了。
[    0.000000]       .text : 0xc1000000 - 0xc1612e9c   (6219 kB)
这个已经表明前16m是留给dma zone了。

我的疑问：3G到3G+8M不是给映像的么？
启动中0-8M和3G到3G+8M都映射到映像，之后会仅仅保留3G到3G+8M的映像映射。

求指点，谢谢！:wink:

chishanmingshen

怎么理解？ 难道dma zone是16M减去映像的大小？不会吧。。。

junnyg

内核代码段的加载位置是PAGE_OFFSET + CONFIG_PHYSICAL_START吧

1. config PHYSICAL_START
   
2.         hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
   
3.         default "0x1000000"
   
4.         ---help---
   
5.           This gives the physical address where the kernel is loaded.
   
6. 
   
7.           If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
   
8.           bzImage will decompress itself to above physical address and
   
9.           run from there. Otherwise, bzImage will run from the address where
   
10.           it has been loaded by the boot loader and will ignore above physical
    
11.           address.
    
12. 
    
13.           In normal kdump cases one does not have to set/change this option
    
14.           as now bzImage can be compiled as a completely relocatable image
    
15.           (CONFIG_RELOCATABLE=y) and be used to load and run from a different
    
16.           address. This option is mainly useful for the folks who don't want
    
17.           to use a bzImage for capturing the crash dump and want to use a
    
18.           vmlinux instead. vmlinux is not relocatable hence a kernel needs
    
19.           to be specifically compiled to run from a specific memory area
    
20.           (normally a reserved region) and this option comes handy.
    
21. 
    
22.           So if you are using bzImage for capturing the crash dump,
    
23.           leave the value here unchanged to 0x1000000 and set
    
24.           CONFIG_RELOCATABLE=y.  Otherwise if you plan to use vmlinux
    
25.           for capturing the crash dump change this value to start of
    
26.           the reserved region.  In other words, it can be set based on
    
27.           the "X" value as specified in the "crashkernel=YM@XM"
    
28.           command line boot parameter passed to the panic-ed
    
29.           kernel. Please take a look at Documentation/kdump/kdump.txt
    
30.           for more details about crash dumps.
    
31. 
    
32.           Usage of bzImage for capturing the crash dump is recommended as
    
33.           one does not have to build two kernels. Same kernel can be used
    
34.           as production kernel and capture kernel. Above option should have
    
35.           gone away after relocatable bzImage support is introduced. But it
    
36.           is present because there are users out there who continue to use
    
37.           vmlinux for dump capture. This option should go away down the
    
38.           line.
    
39. 
    
40.           Don't change this unless you know what you are doing.

复制代码

详见http://bbs.chinaunix.net/thread-2029114-1-1.html

chishanmingshen

回复 8# junnyg

你说的没错，但是你看我6楼的问题啊。

   

embeddedlwp

回复 5# junnyg

除0x1000是因为memblock_trim_memory()中有个以页对齐向上取整的操作，这样0x0000就变成0x1000了。