search for: bios_boot_linux

...32, 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 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. In basic testing, keeppxe seems to work with the patch applied. --- syslinux-6.04-pre1.orig/com32/elflink/ldlinux/kernel.c 2016-03-01 21:06:02.000000000 -0800 +++ syslinux-6.04-pre1/com32/elflink/ldlinu...

...does have a substantial payload (0x59f50 bytes.) > > I am guessing that that is the source of the problems, but I'm still > at a loss from staring at the code. If you could try turning on > debugging output by having debug.c32 installed on the system and running: > > debug bios_boot_linux calc_cmdline_offset > > ... from the command line before trying to load ipxe.lkrn? > > I should try it out myself if I can find the time... 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...

...ger 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 > 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. > > In basic testing, keeppxe seems to work with the patch applied. > > > --- syslinux-6.04-pre1.orig/com32/elflink/ldlinux/kernel.c 2016-03-01 21:06:02.000000000 -0800 > +++...

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 going on. The p...

A Toshiba CB35 Chromebook running Google's stock SeaBIOS reboots after selecting a relocatable kernel from extlinux 6.03. This is a regression caused by commit 8f470e7b movebits: Add syslinux_memmap_find() which factors syslinux_memmap_find() out of bios_boot_linux(). Prior to the refactoring, prot_mode_size was passed as the length in the first call to syslinux_memmap_type(). After the refactoring, hdr.init_size was passed. Now, with commit ef81a3ad, one or the other is passed according to whether the kernel is relocatable. bios_boot_linux() reaches sys...

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

> A Toshiba CB35 Chromebook running Google's stock SeaBIOS reboots after > selecting a relocatable kernel from extlinux 6.03. > > This is a regression caused by commit 8f470e7b > movebits: Add syslinux_memmap_find() > > which factors syslinux_memmap_find() out of bios_boot_linux(). Prior to > the refactoring, prot_mode_size was passed as the length in the first call > to syslinux_memmap_type(). After the refactoring, hdr.init_size was > passed. Now, with commit ef81a3ad, one or the other is passed according to > whether the kernel is relocatable. > >...

...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 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -155,8 +155,8 @@ int bios_boot_linux(void *kernel_buf, size_t kernel_size, char *cmdline) { struct linux_header hdr, *whdr; - size_t real_mode_size, prot_mode_size, base; - addr_t real_mode_base, prot_mode_base, prot_mode_max; + size_t real_mode_size, prot_mode_size; + addr_t real_mode_base, prot_mode_base, pr...

Christian Hesse <list at eworm.de> on Tue, 2013/10/22 13:14: > Christian Hesse <list at eworm.de> on Tue, 2013/10/22 12:56: > > Gene Cumm <gene.cumm at gmail.com> on Tue, 2013/10/22 06:35: > > > On Tue, Oct 22, 2013 at 5:41 AM, Christian Hesse <list at eworm.de> wrote: > > > > Hello everybody, > > > > > > > > iPXE builds

> On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > > > >> > 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....

...UEFI is supported BIOS Revision: 2.9 -- Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Kontron Europe GmbH Product Name: COMe-mBTi10 Version: C.0.4 -- syslinux.cfg -- PROMPT 0 TIMEOUT 50 SERIAL 0 DEFAULT dbg LABEL dbg COM32 debug.c32 APPEND bios_boot_linux free #DEFAULT linux.c32 root=/dev/mmcblk0p2 #DEFAULT vmlinuz0 root=/dev/mmcblk0p2 DEFAULT mylabel LABEL mylabel COM32 sysdump.c32 ymodem xzy 0 9600 #KERNEL linux.c32 #APPEND vmlinuz0 initrd=initrd0.img root=/dev/mmcblk0p2 rootwait rootfstype=ext3 console=tty0 console=ttyS0,9600 LINUX vmlinuz0 #K...

...an example? also on minicom ymodem reception I only receive headers NO files. why so? Using debug.c32 like below in a syslinux.cfg is OK?, but then where do I call the kernel? right below or in a separate label? where do I get the error messages? DEFAULT dbg LABEL dbg COM32 debug.c32 APPEND bios_boot_linux free please provide some examples if possible if my above shown syslinux.cfg file. ? Please advise other possible debugging methods. best regards. 2014-11-19 13:49 GMT+01:00 Ady <ady-sf at hotmail.com>: > > > > > Hi > > I have tried to install syslinux 4.06 on the SD...

...e of common code. > 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 Probably the best choice. > 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. > In basic testing, keeppxe seems to work with the patch applied...

On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > >> > 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,...

...sed to a bzImage file), but it does have a substantial payload (0x59f50 bytes.) I am guessing that that is the source of the problems, but I'm still at a loss from staring at the code. If you could try turning on debugging output by having debug.c32 installed on the system and running: debug bios_boot_linux calc_cmdline_offset ... from the command line before trying to load ipxe.lkrn? I should try it out myself if I can find the time... -hpa

"H. Peter Anvin" <hpa at zytor.com> on Wed, 2013/12/04 09:43: > 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 c...

...rect a type" com32/lib/syslinux/load_linux.c | 1 + 1 file changed, 1 insertion(+) diff --git a/com32/lib/syslinux/load_linux.c b/com32/lib/syslinux/load_linux.c index 06ae2a9..5cecef4 100644 --- a/com32/lib/syslinux/load_linux.c +++ b/com32/lib/syslinux/load_linux.c @@ -323,6 +323,7 @@ int bios_boot_linux(void *kernel_buf, size_t kernel_size, } whdr->code32_start += base - prot_mode_base; + prot_mode_base = base; /* Real mode code */ if (syslinux_memmap_find(amap, &real_mode_base, -- 2.3.0-rc2

...gt; be looking at (bios i[?m guessing ] to understand why one wont work without > this setting and one wont work with it. They each use RAM differently. meminfo.c32 will print the results from INT 15h AH=88h, INT 15h AX=E801h, and the map from INT 15h AX=E820h. com32/lib/syslinux/load_linux.c:bios_boot_linux() line 180 is the code that deals with the option. Line 298 is where it's then added to the memory map. Details like make, model, BIOS/firmware revision, whether the machine is (U)EFI-based in CSM-mode versus a traditional BIOS system, exactly how much RAM and how each fails would probably be...

...ps testing Syslinux 6.xx under VBox 4.1.x might help solve bug > #45? > > TIA, > Ady. I followed hpa's instructions (given at #syslinux, on syslinux 6.03pre3): 1_ Add: -DDEBUG=1 -DCORE_DEBUG=1 to mk/devel.mk. 2_ Build. I used 'make bios' 3_ Test with: debug.c32 -e bios_boot_linux debug.c32 -e syslinux_do_shuffle debug.c32 -e syslinux_dump_memmap debug.c32 -e syslinux_dump_movelist (I actually used debug.c32 -e <func1> , <func2> , ... I am typing it as 4 individual lines here just for clarity.) 4_ Launch the kernel (which fails as described in bug 45). I am a...

On Wed, Jun 15, 2016 at 1:02 PM, Ady via Syslinux <syslinux at zytor.com> wrote: > >> On Tue, Jun 14, 2016 at 12:33 PM, Ady via Syslinux <syslinux at zytor.com> wrote: >> > >> >> > 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 ev...