Re: [PATCHES] CD + extended floppy format

[Thierry Laronde]

Hello,

On Mon, Oct 15, 2001 at 02:09:54PM +0900, Yoshinori K. Okuji wrote:
> From: Thierry Laronde <address@hidden>
> Subject: [PATCHES] CD + extended floppy format
> Date: Sun, 14 Oct 2001 16:24:47 +0200
> 
> > Here are the patches and the ChangeLog for support of CD booting and
> > extended floppy formats use. Everything works OK for me so please test !
> 
> Thanks for your contribution. I, however, must ask you some questions,
> as your patch is so large! ;)
> 
> A question I have is why you needed the patch to boot GRUB from a
> CD. Could you tell me what was wrong and how you solved it?

Yes, I should have mentionned this since this is the part that took me
so much time to find what was going wrong.

If you read the El Torito specifications, you guess that INT 19h returns
the BIOS number for the emulation : 0x0 for floppy, 0x80 for HD. If this
assumption is correct, the older code should have worked for floppy (and
failed for HD emulation). The problem is that nowhere in the specification
this is said : the number are for INT 13h, not for INT 19h. So the
number returned by INT 19h seems to be special, and you need to call the
INT 13h El Torito extensions to find if we are under emulation and if
this is the case what correct BIOS number to keep. More precisely, a
boot loader only implementing CHS will have worked without
modifications, but the test for %dl (as returned by INT 19h) conducted
Stage1 to LBA.

In fact, El Torito is LBA based BUT the emulation needs CHS. Hence the
mess (with the older code, everything turned back to LBA mode, which was
supported, and this could not work).

Another note. Since I have spent (and lost) a huge amount of time (and
CDs :-^... but reusable in multi-session ;) to find what was going
wrong, I have searched via BPB and so on and that's why I have also 
implemented the support for unusual floppy formats. The changes for 
floppies are huger than for El Torito in fact, but now nobody can say: 
this works under Lilo but not with GRUB.

> 
> One problem I found is that the new function "disk_changed" cannot be
> so simple. The reason is obvious, if you see the Ralf Brown's
> Interrupt List. Here's the very part at which you should take a look:

I have worked with Ralf Brown's list too. My diagnostic is that this
simple code should work 95% of time, and when it fails that simply
creates a call to the diskinfo routines. So this should be OK to only
return %ah, no need to bother with more --- at least for testing.

Cheers,
-- 
Thierry Laronde <address@hidden>
Site Debian Francophone (aka SDF) : http://www.debian-france.org/