Syslinux - Nov 2015 - Only 2.5G of RAM available when syslinux64.efi boots 32-bit linux 686-pae

On Mon, Nov 23, 2015 at 3:06 PM, Ady via Syslinux <syslinux at zytor.com>
wrote:
> It saddens (me)
> C'mon; really?
As you asked.

-- 
-Gene

> On Mon, Nov 23, 2015 at 3:06 PM, Ady via Syslinux <syslinux at
zytor.com> wrote:
> 
> > It saddens (me)
> 
> > C'mon; really?
> 
> As you asked.
> 
> -- 
> -Gene
 
I appreciate the replies. Hopefully someone might be able to come up with 
some contribution / answer.

The Syslinux code has already received at some point some patches 
regarding the EFI handover protocol. Considering that the EFI handover 
protocol has evolved during time [1], I would not be surprised that the 
Syslinux code would need some update, either for the EFI handover 
protocol or for the EFISTUB code.

Please note that the case presented in this email thread makes reference 
to a "3.6" 32-bit PAE kernel, while the current latest EFI handover 
protocol got updated after that, in later kernel versions (at least 
kernel v.3.8).

Quote:
"Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension 
fields to struct boot_params for loading bzImage and ramdisk above 4G in 
64bit."

Question for (kernel) developers: Could APPENDing the "add_efi_memmap"
kernel option be involved in allowing the whole RAM to be seen by a 
32-bit PAE kernel (booted by syslinux.efi X64)?

Quote:
"add_efi_memmap include EFI memory map of available physical RAM"


As of today, the "Extensible Firmware Interface kernel tree" [2] 
repository (maintained by Matt Fleming) has been receiving updates up 
until this same week (incidentally, including updates to the 
documentation regarding the "EFI memory region"). A somewhat
rhetorical
question: when was the last time the related code in Syslinux was patched 
(see [3])? A potential need to update the Syslinux code regarding this 
matter should not be a complete surprise.

Considering that the PAE feature for 32-bit kernels should allow 
allocations of RAM > 2^32 (~4GB) even in EFI, isn't it possible that the 
Syslinux code might be mixing / missing some variable (type)?

Isn't it possible that we are assuming that a UEFI x64 system with more 
than 4GB of RAM would not be (ever) booting a 32-bit PAE kernel, and 
thus, we would not be contemplating such case in the code?

FWIW (or, as generic examples, or of potential interest)...

Although not necessarily / explicitly covering our current particular 
case, the following email thread (2014Mar) is about "EFI mixed mode". 
Incidentally, "PAE" is also part of the conversation:
 http://thread.gmane.org/gmane.linux.kernel.efi/3580 

I cannot help but wonder whether a set of patches under the title "EFI 
urgent fixes" might have some importance for the Syslinux code (at least 
tangentially):
 https://lkml.org/lkml/2014/7/14/323 


I am hopping someone might eventually be able to find the source of the 
problem in Syslinux.

TIA,
Ady.

 [1] :
 https://www.kernel.org/doc/Documentation/x86/boot.txt 

 [2] Extensible Firmware Interface kernel tree :
 https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/ 

 [3]:
 efi/x86_64: leave long mode properly :
 repo.or.cz/syslinux.git/commit/ae853e99a7aed22cb28b387e1e3cb32dbf1ab8fa 

 com32/lib/syslinux/load_linux.c: update prot_mode_base :
 repo.or.cz/syslinux.git/commit/0a2dbb3392ee710838bea6bda80d4daad6b54780 

 load_linux: correct a type :
 repo.or.cz/syslinux.git/commit/83aad4f69065509ba5b1c080edccfed316a4cff0 
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

> Please note that the case presented in this email thread makes reference 
> to a "3.6" 32-bit PAE kernel, while the current latest EFI
handover
> protocol got updated after that, in later kernel versions (at least 
> kernel v.3.8).
> 
> Quote:
> "Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension 
> fields to struct boot_params for loading bzImage and ramdisk above 4G in 
> 64bit."
> 
> Question for (kernel) developers: Could APPENDing the
"add_efi_memmap"
> kernel option be involved in allowing the whole RAM to be seen by a 
> 32-bit PAE kernel (booted by syslinux.efi X64)?
> 
> Quote:
> "add_efi_memmap include EFI memory map of available physical RAM"
> 
 
Sorry, I misremembered; the report was about kernel 3.16, not 3.6. This 
makes the situation even worse, considering that 3.16 should comply to 
the latest EFI handover protocol and to the latest EFISTUB, so the 
problem is even more focused on the Syslinux code.