diff mbox

SeaBIOS error with Nextstep bootloader

Message ID 20100312015937.GA24688@morn.localdomain
State New
Headers show

Commit Message

Kevin O'Connor March 12, 2010, 1:59 a.m. UTC
On Thu, Mar 11, 2010 at 09:44:42AM +0000, Natalia Portillo wrote:
> This is everything I got.

Thanks Natalia!

> NextStep floppy images can be downloaded from http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/MultiCountry/Enterprise/nextstep/floppyimages/
> OpenStep floppy images can be downloaded from http://download.info.apple.com/Apple_Support_Area/Apple_Software_Updates/MultiCountry/Enterprise/openstep/floppyimages/

These floppy images are failing because they spin waiting for a
keypress with irqs disabled, and SeaBIOS doesn't enable irqs in the
handlers being called (same issue seen on "d090723b.zip" image
reported by Roy).

I've put a test image with a workaround for the issue at:

http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100311

See below for the patch I used - I'm still researching it, but the
image can be used for testing.

> Rhapsody floppy images are under NDA.
> Darwin CD images and bootloader source code can be downloaded from http://www.opensource.apple.com/

I was unable to locate CD images that I could download from that site.
I'm also not familiar with Darwin, and I do not know which package to
download for bootloader source.

Thanks again,
-Kevin

Comments

Natalia Portillo March 12, 2010, 9:05 a.m. UTC | #1
Hi,

> These floppy images are failing because they spin waiting for a
> keypress with irqs disabled, and SeaBIOS doesn't enable irqs in the
> handlers being called (same issue seen on "d090723b.zip" image
> reported by Roy).
>
> I've put a test image with a workaround for the issue at:
>
> http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100311
>
> See below for the patch I used - I'm still researching it, but the
> image can be used for testing.

I tested only with NeXTStep 3.3 booting from hard disk and it worked.

I'll test the rest today but considering the PS/2 mouse emulation is  
not working (there is a bug in it that prevents NeXTStep PS/2 mouse  
driver and old X11 PS/2 mouse drivers working).

But for now, it boots up to the GUI flawlessly.
Roy Tam March 13, 2010, 6:30 a.m. UTC | #2
2010/3/12 Natalia Portillo <claunia@claunia.com>:
> Hi,
>
>> These floppy images are failing because they spin waiting for a
>> keypress with irqs disabled, and SeaBIOS doesn't enable irqs in the
>> handlers being called (same issue seen on "d090723b.zip" image
>> reported by Roy).
>>
>> I've put a test image with a workaround for the issue at:
>>
>> http://linuxtogo.org/~kevin/SeaBIOS/test/bios.bin-0.5.1-debug-20100311
>>
>> See below for the patch I used - I'm still researching it, but the
>> image can be used for testing.
>
> I tested only with NeXTStep 3.3 booting from hard disk and it worked.
>
> I'll test the rest today but considering the PS/2 mouse emulation is not
> working (there is a bug in it that prevents NeXTStep PS/2 mouse driver and
> old X11 PS/2 mouse drivers working).
>

mouse problem affects Hydrogen OS too.
http://tommy.planet.free.fr/doku.php?id=hydrogen_os
Natalia Portillo March 13, 2010, 2:42 p.m. UTC | #3
Ok so in resume we have the following PS/2 mouse bugs:

NeXTStep and OpenStep PS/2 driver receives no movement at all from the  
mouse (Darwin PS/2 driver seems to be made from scratch so no helpful  
here).
MS-DOS Mouse driver hangs the whole machine.
Windows Me Setup mouse driver receives no movement at all from the  
mouse.
Old XFree86 PS/2 mouse driver receives no movement at all from  
standard protocols (PS/2, IMPS/2) or random movements (Microsoft).
Hydrogen OS mouse driver does not work.

While the NeXTStep PS/2 bug is known from QEMU 0.7.0 (which used Bochs  
BIOS), the other ones are new (as far as I know) so they may be or may  
not be caused by SeaBIOS.
Roy Tam March 13, 2010, 2:44 p.m. UTC | #4
2010/3/13 Natalia Portillo <claunia@claunia.com>:
> Ok so in resume we have the following PS/2 mouse bugs:
>
> NeXTStep and OpenStep PS/2 driver receives no movement at all from the mouse
> (Darwin PS/2 driver seems to be made from scratch so no helpful here).
> MS-DOS Mouse driver hangs the whole machine.
> Windows Me Setup mouse driver receives no movement at all from the mouse.
> Old XFree86 PS/2 mouse driver receives no movement at all from standard
> protocols (PS/2, IMPS/2) or random movements (Microsoft).
> Hydrogen OS mouse driver does not work.
>
> While the NeXTStep PS/2 bug is known from QEMU 0.7.0 (which used Bochs
> BIOS), the other ones are new (as far as I know) so they may be or may not
> be caused by SeaBIOS.
>

for Hydrogen OS, when I use QEMU BIOS (yes with my -old-bios hack) it
works in git head.
Kevin O'Connor March 13, 2010, 4:52 p.m. UTC | #5
On Sat, Mar 13, 2010 at 02:30:31PM +0800, Roy Tam wrote:
> mouse problem affects Hydrogen OS too.
> http://tommy.planet.free.fr/doku.php?id=hydrogen_os

SeaBIOS turns mouse irqs on by default - the above image doesn't like
that.

-Kevin
diff mbox

Patch

diff --git a/src/clock.c b/src/clock.c
index 5a30e35..9afa71d 100644
--- a/src/clock.c
+++ b/src/clock.c
@@ -226,6 +226,7 @@  timer_setup(void)
 static void
 handle_1a00(struct bregs *regs)
 {
+    yield();
     u32 ticks = GET_BDA(timer_counter);
     regs->cx = ticks >> 16;
     regs->dx = ticks;
diff --git a/src/config.h b/src/config.h
index 5316f22..226919b 100644
--- a/src/config.h
+++ b/src/config.h
@@ -16,9 +16,9 @@ 
 #define CONFIG_COREBOOT 0
 
 // Control how verbose debug output is.
-#define CONFIG_DEBUG_LEVEL 1
+#define CONFIG_DEBUG_LEVEL 8
 // Send debugging information to serial port
-#define CONFIG_DEBUG_SERIAL 0
+#define CONFIG_DEBUG_SERIAL 1
 // Screen writes are also sent to debug ports.
 #define CONFIG_SCREEN_AND_DEBUG 1
 
diff --git a/src/kbd.c b/src/kbd.c
index 44dce57..72f4c02 100644
--- a/src/kbd.c
+++ b/src/kbd.c
@@ -51,6 +51,7 @@  enqueue_key(u8 scan_code, u8 ascii_code)
 static void
 dequeue_key(struct bregs *regs, int incr, int extended)
 {
+    yield();
     u16 buffer_head;
     u16 buffer_tail;
     for (;;) {
@@ -530,9 +531,19 @@  process_key(u8 key)
         // allow for keyboard intercept
         u32 eax = (0x4f << 8) | key;
         u32 flags;
+#if 0
         call16_simpint(0x15, &eax, &flags);
         if (!(flags & F_CF))
             return;
+#else
+        struct bregs br;
+        memset(&br, 0, sizeof(br));
+        br.eax = eax;
+        call16_int(0x15, &br);
+        flags = br.flags;
+        if (!(flags & F_CF))
+            return;
+#endif
         key = eax;
     }
     __process_key(key);