Well hopefully Intel has a better answer for you..... You could do a traditionally init of groups of sockets where memory starts at zero as part of PEI. Then at the start of DXE you could coalesce these sets of sockets into your single system image. I'm guessing this is easier to do in X64 as you don't need to muck about with the page table mapping and you don't have the risk of running out of 32-bit virtual address space.
It's probably possible to do a 2 stage thing in PEI too, but that would get more complex due to the 32-bit virtual address space limitation. So for example to write to a 64-bit register you might have to remap page tables, where in X64 you would just write to the register directly. The only way you could do this in a single step is to have some "other resource" that could contain your page tables. Something like a big SRAM or DRAM that just works when you power the system on. Thanks, Andrew Fish On Jul 23, 2013, at 4:11 PM, "stanley.ganyezu" <stanley.gany...@gmail.com> wrote: > Hi Andrew, > I introduce some background. Our plan is to build a big system with > many sockets. > There are so many sockets that there is no enough MMCFG space below 4Gb. So > we have to put these register at the top of physical space(Ivy bridge > support 46 bit) > We need to access these register to initialize memory. It means we can't > postpone to DXE phase. > > -----邮件原件----- > 发件人: Andrew Fish [mailto:af...@apple.com] > 发送时间: 2013年7月24日 0:22 > 收件人: stanley.ganyezu > 抄送: 'Brian J. Johnson'; edk2-devel@lists.sourceforge.net > 主题: Re: [edk2] switch to 64 bit mode at PEI phase in X86 > > 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/D > xeIplPeim/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
