From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E70D2C3A589 for ; Tue, 20 Aug 2019 14:55:37 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BE0C022DA7 for ; Tue, 20 Aug 2019 14:55:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BE0C022DA7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38262 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i05Xt-0007Jv-1E for qemu-devel@archiver.kernel.org; Tue, 20 Aug 2019 10:55:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58032) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i05XA-0006cr-0M for qemu-devel@nongnu.org; Tue, 20 Aug 2019 10:54:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i05X8-0008B7-3k for qemu-devel@nongnu.org; Tue, 20 Aug 2019 10:54:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53994) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i05X7-00089R-SD for qemu-devel@nongnu.org; Tue, 20 Aug 2019 10:54:50 -0400 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D584A81F2F for ; Tue, 20 Aug 2019 14:54:48 +0000 (UTC) Received: by mail-wm1-f72.google.com with SMTP id g127so880406wme.0 for ; Tue, 20 Aug 2019 07:54:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HvtMLH+rcsaVFuJykLgYe5cdb973jI6rnQhTe6HW0jI=; b=dakSk+jd0bgk5oZNYt8V4Ujb7pYgIsKyzpwJHUOW/hJS4huUa8PISnEiJRh3RfqgCn FO7eudH2DV2lpLvEmn6SjhawxEscdUYet10Eql/M9P0QkkXVHg8Ag7kaJodw1CkofCIW 4EucX27VwMR2fUx6Oj9ks4CPufkmZ34m1QGxg+zorS/RJoNAX7ppYyMXCOdyzSI4Kyms fpHpZgnZe7/3xQLLvPeEJdep6F7NCBSDcatV+ns9TfNL4LHlvyk/RZ5dDNa9JkoaGVdI Imuizn3Fyz4tlyNs+jq/meaZlInsqcGVmOspH8EwVfrF9EfON0soJQLZtRpisuY1j5s5 Xj3w== X-Gm-Message-State: APjAAAWLAkrEbtdmz4v/QsqHottp/QWUHTR3CYrdzev6dRZySeYogTu9 8ws9QQ5QwDDSIwxaqOfk5HoT1zaJgPT10coSRibPJDYen3mINqaYuQAI2A35AKDqkVqDHZsALEc 8Rx8+PmOHa6uq3Gc= X-Received: by 2002:a05:600c:2486:: with SMTP id 6mr467332wms.80.1566312887552; Tue, 20 Aug 2019 07:54:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqyHDhF/srFxOsZnzNj5YUhFUXo7H3NFmrthLzYc2DR1foUB7JOwPtMtYmLBw6H+z8u+CWX5aQ== X-Received: by 2002:a05:600c:2486:: with SMTP id 6mr467308wms.80.1566312887282; Tue, 20 Aug 2019 07:54:47 -0700 (PDT) Received: from [192.168.1.39] (251.red-88-10-102.dynamicip.rima-tde.net. [88.10.102.251]) by smtp.gmail.com with ESMTPSA id u6sm131595wmm.26.2019.08.20.07.54.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Aug 2019 07:54:46 -0700 (PDT) To: "Dr. David Alan Gilbert" References: <699eee57-3009-4160-a9a2-1070f92b9c20@redhat.com> <1a45cee8-66e1-448d-78bc-4f0b9695cab4@redhat.com> <20190820143614.GJ2867@work-vm> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Openpgp: id=89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE; url=http://pgp.mit.edu/pks/lookup?op=get&search=0xA2A3FD6EDEADC0DE Message-ID: <70fd81a1-08bb-5cc8-616c-68ec2a7472e2@redhat.com> Date: Tue, 20 Aug 2019 16:54:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20190820143614.GJ2867@work-vm> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [SeaBIOS] Re: Regression with floppy drive controller X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alex , Nikolay Nikolov , seabios@seabios.org, John Snow , QEMU Developers Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 8/20/19 4:36 PM, Dr. David Alan Gilbert wrote: > * Philippe Mathieu-Daud=C3=A9 (philmd@redhat.com) wrote: >> On 8/20/19 3:38 PM, Philippe Mathieu-Daud=C3=A9 wrote: >>> On 8/20/19 3:12 PM, John Snow wrote: >>>> On 8/20/19 6:25 AM, Philippe Mathieu-Daud=C3=A9 wrote: >>>>> [cross posting QEMU & SeaBIOS] >>>>> >>>>> Hello, >>>>> >>>>> I'v been looking at a QEMU bug report [1] which bisection resulted = in a >>>>> SeaBIOS commit: >>>>> >>>>> 4a6dbcea3e412fe12effa2f812f50dd7eae90955 is the first bad commit >>>>> commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955 >>>>> Author: Nikolay Nikolov >>>>> Date: Sun Feb 4 17:27:01 2018 +0200 >>>>> >>>>> floppy: Use timer_check() in floppy_wait_irq() >>>>> >>>>> Use timer_check() instead of using floppy_motor_counter in BDA = for the >>>>> timeout check in floppy_wait_irq(). >>>>> >>>>> The problem with using floppy_motor_counter was that, after it = reaches >>>>> 0, it immediately stops the floppy motors, which is not what is >>>>> supposed to happen on real hardware. Instead, after a timeout (= like in >>>>> the end of every floppy operation, regardless of the result - s= uccess, >>>>> timeout or error), the floppy motors must be kept spinning for >>>>> additional 2 seconds (the FLOPPY_MOTOR_TICKS). So, now the >>>>> floppy_motor_counter is initialized to 255 (the max value) in t= he >>>>> beginning of the floppy operation. For IRQ timeouts, a differen= t >>>>> timeout is used, specified by the new FLOPPY_IRQ_TIMEOUT consta= nt >>>>> (currently set to 5 seconds - a fairly conservative value, but = should >>>>> work reliably on most floppies). >>>>> >>>>> After the floppy operation, floppy_drive_pio() resets the >>>>> floppy_motor_counter to 2 seconds (FLOPPY_MOTOR_TICKS). >>>>> >>>>> This is also consistent with what other PC BIOSes do. >>>>> >>>>> >>>>> This commit improve behavior with real hardware, so maybe QEMU is n= ot >>>>> modelling something or modelling it incorrectly? [...] >> Looking at the fdc timer I noticed it use a static '50 ns' magic value= . >=20 > That's not 50ns >=20 >> Increasing this value allows the floppy image to boot again, using thi= s >> snippet: >> >> -- >8 -- >> diff --git a/hw/block/fdc.c b/hw/block/fdc.c >> index 9b24cb9b85..5fc54073fd 100644 >> --- a/hw/block/fdc.c >> +++ b/hw/block/fdc.c >> @@ -2134,7 +2134,7 @@ static void fdctrl_handle_readid(FDCtrl *fdctrl, >> int direction) >> >> cur_drv->head =3D (fdctrl->fifo[1] >> 2) & 1; >> timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRT= UAL) + >> - (NANOSECONDS_PER_SECOND / 50)); >=20 > That's 1/50th of a second in ns. Just noticed that too, so we have here 20ms. >> + (NANOSECONDS_PER_SECOND / 5000)); >=20 > I'm not too sure about readid; but assuming we're rotating at 360rpm, > that's 6 revolutions/second, and 18 sectors/track =3D 108 sectors/secon= d > (half of that for a double density disk). >=20 > So, the wait for a sector to spin around and read feels like it should > be in the region of 1/108 of a second + some latency - so 1/50th of a > second would seem to be in the ballpark or being right, where as 1/5000 > of a second is way too fast for a poor old floppy. The first command sent is READ_ID. Reading the Intel 82077AA datasheet: The READ ID command is used to find the present position of the recording heads. The 82077AA stores the values from the first ID Field it is able to read into its registers. If the 82077AA does not find an ID Address Mark on the diskette after the second occurrence of a pulse on the IDX pin, it then sets the IC code in Status Register 0 to =E2=80=98=E2=80=9801=E2=80=99=E2=80=99 = (Abnormal ter- mination), sets the MA bit in Status Register 1 to =E2=80=98=E2=80=991=E2=80=99=E2=80=99, and terminates the command. Then later the SPECIFICATIONS table: nRD/nWR Pulse Width: min 90ns INDEX Pulse Width: min 5 'Internal Clock Period' The nominal values for the 'internal clock period' for the various data rates are: 1 Mbps: 3 * osc period =3D 125ns 500 Kbps: 6 * osc period =3D 250ns 300 Kbps: 10 * osc period =3D 420ns 250 Kbps: 12 * osc period =3D 500ns IIUC the model we have DATARATE SELECT REGISTER (DSR) =3D 0 So DRATESEL=3D0 =3D> datarate =3D 500 Kbps So we should wait at least 250ns. Trying the following snippet it also works: -- >8 -- @@ -2133,8 +2133,8 @@ static void fdctrl_handle_readid(FDCtrl *fdctrl, int direction) FDrive *cur_drv =3D get_cur_drv(fdctrl); cur_drv->head =3D (fdctrl->fifo[1] >> 2) & 1; - timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL= ) + - (NANOSECONDS_PER_SECOND / 50)); + timer_mod(fdctrl->result_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL= ) + + 250); } --- Note this is not the spining-up delay on reset: Before data can be transferred to or from the disk- ette, the disk drive motor must be brought up to speed. For most 3(/2 =C3=97 disk drives, the spin-up time is 300 ms, while the 5(/4 =C3=97 drive usually requires about 500 ms due to the increased moment of inertia asso- ciated with the larger diameter diskette. This looks more closer to the 20ms order. So maybe what we miss here is a RESET delay (of 500ms?) previous to the READ_ID?