similar to: [PATCH 0/3] v2: mbr: Ctrl-key press forces load from first hard disk

The following series of patches add a work-around for a BIOS bug to the MBR code. The user can press a Ctrl key at boot-time to force the MBR to ignore the BIOS-reported drive number (passed in register DL) and use the first hard-disk device (0x80). This works around a common problem that otherwise results in the "Missing operating system" message. If the BIOS-defined boot device order

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 372 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 377 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 382 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

--- mbr/isohdpfx.S | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/mbr/isohdpfx.S b/mbr/isohdpfx.S index 9e9d55c..bddb533 100644 --- a/mbr/isohdpfx.S +++ b/mbr/isohdpfx.S @@ -67,6 +67,7 @@ _start: movw %ax, %ss movw $stack, %sp movw %sp, %si + movw %sp, %bp /* needed later if drive number is to be forced due to Ctrl key being pressed */ pushw %es /*

> There's 0 need to build MBRs for > EFI At least gptmbr.bin might come to mind (after all, GPT is part of the UEFI specs). Isohybrid with UEFI options perhaps too? > and I'm looking at why utils/ depends on mbr/ isohybrid(.pl) and mkdiskimage come to mind here? I'm not saying for certain these are the reasons for such dependencies, but they might (and perhaps

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 371 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 376 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

The handover protocol uses ED as partition type but the comment above it still mentions EE Signed-off-by: Ruben Kerkhof <ruben at rubenkerkhof.com> --- mbr/gptmbr.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mbr/gptmbr.S b/mbr/gptmbr.S index 7f450d3..8ab6b50 100644 --- a/mbr/gptmbr.S +++ b/mbr/gptmbr.S @@ -194,7 +194,7 @@ found_part: pushw %di /* 80 00 00 00

This patches add support for dynamic sectors to GPT MBR code. First 3 patches are trick and optimizations to gain some space for the forth patch. I have a modified version of SeaBIOS, some code and some script o test it I'll send on a different mail.

Op 2013-12-14 om 21:34 schreef Ruben Kerkhof: > Signed-off-by: Ruben Kerkhof <ruben at rubenkerkhof.com> > --- > mbr/gptmbr.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mbr/gptmbr.S b/mbr/gptmbr.S > index 8ab6b50..7d98aee 100644 > --- a/mbr/gptmbr.S > +++ b/mbr/gptmbr.S > @@ -213,7 +213,7 @@ found_part: > > movzwl

It is good to see this ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- Date: Sat, 25 Mar 2017 05:54:09 -0700 From: syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> To: Syslinux commits mailing list <syslinux-commits at zytor.com> Cc: ams at ludd.ltu.se Subject: [syslinux:master] mbr/isohdpfx.S: correct pointer for heads/sectors

Does anyone know how to install the gptmbr.bin onto a USB drive with Windows? I noticed that it would be really easy to modify the source of the installer to install gptmbr.bin instead of mbr.bin with the -m flag, but I'd like a solution that doesn't require me to maintain my own custom syslinux. I'm open to writing and submitting a patch to add a new flag (say -g) to install

Thomas Schmitt wrote: > I have some problems understanding the details of the program's flow. > > - The code inside PARTITION_SUPPORT is supposed to be inactive with > MBR isohdpfx.bin. It belongs to isohybrid --partok which is equivalent > to MBRs isohdppx*.bin. Debian uses isohdpfx.bin. Yes. isohdpfx.bin is generated from isohdpfx.S in which PARTITION_SUPPORT is not

Op 2013-12-15 om 17:39 schreef Ferenc Wagner: > Ruben Kerkhof <ruben at rubenkerkhof.com> writes: > > > /* 80 00 00 00 ee 00 00 00 > > - - bootable partition, type EFI (EE), no CHS information */ > > + - bootable partition, type EFI (ED), no CHS information */ > > Please fix the previous comment line as well. As I understand that, so in _my words_:

On Fri, Mar 24, 2017 at 05:38:31PM +0100, Thomas Schmitt via Syslinux wrote: > isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41. > Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk Drive" > could be set. > https://en.wikipedia.org/wiki/INT_13H > > I understand on David's BIOS after > > andw $1,%cx

From: MartinS <ams at ludd.ltu.se> isohdp[fp]v.S which says E or C if EBIOS or CBIOS is used. isohdppv.S also says G or M if a GPT or MBR partition is detected. Signed-off-by: MartinS <ams at ludd.ltu.se> --- Comments? diff --git a/mbr/Makefile b/mbr/Makefile index be2bded..7095396 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -21,7 +21,8 @@ include $(MAKEDIR)/embedded.mk all:

Hi, On 23/06/2014 12:07, Thomas Schmitt wrote:> Hi, > > i have written an introduction to isohybrid and put it on > the discussion page of the ISOLINUX wiki. > > http://www.syslinux.org/wiki/index.php/Talk:ISOLINUX#Proposal_for_description_of_isohybrid > > Review and proposals are appreciated. Caveat emptor: this is a review by an end user (not a developer), who

EFI systems typically don't support booting off ISO 9660 filesystems, even if written to USB sticks. This patch adds support for generating a GPT that covers the stick as well, with an additional partition entry pointing purely at the secondary El Torito image. When burned to CD the secondary El Torito will be used as an EFI boot image, and when written to a USB stick the GPT partition

> It's source code looks like a BIOS MBR program which shall search > the "active" partition in GPT rather than in the MBR partition table. > See comments about "EBIOS" detection and "CHS" addresses in > https://github.com/geneC/syslinux/blob/master/mbr/gptmbr.S > > "Active" partitn would be the one which has bit 2 set in the

Hi, Martin Str|mberg wrote: > And given that space in isohdpfx is very limited (432 bytes) perhaps > the right thing might be to not have that xor in there. > But then better safe than sorry, and given that there is space _now_, > why not? I still agree. But while answering Ady's questions i get to a question of my own: Do all six fixed isohdp*.bin variations still fit into 432

Thomas Schmitt wrote: > So if we had a MBR which prints the content of the first 512 read bytes > we could tell whether they are block aligned and from which block they > come. Ok. I'll try. Is it the isohdppx or isohdpfx (or both) that is relevant? Meanwhile I have a hacked isohdppx.bin that prints: G if GPT M if MBR <nothing> if no partition info E if EBIOS C if not EBIOS