On Tue, Sep 23, 2008 at 4:23 PM, Viswesh S <[EMAIL PROTECTED]> wrote:
>
>
>
>
> ----- Original Message ----
>> From: Bean <[EMAIL PROTECTED]>
>> To: The development of GRUB 2 <grub-devel@gnu.org>
>> Sent: Monday, 22 September, 2008 9:10:26 AM
>> Subject: Re: Windows,grub and grub2
>>
>> On Tue, Sep 9, 2008 at 2:00 PM, Viswesh S wrote:
>> > Below is the dump of screen output while chainloading the ntfsnew file.
>> > ***************************************
>> > DI=CFF0 SI=07EE BP=1FF0 SP=1FE8 BX=0000 DX=0000 CX=0000 AX=0000
>> > CS=0000 SS=0000 DS=0000 ES=0000 FG=0246 IP=7C57
>> >
>> > DI=7FF0 SI=07EE BP=1FF0 SP=7BF4 BX=55AA DX=0000 CX=0000 AX=0100 CX=07C0
>> > DS=07C0 ES=0000 FG=0007 IP=0082
>> > ******************************************
>> > Could you please let me know the way to disassemble the binary file without
>> > any header.The way in which you decoded the boot record.
>> >
>> > Also one more thing to let you know is that,
>> >
>> > with the grub-1.96 ( without the chainloader patch of disk->dev->read() ) ,
>> > with windows2003 in partition 1 and linux in partition 3, when we
>> > chainload,
>> > if we look at the partition table passed to another bootloader ie location
>> > 0x7be - we can see that it is junk, but the surprising point is that, in
>> > this case as I have mentioned in my first mail, windows boots up from
>> > grub2.So it is that the partition table is not required for the chainloader
>> > thing and just the boot record is sufficient
>>
>> Hi,
>>
>> Oh, sorry for another long delay. I disassemble the file with ida,
>> which is an amazing tool. I don't know if there is open source
>> alternative, please let me know if you find one.
>>
>> The output from ida is in masm format, I modify it a bit so that it
>> can be compiled using nasm. Please note that nasm doesn't generate the
>> same binary file as original one, but you can get an idea what it
>> does.
>>
>> From the output, the program fails at the second int 13 call, int
>> 13/ah = 48h. Although I notice that DL=0, which is not supposed to
>> happen. Perhaps you can add a grub_printf in grub_chainloader_boot to
>> show the value of boot drive:
>>
>> static grub_err_t
>> grub_chainloader_boot (void)
>> {
>> grub_printf ("boot_drive=%d\n", boot_drive);
>> grub_chainloader_real_boot (boot_drive, boot_part_addr);
>>
>> /* Never reach here. */
>> return GRUB_ERR_NONE;
>> }
>>
>> --
>> Bean
>>
>>
>
> Hi,
>
> The value of boot drive is 0x80.
>
> This was the same value in disk->drive also.
Hi,
Interesting, perhaps %dx is changed somewhere. Please try the
following patch, it dumps the value of %dx just before jumping to the
boot sector.
--
Bean
diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index 18f61d8..a50977c 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -639,13 +639,46 @@ FUNCTION(grub_chainloader_real_boot)
/* set up to pass boot drive */
popl %edx
+ movl %edx, %edi
/* ESI must point to a partition table entry */
popl %esi
+
call prot_to_real
.code16
+
+ push %dx
+ call hex_out
+ push %di
+ call hex_out
+
ljmp $0, $GRUB_MEMORY_MACHINE_BOOT_LOADER_ADDR
+
+hex_out:
+ pushw %bp
+ movw %sp, %bp
+ pushaw
+ movb $0xE, %ah
+ movw $7, %bx
+ movw $4, %cx
+ movw 4(%bp), %dx
+1:
+ rol $4, %dx
+ movb %dl, %al
+ andb $0xF, %al
+ cmpb $10, %al
+ jb 2f
+ subb $('0'-'A'+10), %al
+2:
+ addb $'0', %al
+ int $0x10
+ loop 1b
+ movb $' ', %al
+ int $0x10
+ popaw
+ popw %bp
+ ret $2
.code32
#include "../loader.S"
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
