• <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牛人

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            美女久久久久久| 一本一道久久综合狠狠老| 国产精品久久久久久搜索| 精品国产91久久久久久久| 精品午夜久久福利大片| 久久精品成人影院| 欧美va久久久噜噜噜久久| 国产一级做a爰片久久毛片| 人人狠狠综合88综合久久| 99精品国产综合久久久久五月天| 国产三级久久久精品麻豆三级| 久久国产成人亚洲精品影院| 亚洲欧美伊人久久综合一区二区| 7国产欧美日韩综合天堂中文久久久久| 亚洲午夜无码AV毛片久久| 久久人人爽人人爽人人片AV不| 久久天堂电影网| 精品无码久久久久久尤物| 久久av高潮av无码av喷吹| 久久久精品2019免费观看 | 久久精品国产WWW456C0M| 性欧美丰满熟妇XXXX性久久久 | 久久久久久精品成人免费图片| 日本免费一区二区久久人人澡| 97精品伊人久久久大香线蕉| 久久久久久亚洲精品无码| 久久精品国产一区| 久久综合狠狠综合久久综合88| 日韩欧美亚洲综合久久影院Ds| 国产午夜福利精品久久| 精品久久久久久| 麻豆精品久久精品色综合| 99久久99久久| 久久精品成人免费看| 国产精品美女久久久久网| 国产精品视频久久| 草草久久久无码国产专区| 国产精品成人久久久久三级午夜电影 | 狠狠色丁香婷婷久久综合五月| 久久久国产精品网站| 亚洲国产精品久久久久网站 |