On 09.12.2013 18:30, Leif Lindholm wrote: > Hi, > > The EFI memory management code contains a hard-wired limit restricting > physical (and virtual, all 1:1 mapped in UEFI) addresses to 32-bit. > While this may be the right thing to do on x86, and hasn't caused me > any issues on 32-bit ARM, I have received reports of at least two > upcoming 64-bit ARM platforms with no RAM in the lower 4GB of physical > address space. > > A simple fix would be to just stack the ifdefs, but a better one might > be to move the define to one of <cpu/efi/memory.h> (which is currently > a dummy for all platforms, simply including <efi/memory.h>) or types.h. > cpu/efi/memory.h is a possibility. cpu/types.h isn't because it's, at least partially, EFI limitation (due to EFI bugs), not CPU. Real restrictions is a mix of unrelated restriction but it seem to align well with CPU. Increasing it beyond 0xffffffff will need chacking that efi/mm.c can handle it without overflow. The limits are: -0xffffffff on 32-bit platforms due to address space size (i386, arm) -0x7fffffff when x86_64 compiled without -mcmodel=large due to compiler assumptions -0xffffffff on x86_64 because some EFI implementations don't map memory above 4G contrary to spec. - On ia64 it's probably unlimited but I didn't test and there is always a danger of EFI bugs similar to x86_64 one, so better to be conservative about it - arm64. You're the expert. > --- a/include/grub/i386/types.h > +++ b/include/grub/i386/types.h > @@ -25,6 +25,12 @@ > /* The size of long. */ > #define GRUB_TARGET_SIZEOF_LONG 4 > > +#if defined (__code_model_large__) > +#define MAX_USABLE_ADDRESS 0xffffffff > +#else > +#define MAX_USABLE_ADDRESS 0x7fffffff > +#endif > + Should be MAX_USABLE_ADDRESS 0xffffffff
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel