Date: Tue, 22 May 2007 20:30:55 +0200 From: "Die Gestalt" <die.gestalt@gmail.com> To: freebsd-drivers@freebsd.org Subject: Re: Generic int 13h driver Message-ID: <5bf3e10d0705221130t222b80b5w64a4e446b04d6029@mail.gmail.com> In-Reply-To: <5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff@mail.gmail.com> References: <5bf3e10d0705150724q3f0fd25fq89094bd02d8f9d29@mail.gmail.com> <86veetgnk4.fsf@dwp.des.no> <5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Muhahah, despite the world conspiracy against my evil plot to enslave disk drivers with the BIOS I now manage to write to the disk. But I get a : kernel: stray irq14 Of course irq14 is the IRQ of the disk controller. The int13h returns with = a status time out, but the writes succeeded anyways (he had no choice: I have sharks with laser beams attached to their heads). I can see my random bytes when I open the disk with an hex editor. I think what happens is that the BIOS never gets its IRQ14 "back" and cannot acknowledge that the operation went fine. Any hint? On 5/21/07, Die Gestalt <die.gestalt@gmail.com> wrote: > > On 5/16/07, Dag-Erling Sm=F8rgrav <des@des.no > wrote: > > > > "Die Gestalt" < die.gestalt@gmail.com> writes: > > > As the subject implies I'm currently doing the most unholy thing ever= . > > I'm > > > writing a driver that accesses hard disks through BIOS int13h. The > > reasons > > > why I'm doing this are many, but mainly I will be in a situation wher= e > > I > > > will not be able to update my kernel and where I want to support as > > much > > > devices as possible. I know this will be slow and I know this will > > only work > > > on the i386 platform, I accept that. > > > > It won't work nearly as universally as you intend; for some devices > > (particularly USB devices), the BIOS tries to enter protected mode when > > servicing requests. > > > I know there will be some limitations unfortunately. > > > So far so good, I have a skeleton which is able to query the drive > > > parameters and some basic stuff. But when I want to read, this doesn'= t > > work, > > > except in QEmu (http://www.qemu.org). I've tried on a VMWare and a > > real > > > machine, what I get is a stall for maybe 10 s (sometimes not) and the > > > operations returns saying it's successful but my buffer is actually > > left > > > untouched. I get no kernel message. > > > > Have you verified that the buffer you write from or read into is mapped > > correctly in virtual 8086 mode, and that you pass the correct address t= o > > > > the BIOS? > > > I think so. It works when I request a buffer to be filled with > information. For instance function 48h of the int 13h correctly fills my > buffer. > > To pass the address I use vm86_addpage to update a vm86context and then I > pass this context to vm86_datacall. > > I think this might be a DMA problem. When the BIOS writes to the buffer, > it does it via DMA, and I get typical DMA problems. However I've tried to > use a buffer allocated via buf_dmamem_alloc() to no success. > > Thanks for your answer. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5bf3e10d0705221130t222b80b5w64a4e446b04d6029>