Leif and Mark,
From my reading of Table 25 in the UEFI 2.4 spec, I think that the
following types should be considered when looking for the base of dram:
* EfiLoaderCode: The code portions of a loaded application. (Note that UEFI OS loadersare UEFI applications.) * EfiLoaderData: The data portions of a loaded application and the default data allocation type used by an application to allocate pool memory. * EfiBootServicesCode: The code portions of a loaded Boot Services Driver. * EfiBootServicesData: The data portions of a loaded Boot Serves Driver, and the default data allocation type used by a Boot Services Driver to allocate pool memory. * EfiRuntimeServicesCode: The code portions of a loaded Runtime Services Driver. * EfiRuntimeServicesData: The data portions of a loaded Runtime Services Driver and the default data allocation type used by a Runtime Services Driver to allocate pool memory. * EfiConventionalMemory: Free (unallocated) memory. * EfiACPIReclaimMemory: Memory that holds the ACPI tables. * EfiACPIMemoryNVS: Address space reserved for use by the firmware.
and the following should be ignored:
* EfiReservedMemoryType: Not used. * EfiUnusableMemory: Memory in which errors have been detected. * EfiMemoryMappedIO: Used by system firmware to request that a memory-mapped IO region be mapped by the OS to a virtual address so it can be accessed by EFI runtime services. * EfiMemoryMappedIOPortSpace: System memory-mapped IO region that is used to translate memory cycles to IO cycles by the processor. * EfiPalCode: Address space reserved by the firmware for code that is part of the processor.
Does this seem reasonable? Roy
On Tue, Jan 28, 2014 at 07:08:49PM -0800, Roy Franz wrote:
From my reading of Table 25 in the UEFI 2.4 spec, I think that the following types should be considered when looking for the base of dram:
Actually, to find the start of RAM we sort of have to go by attributes rather than type. For the memblock code, we use the write-back cacheable attribute, same as ia64.
If we can't allocate at the required offset from there - kaboom, regardless of what type other than EfiConventionalMemory is in the way.
At some point (not yet), we probably need to make the code handle a system that makes this impossible (at a cost of usable system RAM), but until we have shipping hardware products, I'm happy for a hard fault to serve as a warning to the unwise :)
/ Leif
-
Leif Lindholm -
Roy Franz