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

> On Sat, Nov 21, 2015 at 1:04 AM, Andrey Plankin via Syslinux
> <syslinux at zytor.com> wrote:
> > Hello,
> >
> > I'm booting linux-3.16-686-pae kernel (32-bit) via syslinux.efi
64-bit version.
> > After boot linux sees only 2.5G of RAM while system has 32G installed.
> 
> Why not use a 64-bit kernel with such a large machine?
> 
> Do you have the config used to build that kernel?  I'm specifically
> looking for any config line with "EFI" in it.
> 
> > If I boot the same kernel with GRUB64 efi instead of syslinux
> > then amount of RAM available to linux is 32G.
> >
> > Is this a bug or I'm missing something?
> 
> It's certainly unexpected behavior but booting a 32-bit kernel from a
> 64-bit EFI is also a little unexpected.  Syslinux will definitely try
> to use the EFI stub in the kernel to boot the kernel.  I can't speak
> for GRUB but it has done some forced behaviors in the past.
> 
> Could you post the memory map that Linux uses in both cases?  dmesg
> should be able to help.
> 
> > syslinux.cfg:
> >
> > label live-686-pae
> >         menu label Linux (686-pae)
> >         menu default
> >         linux /live/vmlinuz
> >         initrd /live/initrd.img
> >         append boot=live config persistence username=user
live-config.utc=no acpi_osi=Linux live-config.noautologin
> 
> Is this the entire file or just an excerpt?  If an excerpt, I'd wonder
> if there's any other stray APPEND.  What does your kernel show as the
> command line?
> 
> > Current git: e0be4d87135
> 
> So a build of Syslinux from that commit.
> 
> -- 
> -Gene
 
 
While we wait for a reply from Andrey...


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).

According to the report, both grub2 and Syslinux are booting this 
32-bit kernel; with the difference being somehow related to the PAE 
feature.

Without PAE, the kernel would be able to see less than 4GB of RAM. 
According to the report, grub2 somehow is being able to boot this 
kernel with its PAE feature enabled (thus, the kernel / OS sees the 
whole RAM) while syslinux.efi seems to "block" the potential 
availability of at least part of the available RAM.

Is there any assumption in syslinux.efi about the available RAM when 
booting mixed architecture / bitness kernels? Is there some kind of 
(RAM) limitation / assumption in syslinux.efi for 32-bit? Are PAE 
kernels actually supported by the EFI handover implementation in 
syslinux.efi? If I am not mistaken, these seem to be the key points to 
be reviewed.

Regards,
Ady.

PS: The EFI-related code in the Linux kernel (e.g. EFI handover 
protocol) has seen (additional) developments during the last 1.5~2 
years. Perhaps it's time to contact Matt Fleming, or at least to visit 
the current efi code and update the Syslinux's code accordingly / if 
needed?

Regards,
Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>

2015-11-26 16:39 UTC+01:00, Ady via Syslinux <syslinux at
zytor.com>:
>
>> On Sat, Nov 21, 2015 at 1:04 AM, Andrey Plankin via Syslinux
>> <syslinux at zytor.com> wrote:
>> > Hello,
>> >
>> > I'm booting linux-3.16-686-pae kernel (32-bit) via
syslinux.efi 64-bit
>> > version.
>> > After boot linux sees only 2.5G of RAM while system has 32G
installed.
>>
>> Why not use a 64-bit kernel with such a large machine?
>>
>> Do you have the config used to build that kernel?  I'm specifically
>> looking for any config line with "EFI" in it.
>>
>> > If I boot the same kernel with GRUB64 efi instead of syslinux
>> > then amount of RAM available to linux is 32G.
>> >
>> > Is this a bug or I'm missing something?
>>
>> It's certainly unexpected behavior but booting a 32-bit kernel from
a
>> 64-bit EFI is also a little unexpected.  Syslinux will definitely try
>> to use the EFI stub in the kernel to boot the kernel.  I can't
speak
>> for GRUB but it has done some forced behaviors in the past.
>>
>> Could you post the memory map that Linux uses in both cases?  dmesg
>> should be able to help.
>>
>> > syslinux.cfg:
>> >
>> > label live-686-pae
>> >         menu label Linux (686-pae)
>> >         menu default
>> >         linux /live/vmlinuz
>> >         initrd /live/initrd.img
>> >         append boot=live config persistence username=user
>> > live-config.utc=no acpi_osi=Linux live-config.noautologin
>>
>> Is this the entire file or just an excerpt?  If an excerpt, I'd
wonder
>> if there's any other stray APPEND.  What does your kernel show as
the
>> command line?
>>
>> > Current git: e0be4d87135
>>
>> So a build of Syslinux from that commit.
>>
>> --
>> -Gene
>
>
> While we wait for a reply from Andrey...
>
>
> 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.


Celelibi

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