• <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)存管理機制

                  Windows CE引入了虛擬內(nèi)存機制管理多達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)核以后使用,這個虛實映射機制軟件上通過OEMAddressTable實現(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)體.在虛實地址映射文件(如ARM下的map.a)的OEMAddressTable中建立虛實地址的靜態(tài)映射關(guān)系,包括RAM,FLASH各部分存儲空間. (OS啟動后所能夠識別的物理內(nèi)存). 接著在config.bib的MEMORY段(參考HELP里的Memory Section)把RAM映射后的虛擬地址進行分段,比如NK的大小,各種外設(shè)緩沖區(qū)的保留等.(注意這里是虛擬地址的劃分,必須建立在映射基礎(chǔ)上)  這種靜態(tài)的虛擬地址只能夠由內(nèi)核層訪問,如果在APP中訪問,還必須建立動態(tài)映射.

                   

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

            評論

            # re: Windows CE內(nèi)存管理機制 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)存管理機制 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)存管理機制 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)存管理機制 2008-07-29 15:55 wogo

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

            導(dǎo)航

            統(tǒng)計

            公告

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

            常用鏈接

            留言簿(37)

            隨筆分類(104)

            隨筆檔案(101)

            文章分類(51)

            文章檔案(53)

            wince牛人

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            99精品国产在热久久无毒不卡| 亚洲AV伊人久久青青草原| 久久精品麻豆日日躁夜夜躁| .精品久久久麻豆国产精品| 久久人搡人人玩人妻精品首页| 思思久久精品在热线热| 成人国内精品久久久久影院| 国产巨作麻豆欧美亚洲综合久久| 精品一二三区久久aaa片| 久久精品国产精品青草| 久久亚洲精品无码aⅴ大香 | 国内精品伊人久久久久AV影院| 国产一区二区三精品久久久无广告 | 久久精品亚洲中文字幕无码麻豆| 久久精品国产亚洲精品| 国产精品久久久久久久久免费 | 亚洲国产精品无码久久久久久曰| 久久久国产精品亚洲一区| 一级做a爰片久久毛片免费陪| AV无码久久久久不卡网站下载| 香蕉久久夜色精品国产2020| 品成人欧美大片久久国产欧美...| 久久精品aⅴ无码中文字字幕重口| 香蕉99久久国产综合精品宅男自| 久久国产精品视频| 精品久久久久久久久中文字幕| 精品久久久无码人妻中文字幕豆芽 | 久久人人爽人人爽人人AV | 一本色道久久88加勒比—综合| 国产成人久久精品区一区二区| 午夜不卡久久精品无码免费| 热久久最新网站获取| 免费精品久久久久久中文字幕| 日本国产精品久久| 久久久亚洲裙底偷窥综合| 狠狠色丁香久久婷婷综合_中| 伊人情人综合成人久久网小说| 久久久久亚洲av综合波多野结衣| 亚洲午夜久久久久久久久久| 久久久亚洲AV波多野结衣| 人妻少妇久久中文字幕|