Hi Bill! Thanks a lot for your reply! I'll try it in some tests here!
Cheers, Fernando J V da Silva 2014-03-03 17:55 GMT-03:00 Bill Paul <[email protected]>: > Of all the gin joints in all the towns in all the world, Fernando J V da Silva > had to walk into mine at 12:32:44 on Monday 03 March 2014 and say: > >> Hi all! >> >> I've been porting an UEFI application for an ATOM IA32 processor (32 >> bits) but I've >> a question regarding memory: Is it possible to access more than 4GB of >> memory in a 32 bit UEFI application? (Physical Address Extension). >> >> If so, what is the most appropriate way to point to a address above >> 4GB? (BTW, any pointer in 32 bit couldn't directly access anything >> beyond 4GB, so how could I behave in this case?). > > The general answer to this is that you need to create a temporary mapping > using the MMU. Your pointers are always limited to 32-bits -- meaning you can > never access more than 4GB of address space at a time -- but you can set up > page table entries such that a portion of the 32-bit virtual address space is > translated to a physical memory region beyond 4GB. > > Basically this creates a window into the extended memory. You can "slide the > window" to access different regions, if necessary. > > As to whether or not you can do this in a UEFI application, I *think* you can, > using the gBS->AllocatePages() and gBS->FreePages() boot service APIs. These > allow you to allocate pages at a specific EFI_PHYSICAL_ADDRESS, which is 64 > bits wide on both 32-bit and 64-bit UEFI builds. These services are documented > in the UEFI specification. > > Tread carefully. :) > > -Bill > >> Thanks in advance! >> >> Fernando J V da Silva >> >> --------------------------------------------------------------------------- >> --- Subversion Kills Productivity. Get off Subversion & Make the Move to >> Perforce. With Perforce, you get hassle-free workflows. Merge that >> actually works. Faster operations. Version large binaries. Built-in WAN >> optimization and the freedom to use Git, Perforce or both. Make the move >> to Perforce. >> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktr >> k _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > -- > ============================================================================= > -Bill Paul (510) 749-2329 | Senior Member of Technical Staff, > [email protected] | Master of Unix-Fu - Wind River Systems > ============================================================================= > "I put a dollar in a change machine. Nothing changed." - George Carlin > ============================================================================= ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
