[Qemu-devel] [Patch][update] Mainstone re-org plus flash
Hello,
This includes the previous Mainstone re-org patch I sent earlier plus
flash support.
This adds two 32MiB flash devices. Mounts from mtdblock2 on flash device
0 fine at boot.
TIA
Armin
Index: qemu/hw/mainstone.c
===
--- qemu.orig/hw/mainstone.c
+++ qemu/hw/mainstone.c
@@ -14,245 +14,9 @@
#include "net.h"
#include "devices.h"
#include "boards.h"
-
-#define MST_ETH_PHYS 0x1300
-#define MST_FPGA_PHYS 0x0800
-
-/* Mainstone FPGA for extern irqs */
-#define FPGA_GPIO_PIN 0
-#define MST_NUM_IRQS 16
-#define MST_BASE MST_FPGA_PHYS
-#define MST_LEDDAT1 0x10
-#define MST_LEDDAT2 0x14
-#define MST_LEDCTRL 0x40
-#define MST_GPSWR 0x60
-#define MST_MSCWR1 0x80
-#define MST_MSCWR2 0x84
-#define MST_MSCWR3 0x88
-#define MST_MSCRD 0x90
-#define MST_INTMSKENA 0xc0
-#define MST_INTSETCLR 0xd0
-#define MST_PCMCIA0 0xe0
-#define MST_PCMCIA1 0xe4
-
-/* IRQ definitions */
-#define ETHERNET_IRQ 3
-
-typedef struct mst_irq_state {
-target_phys_addr_t target_base;
-qemu_irq *parent;
-qemu_irq *pins;
-
-uint32_t prev_level;
-uint32_t leddat1;
-uint32_t leddat2;
-uint32_t ledctrl;
-uint32_t gpswr;
-uint32_t mscwr1;
-uint32_t mscwr2;
-uint32_t mscwr3;
-uint32_t mscrd;
-uint32_t intmskena;
-uint32_t intsetclr;
-uint32_t pcmcia0;
-uint32_t pcmcia1;
-} mst_irq_state;
-
-static void
-mst_fpga_update_gpio(mst_irq_state *s)
-{
-uint32_t level, diff;
-int bit;
-level = s->prev_level ^ s->intsetclr;
-
-for (diff = s->prev_level ^ level; diff; diff ^= 1 << bit) {
-bit = ffs(diff) - 1;
-qemu_set_irq(s->pins[bit], (level >> bit) & 1 );
-}
-s->prev_level = level;
-}
-
-static void
-mst_fpga_set_irq(void *opaque, int irq, int level)
-{
-mst_irq_state *s = (mst_irq_state *)opaque;
-
-if (level)
-s->prev_level |= 1u << irq;
-else
-s->prev_level &= ~(1u << irq);
-
-if(s->intmskena & (1u << irq)) {
-s->intsetclr = 1u << irq;
-qemu_set_irq(s->parent[0], level);
-}
-}
-
-static uint32_t
-mst_fpga_readb(void *opaque, target_phys_addr_t addr)
-{
-mst_irq_state *s = (mst_irq_state *) opaque;
-addr -= s->target_base;
-
-switch (addr) {
-case MST_LEDDAT1:
-return s->leddat1;
-case MST_LEDDAT2:
-return s->leddat2;
-case MST_LEDCTRL:
-return s->ledctrl;
-case MST_GPSWR:
-return s->gpswr;
-case MST_MSCWR1:
-return s->mscwr1;
-case MST_MSCWR2:
-return s->mscwr2;
-case MST_MSCWR3:
-return s->mscwr3;
-case MST_MSCRD:
-return s->mscrd;
-case MST_INTMSKENA:
-return s->intmskena;
-case MST_INTSETCLR:
-return s->intsetclr;
-case MST_PCMCIA0:
-return s->pcmcia0;
-case MST_PCMCIA1:
-return s->pcmcia1;
-default:
-printf("Mainstone - mst_fpga_readb: Bad register offset "
-REG_FMT " \n", addr);
-}
-return 0;
-}
-
-static void
-mst_fpga_writeb(void *opaque, target_phys_addr_t addr, uint32_t value)
-{
-mst_irq_state *s = (mst_irq_state *) opaque;
-addr -= s->target_base;
-value &= 0x;
-
-switch (addr) {
-case MST_LEDDAT1:
-s->leddat1 = value;
-break;
-case MST_LEDDAT2:
-s->leddat2 = value;
-break;
-case MST_LEDCTRL:
-s->ledctrl = value;
-break;
-case MST_GPSWR:
-s->gpswr = value;
-break;
-case MST_MSCWR1:
-s->mscwr1 = value;
-break;
-case MST_MSCWR2:
-s->mscwr2 = value;
-break;
-case MST_MSCWR3:
-s->mscwr3 = value;
-break;
-case MST_MSCRD:
-s->mscrd = value;
-break;
-case MST_INTMSKENA: /* Mask interupt */
-s->intmskena = (value & 0xFEEFF);
-mst_fpga_update_gpio(s);
-break;
-case MST_INTSETCLR: /* clear or set interrupt */
-s->intsetclr = (value & 0xFEEFF);
-break;
-case MST_PCMCIA0:
-s->pcmcia0 = value;
-break;
-case MST_PCMCIA1:
-s->pcmcia1 = value;
-break;
-default:
-printf("Mainstone - mst_fpga_writeb: Bad register offset "
-REG_FMT " \n", addr);
-}
-}
-
-CPUReadMemoryFunc *mst_fpga_readfn[] = {
-mst_fpga_readb,
-mst_fpga_readb,
-mst_fpga_readb,
-};
-CPUWriteMemoryFunc *mst_fpga_writefn[] = {
-mst_fpga_writeb,
-mst_fpga_writeb,
-mst_fpga_writeb,
-};
-
-static void
-mst_fpga_save(QEMUFile *f, void *opaque)
-{
-struct mst_irq_state *s = (mst_irq_state *) opaque;
-
-qemu_put_be32s(f, &s->prev_level);
-qemu_put_be32s(f, &s->leddat1);
-qemu_put_be32s(f, &s->leddat2);
-qemu_put_be32s(f, &s->ledctrl);
-qemu_put_be32s(f, &s->gpswr);
-qemu_put_be32s(f, &s->mscwr1);
-qemu_put_be32s(f, &s->mscwr2);
-qemu_put_be32s(f, &s->mscwr3);
-qemu_put_be32s(f, &s->mscrd);
-qemu_put_be32s(f, &s
[Qemu-devel] Invalid memory access in catsrv.dll
I cannot install Windows 2000 COM+ layer under QEMU under Ubuntu 7.10 AMD64. The error message from the command "regsrv32 catsrv.dll" is "Invalid memory access in catsrv.dll".
Re: [Qemu-devel] USB performance Question
Streaming media for some reason behaves differently than usb disks, the latter which about always work. To really test a USB device, is to run a camera on it. For example a cheap Toucam Pro or such is a good start. the cameras I am using are bit more exepensive, in the thousands, so you would not be able to get one to try. Are you willing to give me exact debug instructions? Such instructions can be reused by other users, so it would not be a one-off waste. Arnon Gilboa wrote: I have just copied 138 MByte (800 files) from a disk-on-key in 75 sec. This is ~14.7Mbit/s, which is more than USB 1.1 full-speed. I have checked it using KVM and WinXP guest. With QEMU only (-no-kvm), it took 130 sec, which is ~8.5 Mbit/sec. If you can give some info about your USB device (configurations, interfaces, endpoints etc.) and the transfers (isochronous? bulk?) , it would help in solving this issue. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 5:54 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Thanks Arnon. USB1 works really great even for complex streaming cameras! Although it is just very very slow. As mentioned I only get about 10kbit/s! which is something I dont understand why. I would have expected 1Mbit/s and could live with that. If there are any test you want me to do please dont hesitate. Cant wait for your USB2 implementation. Great effort!
[Qemu-devel] qemu qemu-doc.texi
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl 07/11/26 18:46:38 Modified files: . : qemu-doc.texi Log message: Document -M SS-600MP CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.167&r2=1.168
[Qemu-devel] pflash usage question
Hello all, I have two questions regarding how to use pflash. 1) I have two 64MiB flash devices, so do I use one "-pflash" on the command line that has an image that is the total size of both flashes or use two "-pflash" on the command line. 2) The parameters for the pflash register are a bit confusing. The block size for my device is 64 but that does not work, I currently have tested it with 128. Also, the sector value, I could not find that reference in the datasheet for my flash. How should I use it? I used 128 * 1024 and that worked too. With the values I mentions above, I can mount the flash and us it as a root file system. I do get messages when I erase but I know that is not supported at the moment. If someone can set me straight on #1 and #2 then I will have be submitting flash support for the Mainstone shortly. TIA, Armin
[Qemu-devel] qemu/hw mips_malta.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/26 14:52:02 Modified files: hw : mips_malta.c Log message: Add floppy support, tested to work with www.linux-mips.org GIT head. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_malta.c?cvsroot=qemu&r1=1.51&r2=1.52
[Qemu-devel] PATCH: fix Makefile issue with make 3.79
$^ is all dependencies (ie the .c and .h files in dyngen case). Because there is only one .c file to compile, this patch will work in all cases. Tristan. diff -c -r1.136 Makefile *** Makefile24 Nov 2007 23:35:07 - 1.136 --- Makefile26 Nov 2007 13:17:41 - *** *** 132,138 # dyngen host tool dyngen$(EXESUF): dyngen.c ! $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^ clean: # avoid old build problems by removing potentially incorrect old files --- 132,138 # dyngen host tool dyngen$(EXESUF): dyngen.c ! $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $< clean: # avoid old build problems by removing potentially incorrect old files
RE: [Qemu-devel] USB performance Question
I have just copied 138 MByte (800 files) from a disk-on-key in 75 sec. This is ~14.7Mbit/s, which is more than USB 1.1 full-speed. I have checked it using KVM and WinXP guest. With QEMU only (-no-kvm), it took 130 sec, which is ~8.5 Mbit/sec. If you can give some info about your USB device (configurations, interfaces, endpoints etc.) and the transfers (isochronous? bulk?) , it would help in solving this issue. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 5:54 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Thanks Arnon. USB1 works really great even for complex streaming cameras! Although it is just very very slow. As mentioned I only get about 10kbit/s! which is something I dont understand why. I would have expected 1Mbit/s and could live with that. If there are any test you want me to do please dont hesitate. Cant wait for your USB2 implementation. Great effort! Arnon Gilboa wrote: I am in the middle of coding EHCI (USB 2.0) host controller emulation. It is supposed to support faster device speeds (480 Mbit/sec instead of USB 1.1 speeds - 1.5 or 12Mbit/sec). I will post it on the list when it basicly supports simple devices such as disk-on-key. Currently I still have some major problems with the scheduling of async and periodic frame lists. I will check your comment regarding the speed and see what can be done. Anway, if you want to try to solve the issue yourself, the relevant code is in usb-linux.c (Linux host USB redirector) and the USB UHCI/OHCI controller emulations (hw/usb-uhci.c or hw/usb-ohci.c). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 25, 2007 3:01 PM To: qemu-devel@nongnu.org Subject: Re: [Qemu-devel] USB performance Question Does anyone have a comment about this? It would be interesting to know where the USB development is going as it is extremely promising and the only small obstacle (i.m.o) for full feature device access. The only remaining barrier is speed which should be improved. I can look at the code if someone can point me to where in the sources the USB interface is. thanks [EMAIL PROTECTED] wrote: I could get very complicated USB devices to work under Qemu with Windows as guest, Linux as host. This is pretty amazing development and I must congratulate the Qemu developers. The only problem is the USB speed. I get only about 10kbit/s max! This is measured by downloading a 1MByte scientific camera image. Is this the expected USB speed at the moment or is there anything I can do to improve speed? Thanks
[Qemu-devel] [PATCH] ide: remove leftover support for 82371FB (Step A1)
The following patch removes the remaining support for the 82371FB (Step A1)
IDE chip which was added to ide.c in revision 1.53 and then removed (as
it was never used in any profile and was considered dead code) in 1.57.
This code was added to piix_pci.c in revision 1.9 and after the corresponding
code was removed from ide.c was generating the following warning :
qemu/hw/piix_pci.c:318: warning: 'piix_init' defined but not used
Carlo
---
Index: hw/piix_pci.c
===
RCS file: /sources/qemu/qemu/hw/piix_pci.c,v
retrieving revision 1.14
diff -u -p -r1.14 piix_pci.c
--- hw/piix_pci.c 18 Nov 2007 01:44:37 - 1.14
+++ hw/piix_pci.c 26 Nov 2007 09:38:57 -
@@ -314,31 +314,6 @@ static int piix_load(QEMUFile* f, void *
return pci_device_load(d, f);
}
-static int piix_init(PCIBus *bus, int devfn)
-{
-PCIDevice *d;
-uint8_t *pci_conf;
-
-d = pci_register_device(bus, "PIIX", sizeof(PCIDevice),
-devfn, NULL, NULL);
-register_savevm("PIIX", 0, 2, piix_save, piix_load, d);
-
-piix3_dev = d;
-pci_conf = d->config;
-
-pci_conf[0x00] = 0x86; // Intel
-pci_conf[0x01] = 0x80;
-pci_conf[0x02] = 0x2E; // 82371FB PIIX PCI-to-ISA bridge
-pci_conf[0x03] = 0x12;
-pci_conf[0x08] = 0x02; // Step A1
-pci_conf[0x0a] = 0x01; // class_sub = PCI_ISA
-pci_conf[0x0b] = 0x06; // class_base = PCI_bridge
-pci_conf[0x0e] = 0x80; // header_type = PCI_multifunction, generic
-
-piix3_reset(d);
-return d->devfn;
-}
-
int piix3_init(PCIBus *bus, int devfn)
{
PCIDevice *d;
[Qemu-devel] [PATCH] ide: fix GPCMD_GET_CONFIGURATION for OpenSolaris guests
The following patch complements "Partial IDE DVD emulation" which was added in
revision 1.66 and that was generating the following timeouts for OpenSolaris
guests when trying to access the ATAPI cdrom (during installation for example):
WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED] (ata1);
timeout: abort request, target=0 lun=0
WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED] (ata1):
timeout: abort device, target=0 lun=0
WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED] (ata1):
timeout: reset target, target=0 lun=0
WARNING: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],1/[EMAIL PROTECTED] (ata1):
timeout: reset bus, target=0 lun=0
It has been tested not to introduce any regressions with Linux, BSD and
Windows 2K guests and to fix the problem by installing a new guest with
Nexenta OpenSolaris alpha7.
The changes required are :
* change the model name (used by "INQUIRY" and "IDENTIFY DEVICE") to DVD
* recognize and honor "Allocation Length" parameter in "GET CONFIGURATION"
* only set "current profile" for the "GET CONFIGURATION" response if a profile
is current (CD or DVD loaded)
* calculate "data length" including all headers
* refactor code and add comments to help document references to all related
standards (ATAPI-4, SPC-3 and MMC-6)
Carlo
PS. some parts of the current implementation are for ATA-2 and not all those
standards are implemented fully AFAIK
---
Index: hw/ide.c
===
RCS file: /sources/qemu/qemu/hw/ide.c,v
retrieving revision 1.72
diff -u -p -r1.72 ide.c
--- hw/ide.c18 Nov 2007 01:44:37 - 1.72
+++ hw/ide.c26 Nov 2007 07:43:43 -
@@ -541,7 +541,7 @@ static void ide_atapi_identify(IDEState
put_le16(p + 21, 512); /* cache size in sectors */
put_le16(p + 22, 4); /* ecc bytes */
padstr((uint8_t *)(p + 23), QEMU_VERSION, 8); /* firmware version */
-padstr((uint8_t *)(p + 27), "QEMU CD-ROM", 40); /* model */
+padstr((uint8_t *)(p + 27), "QEMU DVD-ROM", 40); /* model */
put_le16(p + 48, 1); /* dword I/O (XXX: should not be set on CDROM) */
#ifdef USE_DMA_CDROM
put_le16(p + 49, 1 << 9 | 1 << 8); /* DMA and LBA supported */
@@ -1630,12 +1630,13 @@ static void ide_atapi_cmd(IDEState *s)
buf[6] = 0; /* reserved */
buf[7] = 0; /* reserved */
padstr8(buf + 8, 8, "QEMU");
-padstr8(buf + 16, 16, "QEMU CD-ROM");
+padstr8(buf + 16, 16, "QEMU DVD-ROM");
padstr8(buf + 32, 4, QEMU_VERSION);
ide_atapi_cmd_reply(s, 36, max_len);
break;
case GPCMD_GET_CONFIGURATION:
{
+uint32_t len;
int64_t total_sectors;
/* only feature 0 is supported */
@@ -1644,17 +1645,27 @@ static void ide_atapi_cmd(IDEState *s)
ASC_INV_FIELD_IN_CMD_PACKET);
break;
}
-memset(buf, 0, 32);
+max_len = ube16_to_cpu(packet + 7);
bdrv_get_geometry(s->bs, &total_sectors);
-buf[3] = 16;
-buf[7] = total_sectors <= 1433600 ? 0x08 : 0x10; /* current
profile */
-buf[10] = 0x10 | 0x1;
-buf[11] = 0x08; /* size of profile list */
+memset(buf, 0, 32);
+if (total_sectors) {
+if (total_sectors > 1433600) {
+buf[7] = 0x10; /* DVD-ROM */
+} else {
+buf[7] = 0x08; /* CD-ROM */
+}
+} else {
+buf[7] = 0x00; /* no current profile */
+}
+buf[10] = 0x02 | 0x01; /* persistent and current */
+buf[11] = 0x08; /* size of profile list = 4 bytes per profile */
buf[13] = 0x10; /* DVD-ROM profile */
-buf[14] = buf[7] == 0x10; /* (in)active */
+buf[14] = buf[13] == buf[7]; /* (in)active */
buf[17] = 0x08; /* CD-ROM profile */
-buf[18] = buf[7] == 0x08; /* (in)active */
-ide_atapi_cmd_reply(s, 32, 32);
+buf[18] = buf[17] == buf[7]; /* (in)active */
+len = 8 + 4 + buf[11]; /* headers + size of profile list */
+cpu_to_ube32(buf, len - 4); /* data length */
+ide_atapi_cmd_reply(s, len, max_len);
break;
}
default:
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer 07/11/26 09:01:34 Modified files: target-mips: translate.c Log message: Micro-optimize back-to-back store-load sequences. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.115&r2=1.116
Re: [Qemu-devel] wrong bios.bin file in Ubuntu Linux 7.10 causes blue screen on w2k guest
On Fri, Nov 23, 2007 at 02:48:34PM +0100, andrzej zaborowski wrote: >>> As far as I understand Qemu uses the BIOS from the Bochs project and >>> the diff is applied for Qemu and it becomes the Qemu BIOS. >> If that's really the case, I'm curious why it's distributed in its >> binary form rather than being built at runtime. > build-time? Perhaps because the (cross-)compiler used to build the > BIOS is not present in many distros and would be a quite inconvenient > dependency. I happened to discuss this with someone yesterday, and he pointed out something even graver, that I had somehow completely overlooked. bochs is licensed under the LGPL, so shipping a binary built from bochs without also shipping the full source, is actually in violation of bochs' license.. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature
