Mailing List Archive: Syslinux Bootsector

Syslinux Bootsector

May 15, 2002, 3:47 AM

Post #1 of 4 (1390 views)

Hi!

Facing a strange problem about not being able to access
the floppy drive after booting from a rescue-floppy with
2.2.x kernel on an asus p4te mainboard, i searched the
net and found a bug in the bootsector of the 2.2.x kernels.
Before control is redirected to the kernel, the floppy drive
is shut down in a way, that freezes the FD-Controller on
recent mainboards (like the ASUS P4T-E).
The Syslinux-Bootsector (at least until version 1.72) uses
the same method of "stopping" the floppy; this makes the
installation with multiple floppies impossible.
I'd like to submit a change of the SysLinux Bootsector that
is based on the newer 2.4.x kernel approaches to that problem
and worked fine for me:

;
; Linux wants the floppy motor shut off before starting the kernel,
; at least bootsect.S seems to imply so
;
kill_motor:
push ax
push dx
xor ax,ax
xor dx,dx
int 13h
pop dx
pop ax

instead of

mov dx,03F2h
xor al,al
call slow_out

Thx for any comments,
Martin Neuhaeusser

--
\ /
---==( o )==---

PGP encrypted messages preferred. Public-Key at:
http://sawfish.weh.rwth-aachen.de/~martin/index.html

Syslinux Bootsector [ In reply to ]

hpa at zytor

May 15, 2002, 2:27 PM

Post #2 of 4 (1352 views)

Permalink

martin@weh.rwth-aachen.de wrote:
> Hi!
>
> Facing a strange problem about not being able to access
> the floppy drive after booting from a rescue-floppy with
> 2.2.x kernel on an asus p4te mainboard, i searched the
> net and found a bug in the bootsector of the 2.2.x kernels.
> Before control is redirected to the kernel, the floppy drive
> is shut down in a way, that freezes the FD-Controller on
> recent mainboards (like the ASUS P4T-E).
> The Syslinux-Bootsector (at least until version 1.72) uses
> the same method of "stopping" the floppy; this makes the
> installation with multiple floppies impossible.
> I'd like to submit a change of the SysLinux Bootsector that
> is based on the newer 2.4.x kernel approaches to that problem
> and worked fine for me:
>
> ;
> ; Linux wants the floppy motor shut off before starting the kernel,
> ; at least bootsect.S seems to imply so
> ;
> kill_motor:
> push ax
> push dx
> xor ax,ax
> xor dx,dx
> int 13h
> pop dx
> pop ax
>
> instead of
>
> mov dx,03F2h
> xor al,al
> call slow_out
>

Looks sensible. In fact, that particular poking directly on the floppy
controller has been bugging me for quite a while... it's simply not the
Right Thing to do since you don't know for sure that the int 13h device
and the hardware floppy is the same thing, especially not in the
presence of IDE/USB floppy or things like MEMDISK.

-hpa

Syslinux Bootsector [ In reply to ]

mterlo1 at uic

May 15, 2002, 3:13 PM

Post #3 of 4 (1320 views)

Permalink

>
> Looks sensible. In fact, that particular poking directly on the
floppy
> controller has been bugging me for quite a while... it's simply not
the
> Right Thing to do since you don't know for sure that the int 13h
device
> and the hardware floppy is the same thing, especially not in the
> presence of IDE/USB floppy or things like MEMDISK.
>
> -hpa
>

I can't remember where exactly I borrowed this from (some os boot
loader), but it works and it tricks the BIOS into shutting down the
motor (therefore no knowledge of the underlying hardware is necessary).

mov cx, 100 ; advance BIOS counter 100 times

.shut_down_floppy_motor:

int 8 ; call the PIT's interrupt handler
loop .shut_down_floppy_motor ; make BIOS think time
is ticking

You can vary cx as you see fit, and preserve/restore the tick count in
the BIOS data segment if you're worried about artificially advancing the
timer.

Another case where programming the FDC directly won't work is on the
Toshiba Libretto, where the floppy disk is a PCMCIA device. The ports
mapped to the PC card are not the standard FDC ports.

Syslinux Bootsector [ In reply to ]

hpa at zytor

May 15, 2002, 5:12 PM

Post #4 of 4 (1336 views)

Permalink

Michael K Ter Louw wrote:
>>
> I can't remember where exactly I borrowed this from (some os boot
> loader), but it works and it tricks the BIOS into shutting down the
> motor (therefore no knowledge of the underlying hardware is necessary).
>

I think I like calling the actual reset API entrypoint better...! (INT
13h AH=0 is RESET SUBSYSTEM.)

-hpa