search for: kernel_jump

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

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 segments have to be updated, but they are not > 3. Disabling paging has to be done before disabling long mod...

> 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 segments have to be updated, but they are not > 3. Disabling paging has to be done before disabling lon...

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

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

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 segments have to be updated, but they are not > 3. Disabling paging has to be done before disabling long mod...

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

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 segments have to be updated, but they are not > 3. Disabling paging has to be done before disabling long mod...

>>> > Have you tested it? > Have you checked that efi64 loading 64bit kernels is OK from a kernel_jump point of view? For a 32-bit kernel, I did. For a 64-bit kernel, I didn't but I see no reason it should failed. I will try just to be sure. <<< Unfortunately at the moment I cannot test your finding (probably Gene will). Now that you are immerse in the topic it would be great if y...

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

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.

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? >

...ent. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> --- efi/x86_64/linux.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/efi/x86_64/linux.S b/efi/x86_64/linux.S index 972c0b2..29dde94 100644 --- a/efi/x86_64/linux.S +++ b/efi/x86_64/linux.S @@ -27,7 +27,7 @@ kernel_jump: base_address: pop %rsi - /* need to perform a long jump to update cs + /* need to perform a long jump to update cs */ /* load absolute address of pm_code in jmp_address location */ lea (pm_code - base_address)(%rsi, 1), %rax -- 2.5.1

...even improving it for BIOS too ;). In the meantime, perhaps some suggested patches (regarding other issues) might deserve some attention / not-so-low priority? Recent examples: _ com32: write_sectors fixes http://www.syslinux.org/archives/2015-August/023962.html _ efi: leaving long mode in kernel_jump routine http://www.syslinux.org/archives/2015-August/023911.html (Somewhat self-centered, but not so much: I would also like to see the initial patches from Patrick about the CLI and lss16 being taken by someone so to improve them, after 3 years of patiently waiting.) To be clear, I do not k...

...com> Thanks, Paulo > --- > efi/x86_64/linux.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/efi/x86_64/linux.S b/efi/x86_64/linux.S > index 972c0b2..29dde94 100644 > --- a/efi/x86_64/linux.S > +++ b/efi/x86_64/linux.S > @@ -27,7 +27,7 @@ kernel_jump: > base_address: > pop %rsi > > - /* need to perform a long jump to update cs > + /* need to perform a long jump to update cs */ > > /* load absolute address of pm_code in jmp_address location > */ lea (pm_code - base_address)(%rsi, 1), %rax -- Paulo Alcantara,...

Updating myself again: On 07-08-15 16:03, Oscar Roozen wrote: > e466d24 still has an issue with png's in vesalinux causing crashes I can confirm this remaining crash is caused by the line "MENU BACKGROUND bootlogo.png". The original bootlogo.png is 640x480. Forcing the videomode with "MENU RESOLUTION 640 480" did not resolve the crashes, nor did resizing the png