search for: config_efi_mix

...ent 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 th...

...s than 1gB RAM. X64 systems should be able to run 32bit kernels as > well. i tried it. show up finding kernel and initrd with ok .. and > crashes thereafter. > > questions: > - should it be possible to boot a 32bit kernel on X64 systems? If the x86 (IA32) kernel was built with CONFIG_EFI_MIXED enabled (among the other "typical" settings), then the answer should in theory be "yes", although, I would recommend using version 6.04-pre1 or newer of Syslinux. > - if yes - can it be done using syslinux UEFI as already setup? I don't see why not. Moreover,...

hi i was creating a boot stick for BIOS years ago, which still is working - of course. need just update kernels. i now need to set up new linux laptops. as i do not want to run into troubles i do intend to create a new stick for UEFI. do not mix BIOS/UEFI on one device. once again nothing fancy. prompt and say will do. was reading all available text about best solution. i so prepared a

..., the kernel config should include: CONFIG_RELOCATABLE=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_FB_EFI=y CONFIG_FRAMEBUFFER_CONSOLE=y For UEFI ia32 firmware, it should be possible (in theory, and if I understand correctly) to use 32 bit Syslinux to load a 64 bit kernel, as long as the latter has CONFIG_EFI_MIXED enabled. We have seen reports of failure to boot relocatable kernels when they are not built using also (some of) the other config settings. Even when we are now talking about booting in CSM mode, perhaps the relocatable kernel needs all these config settings so to be bootable by current Sys...

...FIG_RELOCATABLE=y > CONFIG_EFI=y > CONFIG_EFI_STUB=y > CONFIG_FB_EFI=y > CONFIG_FRAMEBUFFER_CONSOLE=y > > For UEFI ia32 firmware, it should be possible (in theory, and if I > understand correctly) to use 32 bit Syslinux to load a 64 bit kernel, > as long as the latter has CONFIG_EFI_MIXED enabled. > > We have seen reports of failure to boot relocatable kernels when they > are not built using also (some of) the other config settings. > > Even when we are now talking about booting in CSM mode, perhaps the > relocatable kernel needs all these config settings so...

...both 32-bit and 64-bit kernels, got the same problem, that is, nothing after "Loading vmlinuz... ok". I took a punt on something. From the docs, I thought that the kernel parameter CONFIG_EFI_STUB is not required. However, I set it: CONFIG_EFI_PARTITION=y CONFIG_EFI=y CONFIG_EFI_STUB=y CONFIG_EFI_MIXED=y CONFIG_FB_EFI=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_EFI_VARS=m # CONFIG_EFIVAR_FS is not set CONFIG_EARLY_PRINTK_EFI=y For a generic x86-64 kernel, after the "Loading vmlinux... ok", I now get kernel logging to the screen. It has a kernel panic as cannot run init, but t...

On Fri, 6 Feb 2015, Ady wrote: > ... > But if we are talking about Chromebooks with SeaBIOS, are we talking > about booting kernels in CSM mode? Or in UEFI mode? > > Other than Chromebooks with (stock) SeaBIOS, is this new reported > behavior also seen under other cases / hardware / firmware / kernels > (versions)? Hi Ady, With a clone of the git repo on kernel.org I run

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:

> I have done another install to the usb stick. > > # syslinux --directory EFI/BOOT --install /dev/sdc1 > > ...this creates files ldlinux.c32 and ldlinux.sys in /EFI/BOOT > > I then mounted the 1st partition of the usb stick and copied > syslinux.efi and ldlinux.e64 from /usr/share/syslinux/efi64 to > /EFI/BOOT in the usb stick. > > I renamed syslinux.efi to

...gt; Are there any obvious errors there? Where is the proper formal syntax listed? A previous mail sounds interesting/applicable: >..... > If the _firmware_ is UEFI x64, then use the adequate syslinux.efi file, > plus ldlinux.e64. With that bootloader, you should be able to load a > (CONFIG_EFI_MIXED-enabled) Linux kernel for x86 (IA32) or for x86_64 > (X64). > If the _firmware_ is UEFI x64, then the syslinux.efi file for x86 > (IA32) won't boot in such system (and it is not needed, nor intended > for such platform). > BTW, it is possible to use a mix of SYSLINUX (for BI...

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

...> > CONFIG_EFI_STUB=y > > CONFIG_FB_EFI=y > > CONFIG_FRAMEBUFFER_CONSOLE=y > > > > For UEFI ia32 firmware, it should be possible (in theory, and if I > > understand correctly) to use 32 bit Syslinux to load a 64 bit kernel, > > as long as the latter has CONFIG_EFI_MIXED enabled. > > > > We have seen reports of failure to boot relocatable kernels when they > > are not built using also (some of) the other config settings. > > > > Even when we are now talking about booting in CSM mode, perhaps the > > relocatable kernel needs...

...c) + .word boot_idt_end - boot_idt + .quad 0 +SYM_DATA_END(boot_idt_desc) + .balign 8 +SYM_DATA_START(boot_idt) + .rept BOOT_IDT_ENTRIES + .quad 0 + .quad 0 + .endr +SYM_DATA_END_LABEL(boot_idt, SYM_L_GLOBAL, boot_idt_end) + #ifdef CONFIG_EFI_STUB SYM_DATA(image_offset, .long 0) #endif - #ifdef CONFIG_EFI_MIXED SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0) SYM_DATA(efi_is64, .byte 1) diff --git a/arch/x86/boot/compressed/idt_64.c b/arch/x86/boot/compressed/idt_64.c new file mode 100644 index 000000000000..46ecea671b90 --- /dev/null +++ b/arch/x86/boot/compressed/idt_64.c @@ -0,0 +1,43 @@ +// SPDX-Lic...

...END_LABEL(gdt, SYM_L_LOCAL, gdt_end) +SYM_DATA_START(boot_idt_desc) + .word boot_idt_end - boot_idt + .quad 0 +SYM_DATA_END(boot_idt_desc) + .balign 8 +SYM_DATA_START(boot_idt) + .rept BOOT_IDT_ENTRIES + .quad 0 + .quad 0 + .endr +SYM_DATA_END_LABEL(boot_idt, SYM_L_GLOBAL, boot_idt_end) + #ifdef CONFIG_EFI_MIXED SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0) SYM_DATA(efi_is64, .byte 1) diff --git a/arch/x86/boot/compressed/idt_64.c b/arch/x86/boot/compressed/idt_64.c new file mode 100644 index 000000000000..46ecea671b90 --- /dev/null +++ b/arch/x86/boot/compressed/idt_64.c @@ -0,0 +1,43 @@ +// SPDX-Licens...

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. 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? syslinux.cfg: label live-686-pae menu label Linux (686-pae) menu

Hi, This is a proof of concept of GPU forwarding for Linux guest on Linux host. I'd like to get comments and suggestions from community before I put more time on it. To summarize what it is: 1. It's a solution to bring GPU acceleration for Linux vm guest on Linux host. It could works with different GPU although the current proof of concept only works with Intel GPU. 2. The basic idea

This patch series aims to move the logical block size checking to the block code. This was inspired by missing check for valid logical block size in virtio-blk which causes the kernel to crash in a weird way later on when it is invalid. I added blk_is_valid_logical_block_size which returns true iff the block size is one of supported sizes. I added this check to virtio-blk, and also converted

This patch series aims to move the logical block size checking to the block code. This was inspired by missing check for valid logical block size in virtio-blk which causes the kernel to crash in a weird way later on when it is invalid. I added blk_is_valid_logical_block_size which returns true iff the block size is one of supported sizes. I added this check to virtio-blk, and also converted

Hi, here is the next version of changes to enable Linux to run as an SEV-ES guest. The code was rebased to v5.7-rc3 and got a fair number of changes since the last version. What is SEV-ES ============== SEV-ES is an acronym for 'Secure Encrypted Virtualization - Encrypted State' and means a hardware feature of AMD processors which hides the register state of VCPUs to the hypervisor by

Hi, here is the next version of changes to enable Linux to run as an SEV-ES guest. The code was rebased to v5.7-rc3 and got a fair number of changes since the last version. What is SEV-ES ============== SEV-ES is an acronym for 'Secure Encrypted Virtualization - Encrypted State' and means a hardware feature of AMD processors which hides the register state of VCPUs to the hypervisor by