On Fri, Jun 12, 2020 at 08:26:49PM +0200, felix wrote:
Hello,
Not so long ago, I have stumbled upon some rather disappointing behaviour in the SeaBIOS floppy driver. After some investigations, I concluded it would in fact be worthy of a bug report. So here it is.
The problem is that when SeaBIOS starts, it looks up the type of the floppy drive in firmware configuration variables and internally stores a maximum disk geometry corresponding to the type of the drive. This geometry is later used to validate interrupt 0x13 requests and internally convert them to use LBA sector numbers, which are later converted back into CHS when communicating with the floppy controller. This design – apart from being somewhat silly in itself, with the shoehorned CHS-to-LBA-to-CHS conversion – prevents using SeaBIOS’s interrupt 0x13 service with superformatted floppies, i.e. those with geometries larger than typical for the initially detected drive type, even if the drive itself could handle such floppies without problems.
FYI, the SeaBIOS floppy code originates from the legacy "bochs bios" implementation, which was only targeted at VM setups. It has since been extended to work on real hardware. However, the goal has only been to get standard setups working as there isn't much demand for floppies these days (even emulated floppies).
It's fine if you (or someone else) wishes to submit code to extend the floppy code. I am aware that it isn't fully "standards compliant", but no one has yet cared enough to take on the substantial work of an upgrade. If you (or someone else) does wish to take this on, it will be necessary to identify several real-world test cases for the floppy driver - both for the new features and for existing support. And be willing to run all those test cases. Testing will be crucial for any work as we don't want to introduce a regression as a trade-off to adding support for a relatively rare use case
Cheers, -Kevin