Displaying 20 results from an estimated 1000 matches similar to: "[PATCH] efi: leaving long mode in kernel_jump routine"
2015 Aug 23
0
[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. Other
2015 Aug 24
1
[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.
2015 Sep 11
2
[PATCH 1/1] efi/x86_64: fix trivial compilation warning
From: Sylvain Gault <sylvain.gault at gmail.com>
Missing */ at the end of a comment.
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:
2015 Aug 08
2
[PATCH] efi: leaving long mode in kernel_jump routine
>>>
> 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
2015 Sep 11
0
[PATCH 1/1] efi/x86_64: fix trivial compilation warning
On Fri, 11 Sep 2015 03:59:09 +0200
celelibi--- via Syslinux <syslinux at zytor.com> wrote:
> From: Sylvain Gault <sylvain.gault at gmail.com>
>
> Missing */ at the end of a comment.
>
> Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com>
Reviewed-by: Paulo Alcantara <pcacjr at zytor.com>
Thanks,
Paulo
> ---
> efi/x86_64/linux.S | 2 +-
>
2015 Aug 23
0
[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. Other
2015 Aug 31
1
[PATCH] efi: leaving long mode in kernel_jump routine
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.
2015 Sep 08
0
[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. Other
2015 Aug 04
2
[PATCH] efi: leaving long mode in kernel_jump routine
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 Aug 04
2
[PATCH] efi: leaving long mode in kernel_jump routine
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
2015 Aug 08
0
[PATCH] efi: leaving long mode in kernel_jump routine
> 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
2015 Aug 04
0
[PATCH] efi: leaving long mode in kernel_jump routine
>>>
> 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
2015 Aug 04
0
[PATCH] efi: leaving long mode in kernel_jump routine
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
2015 Aug 04
0
[PATCH] efi: leaving long mode in kernel_jump routine
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
2015 Aug 05
0
[PATCH] efi: leaving long mode in kernel_jump routine
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
2015 Aug 11
0
[PATCH] efi: leaving long mode in kernel_jump routine
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.
2015 Sep 16
2
[PATCH 0/4] efi: Makefile improvement
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
2018 Oct 30
1
EFI 64bit and Kernel 32 bit
Thank you for the info,
I tested the latest version Syslinux 6.03 (64 bit) and it didn't work.
the boot loader text shows up, then the screen freezes.
maybe it works only on some specific boards/CPUs.
Thank you for the reply's, the problem is now solved by using another
Bootloader.
Best Regards,
On 29.10.18 15:29, Letan Thomas wrote:
> I was able to successfully boot 32-bit
2018 Oct 18
3
EFI 64bit and Kernel 32 bit
Hello Ady
thank you very much for the accurate reply and for saving my time :-)
Best Regards,
On 17.10.18 18:06, Ady Ady via Syslinux wrote:
>> is it possible to boot a 32 Bit Kernel on 64 EFI firmware with Syslinux?
>
> In theory, booting 32-bit kernels from 64-bit EFI is supposed to be
> supported by "efi64/efi/syslinux.efi" since 2013Jun.
>
> In practice:
2017 Nov 17
0
[RFC PATCH v2 4/5] ACPI/IORT: Support paravirtualized IOMMU
To describe the virtual topology in relation to a virtio-iommu device,
ACPI-based systems use a "paravirtualized IOMMU" IORT node. Add support
for it.
This is a RFC because the IORT specification doesn't describe the
paravirtualized node at the moment, it is only provided as an example in
the virtio-iommu spec. What we need to do first is confirm that x86
kernels are able to use the