grub-devel
[Top][All Lists]
Advanced

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

Re: Windows,grub and grub2


From: Bean
Subject: Re: Windows,grub and grub2
Date: Mon, 29 Sep 2008 18:50:57 +0800

On Mon, Sep 29, 2008 at 1:18 PM, Viswesh S <address@hidden> wrote:
> Hi,
>
>
>
> ----- Original Message ----
>> From: Bean <address@hidden>
>> To: The development of GRUB 2 <address@hidden>
>> Sent: Tuesday, 23 September, 2008 7:20:49 PM
>> Subject: Re: Windows,grub and grub2
>>
>> On Tue, Sep 23, 2008 at 4:23 PM, Viswesh S wrote:
>> >
>> >
>> >
>> >
>> > ----- Original Message ----
>> >> From: Bean
>> >> To: The development of GRUB 2
>> >> 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
>
> The patch works and now Windows is booting perfectly fine from Grub2.
>
> I will go through the assembly and try to understand what modifications you 
> have done.So there is a problem in Grub2 code, which needs to be fixed ?
>
> Till this point, I was chainloading grub from Grub2 and then chainloading 
> Windows2008 from it.
>
> Thanks for the consistent help till this point and for the future also.

Hi,

That's strange, the patch doesn't do anything except output the value of dx:

        /* 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"

Perhaps you can try:

1, %edi is used as backup register in case %edx is changed by
prot_to_real, you can remove "movl %edx, %edi", "push %di", "call
hex_out" and see if it still works.

2, It's possible that the bug is position related, replace "push %dx",
"call hex_out" with equal number of nop and see what happens.

-- 
Bean




reply via email to

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