[ros-diffs] [mist] 25062: ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil. == A20 Gate and the Keyboard Controller == In order to turn on the A20 gate, the keyboard controller has to be emptied. This is done in freeldr by reading bytes until the keyboard controller signals it's empty. Intel Macs don't have PS/2 keyboard controller and the status register always reads back 0xFF, so the "there is data" bit will never be cleared. (The same problem has been in GRUB as well as in Darwin's BIOS loader.) Added code that doesn't bother to clear the keyboard buffer if the status port reads back 0xFF. == Serial Port BIOS Bug == Insyde's BIOS reports that there is a COM1 serial port at 0x3F8 (as stored in 0040:0000 in memory), but there is none in Intel Macs, so freeldr spins infinitely while trying to empty the serial port's buffer. Added code that makes sure the loop only gets executed up to 200 times
mist at svn.reactos.org
mist at svn.reactos.org
Mon Dec 4 16:00:11 CET 2006
- Previous message: [ros-diffs] [cwittich] 25061: -replaced some really stupid code -added error handling
- Next message: [ros-diffs] [mist] 25063: ReactOS Intel Mac compatibility commits, part 2/2 == LBA Functionality BIOS Bug == When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the device is a hard disk, but it will pretend that even the function to ask about this functionality is unsupported if asked about a CD drive. This is similar to what is documented in the code already: Some BIOSes return "doesn't support INT 13 extensions" for CDs. Code has been added to use INT 13 extensions (and therefore LBA read as opposed to CHS) even if the BIOS claims this is unsupported, if the device is a CD-ROM. The check for the drive type is done by comparing with 0x90: If the device number is 0x90 or above, it's a CD drive. (On Insyde's BIOS, it's 0x90, on most others, it's 0x9F). (Ironically, Insyde's BIOS cannot even do CHS on CDs, so if the bootloader correctly asks for LBA support, it will get a "no" and will fail when trying to do CHS: When querying the max. CHS values, the BIOS returns 0 sectors per track, which will make conversions from LBA to CHS impossible.) == LBA Read BIOS Bug == When trying to read from CD using the LBA function INT 13/42, the BIOS function will return as it is supposed to, with CF and AH cleared, but with an unchanged buffer. This is because freeldr passes a "disk address packets" that structure contains an extra 64 bit value at the end and is therefore 24 bytes long instead of 16. This is perfectly fine, and a BIOS should ignore any extra data in the structure, but Insyde's BIOS, which doesn't support the extra field (and thus the EDD-3.0 standard) just ignores the complete task and returns in this case. The extra field has been removed from the structure in freeldr, as it is not used anyway. The structure is now 16 bytes long.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: mist
Date: Mon Dec 4 18:00:11 2006
New Revision: 25062
URL: http://svn.reactos.org/svn/reactos?rev=25062&view=rev
Log:
ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil.
== A20 Gate and the Keyboard Controller ==
In order to turn on the A20 gate, the keyboard controller has to be emptied. This is done in freeldr by reading bytes until the keyboard controller signals it's empty. Intel Macs don't have PS/2 keyboard controller and the status register always reads back 0xFF, so the "there is data" bit will never be cleared. (The same problem has been in GRUB as well as in Darwin's BIOS loader.)
Added code that doesn't bother to clear the keyboard buffer if the status port reads back 0xFF.
== Serial Port BIOS Bug ==
Insyde's BIOS reports that there is a COM1 serial port at 0x3F8 (as stored in 0040:0000 in memory), but there is none in Intel Macs, so freeldr spins infinitely while trying to empty the serial port's buffer.
Added code that makes sure the loop only gets executed up to 200 times
Modified:
trunk/reactos/boot/freeldr/freeldr/arch/i386/arch.S
trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c
Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/arch.S
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/arch.S?rev=25062&r1=25061&r2=25062&view=diff
==============================================================================
--- trunk/reactos/boot/freeldr/freeldr/arch/i386/arch.S (original)
+++ trunk/reactos/boot/freeldr/freeldr/arch/i386/arch.S Mon Dec 4 18:00:11 2006
@@ -219,8 +219,11 @@
empty_8042:
.word 0x00eb,0x00eb // jmp $+2, jmp $+2
inb $0x64,%al
+ cmp $0xff, %al // legacy-free machine without keyboard
+ jz empty_8042_ret // controllers on Intel Macs read back 0xFF
testb $0x02,%al
jnz empty_8042
+empty_8042_ret:
ret
/*
Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c?rev=25062&r1=25061&r2=25062&view=diff
==============================================================================
--- trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c (original)
+++ trunk/reactos/boot/freeldr/freeldr/arch/i386/hardware.c Mon Dec 4 18:00:11 2006
@@ -987,7 +987,7 @@
{
CHAR Buffer[4];
ULONG i;
- ULONG TimeOut = 200;
+ ULONG TimeOut;
UCHAR LineControl;
/* Shutdown mouse or something like that */
@@ -995,9 +995,19 @@
WRITE_PORT_UCHAR((PUCHAR)Port + 4, (LineControl & ~0x02) | 0x01);
StallExecutionProcessor(100000);
- /* Clear buffer */
+ /*
+ * Clear buffer
+ * Maybe there is no serial port although BIOS reported one (this
+ * is the case on Apple hardware), or the serial port is misbehaving,
+ * therefore we must give up after some time.
+ */
+ TimeOut = 200;
while (READ_PORT_UCHAR((PUCHAR)Port + 5) & 0x01)
- READ_PORT_UCHAR((PUCHAR)Port);
+ {
+ if (--TimeOut == 0)
+ return MOUSE_TYPE_NONE;
+ READ_PORT_UCHAR((PUCHAR)Port);
+ }
/*
* Send modem control with 'Data Terminal Ready', 'Request To Send' and
@@ -1009,6 +1019,7 @@
StallExecutionProcessor(10000);
/* Read first four bytes, which contains Microsoft Mouse signs */
+ TimeOut = 200;
for (i = 0; i < 4; i++)
{
while (((READ_PORT_UCHAR((PUCHAR)Port + 5) & 1) == 0) && (TimeOut > 0))
- Previous message: [ros-diffs] [cwittich] 25061: -replaced some really stupid code -added error handling
- Next message: [ros-diffs] [mist] 25063: ReactOS Intel Mac compatibility commits, part 2/2 == LBA Functionality BIOS Bug == When the BIOS is asked whether it supports INT 13 extensions, it will answer yes if the device is a hard disk, but it will pretend that even the function to ask about this functionality is unsupported if asked about a CD drive. This is similar to what is documented in the code already: Some BIOSes return "doesn't support INT 13 extensions" for CDs. Code has been added to use INT 13 extensions (and therefore LBA read as opposed to CHS) even if the BIOS claims this is unsupported, if the device is a CD-ROM. The check for the drive type is done by comparing with 0x90: If the device number is 0x90 or above, it's a CD drive. (On Insyde's BIOS, it's 0x90, on most others, it's 0x9F). (Ironically, Insyde's BIOS cannot even do CHS on CDs, so if the bootloader correctly asks for LBA support, it will get a "no" and will fail when trying to do CHS: When querying the max. CHS values, the BIOS returns 0 sectors per track, which will make conversions from LBA to CHS impossible.) == LBA Read BIOS Bug == When trying to read from CD using the LBA function INT 13/42, the BIOS function will return as it is supposed to, with CF and AH cleared, but with an unchanged buffer. This is because freeldr passes a "disk address packets" that structure contains an extra 64 bit value at the end and is therefore 24 bytes long instead of 16. This is perfectly fine, and a BIOS should ignore any extra data in the structure, but Insyde's BIOS, which doesn't support the extra field (and thus the EDD-3.0 standard) just ignores the complete task and returns in this case. The extra field has been removed from the structure in freeldr, as it is not used anyway. The structure is now 16 bytes long.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Ros-diffs
mailing list