Stanley, The main point of PEI is to turn on memory. Given the complexity of this on modern PCs there has been a tendency to do "too much" work in PEI. When we designed SEC/PEI/DXE/BDS we thought that PEI would be smaller and DXE larger than it turns out today in many systems. So my first answer is do the work in DXE.
After memory is available in PEI it is possible to enter long mode (this is what the DXE IPL code does https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c), but this work is already done prior to jumping into to DXE, so why reinvent the wheel? Just do it in DXE. Andrew Fish PS I thought PSE supported 36-bits of physical address, and PAE supports 52-bits. The PAE bit enables an extra level of page tables or some such. Note 52-bits is what is possible in the page table, but the CPU may not support that much physical address space. On Jul 23, 2013, at 5:52 AM, "stanley.ganyezu" <stanley.gany...@gmail.com> wrote: > Hi Andrew, > You're right. Itanium have 64-bit PEI. Actually, I need to access > the MMIOH space between 32T~64T. > But PAE can only support up to 64GB. If only PAE enabled, it still can not > solve my problem. Do Intel ever think about this limitation? > Is there any Intel guys to give some help? > > > -----邮件原件----- > 发件人: Andrew Fish [mailto:af...@apple.com] > 发送时间: 2013年7月23日 8:44 > 收件人: stanley.ganyezu > 抄送: 'Brian J. Johnson'; edk2-devel@lists.sourceforge.net > 主题: Re: [edk2] switch to 64 bit mode at PEI phase in X86 > > > On Jul 22, 2013, at 5:38 PM, "stanley.ganyezu" <stanley.gany...@gmail.com> > wrote: > >> Thanks for Andrew and Brian. Do somebody ever succeed before? >> > > It works fine in an emulator or VM, but if you run on real hardware without > memory (at least t he ones I tried) the processor crashes if the page tables > are in FLASH or CAR. > > For Itanium and Aarch64 it is possible to have a 64-bit PEI, so most of the > generic code is 64-bit clean. > > Thanks, > > Andrew Fish > >> -----邮件原件----- >> 发件人: Andrew Fish [mailto:af...@apple.com] >> 发送时间: 2013年7月23日 7:36 >> 收件人: Brian J. Johnson >> 抄送: stanley.ganyezu; edk2-devel@lists.sourceforge.net >> 主题: Re: [edk2] switch to 64 bit mode at PEI phase in X86 >> >> Most of the X64 (x86_64) processors I know about crash and die hard if you >> place page tables in the Cache as RAM or the FLASH. That is why you see > IA32 >> PEI and X64 DXE on this class of systems. >> >> It is possible to use PAE in IA32 mode to access memory above 4 GB, >> http://en.wikipedia.org/wiki/Physical_Address_Extension >> >> Thanks, >> >> Andrew Fish >> >> >> On Jul 22, 2013, at 3:16 PM, "Brian J. Johnson" <bjohn...@sgi.com> wrote: >> >>> On 07/22/2013 08:55 AM, stanley.ganyezu wrote: >>>> Hi Everyone, >>>> >>>> I want to access address above 4Gb at PEI phase in X86. Can we >>>> switch to 64 bit mode before MRC? >>> >>> I wouldn't call myself a real expert on X86 addressing modes, but here >>> are some thoughts: >>> >>> AFAIK the PEI core and common modules work just fine in 64-bit mode. So >>> that's good. >>> >>> If you don't have RAM available, i.e. if you're running on real hardware >>> as opposed to a virtual machine or emulator, switching to 64-bit mode >>> may be difficult. Running C code before RAM is initialized requires >>> putting the CPU in cache-as-RAM mode, where it uses the CPU caches as a >>> small amount of RAM. I'm not sure if it's possible to use cache-as-RAM >>> in 64-bit mode... you'd need to read the CPU manufacturer's docs pretty >>> carefully to find out. (I've never seen it done, but that doesn't >>> necessarily mean it's impossible... SMM was never run in 64-bit mode in >>> the past, and I was told it was impossible, but now it's done regularly.) >>> >>> A big "gotcha" for 64-bit mode is that it requires writable page tables, >>> which requires generating the required tables in your cache-as-RAM in >>> 32-bit mode (which uses several 4k pages of space, unless you're really >>> clever about repurposing the unused table entries for other data) or >>> implementing a TLB miss handler. If you can map all addresses with >>> gigabyte-sized pages, and especially if you don't need to access the >>> entire address space before MRC, the tables shouldn't take that much >>> space. If you try to map a 2^46 address space with 4k pages, your >>> tables will never fit in cache-as-RAM.... >>> >>> You may need to switch back to 32-bit mode to exit cache-as-RAM... not >>> sure just what that dance would look like. It would probably take some >>> experimentation. >>> >>> There may be other issues I haven't thought of. Good luck! >>> -- >>> >>> Brian J. Johnson >>> >>> -------------------------------------------------------------------- >>> >>> "If you want your dreams to come true: Wake Up!" >>> -- Jaime Roman's Radio >>> >>> >> > ---------------------------------------------------------------------------- >> -- >>> See everything from the browser to the database with AppDynamics >>> Get end-to-end visibility with application monitoring from AppDynamics >>> Isolate bottlenecks and diagnose root cause in seconds. >>> Start your free trial of AppDynamics Pro today! >>> >> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >> > ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
