From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.34) id 1BO0Zy-00071b-Aq for qemu-devel@nongnu.org; Wed, 12 May 2004 16:43:50 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1BO0ZQ-0006rx-Bv for qemu-devel@nongnu.org; Wed, 12 May 2004 16:43:47 -0400 Received: from [193.252.22.27] (helo=mwinf0404.wanadoo.fr) by monty-python.gnu.org with esmtp (Exim 4.34) id 1BO0NU-0003dw-Fa for qemu-devel@nongnu.org; Wed, 12 May 2004 16:30:56 -0400 Received: from bellard.org (ATuileries-112-1-2-143.w80-14.abo.wanadoo.fr [80.14.188.143]) by mwinf0404.wanadoo.fr (SMTP Server) with ESMTP id 988F2380013A for ; Wed, 12 May 2004 22:30:55 +0200 (CEST) Message-ID: <40A28A07.4080706@bellard.org> Date: Wed, 12 May 2004 22:33:11 +0200 From: Fabrice Bellard MIME-Version: 1.0 Subject: Re: [Qemu-devel] Better floppy disk support References: <40A0E16D.6080400@easynet.be> In-Reply-To: <40A0E16D.6080400@easynet.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Mark Jonckheere wrote: > I propose some patches for better floppy disk support: > > 1. To make "tomsrtbt-2.0.103.ElTorito.288.img" bootable. > > The first one is in fdc.c. It removes the test in fd_init(), since it > always forces the disk type to 1.44 MB, It is better to give the first > call to fd_revalidate() a chance to decide if it is a 1.44 or 2.88 drive. This is incorrect as the BIOS configuration will be invalid. I think it is better to probe the disk image size in fd_init (just to select between 1.44 and 2.88 drives). > 2. To make my standalone chntpw-disk bootable (google for bd000607.zip). > > Booting from bd000607.img gives a segmentation error. It seems that the > bootcode on this floppy (syslinux-ldlinux) does a word-length (16-bit) > INW at address 0x80 which was translated by function default_ioport_readw() > in a call to default_ioport_readb(NULL, 0x80) and read_page(NULL, 0x81). > The second function (in dma.c) needs a (dma_cont *) pointer as its first > parameter and segfaults when it tries to dereference the NULL-pointer. > > To avoid this problem with word-length io-reads to two adjacent io-ports > from different or undefined devices it is best to translate it into two > readb calls each with its own opaque value. The function > default_ioport_readw() > is not the most logical place for doing this, it is better to do this > upstream in the function cpu_inw(). > > I modified cpu_inw() and cpu_outw(), but the same problem could also > happen with cpu_inl() and cpu_outl(). I have commited a slightly different patch (your patch breaks 16 bit I/Os and is too slow). > 3. To accept "--nics 0" as a legal argument. > > Sometimes it can be usefull to install software without ethernet support. > I made a minor modification to accept 0 as a legal value for the argument > --nics. Since the default value remains 1, nothing changes for current > usage. OK. Fabrice.