Hello, On Mon, Oct 15, 2001 at 02:09:54PM +0900, Yoshinori K. Okuji wrote: > From: Thierry Laronde <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> Site Debian Francophone (aka SDF) : http://www.debian-france.org/ _______________________________________________ Bug-grub mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-grub