Date: Mon, 21 May 2007 16:44:50 +0200 From: "Die Gestalt" <die.gestalt@gmail.com> To: "=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=" <des@des.no> Cc: freebsd-drivers@freebsd.org Subject: Re: Generic int 13h driver Message-ID: <5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff@mail.gmail.com> In-Reply-To: <86veetgnk4.fsf@dwp.des.no> References: <5bf3e10d0705150724q3f0fd25fq89094bd02d8f9d29@mail.gmail.com> <86veetgnk4.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
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 where = I > > > will not be able to update my kernel and where I want to support as muc= h > > 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 lef= t > > > 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 to > 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?5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff>