grub-devel
[Top][All Lists]
Advanced

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

Re: CD-ROM booting staus update


From: Alex Roman
Subject: Re: CD-ROM booting staus update
Date: Thu, 28 Jun 2007 10:04:12 -0400

On 26/06/07, Alex Roman <address@hidden> wrote:
Thought I'd write a little status update on this project.

All right, I took a look at the Bochs BIOS source code, and they seem
to be implementing just one Int 13h function that is specified in the
Eltorito specification: the 4B01h that isolinux needs to boot.

Next, I started to use Bochs' internal debugger and I noticed that the
grub_gate_a20 function clobbers %edx which was what was causing me the
grief, since I was holding the number of bytes to copy from my buffer
(that I read into from the CD) to 7c00h. So, instead of copying at
least 2k which is what ISOLINUX expects, it was copying only 224 bytes
(or something like that, the leftover value in %edx).

Now that I figured that out, *I managed to get the FreeDOS CD to boot! :)*

However, this relies on a little trick: my grub_eltorito_boot()
function in startup.S is placed at the very end of the file. It takes
in 3 parameters:
* the BIOS drive we're booting from (to be later placed in %dl)
* a pointer (linear address) to a buffer which stores the boot image
read from the CD
* the number of bytes to copy from the buffer to 7c00h

The function will then turn off the a20 gate, switch to real mode.

Then it will copy however many bytes I tell it from the buffer to
7c00h, overwriting parts of GRUB (including the functions needed to
gate a20 and go to real mode, which is why we do it early on).

After that it will clear all segments and perform a long jump (to set
%cs) to 0:7c00h and the boot process is completed.

The issues with this are:
* As soon as we enter the grub_eltorito_boot() function, there's no
chance of returning
* Other boot codes (not isolinux) may expect that more than 2k will
be copied to 7c00h, which means we may end up overwriting code in this
grub_eltorito_boot() function

A possible solution is to figure out a place where this function could
copy itself, high in memory so that it will be able to copy more than
2k, without overwriting itself, or the buffer I use to copy data into
from the CD.

That being said, I will clean up the code I have so far and send it as
a patch for review ASAP (tonight or tomorrow latest)...

I'd like any comments or objections on the current solution... Also,
sorry for the long email :)


Thanks!

--
Alex Roman <address@hidden>




reply via email to

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