Hi, 2010/9/15 Dmitry Ilyin <idv1...@mail.ru>: > I guess it is possible to chainload to real cdrom in your drive same way we > chainload to windows partition, you can also use script (grub or lua) to > determine that your drive is not empty and show chainload menu entry. > > Or if you cannot chainload perhaps you could boot this (maybe with memdisk > from syslinux) > http://btmgr.sourceforge.net/about.html
The problem with "chainloading" a CD-ROM (more correct would be "emulating El Torito for a CD-ROM") is that often the BIOS only provides a device number (and support via. "int 0x13") for the CD-ROM when the BIOS itself has booted the CD-ROM. This means that to reliably access the CD-ROM you'd need to do device detection (e.g. scan PCI buses looking for likely controllers), provide drivers for different types of controllers (ATA, AHCI, 3 or 4 types of USB, lots of different SCSI, etc, and maybe the legacy proprietory interfaces you find on ancient sound cards) and drivers for different CD-ROMs that can be attached to those controllers. In addition to that you'd need to hook the BIOS's "int 0x13", so that when the boot loader on the CD-ROM tries to load sectors from CD using the BIOS it works like it should (with all types of booting from CD - "emulated floppy", "emulated hard disk" and "no emulation"); and to do that properly you'd need to steal some RAM from the BIOS (to store GRUB's drivers in); which is typically done by intercepting the BIOS functions that are used to get the amount of free memory (e.g. "int 0x15, eax=0xE820", plus "int 0x12" and the "segment of EBDA" value in the BIOS data area). Of course after the OS boots there's no way to tell it that it can use the RAM that GRUB's drivers were using so that RAM is "lost"; and because OS's tend to make assumptions (like "there's at least 512 KiB of usable RAM starting at 0x00000000") you'd need to make sure the drivers are small (e.g. no more than about 64 KiB for everything). You also wouldn't be able to assume that the boot loader on the CD doesn't constantly switch between real mode and protected mode, or use "unreal mode", which means you'd be limited to 16-bit real mode code, and you couldn't switch to 32-bit code when you want because there's no way of doing that without trashing CPU state that the CD's boot loader could be relying on. Basically it's not impossible, but it is a lot of work, especially if you don't limit it to "all kinds of IDE ATAPI CD-ROMs" (and forget/ignore SATA/AHCI, USB, SCSI, etc). Cheers, Brendan _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
