用戶(hù)態(tài)mmap匿名映射的問(wèn)題！

312-pirl0

系統(tǒng)內(nèi)存為512M，用mmap匿名映射了0x10000000地址起始的128M內(nèi)存，如何mmap返回成功的話(huà)，那么操作系統(tǒng)還會(huì)去將0x10000000～0x18000000的內(nèi)存分給別的程序嗎？

312-pirl0

其實(shí)，我想解決的一個(gè)問(wèn)題就是，想將一段固定地址的物理內(nèi)存分配出來(lái)給app用，由于這塊內(nèi)存將會(huì)給其他硬件使用，所以，必須是物理地址連續(xù)的。
而且分配的size比較大，有256M之多。所以，內(nèi)核里面的allloc_pages無(wú)能為力了。所以，想到用mmap的匿名映射來(lái)實(shí)現(xiàn)。
不知道其他朋友，遇到這種問(wèn)題都是如何解決？

humjb_1983

312-pirl0 發(fā)表于 2014-08-03 22:53
其實(shí)，我想解決的一個(gè)問(wèn)題就是，想將一段固定地址的物理內(nèi)存分配出來(lái)給app用，由于這塊內(nèi)存將會(huì)給其他硬件使 ...

可以使用mem=內(nèi)核啟動(dòng)參數(shù)保留一段內(nèi)存出來(lái)，然后ioremap專(zhuān)用。。。

312-pirl0

剛開(kāi)始，我也是想的這一招，但是在xilinx zynq芯片提供kernel中使用該參數(shù)時(shí)，kernel panic。我查了一下，應(yīng)該是rootfs initrd和dtb存放的地址在ddr的高地址上，所以造成的panic。

panic log：
Linux version 3.12.0-xilinx (root@debian) (gcc version 4.6.3 (Wind River Linux Sourcery CodeBench 4.6a-105) ) #4 SMP PREEMPT Sat Jun 7 22:36:15 CST 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq
bootconsole [earlycon0] enabled
INITRD: 0x1f61e000+0x005104dd is not a memory region - disabling initrd
Memory policy: Data cache writealloc
Unable to handle kernel paging request at virtual address df619000
pgd = c0004000
[df619000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-xilinx #4
task: c053b020 ti: c0530000 task.ti: c0530000
PC is at __unflatten_device_tree+0xd0/0x270
LR is at 0x0
pc : [<c02f0d64>]    lr : [<00000000>]    psr: 600001d3
sp : c0531f60  ip : d00dfeed  fp : 00000000
r10: 00000000  r9 : 413fc090  r8 : 413fc090
r7 : c053bef0  r6 : c05086fc  r5 : c056a790  r4 : df619000
r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : c056a790
Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 18c5387d  Table: 0000404a  DAC: 00000015
Process swapper (pid: 0, stack limit = 0xc0530240)
Stack: (0xc0531f60 to 0xc0532000)
1f60: df619000 c05919e0 c05086fc c05919e0 c052514c c0589a18 c0799c40 c051cf00
1f80: 00000000 c0507a64 00000000 18c5387d 413fc090 00000000 00000000 c0397c60
1fa0: c046a00a c0531fbc 00000000 c0531fbc c0530000 00000001 ffffffff c0531fc8
1fc0: 0000406a c05047f4 00000000 00000000 00000000 00000000 00000000 c0526188
1fe0: 18c5387d c05383cc c0526184 c053c000 0000406a 00008074 00000000 00000000
[<c02f0d64>] (__unflatten_device_tree+0xd0/0x270) from [<c051cf00>] (unflatten_device_tree+0x18/0x30)
[<c051cf00>] (unflatten_device_tree+0x18/0x30) from [<c0507a64>] (setup_arch+0x5bc/0x89
[<c0507a64>] (setup_arch+0x5bc/0x89 from [<c05047f4>] (start_kernel+0x78/0x304)
[<c05047f4>] (start_kernel+0x78/0x304) from [<00008074>] (0x8074)
Code: e6bf2f32 e59f117c ebfb7a69 e59fc178 (e594e000)
---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Attempted to kill the idle task!

humjb_1983

312-pirl0 發(fā)表于 2014-08-06 15:54
剛開(kāi)始，我也是想的這一招，但是在xilinx zynq芯片提供kernel中使用該參數(shù)時(shí)，kernel panic。我查了一下，應(yīng) ...

從信息看，像是bug，不過(guò)arm架構(gòu)的東東我不熟，不好判斷或深入分析�？磥�(lái)得想想其它辦法了。
我記得好像有人做過(guò)“內(nèi)存即時(shí)映射”的功能，要找找~
你這段內(nèi)存是留給用戶(hù)態(tài)程序使用？還是內(nèi)核自己使用？

Tinnal

回復(fù) 4# 312-pirl0
rootfs initrd和dtb存放的地址存放的地址也是可以調(diào)的麻，一并往低調(diào)不就行了嗎。

另外一種方式也可以，就是麻煩點(diǎn)，就是在bootmem里把一段頁(yè)框先給保留起來(lái)。不讓buddy去用。以后你自己就可以ioremap了。


   

Tinnal

還有第三種方式，如是你有DTB的話(huà)，應(yīng)該可以在DTS里頭把內(nèi)存分兩段，把低端和你的initrd用戶(hù)的高端留著，把中間一塊挖出來(lái)。

312-pirl0

回復(fù) 5# humjb_1983
留給用戶(hù)態(tài)程序用的。

   

312-pirl0

回復(fù) 6# Tinnal

謝謝，tinnal。我現(xiàn)在使用的方法就是在bootloader中修改rootfs和dtb的存放地址。然后，kernel中就可以使用mem bootarg的參數(shù)了，dts中的memory reg也可以做到。這兩種方法二選一就好了。
   

humjb_1983

312-pirl0 發(fā)表于 2014-08-06 22:46
回復(fù) 5# humjb_1983
留給用戶(hù)態(tài)程序用的。

留給用戶(hù)態(tài)程序，為何要求物理內(nèi)存連續(xù)？沒(méi)這個(gè)必要吧？