similar to: [PATCH 1/1] linux.c32: Fix initrd alignment

On 12/04/2013 12:38 AM, Christian Hesse wrote: > > Sure. Here we go: > > boot: debug -e bios_boot_linux calc_cmdline_offset > boot: ipxe.lkrn > Loading ipxe.lkrn... ok > cmdline_offset at 0x9f7e0 > Initial memory map: > Could not find location for protected-mode code > Booting kernel failed: Invalid argument > OK, that was a useful clue. I think I know what is

Some kernel images use the Linux kernel boot protocol and header structure, but do not actually have any protected-mode code. For instance, grub's 1024-byte lnxboot.img consists of 1024 real-mode bytes and 0 protected-mode bytes; you can concatenate it with a full grub core.img to produce a self-contained bootable kernel, but you can also use it standalone as the kernel with the core.img

Correct base's type to match its initialization from prot_mode_base and passage to syslinux_memmap_find(). Tested with extlinux. Signed-off-by: Scot Doyle <lkml14 at scotdoyle.com> --- com32/lib/syslinux/load_linux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..ac73729 100644 ---

On 07/26/2013 01:27 AM, syslinux-bot for Matt Fleming wrote: > diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c > index 851d467..37c8df0 100644 > --- a/com32/lib/syslinux/load_linux.c > +++ b/com32/lib/syslinux/load_linux.c > @@ -125,10 +125,29 @@ static int map_initramfs(struct syslinux_movelist **fraglist, > } > > static size_t

On Fri, Jun 10, 2016 at 2:06 AM, Adam Goldman via Syslinux <syslinux at zytor.com> wrote: > PXELINUX has stopped recognizing the keeppxe option on the kernel > command line. Here is a patch to make it work again. > > With COM32, it is no longer possible to use preprocessor directives to > determine the SYSLINUX variant. The code inside the #if will never be > compiled. So,

On 07/29/2013 06:28 AM, Matt Fleming wrote: > On Fri, 26 Jul, at 09:49:28AM, H. Peter Anvin wrote: >> Hmm... this might constrain the heap excessively if the SMT_TERMINAL >> cutoff is at the wrong place (because there will be just enough SMT_FREE >> to fit.) I'm wondering if we shouldn't use the highest of these two >> regions. > > Could you give an

Hi, in syslinux-386, I think I've found a problem in com32/lib/syslinux/load_linux.c that leads to cmdline being truncated unnecessarily when e.g. linux.c32 is used. The patch below fixes the problem for me. But I don't know, whether the patch is safe in all cases. I tried to reproduce the logic found in runkernel.inc, but I might have missed something. So, feel free to tell me

On Fri, 26 Jul, at 09:49:28AM, H. Peter Anvin wrote: > Hmm... this might constrain the heap excessively if the SMT_TERMINAL > cutoff is at the wrong place (because there will be just enough SMT_FREE > to fit.) I'm wondering if we shouldn't use the highest of these two > regions. Could you give an example memory map where this would be a problem? I not sure I understand what

If the kernel is relocatable and the protected mode code will not fit in the initially determined location, that code will be moved to the next available location. However, beginning with commit 8f470e7b, the code is moved to the initially determined location instead of the next available location because prot_mode_base is no longer updated to the correct location. Since whdr->code32_start is

PXELINUX has stopped recognizing the keeppxe option on the kernel command line. Here is a patch to make it work again. With COM32, it is no longer possible to use preprocessor directives to determine the SYSLINUX variant. The code inside the #if will never be compiled. So, I changed it to use syslinux_filesystem() to determine the variant. Also, I moved the relevant code from

"H. Peter Anvin" <hpa at zytor.com> on Tue, 2013/12/03 20:26: > On 10/24/2013 01:09 AM, Christian Hesse wrote: > >>> > >>> version 6.02-pre5 works, 6.02-pre6 does not. > >> > >> Struggled with git bisect, but finally succeeded: > >> > >> 8f470e7bfe75f6401f6c5432988c620b863ad274 is the first bad commit > >>

gfxboot uses those three calls, but currently doesn't really handle returns from them. syslinux_boot_linux (lib/syslinux/load_linux.c) can return ("bail" label). syslinux_local_boot (lib/syslinux/localboot.c) has a comment which says "returns only on failure". The documentation for "Local boot" in doc/comboot.txt says "Does not return". Which is correct?

On Fri, Feb 20, 2015 at 8:08 AM, Patrick Masotta via Syslinux <syslinux at zytor.com> wrote: > This patch adds to the core EFI image booting capabilities. > It was tested on VMware EFI clients and HP Elitebook EFI notebooks, > only on PXE environments but it should work on non-PXE scenarios as well. > > Feedback appreciated. If you've made any changes to this, I'd

"syslinux-bot for H. Peter Anvin" <hpa at zytor.com> on Wed, 2013/12/04 12:39: > Commit-ID: ef81a3ad54845ffb5ad62714cd62db4740ad5cff > Gitweb: > http://www.syslinux.org/commit/ef81a3ad54845ffb5ad62714cd62db4740ad5cff > Author: H. Peter Anvin <hpa at zytor.com> AuthorDate: Wed, 4 Dec 2013 > 12:35:09 -0800 Committer: H. Peter Anvin <hpa at zytor.com>

> On Mon, Nov 23, 2015 at 3:06 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > It saddens (me) > > > C'mon; really? > > As you asked. > > -- > -Gene I appreciate the replies. Hopefully someone might be able to come up with some contribution / answer. The Syslinux code has already received at some point some patches regarding the EFI

We want to be able to guarantee the location of the allocated buffer object if we're going to be able to reliably allocate the existing framebuffer at startup. Add an argument to do so and pass that through to the ttm core. Signed-off-by: Matthew Garrett <mjg at redhat.com> --- drivers/bcma/main.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++++++-

On 03/19/2014 01:30 PM, Gene Cumm wrote: > On Wed, Mar 19, 2014 at 4:16 PM, Mau Z <zmau1962 at gmail.com> wrote: >> Hi, >> >> I am wondering how to implement the following customer's requirement : >> The system is a stand alone embedded system with no operator (with Linux). >> There is one SSD for the system's usage (and that is where the system loads

Hi, It is possible for some BIOSes to return non-page-aligned values for the start and length of regions in the BIOS memory map (through int 15h, e820h). As a result, the initrd is loaded by linux.c32 (a provided com32 module) in a manner such that the last page contains both a portion of initrd and some BIOS data. The linux kernel treats this page as part of the ramdisk file system and ends up

> > kernel.c:new_linux_kernel() to load_linux.c:bios_boot_linux() because > > there is no convenient way in new_linux_kernel() to control the boot > > flags value. > > This is the part that has me questioning things and trying to recall > if any other KERNEL-like directives ever utilize keeppxe. > @Gene, Not being a developer myself, I don't understand this

This patch adds to the core EFI image booting capabilities. It was tested on VMware EFI clients and HP Elitebook EFI notebooks, only on PXE environments but it should work on non-PXE scenarios as well. Feedback appreciated. Best, Patrick Signed-off-by: Patrick Masotta <masottaus at yahoo.com> --- diff -uprN a/com32/elflink/ldlinux/execute.c b/com32/elflink/ldlinux/execute.c ---