similar to: [PATCH] new *br: Show handoff data

Thomas Schmitt wrote: > My main point of interest is which block is really loaded as first one > of isolinux.bin. [Program snipped.] > (It could be shorter if i did not insist in big endian words.) Why insisting? Anyway appended is a dumper version. I could put up a binery version if needed. Let me know if so. -- MartinS /*

If EBIOS is detected for this drive it tries to read sector size and use it. If error or no EBIOS 512 is assumed. Buffer to read sector size if always allocated into the stack. CHS informations are not readed as not needed and same space not restoring %dl for drive number. Signed-off-by: Frediano Ziglio <frediano.ziglio at citrix.com> --- mbr/gptmbr.S | 42

On Sat, Mar 25, 2017 at 06:51:50PM +0100, Geert Stappers via Syslinux wrote: > 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> > Subject: [syslinux:master] mbr/isohdpfx.S: correct pointer for

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

On Fri, Mar 24, 2017 at 2:55 PM, Martin Str|mberg via Syslinux <syslinux at zytor.com> wrote: > 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. >>

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

From: Jean-Christian de Rivaz <jc at eclis.ch> I suspect that some instructions about how to use the diag/mbr was not updated when the source file was renamed to handoff.S. Here is a simple proposition to fix that. Jean-Christian de Rivaz --- diag/mbr/README | 4 ++-- diag/mbr/handoff.S | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/diag/mbr/README

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, FYI syslinux upstream has a bugfix. Both in the 6.xx branch and the 4.xx branch. ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- Date: Sat, 15 Apr 2017 10:27:08 -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:

Thomas Schmitt said: > I am wondering about the meaning or reason of "+20" in this assembler line: > > movl (32+20)(%si), %ecx > > Why that extra offset 20 on the byte offset 32 which is specified by > GPT specs (UEFI 2.4, 5.3.3) ? (Do i get the language wrong ?) Well I've been looking at this. It seems gptmbr.S

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

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

On Wed, Mar 22, 2017 at 12:06:12PM +0100, Thomas Schmitt via Syslinux wrote: > There is a suspicious discrepancy in the code: > > heads = (stack-16) > sectors = (stack-18) > > ... > /* here we computer CHS values or just do some dummy computation for EBIOS */ > andw $0x3f, %cx /* Sector count */ > popw %bx /* EBIOS flag */ > pushw %cx /* -16: Save

Hi, i am looking now at the code which i assume loads the rest of isolinux.bin. The entry point for program execution from the MBR is obviously at http://git.zytor.com/syslinux/syslinux.git/tree/core/isolinux.asm#n186 (Do i get it right that this is the Intel syntax ? (Gronfff)) If POP yields the victim of the most recent not yet popped PUSH, then this does not look correctly coordinated

Hi, given the fact that the conversion has the factor HC*SH = "secpercyl", which is invariant under swapping, there remains as suspect in read_sector_cbios only this division: divb (sectors) There is a suspicious discrepancy in the code: heads = (stack-16) sectors = (stack-18) ... /* here we computer CHS values or just do some dummy computation for EBIOS */ andw $0x3f,

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

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 %cx,%eax /* Length of GPT entry */ stosl - + rep; movsb /* GPT entry follows MBR entry */ popw %si

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

On Sun, Dec 29, 2013 at 2:53 AM, Geert Stappers <stappers at stappers.nl> wrote: > 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

I wrote: > Also besides the 16/32 confusion in gptmbr.S there's more weirdness > that looks like a bug: > > /* Check to see if we have EBIOS */ ... > int $0x13 > popw %dx /* restore drive */ > movb $0x08, %ah /* get CHS geometry */ > jc 1f ... [More blather _why_ this is buggy.] Today I see that