To my knowledge, no such driver has ever been written.
Since the very earliest versions, Linux has been a pure 32-bit protected-mode kernel that drove most devices (including disk controllers) directly, without going through the BIOS. The kernel has never had any facility to invoke 16-bit code from kernel mode during normal operation (after early boot); even the APM driver only ever supported the 32-bit protected-mode entry point. While support for 16-bit protected mode and virtual 8086 mode has been added, it was only ever driven by userspace, i.e. by DOSEMU, Wine and (userspace) VBE video drivers. The closest Linux got to a mechanism to invoke real-mode code from kernel mode is in a patch for the vesafb
driver in Linux 2.6.20 that was never merged into the mainline kernel; the patch’s successor, uvesafb
, likewise invoked the video BIOS from userspace.
In particular, there has never been a BIOS-based kernel disk driver. Such a driver does exist in ELKS (a fork of Linux focusing on embedded systems), but I assume that ELKS and mainline Linux have already diverged enough to make adapting this driver for the latter a highly non-trivial task.
Your best bet is probably to write a driver for this device yourself: either via reverse-engineering or by creating a virtual 8086 mode monitor/emulator to run the BIOS-based driver in, like userspace VBE drivers do. In the general case, I expect the latter approach to be very fragile, as the ROM BIOS code may assume that it has the entirety of the hardware at its disposal, make all sorts of assumptions about its state, and attempt to perform operations that are difficult to emulate, especially from userspace code. In particular it may try to:
- raise a System Management Interrupt (the BIOS on a laptop I am writing this on does that),
- turn off interrupts to guarantee atomicity,
- reconfigure the Programmable Interrupt Controller and other hardware,
- perform DMA transfers,
And many other things. Most of these considerations usually do not apply to video BIOSes, as those usually confine themselves to operating on the video hardware itself. As such, they only require access to I/O ports and memory, and those are rather easy to provide.
Also note that the BIOS interrupt calls were not designed to be reentrant or execute under the supervision of a multitasking operating system (they were designed as drivers for DOS, after all). Given that, environments which do provide BIOS-based disk drivers are either single-tasking systems like DOS anyway or take some pains to ensure that BIOS calls have exclusive access to all the hardware (including the CPU) and do not interfere with anything else:
- GNU GRUB 2, a boot loader containing both BIOS and ‘bare-metal’ disk drivers, is a single-tasking, pure ring-0 environment that contains some logic to ensure firmware-based and native drivers are not used at the same time;
- The real-mode mapper in Windows 9x (i.e. its DOS/BIOS file system driver) executes real-mode code in ring 0 and guards it by the critical section, which is essentially a global kernel lock (cf. Linux removing the Big Kernel Lock entirely in version 2.6.39)
All of the above told, things are not hopeless: if you stick to a narrow goal of writing a driver that works with a specific BIOS whose behaviour is known so that you can apply workarounds specific to your firmware (as opposed to creating a fully general solution), there is a good chance it might actually work quite reliably. Especially if the BIOS comes from an option ROM on an extension card, as those are much less free to assume things about other hardware that may be present.
vesafb
only calls the video BIOS once at boot, before the kernel is properly started (mode-switching is impossible afterwards), whileuvesafb
delegates BIOS calls to userspace. – user3840170 Oct 2 '20 at 17:39