[syslinux] Only 2.5G of RAM available then syslinux64.efi boots 32-bit linux 686-pae

[H. Peter Anvin]

On 11/26/15 21:44, Celelibi via Syslinux wrote:
>>
>> According to the report, syslinux.efi X64 is successfully booting the
>> 32-bit kernel. In theory, this should / would mean that the kernel was
>> built with CONFIG_EFI_MIXED, among others.
>>
>> As far as I know, the EFISTUB code doesn't know how to boot a kernel
>> with a different architecture / bitness than the firmware. If this is
>> (still) correct, then syslinux.efi X64 should be using the (latest) EFI
>> handover protocol to be able to boot this 32-bit kernel (not the
>> EFISTUB code).
> 
> In case of mixing 32/64 bits firmware vs. kernel, the handover
> protocol isn't used at all (at least shouldn't be, the code is written
> that way). It falls back to the legacy booting method where there's
> nothing much to do regarding the memory management. So any change to
> the EFI stub in the Linux kernel should be irrelevant here.
> 
> However, I see here a definition that is never used.
> http://repo.or.cz/syslinux.git/blob/e0be4d87135b2e7dd55e028eabad10887dcf539d:/efi/x86_64/linux.S#l14
> So, maybe there's something not implemented yet.
> 

For 64-bit kernels, with CONFIG_EFI_MIXED, there is now two EFI stubs in
the kernel, one for 32-bit and one for 64-bit EFI.  That assumes the
bootloader knows about the dual stubs, of course.

However, there is no support for CONFIG_EFI_MIXED on 32 bit kernels, so
this 32-bit kernel is entered via the legacy path.

What seems clear is that *something* is filtering out the entries about
memory > 4 GiB and forgetting about them, which is almost certainly
related to 32-bitness.  Since this is legacy path, this means this is an
issue in Syslinux how we set up the memory map for a 32-bit kernel on
EFI64...

	-hpa