grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3. Re: LiveCD bootloader


From: Brendan Trotter
Subject: Re: 3. Re: LiveCD bootloader
Date: Thu, 16 Sep 2010 01:40:45 +0930

Hi,

2010/9/15 Dmitry Ilyin <address@hidden>:
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]