Syslinux - Sep 2002 - isolinux.asm - improving spec_query_failed routine ...

> -----Original Message-----
> From: Michael K Ter Louw [mailto:mterlouw at gmx.net]
> Sent: woensdag 4 september 2002 1:24
> To: Lagerweij B ; syslinux at zytor.com
> Subject: Re: [syslinux] isolinux.asm - improving spec_query_failed
> routine...
> 
> 
> 
> Hi Peter, Bart, and everyone else,
> 
> I also write software that boots from the CD drive, so this 
> subject is 
> rather interesting to me.  Currently I'm having difficulty 
> booting from 
> an HP e-Vectra that I think might be caused by the BIOS 
> passing me a bad 
> drive number in dl, so I was wondering if we could put our heads 
> together and see what's the best we can do in this situation.
> 
> First, I'd like to make some observations about the 
> differences between 
> HPA's and Bart's approach.
> ---------------------------------------------------------------------
> 
> Bart:
> Ignores CF returned from Int 0x13/AX=0x4B01, instead uses 
> returned spec 
> packet size to determine success (must be between 13 and 20 bytes).
> 
> HPA:
> Uses CF to determine whether spec packet has been returned.
When scanning from ff..80 we cannot completely trust the CF on some bioses
 
> ---------------------------------------------------------------------
> 
> Bart:
> Doesn't worry if the returned drive number (offset 2 in spec 
> packet) is 
> different from the value passed to Int 0x13/AX=4B01 in the dl 
> register.
> 
> HPA:
> Makes sure the returned drive number (offset 2 in spec packet) is the 
> same as the value passed to Int 0x13/AX=0x4B01 in the dl 
> register.  If 
> it doesn't match, then scan drives 0xFF down to the the drive number 
> that was passed to the Isolinux boot sector in the dl 
> register.  If no 
> matches are found to this point, then continue "on thin ice" with
the
> drive number that was passed to the boot loader in the dl 
> register.  It 
> should be noted that in this situation (where CF is returned 
> clear but 
> the drive numbers don't match), the values 0x80 to the 
> original dl are 
> never checked for a valid spec packet.
> 
> ---------------------------------------------------------------------
> 
> So other than these two points, the approaches are identical. 
>  Basically 
> check to see if you can get a valid emulation spec packet for the 
> passed-in drive number, and if not, scan the range 0xFF down 
> to 0x80 to 
> see if a valid spec packet can be obtained (should we be 
> accepting 0x80? 
>   According to R. Brown and the Phoenix El Torito spec, 0x80 
> is reserved 
> for HDD emulation).
> 
> Apparently I missed the boat on this one, because I was just blindly 
> using the passed-in dl value.  I did, however, run the Int 0x13 
> installation check (Int 0x13, AH=0x41, BX=0x55AA) on it to 
> see if it was 
> valid.  Note that many BIOSes don't return proper values in CL (API 
> support bitmap), which should at the very least have bit zero 
> set if we 
> expect to be able to use Int 0x13/AH=0x42 (extended read).
Note! I don't use it from within a bootstrap loader, I used this "wing
it"
routine in ettool.com and eltorito.sys, so in Dos and there is no booted
"cd-rom" drive number available... I would not know any boot situation
where
it is "unsafe" to use the drive number in DL...
  
> So I'm wondering, is there a hybrid that would work in the most dire 
> circumstances?  I think that HPA's method would work in most 
> cases.
Yes, even bad Dell/compaq bios will return spec packet on the
"correct"
booted drive number and also CF is return OK.

But.. the trouble start's when the passed in DL number is not the correct
one (never seen it myself) and the "wing it" routine starts. Bad
compaq/dell
(and other Phoenix BIOS
version 1.10 based bioses) do not return proper CF values when a call has
been made with an *incorrect* drive number.

Maybe it would be bether to just use the value in DL (even when spec packet
fails) and not trying to "wing it"...

Peter, do you know what bios fails spec packet info call and needs to be
"winged"...
> We 
> could add Bart's way of determining a successful return from function 
> 0x4B01 to increase compatibility.  Then have HPA's routine 
> further scan 
> the drives from 0x81 up to the passed-in-dl drive number to 
> exhaust all 
> possible means before 'settling' for a certain value.  When 
> all is said 
> and done and we have our drive number, should we then check 
> for Int 0x13 
> Extensions support on that drive, or just go ahead and assume 
> we can do 
> extended reads?  Lastly, should we allow dl to be equal to 0x80?
Some systems use last hd number+1 as the cdrom driver number, so when you do
not have a harddisk wouldn't the cdrom get 0x80???
> I think we could all benefit from finding a solution that 
> works as close 
> to 100% of the time as we can get.  Maybe one of us should 
> reverse-engineer Microsoft's CD-ROM boot sector and see what
they're
> doing.  Has anyone come across a machine that *won't* boot a Windows 
> install CD?
As far as I can tell (it was a while back), they use the value in DL
register... and they do not inquire for a spec packet... so they completely
trust the DL driver number... If I remember correctly they do not use any
eltorito function... I have coded this behaviour into diskem1x.bin by
looking at the NT4 cdrom bootsector.

Regards,
Bart.
  
> Mike
> 
> 
> Lagerweij B wrote:
> > Hi Peter,
> > 
> > I noticed in your isolinux.asm code,
> > when loading spec packet fails you are trying to wing it, 
> in other word,
> > loop the drive numbers from 0xff through 0x80 until the 
> booted drive number
> > is found...
> > 
> > I write software that also "wings it".
> > Recently I had to create some "wird" workarounds because of 
> bad bios in some
> > Dell and Compaq PC's.
> > 
> > Below is my function for finding (wing it) the booted 
> eltorito drive number,
> > this methode works on the worst and badly coded bioses out there...
> > Maybe it can help you with development of future version of 
> isolinux.asm
> > 
> > You provide isolinux for the world, for free, so improving 
> your code is the
> > least I can do back...
> > 
> > Best regards and good luck,
> > Bart "nu2" Lagerweij.
> > 
> > ---
> > Bart Lagerweij - http://www.nu2.nu
> > To contact me go here: http://www.nu2.nu/contact/bart
> > ---
>

Lagerweij B wrote:
> 
> Peter, do you know what bios fails spec packet info call and needs to be
> "winged"...
> 
Not off the top of my head.
> 
>>I think we could all benefit from finding a solution that 
>>works as close 
>>to 100% of the time as we can get.  Maybe one of us should 
>>reverse-engineer Microsoft's CD-ROM boot sector and see what
they're
>>doing.  Has anyone come across a machine that *won't* boot a Windows
>>install CD?
> 
Yes... what seems to be uniform is that each system seems to be able to 
boot **the version of Windows that was current when the machine 
shipped.**  Some (Promise) have even been known to hard-code the layout 
of that CD!

	-hpa