[PATCH] Loading windows in macbook

[PATCH] Loading windows in macbook

[Bean]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Hi,

This patch fix two problem that can cause problem for grub-pc in macbook.

1, In grub-setup, we should skip the first 1024 bytes when comparing
data, as it have previously made change to the buffer with
install_dos_part and install_bsd_part, cause the comparison to fail.
This problem is not showed if the loader can be embedded in mbr.

2. Macbook will halt if we disable a20, so I add a new option
--keep-a20 to keep the a20 gate open.

With this patch, you can chainload windows with the following command:

set root=(hd0,4)
chainloader --keep-a20 +1
boot

-- 
Bean

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: a20.diff --]
[-- Type: text/x-diff; name=a20.diff, Size: 4970 bytes --]

diff --git a/include/grub/i386/pc/chainloader.h b/include/grub/i386/pc/chainloader.h
index c28a42d..b9b65ad 100644
--- a/include/grub/i386/pc/chainloader.h
+++ b/include/grub/i386/pc/chainloader.h
@@ -22,12 +22,10 @@
 #include <grub/dl.h>
 
 /* Common function for normal and rescue mode commands. */
-typedef enum
-  {
-    GRUB_CHAINLOADER_FORCE = 0x1
-  } grub_chainloader_flags_t;
+#define GRUB_CHAINLOADER_FORCE		0x1
+#define GRUB_CHAINLOADER_KEEP_A20	0x2
 
 void EXPORT_FUNC(grub_chainloader_cmd) (const char * file,
-					grub_chainloader_flags_t flags);
+					int flags);
 
 #endif /* GRUB_CHAINLOADER_MACHINE_HEADER */
diff --git a/include/grub/i386/pc/loader.h b/include/grub/i386/pc/loader.h
index 3e03141..2405dbb 100644
--- a/include/grub/i386/pc/loader.h
+++ b/include/grub/i386/pc/loader.h
@@ -23,6 +23,6 @@
 #include <grub/cpu/loader.h>
 
 /* This is an asm part of the chainloader.  */
-void EXPORT_FUNC(grub_chainloader_real_boot) (int drive, void *part_addr) __attribute__ ((noreturn));
+void EXPORT_FUNC(grub_chainloader_real_boot) (int drive, void *part_addr, int keep_a20) __attribute__ ((noreturn));
 
 #endif /* ! GRUB_LOADER_MACHINE_HEADER */
diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index 9542978..e0edacc 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -594,7 +594,7 @@ FUNCTION(grub_halt)
 	
 	
 /*
- *  void grub_chainloader_real_boot (int drive, void *part_addr)
+ *  void grub_chainloader_real_boot (int drive, void *part_addr, int keep_a20)
  *
  *  This starts another boot loader.
  */
@@ -602,13 +602,19 @@ FUNCTION(grub_halt)
 FUNCTION(grub_chainloader_real_boot)
 	pushl	%edx
 	pushl	%eax
+	pushl	%ecx
 
 	call	EXT_C(grub_dl_unload_all)
 
+	popl	%ecx
+	orl	%ecx, %ecx
+	jnz	1f
+
 	/* Turn off Gate A20 */
 	xorl	%eax, %eax
 	call	EXT_C(grub_gate_a20)
 
+1:
 	/* set up to pass boot drive */
 	popl	%edx
 
diff --git a/loader/i386/pc/chainloader.c b/loader/i386/pc/chainloader.c
index 825dbb3..fe2a932 100644
--- a/loader/i386/pc/chainloader.c
+++ b/loader/i386/pc/chainloader.c
@@ -35,11 +35,12 @@
 static grub_dl_t my_mod;
 static int boot_drive;
 static void *boot_part_addr;
+static int keep_a20;
 
 static grub_err_t
 grub_chainloader_boot (void)
 {
-  grub_chainloader_real_boot (boot_drive, boot_part_addr);
+  grub_chainloader_real_boot (boot_drive, boot_part_addr, keep_a20);
 
   /* Never reach here.  */
   return GRUB_ERR_NONE;
@@ -53,7 +54,7 @@ grub_chainloader_unload (void)
 }
 
 void
-grub_chainloader_cmd (const char *filename, grub_chainloader_flags_t flags)
+grub_chainloader_cmd (const char *filename, int flags)
 {
   grub_file_t file = 0;
   grub_uint16_t signature;
@@ -118,6 +119,7 @@ grub_chainloader_cmd (const char *filename, grub_chainloader_flags_t flags)
 
   boot_drive = drive;
   boot_part_addr = part_addr;
+  keep_a20 = ((flags & GRUB_CHAINLOADER_KEEP_A20) != 0);
   
   grub_loader_set (grub_chainloader_boot, grub_chainloader_unload, 1);
   return;
@@ -133,7 +135,7 @@ grub_chainloader_cmd (const char *filename, grub_chainloader_flags_t flags)
 static void
 grub_rescue_cmd_chainloader (int argc, char *argv[])
 {
-  grub_chainloader_flags_t flags = 0;
+  int flags = 0;
 
   if (argc > 0 && grub_strcmp (argv[0], "--force") == 0)
     {
@@ -142,6 +144,13 @@ grub_rescue_cmd_chainloader (int argc, char *argv[])
       argv++;
     }
   
+  if (argc > 0 && grub_strcmp (argv[0], "--keep-a20") == 0)
+    {
+      flags |= GRUB_CHAINLOADER_KEEP_A20;
+      argc--;
+      argv++;
+    }
+
   if (argc == 0)
     grub_error (GRUB_ERR_BAD_ARGUMENT, "no file specified");
   else
diff --git a/loader/i386/pc/chainloader_normal.c b/loader/i386/pc/chainloader_normal.c
index 106cd56..8bae1a3 100644
--- a/loader/i386/pc/chainloader_normal.c
+++ b/loader/i386/pc/chainloader_normal.c
@@ -25,6 +25,7 @@
 static const struct grub_arg_option options[] =
   {
     {"force", 'f', 0, "skip bootsector magic number test", 0, 0},
+    {"keep-a20", 'k', 0, "keep a20 gate enabled", 0, 0},
     {0, 0, 0, 0, 0, 0}
   };
 
@@ -32,7 +33,13 @@ static grub_err_t
 chainloader_command (struct grub_arg_list *state,
 		     int argc, char **args)
 {
-  grub_chainloader_flags_t flags = state[0].set ? GRUB_CHAINLOADER_FORCE : 0;
+  int flags = 0;
+
+  if (state[0].set)
+    flags |= GRUB_CHAINLOADER_FORCE;
+
+  if (state[1].set)
+    flags |= GRUB_CHAINLOADER_KEEP_A20;
   
   if (argc == 0)
     grub_error (GRUB_ERR_BAD_ARGUMENT, "no file specified");
diff --git a/util/i386/pc/grub-setup.c b/util/i386/pc/grub-setup.c
index 043484e..ecf1682 100644
--- a/util/i386/pc/grub-setup.c
+++ b/util/i386/pc/grub-setup.c
@@ -393,7 +393,7 @@ setup (const char *dir,
 		   != (grub_ssize_t) core_size)
 	    grub_util_info ("succeeded in opening the core image but cannot read %d bytes",
 			    (int) core_size);
-	  else if (memcmp (core_img, tmp_img, core_size) != 0)
+	  else if (memcmp (core_img + 1024, tmp_img + 1024, core_size - 1024) != 0)
 	    {
 #if 0
 	      FILE *dump;

Re: [PATCH] Loading windows in macbook

[Javier Martín]

El mié, 25-06-2008 a las 04:11 +0800, Bean escribió:
> 2. Macbook will halt if we disable a20, so I add a new option
> --keep-a20 to keep the a20 gate open.
Does any OS fail to boot if it has A20 enabled when it is jumped to?
AFAIK some BIOS even had an option to enable it at POST time, so I think
we should make this new option the default and have an option called
"--reset-a20" or something like that.

Re: [PATCH] Loading windows in macbook

[Bean]

On Wed, Jun 25, 2008 at 4:38 AM, Javier Martín <lordhabbit@gmail.com> wrote:
> El mié, 25-06-2008 a las 04:11 +0800, Bean escribió:
>> 2. Macbook will halt if we disable a20, so I add a new option
>> --keep-a20 to keep the a20 gate open.
> Does any OS fail to boot if it has A20 enabled when it is jumped to?
> AFAIK some BIOS even had an option to enable it at POST time, so I think
> we should make this new option the default and have an option called
> "--reset-a20" or something like that.

I don't know of any os that would fail if a20 is enabled. Normally,
they try to enable it as soon as possible as they need to access upper
memory. So making it default is not a bad idea.

-- 
Bean

Re: [PATCH] Loading windows in macbook

[Marco Gerards]

Bean <bean123ch@gmail.com> writes:

> On Wed, Jun 25, 2008 at 4:38 AM, Javier Martín <lordhabbit@gmail.com> wrote:
>> El mié, 25-06-2008 a las 04:11 +0800, Bean escribió:
>>> 2. Macbook will halt if we disable a20, so I add a new option
>>> --keep-a20 to keep the a20 gate open.
>> Does any OS fail to boot if it has A20 enabled when it is jumped to?
>> AFAIK some BIOS even had an option to enable it at POST time, so I think
>> we should make this new option the default and have an option called
>> "--reset-a20" or something like that.
>
> I don't know of any os that would fail if a20 is enabled. Normally,
> they try to enable it as soon as possible as they need to access upper
> memory. So making it default is not a bad idea.

It's disabled for legacy reasons.  Some old DOS applications expect
addresses to wrap around.  And thus a20 gate should be disabled.

--
Marco

Re: [PATCH] Loading windows in macbook

[Bean]

On Wed, Jun 25, 2008 at 6:19 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> Bean <bean123ch@gmail.com> writes:
>
>> On Wed, Jun 25, 2008 at 4:38 AM, Javier Martín <lordhabbit@gmail.com> wrote:
>>> El mié, 25-06-2008 a las 04:11 +0800, Bean escribió:
>>>> 2. Macbook will halt if we disable a20, so I add a new option
>>>> --keep-a20 to keep the a20 gate open.
>>> Does any OS fail to boot if it has A20 enabled when it is jumped to?
>>> AFAIK some BIOS even had an option to enable it at POST time, so I think
>>> we should make this new option the default and have an option called
>>> "--reset-a20" or something like that.
>>
>> I don't know of any os that would fail if a20 is enabled. Normally,
>> they try to enable it as soon as possible as they need to access upper
>> memory. So making it default is not a bad idea.
>
> It's disabled for legacy reasons.  Some old DOS applications expect
> addresses to wrap around.  And thus a20 gate should be disabled.

Right, but new version of dos will enable a20 as well, so application
that depend on such feature would have serious compatibility issue.
Anyway, the question is whether we should leave it on by default. A20
is a common issue for buggy bios, I think we should leave it alone as
much as possible.

-- 
Bean

Re: [PATCH] Loading windows in macbook

[Yoshinori K. Okuji]

On Wednesday 25 June 2008 12:53:17 Bean wrote:
> On Wed, Jun 25, 2008 at 6:19 PM, Marco Gerards <mgerards@xs4all.nl> wrote:
> > Bean <bean123ch@gmail.com> writes:
> >> On Wed, Jun 25, 2008 at 4:38 AM, Javier Martín <lordhabbit@gmail.com> 
wrote:
> >>> El mié, 25-06-2008 a las 04:11 +0800, Bean escribió:
> >>>> 2. Macbook will halt if we disable a20, so I add a new option
> >>>> --keep-a20 to keep the a20 gate open.
> >>>
> >>> Does any OS fail to boot if it has A20 enabled when it is jumped to?
> >>> AFAIK some BIOS even had an option to enable it at POST time, so I
> >>> think we should make this new option the default and have an option
> >>> called "--reset-a20" or something like that.
> >>
> >> I don't know of any os that would fail if a20 is enabled. Normally,
> >> they try to enable it as soon as possible as they need to access upper
> >> memory. So making it default is not a bad idea.
> >
> > It's disabled for legacy reasons.  Some old DOS applications expect
> > addresses to wrap around.  And thus a20 gate should be disabled.
>
> Right, but new version of dos will enable a20 as well, so application
> that depend on such feature would have serious compatibility issue.
> Anyway, the question is whether we should leave it on by default. A20
> is a common issue for buggy bios, I think we should leave it alone as
> much as possible.

No, no, no. Please don't forget the principle: a boot loader should pass 
control in the same environment as when directly booted, as much as possible. 
All sane PC BIOSes start with a20 disabled, so it must be disabled.

Okuji

Re: [PATCH] Loading windows in macbook

[Yoshinori K. Okuji]

On Tuesday 24 June 2008 22:11:18 Bean wrote:
> This patch fix two problem that can cause problem for grub-pc in macbook.
>
> 1, In grub-setup, we should skip the first 1024 bytes when comparing
> data, as it have previously made change to the buffer with
> install_dos_part and install_bsd_part, cause the comparison to fail.
> This problem is not showed if the loader can be embedded in mbr.
>
> 2. Macbook will halt if we disable a20, so I add a new option
> --keep-a20 to keep the a20 gate open.
>
> With this patch, you can chainload windows with the following command:
>
> set root=(hd0,4)
> chainloader --keep-a20 +1
> boot

Generally speaking, it is a bad idea to make this kind of option, since most 
users don't understand why, and it is a nightmare for distributors to make 
this working correctly (when should it be enabled?).

So please try to find a way to detect the right behavior for given hardware 
automatically rather than asking the user to do so. Usually, there should be 
some data in the BIOS to identify the vendor or something.

Okuji

macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Robert Millan]

On Wed, Jun 25, 2008 at 04:11:18AM +0800, Bean wrote:
> Hi,
> 
> This patch fix two problem that can cause problem for grub-pc in macbook.

Somewhat unrelated but, it just made me remember:

I received reports that performing the keyboard workaround for macbook
twice would hang GRUB.  This is typically done when chain-loading GRUB 2
core.img from GRUB Legacy.

Does this sound plausible?  Is the workaround in GRUB 2 meant to support
system states in which it has already been performed?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Bean]

On Thu, Jun 26, 2008 at 10:13 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Wed, Jun 25, 2008 at 04:11:18AM +0800, Bean wrote:
>> Hi,
>>
>> This patch fix two problem that can cause problem for grub-pc in macbook.
>
> Somewhat unrelated but, it just made me remember:
>
> I received reports that performing the keyboard workaround for macbook
> twice would hang GRUB.  This is typically done when chain-loading GRUB 2
> core.img from GRUB Legacy.
>
> Does this sound plausible?  Is the workaround in GRUB 2 meant to support
> system states in which it has already been performed?
>

The keyboard patch for grub2 should not affect system state. It's
basically a polling mode read, with halt to prevent busy waiting.
Also, I have tried chainloading core.img from grub2, and it works
fine.

-- 
Bean

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Robert Millan]

On Thu, Jun 26, 2008 at 11:34:07PM +0800, Bean wrote:
> On Thu, Jun 26, 2008 at 10:13 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Wed, Jun 25, 2008 at 04:11:18AM +0800, Bean wrote:
> >> Hi,
> >>
> >> This patch fix two problem that can cause problem for grub-pc in macbook.
> >
> > Somewhat unrelated but, it just made me remember:
> >
> > I received reports that performing the keyboard workaround for macbook
> > twice would hang GRUB.  This is typically done when chain-loading GRUB 2
> > core.img from GRUB Legacy.
> >
> > Does this sound plausible?  Is the workaround in GRUB 2 meant to support
> > system states in which it has already been performed?
> >
> 
> The keyboard patch for grub2 should not affect system state. It's
> basically a polling mode read, with halt to prevent busy waiting.
> Also, I have tried chainloading core.img from grub2, and it works
> fine.

Strange.. does it work for you if you chainload it from GRUB Legacy?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Bean]

On Sun, Jun 29, 2008 at 7:23 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Thu, Jun 26, 2008 at 11:34:07PM +0800, Bean wrote:
>> On Thu, Jun 26, 2008 at 10:13 PM, Robert Millan <rmh@aybabtu.com> wrote:
>> > On Wed, Jun 25, 2008 at 04:11:18AM +0800, Bean wrote:
>> >> Hi,
>> >>
>> >> This patch fix two problem that can cause problem for grub-pc in macbook.
>> >
>> > Somewhat unrelated but, it just made me remember:
>> >
>> > I received reports that performing the keyboard workaround for macbook
>> > twice would hang GRUB.  This is typically done when chain-loading GRUB 2
>> > core.img from GRUB Legacy.
>> >
>> > Does this sound plausible?  Is the workaround in GRUB 2 meant to support
>> > system states in which it has already been performed?
>> >
>>
>> The keyboard patch for grub2 should not affect system state. It's
>> basically a polling mode read, with halt to prevent busy waiting.
>> Also, I have tried chainloading core.img from grub2, and it works
>> fine.
>
> Strange.. does it work for you if you chainload it from GRUB Legacy?

Hi,

But grub legacy should have the keyboard issue as well, is there a
patch for it ?

-- 
Bean

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Robert Millan]

On Sun, Jun 29, 2008 at 07:43:13PM +0800, Bean wrote:
> >
> > Strange.. does it work for you if you chainload it from GRUB Legacy?
> 
> Hi,
> 
> But grub legacy should have the keyboard issue as well, is there a
> patch for it ?

In the debian version we have this patch:

  http://svn.debian.org/viewsvn/pkg-grub/grub/trunk/debian/patches/intelmac.diff?rev=215&view=log

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Bean]

On Mon, Jun 30, 2008 at 1:36 AM, Robert Millan <rmh@aybabtu.com> wrote:
> On Sun, Jun 29, 2008 at 07:43:13PM +0800, Bean wrote:
>> >
>> > Strange.. does it work for you if you chainload it from GRUB Legacy?
>>
>> Hi,
>>
>> But grub legacy should have the keyboard issue as well, is there a
>> patch for it ?
>
> In the debian version we have this patch:
>
>  http://svn.debian.org/viewsvn/pkg-grub/grub/trunk/debian/patches/intelmac.diff?rev=215&view=log

Hi,

Oh, that patch uses busy waiting, is it good ?

Anyway, I just try chainloading core.img from grub legacy, it's ok,
the keyboard doesn't hang.

-- 
Bean

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Vesa Jääskeläinen]

Bean wrote:
> On Mon, Jun 30, 2008 at 1:36 AM, Robert Millan <rmh@aybabtu.com> wrote:
>> On Sun, Jun 29, 2008 at 07:43:13PM +0800, Bean wrote:
>>>> Strange.. does it work for you if you chainload it from GRUB Legacy?
>>> Hi,
>>>
>>> But grub legacy should have the keyboard issue as well, is there a
>>> patch for it ?
>> In the debian version we have this patch:
>>
>>  http://svn.debian.org/viewsvn/pkg-grub/grub/trunk/debian/patches/intelmac.diff?rev=215&view=log
> 
> Hi,
> 
> Oh, that patch uses busy waiting, is it good ?
> 
> Anyway, I just try chainloading core.img from grub legacy, it's ok,
> the keyboard doesn't hang.

Busy looping is the last thing we want to have.

If this is the way for mac, then detect mac and add workaround for only it.

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Robert Millan]

On Sun, Jun 29, 2008 at 09:02:19PM +0300, Vesa Jääskeläinen wrote:
> Bean wrote:
> >On Mon, Jun 30, 2008 at 1:36 AM, Robert Millan <rmh@aybabtu.com> wrote:
> >>On Sun, Jun 29, 2008 at 07:43:13PM +0800, Bean wrote:
> >>>>Strange.. does it work for you if you chainload it from GRUB Legacy?
> >>>Hi,
> >>>
> >>>But grub legacy should have the keyboard issue as well, is there a
> >>>patch for it ?
> >>In the debian version we have this patch:
> >>
> >> http://svn.debian.org/viewsvn/pkg-grub/grub/trunk/debian/patches/intelmac.diff?rev=215&view=log
> >
> >Hi,
> >
> >Oh, that patch uses busy waiting, is it good ?
> >
> >Anyway, I just try chainloading core.img from grub legacy, it's ok,
> >the keyboard doesn't hang.
> 
> Busy looping is the last thing we want to have.
> 
> If this is the way for mac, then detect mac and add workaround for only it.

This is from the patch we had for GRUB Legacy in Debian.  Don't worry about
it, official GRUB 2 has a proper hack Bean made.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: macbook keyboard workaround (Re: [PATCH] Loading windows in macbook)

[Robert Millan]

On Mon, Jun 30, 2008 at 01:56:44AM +0800, Bean wrote:
> On Mon, Jun 30, 2008 at 1:36 AM, Robert Millan <rmh@aybabtu.com> wrote:
> > On Sun, Jun 29, 2008 at 07:43:13PM +0800, Bean wrote:
> >> >
> >> > Strange.. does it work for you if you chainload it from GRUB Legacy?
> >>
> >> Hi,
> >>
> >> But grub legacy should have the keyboard issue as well, is there a
> >> patch for it ?
> >
> > In the debian version we have this patch:
> >
> >  http://svn.debian.org/viewsvn/pkg-grub/grub/trunk/debian/patches/intelmac.diff?rev=215&view=log
> 
> Hi,
> 
> Oh, that patch uses busy waiting, is it good ?
> 
> Anyway, I just try chainloading core.img from grub legacy, it's ok,
> the keyboard doesn't hang.

So strange;  must have been a bogus report.  Sorry to have bothered.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Loading windows in macbook

[Bean]

[-- Attachment #1: Type: text/plain, Size: 244 bytes --]

Hi,

Oh, actually a20 of macbook can be disabled with fast a20 port 92.
However, the current a20 code do the keyboard controller test before
trying port 92, which cause it to hang. To fix it, I only need to
adjust the order of tests.

-- 
Bean

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: a20_2.diff --]
[-- Type: text/x-diff; name=a20_2.diff, Size: 1681 bytes --]

diff --git a/kern/i386/pc/startup.S b/kern/i386/pc/startup.S
index 9542978..9752828 100644
--- a/kern/i386/pc/startup.S
+++ b/kern/i386/pc/startup.S
@@ -368,9 +368,32 @@ gate_a20_try_bios:
 	popl	%ebp
 	call	gate_a20_check_state
 	cmpb	%al, %dl
-	jnz	gate_a20_try_keyboard_controller
+	jnz	gate_a20_try_system_control_port_a
 	ret
 	
+gate_a20_try_system_control_port_a:
+	/*
+	 * In macbook, the keyboard test would hang the machine, so we move
+	 * this forward.
+	 */
+	/* fourth, try the system control port A */
+	inb	$0x92
+	andb	$(~0x03), %al
+	testb	%dl, %dl
+	jz	6f
+	orb	$0x02, %al
+6:	outb	$0x92
+
+	/* When turning off Gate A20, do not check the state strictly,
+	   because a failure is not fatal usually, and Gate A20 is always
+	   on some modern machines.  */
+	testb	%dl, %dl
+	jz	7f
+	call	gate_a20_check_state
+	cmpb	%al, %dl
+	jnz	gate_a20_try_keyboard_controller
+7:	ret
+
 gate_a20_flush_keyboard_buffer:
 	inb	$0x64
 	andb	$0x02, %al
@@ -409,28 +432,9 @@ gate_a20_try_keyboard_controller:
 
 	call	gate_a20_check_state
 	cmpb	%al, %dl
-	jnz	gate_a20_try_system_control_port_a
-	ret
-
-gate_a20_try_system_control_port_a:
-	/* fourth, try the system control port A */
-	inb	$0x92
-	andb	$(~0x03), %al
-	testb	%dl, %dl
-	jz	6f
-	orb	$0x02, %al
-6:	outb	$0x92
-
-	/* When turning off Gate A20, do not check the state strictly,
-	   because a failure is not fatal usually, and Gate A20 is always
-	   on some modern machines.  */
-	testb	%dl, %dl
-	jz	7f	
-	call	gate_a20_check_state
-	cmpb	%al, %dl
 	/* everything failed, so restart from the beginning */
 	jnz	gate_a20_try_bios
-7:	ret
+	ret
 	
 gate_a20_check_state:
 	/* iterate the checking for a while */

Re: [PATCH] Loading windows in macbook

[Marco Gerards]

Hi,

Bean <bean123ch@gmail.com> writes:

> Oh, actually a20 of macbook can be disabled with fast a20 port 92.
> However, the current a20 code do the keyboard controller test before
> trying port 92, which cause it to hang. To fix it, I only need to
> adjust the order of tests.

What is the order you propose?  I wouldn't mind such a fix since the
Intel Mac is quite popular, although changing this might break GRUB on
other systems...

--
Marco

Re: [PATCH] Loading windows in macbook

[Bean]

On Fri, Jul 4, 2008 at 2:40 AM, Marco Gerards <mgerards@xs4all.nl> wrote:
> Hi,
>
> Bean <bean123ch@gmail.com> writes:
>
>> Oh, actually a20 of macbook can be disabled with fast a20 port 92.
>> However, the current a20 code do the keyboard controller test before
>> trying port 92, which cause it to hang. To fix it, I only need to
>> adjust the order of tests.
>
> What is the order you propose?  I wouldn't mind such a fix since the
> Intel Mac is quite popular, although changing this might break GRUB on
> other systems...

Hi,

Currently, the order is

bios
keyboard controller
fast a20 port

The second test would hang macbook, so I suggest
bios
fast a20 port
keyboard controller

I don't know if it will break other system. The fast a20 port code is
simple enough, it reads from port 92, modify and write it back, system
that don't support it shouldn't be affected, unless they use port 92
for other purpose.

-- 
Bean

Re: [PATCH] Loading windows in macbook

[Marco Gerards]

Bean <bean123ch@gmail.com> writes:

> On Fri, Jul 4, 2008 at 2:40 AM, Marco Gerards <mgerards@xs4all.nl> wrote:
>> Hi,
>>
>> Bean <bean123ch@gmail.com> writes:
>>
>>> Oh, actually a20 of macbook can be disabled with fast a20 port 92.
>>> However, the current a20 code do the keyboard controller test before
>>> trying port 92, which cause it to hang. To fix it, I only need to
>>> adjust the order of tests.
>>
>> What is the order you propose?  I wouldn't mind such a fix since the
>> Intel Mac is quite popular, although changing this might break GRUB on
>> other systems...
>
> Hi,
>
> Currently, the order is
>
> bios
> keyboard controller
> fast a20 port
>
> The second test would hang macbook, so I suggest
> bios
> fast a20 port
> keyboard controller
>
> I don't know if it will break other system. The fast a20 port code is
> simple enough, it reads from port 92, modify and write it back, system
> that don't support it shouldn't be affected, unless they use port 92
> for other purpose.

This seems to be a sane order.  I would favor your solution to this
problem.  Please wait a while before you commit this, so Okuji can
comment on this in case he disagrees.

--
Marco

Re: [PATCH] Loading windows in macbook

[Bean]

On Fri, Jul 4, 2008 at 2:59 AM, Marco Gerards <mgerards@xs4all.nl> wrote:
> Bean <bean123ch@gmail.com> writes:
>
>> On Fri, Jul 4, 2008 at 2:40 AM, Marco Gerards <mgerards@xs4all.nl> wrote:
>>> Hi,
>>>
>>> Bean <bean123ch@gmail.com> writes:
>>>
>>>> Oh, actually a20 of macbook can be disabled with fast a20 port 92.
>>>> However, the current a20 code do the keyboard controller test before
>>>> trying port 92, which cause it to hang. To fix it, I only need to
>>>> adjust the order of tests.
>>>
>>> What is the order you propose?  I wouldn't mind such a fix since the
>>> Intel Mac is quite popular, although changing this might break GRUB on
>>> other systems...
>>
>> Hi,
>>
>> Currently, the order is
>>
>> bios
>> keyboard controller
>> fast a20 port
>>
>> The second test would hang macbook, so I suggest
>> bios
>> fast a20 port
>> keyboard controller
>>
>> I don't know if it will break other system. The fast a20 port code is
>> simple enough, it reads from port 92, modify and write it back, system
>> that don't support it shouldn't be affected, unless they use port 92
>> for other purpose.
>
> This seems to be a sane order.  I would favor your solution to this
> problem.  Please wait a while before you commit this, so Okuji can
> comment on this in case he disagrees.

Hi,

If no one objects, I'd commit this soon.

-- 
Bean

Re: [PATCH] Loading windows in macbook

[Robert Millan]

On Thu, Jul 17, 2008 at 11:23:10AM +0800, Bean wrote:
> 
> Hi,
> 
> If no one objects, I'd commit this soon.

Did you test in the situations:

  - core.img is load by grub legacy
  - core.img is load by grub legacy with apple keyboard patch
    (e.g. the version in debian)
  - core.img is load by grub 2

  ?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What good is a phone call… if you are unable to speak?
(as seen on /.)

Re: [PATCH] Loading windows in macbook

[Bean]

On Sat, Jul 19, 2008 at 10:29 PM, Robert Millan <rmh@aybabtu.com> wrote:
> On Thu, Jul 17, 2008 at 11:23:10AM +0800, Bean wrote:
>>
>> Hi,
>>
>> If no one objects, I'd commit this soon.
>
> Did you test in the situations:
>
>  - core.img is load by grub legacy
>  - core.img is load by grub legacy with apple keyboard patch
>    (e.g. the version in debian)
>  - core.img is load by grub 2

Hi,

Loading core.img should be ok. core.img is multiboot kernel, it don't
leave protected mode. Only chainloader command would try to disable
a20.

-- 
Bean

Re: [PATCH] Loading windows in macbook

[Bean]

Committed.

-- 
Bean