qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Better floppy disk support


From: Fabrice Bellard
Subject: Re: [Qemu-devel] Better floppy disk support
Date: Wed, 12 May 2004 22:33:11 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]