On 26/06/07, Alex Roman <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
