• <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 閱讀(4599) 評論(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牛人

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            囯产精品久久久久久久久蜜桃 | 韩国免费A级毛片久久| 久久久亚洲AV波多野结衣| 亚洲综合伊人久久综合| 久久综合久久综合九色| 国产69精品久久久久9999| 一日本道伊人久久综合影| AV狠狠色丁香婷婷综合久久| 久久精品国产欧美日韩| 国产精品久久久久AV福利动漫| 久久精品这里只有精99品| 色综合久久久久综合体桃花网| 久久精品国产一区二区三区日韩| 久久午夜福利无码1000合集| 香港aa三级久久三级| 色婷婷综合久久久中文字幕| 久久夜色撩人精品国产小说| 国产精品久久久久久福利漫画| 久久无码高潮喷水| 欧美粉嫩小泬久久久久久久 | 亚洲综合伊人久久综合| 日韩欧美亚洲国产精品字幕久久久| 久久99精品久久久久婷婷| 久久这里都是精品| 亚洲第一永久AV网站久久精品男人的天堂AV| 久久天天躁狠狠躁夜夜avapp| 精品久久久久久无码不卡| 久久青青草视频| 亚洲国产精品无码久久久久久曰| 久久久精品国产亚洲成人满18免费网站| 精品永久久福利一区二区| 久久精品国产亚洲AV麻豆网站| 欧美亚洲国产精品久久| 亚洲国产精品综合久久网络 | 国产精品美女久久久网AV| 久久精品一区二区国产| 国产精品久久久福利| 久久亚洲国产中v天仙www| 青青青青久久精品国产| 国产亚洲精午夜久久久久久| 久久毛片免费看一区二区三区|