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

                   

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

            評論

            # 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ù)  更多評論   

            # 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ù)  更多評論   

            # 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ù)  更多評論   

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

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

            導(dǎo)航

            統(tǒng)計(jì)

            公告

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

            常用鏈接

            留言簿(37)

            隨筆分類(104)

            隨筆檔案(101)

            文章分類(51)

            文章檔案(53)

            wince牛人

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            国产激情久久久久影院小草 | 欧美一区二区三区久久综合 | 中文字幕无码久久久| 波多野结衣久久一区二区| 国内精品久久久久伊人av| 潮喷大喷水系列无码久久精品| 91精品国产9l久久久久| 久久中文字幕视频、最近更新| 久久综合国产乱子伦精品免费| 国产福利电影一区二区三区久久老子无码午夜伦不 | 久久久中文字幕日本| 中文字幕精品久久| 久久婷婷五月综合成人D啪| 久久综合九色综合欧美狠狠| 久久综合九色欧美综合狠狠| 久久精品国产亚洲AV无码娇色| 久久国产热这里只有精品| 久久久无码精品亚洲日韩蜜臀浪潮 | 国内精品欧美久久精品| 亚洲av成人无码久久精品| 久久亚洲欧洲国产综合| 亚洲国产精品人久久| 亚洲va久久久噜噜噜久久| 亚洲精品无码久久久| 久久久WWW成人免费精品| 99久久国语露脸精品国产| 伊人久久大香线蕉亚洲| 精品久久久久久久久免费影院| 久久国产精品免费一区| 久久精品?ⅴ无码中文字幕| 国产精品无码久久久久| 狠狠色综合网站久久久久久久| 美女写真久久影院| 日本久久久精品中文字幕| 国产精品九九九久久九九| 7777久久亚洲中文字幕| 国产成人综合久久综合| 青青热久久综合网伊人| 91精品国产91久久久久久青草| 亚洲乱亚洲乱淫久久| 久久婷婷五月综合97色直播|