similar to: Fair warning regarding the future of the COM32 format

From: Tim Deegan <Tim.Deegan at cl.cam.ac.uk> Fix register constraints of final jump to kernel entry. When compiled with some GCC versions, mboot.c32 would clobber the kernel load address and try to jump to 0x2badb002. Signed-off-by: Tim Deegan <Tim.Deegan at cl.cam.ac.uk> --- --- syslinux-3.20-pre8/com32/modules/mboot.c.orig 2006-05-22 11:06:17.000000000 +0100 +++

On Thu, Oct 5, 2017 at 11:48 AM, Tu Do via Syslinux <syslinux at zytor.com> wrote: > Hi list, > > I ran a syslinux drive on a QEMU machine with a gdbstub opened. I tried the simplest modules: the hello.c in com32/samples/ directory, which is compiled into hello.c32 in bios/com32/samples/. I already compiled the module with debug info attached via -g option added to CFLAGS in the

Hi list, I ran a syslinux drive on a QEMU machine with a gdbstub opened. I tried the simplest modules: the hello.c in com32/samples/ directory, which is compiled into hello.c32 in bios/com32/samples/. I already compiled the module with debug info attached via -g option added to CFLAGS in the Makefile. However, the problem is that the generated module is a shared dynamic module, which only

Hi Everyone, This question might be a long shot, but is it possible to mix and match com32 programs written against Syslinux 3 with com32 programs written against Syslinux 4 without recompiling. We are trying to have our com32 programs run with different versions of Syslinux without modification. Appreciate any advice, thanks in advance.

Hello, I'm having trouble PXE booting the Xen hypervisor kernel as follows: PXELINUX 3.31 0x4518b206 Copyright (C) 1994-2005 H. Peter Anvin UNDI data segment at: 00094FC0 UNDI data segment size: 4A30 UNDI code segment at: 000999F0 UNDI code segment size: 44E4 PXE entry point found (we hope) at 999F:00D6 My IP address seems to be 0A000063 10.0.0.99

Hello, I use Tim's mboot.c32 to load multiboot kernels over pxelinux. However, some kernels require the symbol table and other information in the ELF section header table to be able to load properly. This functionality is not present in mboot.c now, so I added support for it. The patch is attached. It would be great if you can push this into the next release of syslinux so ELF multiboot

Hi, Matt Fleming wrote: > ld: libpng/pngrtran.o: warning: relocation against `png_do_read_filler' in readonly section `.text'. > ld: warning: creating a DT_TEXTREL in object. > > Looks like your files aren't position-independent. What does, > > file com32/gpllib/dmi/dmi.o > > say? # file com32/gpllib/dmi/dmi.o com32/gpllib/dmi/dmi.o: ELF 32-bit LSB

I'm seeing this on a HP Blade and i'm not sure why this is happning since the nature of the issue is so wierd. I compiled mboot.c with a DEBUG defined in the mboot.c file. In the funciton init_mmap(), it prints the e820 map and on the HP blade this map values come out to be totally random. Some weird numbers which dont make any sense at all. However, if i add a while(1); or a exit(1); at

Hi! Using the following extlinux.conf serial 0x2f8 57600 0x013 # that is, RTS/CTS flow control on COM2 prompt 1 timeout 100 say Select 'linux' or 'xen'. say Automatically booting 'xen' in 10 seconds. default xen label linux kernel /vmlinuz-2.6.18-6-686 append initrd=/initrd.img-2.6.18-6-686 root=/dev/mapper/xen1-root ro console=tty0 console=ttyS1,57600n8r noresume

Is there a required Clang and LLVM version one needs to do a ''make xen-dist clang=y''? I recently tried and the process failed. I haven''t begun debugging as I figured I would ask the obvious first. The build failed with the following: ... make[4]: Entering directory `/home/builder/xen-unstable/xen/drivers'' make -f /home/builder/xen-unstable/xen/Rules.mk -C char

Hi All: I found this old message on the web archives. I've gotten Xen working with PXELinux, albeit with something of a hack. The basic chain is: 1. pxelinux 2. memdisk 3. FAT16 floppy image 4. grub installed on floppy image 5. xen.gz and vmlinuz on floppy image While this seems pretty simple, the key bits were to use: 1. FAT16 (not ext2, etc) for the floppy image 2. use the 'raw'

Hello, I get the following message while loading my multiboot kernel with mboot.c32: "Invalid Multiboot image: neither ELF header nor a.out kludge found". I checked the code and came across this (com32/mboot/map.c line 130) : if (i + mbh_len < len) mbh_len = 0; /* Invalid... */ else break; /* Found something... */ } Shouldn't it be "if (i + mbh_len >=

If you have a multiboot kernel which is booted by syslinux/pxelinux/isolinux, etc., is there a way to determine who actually is the bootloader among the three? I'm wondering if the multiboot header or any part of memory has a consistent identifier somewhere. thanks, Ram

I''ve now given up trying to get grub working with my particular e1000 adapter, I''ve tried all the patches and all I can get is something that works a little bit but never past the grub menu. I''m sure I read something somewhere about a tool which would combine a multiboot image + modules into a single bootable item which could be loaded by lilo, and am hoping that the

On 10/10/17 12:11 AM, Gene Cumm wrote: > > I can't say I've ever tried using gdb against COM32 modules. > Well, in syslinux v5.00 and above, com32 modules are effectively built as ELF. Btw, I already found a way, though not perfect: - Create a FAT bootable disk image using "syslinux --install". - Copy hello.c32 module and load it in syslinux.cfg. - Find the

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

Op 2014-06-10 om 22:55 schreef Geert Stappers: > > Hello, > > A `make efi32` yeilds me > > make[3]: *** No rule to make target `efi32/com32/lib/memcmp.o', needed by `syslinux.so'. Stop. > make[3]: Leaving directory `efi32/efi' > make[2]: *** [efi] Error 2 It was encountered while doing `make`. The `make efi32` is just to faster reproduce the build

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

From: Matt Fleming <matt.fleming at intel.com> GCC 4.7 now places pointers to functions with the 'constructor' and 'destructor' function attributes in .init_array and .fini_array sections, respectively, whereas previously they were in the .ctors and .dtors sections. This change breaks the ctors/dtors code as it only expects function to be in the .ctors and .dtors sections,

From: Sylvain Gault <sylvain.gault at gmail.com> When a COM32 module exits, the functions never return and a new call to ldlinux_enter_command is made. This could fill the stack and overflow on some data present in memory. This patch use setjmp/longjmp to return to the main function and restart from there when a COM32 module exits. Signed-off-by: Sylvain Gault <sylvain.gault at