[directfd] Add support for 2880k discs, multiple open/close

[ghaerr]

Adds support for 2.88M floppies to direct FD driver, which are the same as a 1.44M floppy except 36 sectors and a 1M data FDC rate (=3). Using tables from QEMU's SeaBIOS source at https://github.com/coreboot/seabios/blob/master/src/hw/floppy.c.

This allows for a large floppy for extensive I/O testing in emulated environment.

Tested working only on QEMU. Unknown whether floppy gap1/gap2 change or other needed on real hardware.

Separates floppy_init a bit, allowing for linking direct FD driver into kernel when booting using bioshd. More work needed there, next step is to request/release IRQ and DMA on driver open/close (the way serial drivers work), rather than all the time. These changes will make direct FD and/or BIOS FD drivers optional and usable dynamically.

From some discussion on Mellvik/TLVC#24.

[ghaerr]

This PR now allows switching between the BIOS and direct floppy (DF) disk drivers, as well as booting and mounting the root filesystem on the direct floppy driver.

The ability to switch between disk drivers at runtime is nice for testing and data verification. The DF driver now allocates and deallocates its DMA and IRQ channels when opened and closed. The biggest advantage of this is that the DF driver can be linked into the kernel, and used along with the BIOS FD driver only when desired or for easy platform testing, without having to boot directly to it.

For instance, one can now do (when run from a hard disk-booted system):

hd /dev/fd0    # display from BIOS floppy
hd /dev/df0    # display from DF floppy

root=df0   # specify this in /bootopts to mount root on DF driver

Although the above shows how one can switch between drivers for reading, one can't mix the BIOS and DF drivers if a filesystem is mounted on one or the other. In other words, one can't use both drivers simultaneously. This usually means booting from HD for the time being (which is what I'm using for QEMU testing).

With the DF driver linked into the kernel and all tracing configured, we're now down to about 1K free in the near text segment. With the DF driver being so large (~7K bytes), the next step may be moving it entirely into the .fartext segment.

[toncho11]

Hi @ghaerr,

If you can provide me a 360kb image with DF configured to boot then I will test it on real hardware.

[ghaerr]

Ok @toncho11 thanks! I'm working on one now, I'm current fighting with QEMU and the DF disk driver setting the drive type to 1.2M instead of 360k when a 360k floppy is attached. The same happens for 720k, QEMU shows CMOS setting of 1.44M. This matters because the DF driver uses the CMOS settings rather than the BIOS settings for the floppy, and the DF driver doesn't do probing in the case BIOS recognizes the incorrect type, which QEMU also seems to be doing.

I'll try overriding the CMOS entry for the time being on the DF driver to 360k and see if I can get it to work. I don't want to send you something that won't boot on QEMU! :)

[ghaerr]

@toncho11, go ahead and try this. Its a MINIX 360k floppy. I can get it to boot on BIOS driver, but the DF driver fails under QEMU. I think this is a QEMU issue though since QEMU thinks its a 1.22M drive.

fd360.img.zip

[toncho11]

It fails with:

[ghaerr]

@toncho11,

Thanks a lot for testing, that helps a lot. Although the drive recognition is different between your system (whose CMOS settings appear to be set to no floppies) and QEMU, my QEMU emulation of this image is getting the same error. I don't think the issue is related to CMOS though. QEMU boots the 720k and 1.44M DF images, but not 360k, and the image you tested forces the drive type to 360k and disregards CMOS.

I'll play around with this some more until I can get it booting on QEMU and then send you another image.

Thanks a lot!

[toncho11]

Not that it matters, but the CMOS battery is disconnected on this computer. It is an Amstrad 1640 with only 1 360kb floppy and XT-IDE (and XT-IDE BIOS extension I think)