similar to: Possible improvements for chain.c

This patch introduces extra functionality to chain.c, mainly with reference to BPB adjustments, but not only that. It expects 3 small patches I sent earlier (they are included for easy reference, patches 1-3/4). The changes introduced are: 1) file and boot sector use separate options to control load address and jump address (if applicable). Options are as described below: *

On Mon, Feb 20, 2017 at 2:17 PM, Ady Ady via Syslinux <syslinux at zytor.com> wrote: > Correct the "seg=" value(s) corresponding to the "reactos=" option > for chain.c32. > > The correct segment parameter should be "seg=0x0F80", > instead of the incorrect / failing ones "seg=0:0x8000:0x8100". > > References: >

Correct the "seg=" value(s) corresponding to the "reactos=" option for chain.c32. The correct segment parameter should be "seg=0x0F80", instead of the incorrect / failing ones "seg=0:0x8000:0x8100". References: https://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/notes.txt?revision=73859&view=markup&pathrev=73859#l24

(snip) > > It's a bit more complex. At the time of writing, the data was perfect. > > https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/boot/freeldr/freeldr/include/arch/pc/x86common.h;hb=28e58e6d01892c1f2f0e1d323745e6463cb9e6c9 > dated 2011-06-14 > >

This adds (basic) support for GRUB stage2 image files. Loading a stage2 image will probably give you a GRUB prompt, with GRUB's "root" set at "(hd0)" (ie, entire first disk). Maybe the "root" will differ in less common setups. (One can of course select another disk and/or partition with GRUB's "root" command.) This has only been tested with version

Allow the grub loader to (optionally) support using a GRUB menu file. For example chain fs grub=stage2,grub.conf will load GRUB's stage2 and pass the (absolute) path to the file "grub.conf" in the Syslinux filesystem to GRUB's stage2. The path is passed to stage2 in GRUB's device/partition syntax (eg, "(hd0,1)/foo"). Note that we don't check whether the

1) code split and move Iterator related functionality is yanked from chain.c and moved to iterator.{c,h}. Both are moved to com32/chain and this way chain.c is ready for further splitting. Alternatively, partiter could be moved to com32/lib at any time in the future. It's potentially useful for other modules (e.g. if someone wanted to code partition dumper or editor). 2) Iterator updates

Hello Peter, the following changes since commit 67496f7afab45f17a6a4ce4fc183d9e0c15ead03: Michal Soltys (1): chain.c32 sethidden option fix are available in the git repository at: git://repo.or.cz/syslinux/sherbszt.git gfxboot32 Steffen Winterfeldt (7): gfxboot: support MENU LABEL statement gfxboot: make config statements case-insensitive gfxboot: handle IPAPPEND

On 12/2/18 10:33 AM, Richard W.M. Jones wrote: > The cow and cache filters both use a bitmap mapping virtual disk > blocks to status stored in the bitmap. The implementation of the > bitmaps is very similar because one was derived from the other when > the filters were implemented. > > The main difference is the cow filter uses a simple bitmap (one bit > per block), whereas

It's useful to be able to search for the next non-zero entry in a bitmap. This commit adds a ?bitmap_next? function to do that. Because the bitmap is just a uint8_t buffer, using fast string functions we should be able to do this quickly even if the bitmap is sparse. (However the actual implementation is not optimized since that is quite complicated - see to-do comments in

git://git.hasevolq.net/syslinux.git Split and expanded version of chain module is on the chaindev branch. The module is fully documented in doc/chain.txt I wasn't sure if to make one giant commit, or kept all the history as I was going - so I chose the latter. Tag 'chaindev-review' marks the commit. New feats since my last mail include options: mbrchs, hideall, bss, bs, warn (see

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

filename to GRUB Legacy GRUB Legacy reserves 89 bytes for storing the filename of the configfile from memory address 0x8217 to 0x826f. We allow overwriting the default value (/boot/grub/menu.lst) when grubcfg=<filename> is used together with grub=<loader>. Examples: chain.c32 fs grub=/boot/grub/stage2 grubcfg=/boot/grub/grub.lst chain.c32 hd1,10 grub=/boot/grub/stage2

Here is a patch that makes it possible to chainload GRUB2 core.img form chain.c32. It reuses the grub= parameter (used for chainloading GRUB Legacy stage2): - both loaded at 0x8000 - start execution at offset 0x200 (0x8200 in memory) GRUB2 allows to specify another "GRUB home dir" than the standard /boot/grub GRUB2 doesn't allow to change the configfile 'grub.cfg' name

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

This is a bit updated set of chain.c32 changes that simplifies a few things (and in partiter part), fixes few minor issues and adds a few new features. Details are in the following commits, below is the summary and pull details at the end. Shao - any chance to peek over them ? Most of those are relatively simple changes and well tested, though of course something might have slipped my attention.

Hello Recently I've been happily experimenting with syslinux, replacing grub and my old bootmanager. All works beautifully, but I have one question - in case of .bss bootsectors - what exactly and under what circumstances is patched in ? With syslinux used as main bootmanager - bootsectors from xp64, xp32 and [pre-syslinux] msdos 7.1 (98se) work perfectly fine when chainloaded natively as

>From 1db8a8919482dbed4cc15509d8078b2f16a289bb Mon Sep 17 00:00:00 2001 From: Gert Hulselmans <gerth at zytor.com> Date: Wed, 30 Jun 2010 14:10:23 +0200 Subject: [PATCH] chain.c32: add grubcfg= for passing an alternative config filename to GRUB Legacy GRUB Legacy reserves 89 bytes for storing the filename of the configfile from memory address 0x8217 to 0x826f. We allow overwriting the

HPA, I believe that support to boot windows CD bootsectors was broken in 3.05. I have tested 2.13, 3.00, 3.02, 3.05, 3.06, 3.08, 3.11, and 3.20pre6. All versions >= 3.05 are broken. All versions <= 3.02 work fine with the same config. The error message I get is: ================================================================ IOSLINUX 3.20 3.20-pre6 Copyright (C) 1994-2005 H. Peter Anvin