[syslinux] ElTorito.sys Scanning Strategy

[Shao Miller]

Good day to all.

Since we've adopted Gary Tong's and Bart Lagerweij's ElTorito.sys (now 
modified by H. Peter Anvin and tiny changes from myself), I'd appreciate 
if anyone with more El Torito experience might criticize my comments 
below and advise as to how they might be wrong.  Some of it is off-topic 
GRUB4DOS detail; safe to ignore.

A bit of history: FDUBCD ("FreeDOS Universal Boot Compact Disc", I 
should think) was reported to work with MEMDISK, but not with GRUB4DOS' 
RAM disk logic.  A modified eltorito.sys was offered by a GRUB4DOS 
developer and appeared to resolve the issue.  I'm not so sure it's the 
best fix, though.

The comments can be found in their original glory, here:

 
http://reboot.pro/topic/17911-access-fdubcdiso-content-from-grub4dos/page-3#entry164754

The G4D developer's patch for eltorito.sys can be found at the top of 
that page, in post #51.

- Shao Miller

--- Comments ---

tinybit (GRUB4DOS developer) typed:

     The above code has another issue. Look at this:

     SendFound:	mov	dl, [SpecPkt+2]
     		clc
     ThingDone:	pop	si
     		pop	ax
     		retn

     It should firstly compare [SpecPkt+2] with DL, if not equal, it 
should fail out. At least one BIOS has etdump output as follows:

     FF: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
     FE: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
     ..
     9F: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
     ..
     81: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7
     80: CF=0 13 00 9F 00 A1 00 00 00 00 00 00 00 00 00 04 00 6D 08 D7

     In the above output, only the line for drive 9F is correct. All the 
others are meaningless.

I responded:

After reviewing, I don't believe this is an issue for ElTorito.sys.  I 
have several reasons outlined, below:

1.    In the El Torito specification 1.0 (1995), the strategy for floppy 
emulation and HDD emulation is to _shift_up_ the pre-existing drive 
numbers and to inject the El Torito disk _before_ those pre-existing 
drive numbers.  This is another reason why it makes sense to scan 
_upward_ instead of downward.  You will get the _last-booted_ El Torito 
floppy or HDD.  This has been the case for close to 17 years.


2.    For no-emulation mode, it is completely up to the BIOS (or hook) 
as to which drive number is used, as long as it's >= 0x81.  In EDD-4, it 
is suggested to use 0xA0 or anything else > 0x9A (26 drive letters 
starting from 0x80, though they forgot that A: and B: floppies would be 
< 0x80).

     This allowance creates a challenge: If you want to know the 
_last-booted_ El Torito drive number, how do you do it?  Is there a 
special invocation?  Do you scan downward or upward?

     Reading the 1995 specification, one might guess that requesting the 
status for drive 0x7F would return the last-booted El Torito drive 
number.  Reading EDD-4, it explicitly states that simply requesting 
status is _expected_ to return the last-booted drive number, with no 
mention of DL anywhere in sight.  That means that compliance with EDD-4 
requires returning the last-booted drive number regardless of the user's 
DL query.  _However_, eltorito.sys has to deal with _other_ [non-EDD-4] 
cases, which one reason for why it performs a scan.

3.    Since probing 0xFF is buggy on some BIOSes, eltorito.sys prefers 
to scan upward.

4.    Since the general strategy of injecting the El Torito drive number 
and shifting the conflicting drive number up can be adopted (for 
consistency) for no-emulation mode, then a pre-existing 0xA0 can be 
shifted to 0xA1 and a upward scan is preferred for this reason, too.

5.    When eltorito.sys gets a valid status, it doesn't care about 
further probing, since it now has the EDD-4 answer, and 
_at_least_a_valid_ answer for a booted (but maybe not _last-booted_) El 
Torito disc.

I propose that GRUB4DOS' INT 0x13 hook should comply with EDD-4 and 
unconditionally return an expected drive number for the El Torito status 
query.

1.    If GRUB4DOS established any virtual optical discs, this could be 
the first one in the drive mapping table, _or_
2.    If the root or chainloader commands were used, it could be 
whichever drive number was involved

Suggested benefits:

     eltorito.sys does not need to be changed and continues to work on 
BIOSes where probing 0xFF is problematic
     eltorito.sys does not need to rely on downward or upward probe 
order when talking with GRUB4DOS' hook, as the very first response from 
G4D will give the answer
3.    GRUB4DOS can put a shiny star sticker beside EDD-4's 8.27

Suggested disadvantages:

-    The time taken to code the changes

Meanwhile, I haven't quite yet reproduced the problem, but given that 
tinybit's modified eltorito.sys appears to work for steve6375's tests, I 
would wonder if the following GRUB4DOS command-sequence would work:

   map --mem /fdubcd.iso (0xA0)
   map (cd) (0xA1)
   map --hook
   root (0xA0)
   map --mem /fdubcd.img (0x00)
   map (0x00) (0x01)
   map --rehook
   map --status
   root (0x00)
   chainloader +1
   boot