similar to: isohybrid boot from logical partition

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

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:

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:

On Tue, Mar 21, 2017 at 09:03:35AM +0100, Thomas Schmitt via Syslinux wrote: > I think we should offer David a binary which he can combine with > the MBR of the ISO and the image with the recognizable blocks. > I will later today upload a binary version of my block producer > and post the URL. > > The combination will be: > 432 bytes from Martin's MBR > 80 bytes

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

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

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

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

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

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

CC:ing syslinux David Christensen reports that my latest isohdpfd.bin reported C, thus it failed early (carry set) in finding an EBIOS. My interpretation is that it must corrupt CX so isolinux is fooled into trying EBIOS first. So, again David, can you please try this one: <http://www.ludd.ltu.se/~ams/tmp/isodavid.tgz> To keep your (our?) spirits up I've named it of you. It

Hi, i wrote: > > I think it still has good reason to exist. Ady wrote: > Would you please clarify what do you mean with "it"? "It" was the code part about xor %cx, %cx /* Clear EBIOS flag. */ which Martin mentioned as "can be ignored" in the the text which i quoted before my statement. Additionally to the wrong stack sequence, which

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

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

Hi, for some reason David always omits the Cc: to this list. He has now reported to Martin and me the outcome of the latest two MBR test proposals. - His BIOS announces no LBA addressing but another extra feature. This lead to unexpected success in one of David's tests. - The newest fix proposal by Martin is a full success ! Distros which produce isohybrid should consider to already

Hi, Geert Stappers wrote: > Contact David off-list, he did unsubscribe. Can you tell when he unsubscribed (i.e. which of the messages he got as last one) ? > Martin posted elsewhere in this thread "Thomas, you found the bug" > and provided a patch. Open question is whether the fix helps with David's BIOS. The newest answer from Martin indicates that a failure to read

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

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