similar to: [PATCH] efi: leaving long mode in kernel_jump routine

> On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2.

>>> > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other segments have to be updated, but they are not > 3. Disabling paging has to be

> Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other segments have to be updated, but they are not > 3. Disabling paging has to be done before

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

2015-08-23 20:09 UTC+02:00, Gene Cumm via Syslinux <syslinux at zytor.com>: > On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux > <syslinux at zytor.com> wrote: >> Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux >> leaves long mode in kernel_jump assembly routine does not follow AMD64 >> specifications. More precisely: >> 1.

On Tue, Aug 4, 2015 at 2:55 AM, Thomas Letan via Syslinux <syslinux at zytor.com> wrote: > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux > leaves long mode in kernel_jump assembly routine does not follow AMD64 > specifications. More precisely: > 1. After setting a new GADT, `cs` has to be refresh by doing a long > jump, but it is not > 2. Other

Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. The way Syslinux leaves long mode in kernel_jump assembly routine does not follow AMD64 specifications. More precisely: 1. After setting a new GADT, `cs` has to be refresh by doing a long jump, but it is not 2. Other segments have to be updated, but they are not 3. Disabling paging has to be done before disabling long mode, but the

Hi, Thomas Letan via Syslinux wrote (04 Aug 2015 06:55:48 GMT) : > Syslinux 6.03 (efi64) fails to boot a 32-bit kernel. Maybe I'm missing something, but this has been working flawlessly for us in Tails so far. What exactly fails? Cheers, -- intrigeri

Hi! Sorry for not responding earlier. I was planning to but I lack time. > AFAIK it seems this patch is even necessary for new kernels in the case > EFI64 boots a 32 Bit kernel, right? I think it is, yes. I will try to do more test myself. I hope I will be able to tell more this week.

Hi > Maybe I'm missing something, but this has been working flawlessly for > us in Tails so far. What exactly fails? Are you using EFI Handover Protocol? It might explain the difference Thomas

Thomas Letan via Syslinux wrote (04 Aug 2015 09:27:38 GMT) : > Are you using EFI Handover Protocol? What we're doing is: label livefailsafe menu label Live (failsafe) kernel /live/vmlinuz2 append initrd=/live/initrd2.img boot=live config live-media=removable apparmor=1 security=apparmor nopersistent noprompt timezone=Etc/UTC block.events_dfl_poll_msecs=1000 splash noautologin

Hi > The effect was simply that the (physical) machine rebooted exactly on > the wrmsr instruction. The result of my investigation was that the > code wasn't following the protocol (by intel and by AMD) for leaving > long mode as pointed out by Thomas Letan. Indeed it's exactly that! > I think qemu and some processors are just more permissive and allow > the current

Actually your Syslinux config is less relevant than the kernel config file. Indeed Syslinux infers the method to use from the kernel image itself. I assume the .config is public. I will take a look as soon as I can Thomas Le 04/08/2015 14:09, intrigeri via Syslinux a ?crit : > Thomas Letan via Syslinux wrote (04 Aug 2015 09:27:38 GMT) : >> Are you using EFI Handover Protocol? >

2015-09-14 14:15 UTC+02:00, Patrick Masotta <masottaus at yahoo.com>: >>>> > These few patches contain a few improvement about the > Makefiles for EFI. Mainly, to rebuild the files when needed, and only when > needed. The three shell scripts efi/{check,build,clean}-gnu-efi.sh > disappeared and > are now integrated as makefile recipes. > <<< >

2015-11-30 14:14 UTC+01:00, Patrick Masotta <masottaus at yahoo.com>: >>>> >> The addition of the EFI_BUILD variable inside Makefiles could potentially >> affect scripts such as package builders, perhaps even the way the >> official (pre)release archives are built(?). > <<< > > I think the -mno-red-zone thing is a good catch, the rest of EFI

On Sat, Jan 10, 2015 at 5:44 AM, Patrick Masotta <masottaus at yahoo.com> wrote: >> I use Syslinux 6.03 EFI64 on a VMware Workstation 10 VM on >> 10.0.2 on Linux. >> > w/o any problem? Yes. > Me too, I just send the ""corresponding"" syslinux.efi >> Are they actually transferring the syslinux.efi files? > > sure > >> What

> I use Syslinux 6.03 EFI64 on a VMware Workstation 10 VM on > 10.0.2 on Linux. > w/o any problem? >> correctly sends back w/o error the "corresponding" syslinux.efi >> "EFI BC" -> EFI64\syslinux.efi >> "EFI IA32"-> EFI32\syslinux.efi >I only send back 1 filename. > Me too, I just send the

On mageia I'm using the following patch https://svnweb.mageia.org/packages/cauldron/syslinux/current/SOURCES/syslinux-nogit.patch?revision=600959&view=markup If it does solve your issue to, I could try pushing it into the repo. 2015-09-16 8:44 GMT+02:00 Thomas Letan via Syslinux <syslinux at zytor.com>: > Hi. > > Sometimes, it may happen that we do not want to clone a

On Mon, Mar 10, 2014 at 8:50 PM, Spike White <spikewhitetx at gmail.com> wrote: > There are no pre-compiled binaries (official or otherwise) on kernel.org. The Syslinux archives at kernel.org are source and binary. Extract them and you'll see. > I assume what is meant is > https://www.kernel.org/pub/linux/utils/boot/syslinux/ > At least, that is where the