Thomas wrote:> I think it still has good reason to exist.Would you please clarify what do you mean with "it"? What exactly should exist? By "it", do you mean the original code, or the patch? Do you mean that the original code (in this section of the file) should remain as it was/is, without applying the relevant part of Martin's patch? Or instead, do you mean that the relevant section of the patch should remain, so the resulting code should be different than it has been for the last few years? Martin wrote:> > As you say, as is is the most safe.Please clarify, what exactly are you referring to with "as is"? Should the whole patch be applied? Or only the first part of the patch should be applied while the second part should be skipped, leaving the second section of the code as it used to be during the last few years? After reverting the last commit 48e94f4fa... (the one with the wrong patch, the one that triggered Geert's question), perhaps there should be 2 separate commits applying the 2 sections of the last valid patch separately? Regards, Ady.
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 prevented booting on David's BIOS, we stumbled over the problem that the experimental MBR "isohdpfc" wrongly told isolinux.bin to use LBA addressing, although the MBR code had decided to use C/H/S addressing for itself. This misunderstanding could happen in real operation if the BIOS returns an unexpected signature in its reply to INT 13 AH 41 together with non-zero content in the CX register. Martin made sure in the proposed successful fix that CX is set to 0 if the MBR decided for C/H/S. So isolinux.bin cannot get the wrong impression that LBA addressing is to be used. I just wanted to support this particular code aspect. ----------------------------------------------------------------- For me the proposed and successfully tested fix looks ok. But my barebone assembler experience is less than a week old. David tested it on a C/H/S needy BIOS. I tested on SeaBIOS of qemu which supports LBA addressing. Others are invited to test whether their favorite isohybrid ISO still boots from USB stick after its first 432 bytes were replaced by http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 The changelog in git https://git.kernel.org/pub/scm/boot/syslinux/syslinux.git/log/mbr/isohdpfx.S gives the impression that the stack interface between isohdpfx.bin and isolinux.bin is unchanged at least since SYSLINUX 3.82-pre2, 2009-05-31. So the new MBR should work with isohybrid ISOs made by that version or by younger ones. It is worth a try to first inquire the version of isolinux.bin in the ISO before patching in the new MBR. On Debian's ISO i get: $ strings /mnt/iso/isolinux/isolinux.bin | grep ISOLINUX ISOLINUX 6.03 20150819 Have a nice day :) Thomas
> 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. >Translation to a more plain language (so to avoid calling both, the original code and the patch too, as "code", or both being "it"): You are suggesting to revert the (wrong) commit 48e94f4fa7b3c3..., and then the whole complete "correct" patch that Martin posted should be applied, not just the first part, but the second part too.>From my prior post, two items remain to be seen:_ clarification from Martin (since I asked a similar question regarding his own email/wording); and _ after reverting the (wrong) commit 48e94f4fa7b3c3..., whether the 2 sections of Martin's patch should rather be applied as one commit, or 2 separate commits, or just the first part of the patch should be applied. Regards, Ady.