• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            milkyway的窩

            最初想法的誕生地

             

            Windows CE內(nèi)存管理機(jī)制

                  Windows CE引入了虛擬內(nèi)存機(jī)制管理多達(dá)4G的虛擬內(nèi)存,最大支持512MB的物理內(nèi)存.不同的CPU內(nèi)存管理方法不同。對(duì)于MIPS和SHX系列CPU來(lái)說(shuō),地址映射是由CPU完成的,CE內(nèi)核可以直接訪(fǎng)問(wèn)512MB的物理內(nèi)存。對(duì)于x86系列和ARM系列的CPU來(lái)說(shuō),在內(nèi)核啟動(dòng)過(guò)程中它會(huì)將現(xiàn)有物理內(nèi)存地址全部映射到0x8000 0000以上的虛擬地址空間中供內(nèi)核以后使用,這個(gè)虛實(shí)映射機(jī)制軟件上通過(guò)OEMAddressTable實(shí)現(xiàn),硬件上要求具備MMU.
                  參考microsun的文章:  
                   "WINCE的內(nèi)存(包括SDRAM及FLASH)的配置包含兩個(gè)方面:源代碼(包括C和匯編)中的定義,及系統(tǒng)配置文件CONFIG.BIB中的定義。源代碼中需要定義內(nèi)存的物理及虛擬地址,大小,并初始化名為OEMAddressTable的結(jié)構(gòu)數(shù)組,以告知系統(tǒng)物理地址與虛擬地址的對(duì)應(yīng)關(guān)系,系統(tǒng)根據(jù)其設(shè)置生成MMU頁(yè)表。而CONFIG.BIB中一般會(huì)將內(nèi)存定義成不同的段,各段用作不同的用途。"
                     我的理解是在*.h文件中聲明各虛擬地址,比如用到的寄存器結(jié)構(gòu)體.在虛實(shí)地址映射文件(如ARM下的map.a)的OEMAddressTable中建立虛實(shí)地址的靜態(tài)映射關(guān)系,包括RAM,FLASH各部分存儲(chǔ)空間. (OS啟動(dòng)后所能夠識(shí)別的物理內(nèi)存). 接著在config.bib的MEMORY段(參考HELP里的Memory Section)把RAM映射后的虛擬地址進(jìn)行分段,比如NK的大小,各種外設(shè)緩沖區(qū)的保留等.(注意這里是虛擬地址的劃分,必須建立在映射基礎(chǔ)上)  這種靜態(tài)的虛擬地址只能夠由內(nèi)核層訪(fǎng)問(wèn),如果在APP中訪(fǎng)問(wèn),還必須建立動(dòng)態(tài)映射.

                   

            posted on 2007-04-15 23:07 milkyway 閱讀(4564) 評(píng)論(4)  編輯 收藏 引用 所屬分類(lèi): Wince學(xué)習(xí)小結(jié)

            評(píng)論

            # re: Windows CE內(nèi)存管理機(jī)制 2007-04-17 13:41 相思酸中有甜

            OEMAddressTable is a static (unchanging, available at startup without doing any work or setup) table of virtual -> physical mappings. The kernel is the only thing that has default access to the resources mapped by this table. If you are operating outside the OAL (i.e. in any kind of driver or application), you must use VirtualCopy() to copy or create memory page mappings. As mentioned above, you can copy any existing mapping as long as you have access to it. This includes a static mapping done by the OEMAddressTable. Some people will map all resources in the OEMAddressTable (so the kernel has access to everything), then just copy those mappings in drivers when they need to. This is not a best practice because it makes driver code less portable -- it is better to read the physical address of a component from the registry, then use the value found there to map to it. If you do this your driver code does not have to change if it is moved to a different platform or extended to use multiple components in different physical locations.

            A mapping does not have to exist in OEMAddressTable in order for you to access the physical resources mapped. You can create a new mapping unknown to the OEMAddressTable by using VirtualCopy with the PAGE_PHYSICAL flag.

            Config.bib reserves regions of memory that romimage knows about, but does not specify kernel memory regions.

            by Kurt,
              回復(fù)  更多評(píng)論   

            # re: Windows CE內(nèi)存管理機(jī)制 2007-04-17 13:42 相思酸中有甜

            OEMAddressTable mentioned in this blog applies only to h/w based TLB designs like x86 and ARM. For SHx and MIPS, there is a architecture pre-defined mapping (512Mb cached and uncached regions) at bootup.

            -- On ARM v6/v7 there is a bit (eXecute Never XN) which can be used to mark individual page entries. Once this is set, then any attempt to execute code from that page will fault. This most likely will be supported in future releases of CE.

            -- There seemed to be lot of confusion (party our fault since there are so many ways you can map physical or virtual memory) on these APIs. In general remember that VirtualCopy can be used to create a virtual address mapped to either a physical address or another virtual address range. Also all the flags are well documented in MSDN so you should take a look at that.

            by thx.

            -Upender

              回復(fù)  更多評(píng)論   

            # re: Windows CE內(nèi)存管理機(jī)制 2007-04-18 09:09 milkyway

            In Windows CE 5.0 and earlier, virtual allocations below 2MB *in size* will be allocated inside of the address space of the process calling it, while allocations above 2MB *in size* will be allocated out of the shared address space. I was not talking about the address of the allocation, I was talking about the size.

            by Sue

              回復(fù)  更多評(píng)論   

            # re: Windows CE內(nèi)存管理機(jī)制 2008-07-29 15:55 wogo

            hao!  回復(fù)  更多評(píng)論   

            導(dǎo)航

            統(tǒng)計(jì)

            公告

            隨筆皆原創(chuàng),文章乃轉(zhuǎn)載. 歡迎留言!

            常用鏈接

            留言簿(37)

            隨筆分類(lèi)(104)

            隨筆檔案(101)

            文章分類(lèi)(51)

            文章檔案(53)

            wince牛人

            搜索

            積分與排名

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            成人国内精品久久久久一区| 51久久夜色精品国产| 久久午夜电影网| 国产精品99久久免费观看| 免费无码国产欧美久久18| 久久久久久精品成人免费图片| 99久久无色码中文字幕人妻| 久久久无码精品亚洲日韩蜜臀浪潮| 色欲久久久天天天综合网精品 | 久久久久人妻一区精品| 青青国产成人久久91网| 精品久久8x国产免费观看| 国产∨亚洲V天堂无码久久久| 国产婷婷成人久久Av免费高清| 91精品国产综合久久婷婷| 久久五月精品中文字幕| 久久久久女人精品毛片| 99热成人精品热久久669| segui久久国产精品| 色偷偷久久一区二区三区| 欧美久久亚洲精品| 久久香蕉一级毛片| 久久精品无码免费不卡| 久久精品久久久久观看99水蜜桃| 人妻久久久一区二区三区| 热久久这里只有精品| 亚洲国产一成久久精品国产成人综合 | 亚洲国产精品成人久久蜜臀 | 亚洲精品国产第一综合99久久 | 亚洲av伊人久久综合密臀性色 | 精品久久久久久久中文字幕| 蜜臀av性久久久久蜜臀aⅴ麻豆 | 国产精品99久久精品| 精品国产一区二区三区久久蜜臀| 欧美日韩中文字幕久久久不卡 | 日日狠狠久久偷偷色综合96蜜桃| 久久笫一福利免费导航| 青青国产成人久久91网| 日韩精品久久久肉伦网站 | 精品免费久久久久国产一区| 99久久国产宗和精品1上映|