From owner-freebsd-drivers@FreeBSD.ORG Tue May 22 18:30:57 2007 Return-Path: X-Original-To: freebsd-drivers@freebsd.org Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DE9D16A468 for ; Tue, 22 May 2007 18:30:57 +0000 (UTC) (envelope-from die.gestalt@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id B858313C45E for ; Tue, 22 May 2007 18:30:56 +0000 (UTC) (envelope-from die.gestalt@gmail.com) Received: by py-out-1112.google.com with SMTP id u77so129570pyb for ; Tue, 22 May 2007 11:30:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=GY63QY/UpwIC8b+VBHkI3P7O5QPdc9dGs5tOBdXdfLvEb6Mh8P63iDIHhmnW9JF1rSt5dUAcCDQXVs/IE20c0SKEHg0UwKaLeiITBUVu6nDVaLPNevKVCTBUHvWCr5y8dy2aAhQylMguzJAIJclX4m7PQOaAl839WQgDuZFTHhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=ZTpQkX/yV6kcH2Lk8XL2tN7TuaaVpuHRKEFT6oxBSe7m9Sahdw96s8U3bOdIGrkH3ghZbaBBPt06BZpaWUUX9ncER+2GOoqqhkB7SwsXvE6aHMcEpDdDIQ1qkncVzVuGRyMGfpjhI688HolfWs8EJFg92lAXxyWY+99XOb71lc0= Received: by 10.64.220.8 with SMTP id s8mr1748959qbg.1179858655131; Tue, 22 May 2007 11:30:55 -0700 (PDT) Received: by 10.64.184.8 with HTTP; Tue, 22 May 2007 11:30:55 -0700 (PDT) Message-ID: <5bf3e10d0705221130t222b80b5w64a4e446b04d6029@mail.gmail.com> Date: Tue, 22 May 2007 20:30:55 +0200 From: "Die Gestalt" To: freebsd-drivers@freebsd.org In-Reply-To: <5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff@mail.gmail.com> MIME-Version: 1.0 References: <5bf3e10d0705150724q3f0fd25fq89094bd02d8f9d29@mail.gmail.com> <86veetgnk4.fsf@dwp.des.no> <5bf3e10d0705210744s119d1c5cpc20ab1036e9f98ff@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Generic int 13h driver X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2007 18:30:57 -0000 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 wrote: > > On 5/16/07, Dag-Erling Sm=F8rgrav 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. >