[Qemu-devel] [Patch] set boot sequence from command line
Real PCs try to boot from a CD, then try the hard drive, and finally go
to the network. And they let their owner change that order.
This patch lets Qemu do the same with -boot dcn.
I'll be happy to hear comments about it,
Dan.
diff --git a/hw/an5206.c b/hw/an5206.c
index 94ecccb..2134184 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -27,7 +27,7 @@ void DMA_run (void)
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, int boot_device,
+static void an5206_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index 993a686..19689ba 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -197,7 +197,7 @@ static void mcf5208_sys_init(qemu_irq *pic)
}
}
-static void mcf5208evb_init(int ram_size, int vga_ram_size, int boot_device,
+static void mcf5208evb_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/palm.c b/hw/palm.c
index 623fcd6..971ff37 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -61,7 +61,7 @@ static void palmte_microwire_setup(struct omap_mpu_state_s
*cpu)
{
}
-static void palmte_init(int ram_size, int vga_ram_size, int boot_device,
+static void palmte_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/pc.c b/hw/pc.c
index a0c824f..3c552ff 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -152,8 +152,25 @@ static void cmos_init_hd(int type_ofs, int info_ofs,
BlockDriverState *hd)
rtc_set_memory(s, info_ofs + 8, sectors);
}
+/* convert boot_device letter to something recognizable by the bios */
+static int boot_device2nible(char boot_device)
+{
+switch(boot_device) {
+case 'a':
+case 'b':
+return 0x01; /* floppy boot */
+case 'c':
+return 0x02; /* hard drive boot */
+case 'd':
+return 0x03; /* CD-ROM boot */
+case 'n':
+return 0x04; /* Network boot */
+}
+return 0;
+}
+
/* hd_table must contain 4 block drivers */
-static void cmos_init(int ram_size, int boot_device, BlockDriverState
**hd_table)
+static void cmos_init(int ram_size, char *boot_device, BlockDriverState
**hd_table)
{
RTCState *s = rtc_state;
int val;
@@ -184,24 +201,12 @@ static void cmos_init(int ram_size, int boot_device,
BlockDriverState **hd_table
rtc_set_memory(s, 0x34, val);
rtc_set_memory(s, 0x35, val 8);
-switch(boot_device) {
-case 'a':
-case 'b':
-rtc_set_memory(s, 0x3d, 0x01); /* floppy boot */
-if (!fd_bootchk)
-rtc_set_memory(s, 0x38, 0x01); /* disable signature check */
-break;
-default:
-case 'c':
-rtc_set_memory(s, 0x3d, 0x02); /* hard drive boot */
-break;
-case 'd':
-rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */
-break;
-case 'n':
-rtc_set_memory(s, 0x3d, 0x04); /* Network boot */
-break;
-}
+/* set boot devices, and disable floppy signature check if requested */
+rtc_set_memory(s, 0x3d,
+boot_device2nible(boot_device[1]) 4 |
+boot_device2nible(boot_device[0]) );
+rtc_set_memory(s, 0x38,
+boot_device2nible(boot_device[2]) 4 | (fd_bootchk ? 0x0 : 0x1));
/* floppy type */
@@ -663,7 +668,7 @@ static void pc_init_ne2k_isa(NICInfo *nd, qemu_irq *pic)
}
/* PC hardware initialisation */
-static void pc_init1(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init1(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
@@ -947,7 +952,7 @@ static void pc_init1(int ram_size, int vga_ram_size, int
boot_device,
#endif
}
-static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init_pci(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename,
int snapshot,
const char *kernel_filename,
@@ -961,7 +966,7 @@ static void pc_init_pci(int ram_size, int vga_ram_size, int
boot_device,
initrd_filename, 1, cpu_model);
}
-static void pc_init_isa(int ram_size, int vga_ram_size, int boot_device,
+static void
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
2007/10/22, Stefan Weil [EMAIL PROTECTED]: Ivan Kalvachev schrieb: According to http://msdn2.microsoft.com/en-us/library/aa365171.aspx this function requires Win XP or Vista. Is qemu supported only on these? Good question. The old IOCTL_DISK_GET_DRIVE_GEOMETRY was also supported for W2K. Will QEMU support W2K as a host longer than MS does? It would make things easier if we dropped support for W2K hosts. If we need host support for W2K, I'll check another method to get the disk size (reading size of partition 0) and send a new patch. Please send your feedback in this case. I hope we don't need W95 or W98 host support!? Why not. :P Anyway, calling the old ioctl code if the new one fails, should be compatible enough. (and the new structure contains the old one, so no need of having 2 variables). It would be even better if somebody finds out what the error for not supported function is (I don't feel like checking 16000 error codes), but it is not critical.
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
Hi, On Wed, 24 Oct 2007, Ivan Kalvachev wrote: 2007/10/22, Stefan Weil [EMAIL PROTECTED]: Ivan Kalvachev schrieb: According to http://msdn2.microsoft.com/en-us/library/aa365171.aspx this function requires Win XP or Vista. Is qemu supported only on these? Good question. The old IOCTL_DISK_GET_DRIVE_GEOMETRY was also supported for W2K. Will QEMU support W2K as a host longer than MS does? It would make things easier if we dropped support for W2K hosts. If we need host support for W2K, I'll check another method to get the disk size (reading size of partition 0) and send a new patch. Please send your feedback in this case. I hope we don't need W95 or W98 host support!? Why not. :P Anyway, calling the old ioctl code if the new one fails, should be compatible enough. (and the new structure contains the old one, so no need of having 2 variables). It is not just that. You'll have to guard the new ioctl within #ifdef's so that it still compiles on MinGW, even if that version does not define the constant. Staying backwards compatible in this case is so easy, it is not even funny. (And certainly no reason to groan over having to support it.) Ciao, Dscho
Re: [Qemu-devel] qemu-2007-10-24 build error
On Wed, Oct 24, 2007 at 09:36:02AM +0900, Hwang YunSong(??) wrote:
gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o
console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o
block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o
block-vpc.o block-vvfat.o block-qcow2.o block-parallels.o irq.o i2c.o
smbus.o scsi-disk.o cdrom.o lsi53c895a.o usb.o usb-hub.o usb-linux.o
usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o eeprom93xx.o eepro100.o
ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o etraxfs_timer.o
etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o slirp/cksum.o
slirp/if.o slirp/ip_icmp.o slirp/ip_input.o slirp/ip_output.o
slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o slirp/socket.o
slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o slirp/tcp_timer.o
slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o libqemu.a -lm -lz
-lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil
libqemu.a(helper.o): In function `do_interrupt':
/usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined
reference to `__builtin_clz'
libqemu.a(translate-op.o): In function `dyngen_code':
/home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to
`__builtin_clz'
libqemu.a(op.o): In function `op_lz_T0_T1':
/usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined reference
to `__builtin_clz'
collect2: ld returned 1 exit status
Linux localhost.localdomain 2.6.19-10hs #1 Tue Apr 3 11:29:42 KST 2007
i686 i686 i386 GNU/Linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-Haansoft-linux
Thread model: posix
gcc version 4.1.1 20061120 (Haansoft 4.1.1-41)
Hello,
This patch adds a version of clz that does not rely on the builtin from GCC for
GCC versions where it's not expected to be available. Test were done with the
cris qemu testsuite with gcc version 4.1.2 (Gentoo 4.1.2) and with gcc version
3.3.6 (Gentoo 3.3.6-r1 p1.4, ssp-3.3.6-1.0, pie-8.7.8).
You indicate the use of a GCC 4.1.1 which AFAIK should provide the
__builtin_clz. I don't know whats going on but from the cmdline (gcc32) one
might guess that a GCC 3.2 was used. Could you verify this?
If so, this patch will hopefully solve the build problem you see.
Best regards
--
Edgar E. Iglesias
Axis Communications AB
diff --git a/target-cris/op.c b/target-cris/op.c
index 3ce9888..fbbae5b 100644
--- a/target-cris/op.c
+++ b/target-cris/op.c
@@ -1006,7 +1006,34 @@ void OPPROTO op_lz_T0_T1 (void)
if (T1 == 0)
T0 = 32;
else
+#if __GNUC__ == 3 __GNUC_MINOR__ = 4 || __GNUC__ 3
+ {
T0 = __builtin_clz(T1);
+ }
+#else
+ {
+ /* Binary search for leading zeros. */
+
+ T0 = 1;
+ if ((T1 16) == 0) {
+ T0 = T0 + 16;
+ T1 = T1 16;
+ }
+ if ((T1 24) == 0) {
+ T0 = T0 + 8;
+ T1 = T1 8;
+ }
+ if ((T1 28) == 0) {
+ T0 = T0 + 4;
+ T1 = T1 4;
+ }
+ if ((T1 30) == 0) {
+ T0 = T0 + 2;
+ T1 = T1 2;
+ }
+ T0 = T0 - (T1 31);
+ }
+#endif
RETURN();
}
Re: [Qemu-devel] qemu host-utils.c
I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. Regards, Fabrice. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/23 23:22:54 Modified files: . : host-utils.c Log message: Fix overflow when multiplying two large positive numbers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.c?cvsroot=qemur1=1.1r2=1.2
Re: [Qemu-devel] qemu-2007-10-24 build error
On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(황윤성) wrote:
gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o
console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o
block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o
block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o
block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o
usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o
eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o
etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o
slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o
slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o
slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o
slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o
libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil
libqemu.a(helper.o): In function `do_interrupt':
/usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined
reference to `__builtin_clz'
libqemu.a(translate-op.o): In function `dyngen_code':
/home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to
`__builtin_clz'
libqemu.a(op.o): In function `op_lz_T0_T1':
/usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined
reference to `__builtin_clz'
collect2: ld returned 1 exit status
It does not seem to be a good idea, imho, to use gcc builtins directly
from micro-ops. But your compiler should implement __builtin_clz. As far
as I can see, the 4.1.1 version I got (Gentoo distribution) has this
builtin implemented, then there might be a problem in your gcc package.
I used this little program to check the builtin presence and found no
version from gcc 3.4.4 to gcc 4.2.2 without __builtin_clz implemented:
int a = 123456;
int main (void)
{
int b;
b = __builtin_clz(a);
return b;
}
Compiled with gcc-version -O2 -Wall -W -o /tmp/clz /tmp/ckz.c
[...]
--
J. Mayer [EMAIL PROTECTED]
Never organized
Re: [Qemu-devel] qemu host-utils.c
On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote: I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. I fully agree with this. I still use the same code in the PowerPC op_helper.c file because I never conviced myself that the host_utils version was bug-free. I would likely switch to the common version if I could be sure it cannot lead to any regression. Thiemo Seufer wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/23 23:22:54 Modified files: . : host-utils.c Log message: Fix overflow when multiplying two large positive numbers. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/host-utils.c?cvsroot=qemur1=1.1r2=1.2 -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] Mips 64 emulation not compiling
The latest patches in clo makes gcc 3.4.6 fail to build the mips64
targets on my amd64 host (looks like an register allocation clash in the
optimizer code).
Furthermore, the clz micro-op for Mips seems very suspect to me,
according to the changes made in the clo implementation.
I did change the clz / clo implementation to use the same code as the
one used for the PowerPC implementation. It seems to me that the result
would be correct... And it compiles...
Please take a look to the folowing patch:
Index: target-mips/op.c
===
RCS file: /sources/qemu/qemu/target-mips/op.c,v
retrieving revision 1.80
diff -u -d -d -p -r1.80 op.c
--- target-mips/op.c24 Oct 2007 00:10:32 - 1.80
+++ target-mips/op.c24 Oct 2007 10:38:26 -
@@ -535,37 +535,44 @@ void op_rotrv (void)
RETURN();
}
-void op_clo (void)
+static always_inline int _do_cntlzw (uint32_t val)
{
-int n;
-
-if (T0 == ~((target_ulong)0)) {
-T0 = 32;
-} else {
-for (n = 0; n 32; n++) {
-if (!(((int32_t)T0) (1 31)))
-break;
-T0 = 1;
-}
-T0 = n;
+int cnt = 0;
+if (!(val 0xUL)) {
+cnt += 16;
+val = 16;
+}
+if (!(val 0xFF00UL)) {
+cnt += 8;
+val = 8;
}
+if (!(val 0xF000UL)) {
+cnt += 4;
+val = 4;
+}
+if (!(val 0xC000UL)) {
+cnt += 2;
+val = 2;
+}
+if (!(val 0x8000UL)) {
+cnt++;
+val = 1;
+}
+if (!(val 0x8000UL)) {
+cnt++;
+}
+return cnt;
+}
+
+void op_clo (void)
+{
+T0 = _do_cntlzw(~T0);
RETURN();
}
void op_clz (void)
{
-int n;
-
-if (T0 == 0) {
-T0 = 32;
-} else {
-for (n = 0; n 32; n++) {
-if (T0 (1 31))
-break;
-T0 = 1;
-}
-T0 = n;
-}
+T0 = _do_cntlzw(T0);
RETURN();
}
--
J. Mayer [EMAIL PROTECTED]
Never organized
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
Johannes Schindelin wrote: Hi, On Wed, 24 Oct 2007, Ivan Kalvachev wrote: 2007/10/22, Stefan Weil [EMAIL PROTECTED]: Ivan Kalvachev schrieb: According to http://msdn2.microsoft.com/en-us/library/aa365171.aspx this function requires Win XP or Vista. Is qemu supported only on these? Good question. The old IOCTL_DISK_GET_DRIVE_GEOMETRY was also supported for W2K. Will QEMU support W2K as a host longer than MS does? It would make things easier if we dropped support for W2K hosts. If we need host support for W2K, I'll check another method to get the disk size (reading size of partition 0) and send a new patch. Please send your feedback in this case. I hope we don't need W95 or W98 host support!? Why not. :P Anyway, calling the old ioctl code if the new one fails, should be compatible enough. (and the new structure contains the old one, so no need of having 2 variables). It is not just that. You'll have to guard the new ioctl within #ifdef's so that it still compiles on MinGW, even if that version does not define the constant. Staying backwards compatible in this case is so easy, it is not even funny. (And certainly no reason to groan over having to support it.) A undirected remark to the general public: If somebody comes up with a patch for better backward compatibility I'll certainly consider it. Thiemo
Re: [Qemu-devel] qemu-2007-10-24 build error
On Wed, Oct 24, 2007 at 12:33:24PM +0200, J. Mayer wrote:
On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(?) wrote:
gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o
console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o
block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o
block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o
block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o
usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o
eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o
etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o
slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o
slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o
slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o
slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o
libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil
libqemu.a(helper.o): In function `do_interrupt':
/usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined
reference to `__builtin_clz'
libqemu.a(translate-op.o): In function `dyngen_code':
/home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to
`__builtin_clz'
libqemu.a(op.o): In function `op_lz_T0_T1':
/usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined
reference to `__builtin_clz'
collect2: ld returned 1 exit status
It does not seem to be a good idea, imho, to use gcc builtins directly
from micro-ops. But your compiler should implement __builtin_clz. As far
Hi,
I submitted a patch that at compile-time fallbacks to clz code without
builtins. Do you see any additional issues with using the builtins?
I think the speed-up with GCC ports implementing fast builtin variants of
operations like clz would be significant enough to justify their use but if
there is disagreement I'll send in a new patch removing the builtin_clz
alltogether.
Best regards
as I can see, the 4.1.1 version I got (Gentoo distribution) has this
builtin implemented, then there might be a problem in your gcc package.
I used this little program to check the builtin presence and found no
version from gcc 3.4.4 to gcc 4.2.2 without __builtin_clz implemented:
int a = 123456;
int main (void)
{
int b;
b = __builtin_clz(a);
return b;
}
Compiled with gcc-version -O2 -Wall -W -o /tmp/clz /tmp/ckz.c
[...]
--
J. Mayer [EMAIL PROTECTED]
Never organized
--
Edgar E. Iglesias
Axis Communications AB
Re: [Qemu-devel] qemu-2007-10-24 build error
Edgar E. Iglesias wrote: On Wed, Oct 24, 2007 at 12:33:24PM +0200, J. Mayer wrote: On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(?) wrote: gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil libqemu.a(helper.o): In function `do_interrupt': /usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined reference to `__builtin_clz' libqemu.a(translate-op.o): In function `dyngen_code': /home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to `__builtin_clz' libqemu.a(op.o): In function `op_lz_T0_T1': /usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined reference to `__builtin_clz' collect2: ld returned 1 exit status It does not seem to be a good idea, imho, to use gcc builtins directly from micro-ops. But your compiler should implement __builtin_clz. As far Hi, I submitted a patch that at compile-time fallbacks to clz code without builtins. Do you see any additional issues with using the builtins? I think the speed-up with GCC ports implementing fast builtin variants of operations like clz would be significant enough to justify their use but if there is disagreement I'll send in a new patch removing the builtin_clz alltogether. If the builtin ends up calling into libgcc (this can happen depending on the host / host compiler), then the dynamic code generation breaks. It is safer not to force the compiler to use builtins. Thiemo
[Qemu-devel] Bug in qemu-img
I think you should already know of a bug in qemu-img that prevents it from using the -c option; the problem is the line if (flags BLOCK_FLAG_COMPRESS drv != bdrv_vmdk) in img_convert() should read if (flags BLOCK_FLAG_COMPAT6 drv != bdrv_vmdk) That's it! By the way, congratulations for the great job you have done so far. Thank you very much. Edivaldo de Araujo Pereira Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/
Re: [Qemu-devel] qemu-2007-10-24 build error
On Wed, Oct 24, 2007 at 04:33:49PM +0100, Thiemo Seufer wrote:
Edgar E. Iglesias wrote:
On Wed, Oct 24, 2007 at 12:33:24PM +0200, J. Mayer wrote:
On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(?) wrote:
gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o
console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o
block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o
block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o
block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o
usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o
eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o
etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o
slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o
slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o
slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o
slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o
libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil
libqemu.a(helper.o): In function `do_interrupt':
/usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined
reference to `__builtin_clz'
libqemu.a(translate-op.o): In function `dyngen_code':
/home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to
`__builtin_clz'
libqemu.a(op.o): In function `op_lz_T0_T1':
/usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined
reference to `__builtin_clz'
collect2: ld returned 1 exit status
It does not seem to be a good idea, imho, to use gcc builtins directly
from micro-ops. But your compiler should implement __builtin_clz. As far
Hi,
I submitted a patch that at compile-time fallbacks to clz code without
builtins. Do you see any additional issues with using the builtins?
I think the speed-up with GCC ports implementing fast builtin variants of
operations like clz would be significant enough to justify their use but if
there is disagreement I'll send in a new patch removing the builtin_clz
alltogether.
If the builtin ends up calling into libgcc (this can happen depending
on the host / host compiler), then the dynamic code generation breaks.
It is safer not to force the compiler to use builtins.
Right, if calls are made things could break. Thanks for clarifying that.
Here's a new patch to remove the builtin altogether. When building the system
simulator for CRIS I found another one which will cause build problems with
older GCC's so I replaced that one aswell.
Best regards
--
Edgar E. Iglesias
Axis Communications AB
diff --git a/target-cris/helper.c b/target-cris/helper.c
index 3db3bea..43fcdd1 100644
--- a/target-cris/helper.c
+++ b/target-cris/helper.c
@@ -87,6 +87,32 @@ static void cris_shift_ccs(CPUState *env)
env-pregs[SR_CCS] = ccs;
}
+static int cris_clz(uint32_t x)
+{
+ int n;
+ /* Binary search for leading zeros. */
+
+ n = 1;
+ if ((x 16) == 0) {
+ n = n + 16;
+ x = x 16;
+ }
+ if ((x 24) == 0) {
+ n = n + 8;
+ x = x 8;
+ }
+ if ((x 28) == 0) {
+ n = n + 4;
+ x = x 4;
+ }
+ if ((x 30) == 0) {
+ n = n + 2;
+ x = x 2;
+ }
+ n = n - (x 31);
+ return n;
+}
+
void do_interrupt(CPUState *env)
{
uint32_t ebp, isr;
@@ -135,7 +161,7 @@ void do_interrupt(CPUState *env)
}
irqnum = 31 -
- __builtin_clz(env-pending_interrupts);
+ cris_clz(env-pending_interrupts);
irqnum += 0x30;
ebp = env-pregs[SR_EBP];
isr = ldl_code(ebp + irqnum * 4);
diff --git a/target-cris/op.c b/target-cris/op.c
index 3ce9888..12188b4 100644
--- a/target-cris/op.c
+++ b/target-cris/op.c
@@ -1006,7 +1006,28 @@ void OPPROTO op_lz_T0_T1 (void)
if (T1 == 0)
T0 = 32;
else
- T0 = __builtin_clz(T1);
+ {
+ /* Binary search for leading zeros. */
+
+ T0 = 1;
+ if ((T1 16) == 0) {
+ T0 = T0 + 16;
+ T1 = T1 16;
+ }
+ if ((T1 24) == 0) {
+ T0 = T0 + 8;
+ T1 = T1 8;
+ }
+ if ((T1 28) == 0) {
+ T0 = T0 + 4;
+ T1 = T1 4;
+ }
+ if ((T1 30) == 0) {
+ T0 = T0 + 2;
+ T1 = T1 2;
+ }
+ T0 = T0 - (T1 31);
+ }
RETURN();
}
[Qemu-devel] qemu qemu-img.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/24 16:11:42 Modified files: . : qemu-img.c Log message: Fix typo, spotted by Edivaldo de Araujo Pereira. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemur1=1.21r2=1.22
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
Hi, On Wed, 24 Oct 2007, Thiemo Seufer wrote: Johannes Schindelin wrote: Staying backwards compatible in this case is so easy, it is not even funny. (And certainly no reason to groan over having to support it.) A undirected remark to the general public: If somebody comes up with a patch for better backward compatibility I'll certainly consider it. I think I fixed it. Since I am not your regular Windows user (I only use Windows when I have to), I cannot tell if it works, though. It is here: http://repo.or.cz/w/qemu/dscho.git?a=shortlog;h=diskgeometry Any testing (especially the physical drive on Windows XP) would be very much appreciated. There is also a compilation bugfix with the current CVS on Windows: the tap down script patch left a for() loop without a body. A question: on some other lists, the preferred way to submit patches is to inline them into the mail, but here I saw many attachments and/or weblinks to patches. The easiest way for me would be like I just did: provide a link to repo.or.cz. What is the preferred way on this list? Ciao, Dscho
Re: [Qemu-devel] qemu host-utils.c
J. Mayer wrote:
On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote:
I strongly suggest to reuse my code which was in target-i386/helper.c
revision 1.80 which was far easier to validate. Moreover, integer
divisions from target-i386/helper.c should be put in the same file.
I fully agree with this. I still use the same code in the PowerPC
op_helper.c file because I never conviced myself that the host_utils
version was bug-free. I would likely switch to the common version if I
could be sure it cannot lead to any regression.
Like this? Questions/Comments I have:
- Is the BSD-style copyright still ok for this version?
- The x86-64 assembler is untested for this version, could you check
it works for you?
- SPARC and Alpha look like they will break on 32bit hosts, they should
do multiplications the same way as the other 64bit targets.
Thiemo
Index: qemu-cvs/host-utils.c
===
--- qemu-cvs.orig/host-utils.c
+++ qemu-cvs/host-utils.c
@@ -1,6 +1,8 @@
/*
* Utility compute operations used by translated code.
*
+ * Copyright (c) 2003 Fabrice Bellard
+ * Copyright (c) 2003-2007 Jocelyn Mayer
* Copyright (c) 2007 Aurelien Jarno
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
@@ -24,54 +26,90 @@
#include vl.h
-/* Signed 64x64 - 128 multiplication */
+#define DEBUG_MULDEV
-void muls64(int64_t *phigh, int64_t *plow, int64_t a, int64_t b)
+/* Long integer helpers */
+static void add128 (uint64_t *plow, uint64_t *phigh, uint64_t a, uint64_t b)
{
-#if defined(__x86_64__)
-__asm__ (imul %0\n\t
- : =d (*phigh), =a (*plow)
- : a (a), 0 (b)
- );
-#else
-int64_t ph;
-uint64_t pm1, pm2, pl;
+*plow += a;
+/* carry test */
+if (*plow a)
+(*phigh)++;
+*phigh += b;
+}
+
+static void neg128 (uint64_t *plow, uint64_t *phigh)
+{
+*plow = ~*plow;
+*phigh = ~*phigh;
+add128(plow, phigh, 1, 0);
+}
-pl = (uint64_t)((uint32_t)a) * (uint64_t)((uint32_t)b);
-pm1 = (a 32) * (uint32_t)b;
-pm2 = (uint32_t)a * (b 32);
-ph = (a 32) * (b 32);
-
-ph += (int64_t)pm1 32;
-ph += (int64_t)pm2 32;
-pm1 = (uint64_t)((uint32_t)pm1) + (uint64_t)((uint32_t)pm2) + (pl 32);
+static void mul64 (uint64_t *plow, uint64_t *phigh, uint64_t a, uint64_t b)
+{
+uint32_t a0, a1, b0, b1;
+uint64_t v;
-*phigh = ph + ((int64_t)pm1 32);
-*plow = (pm1 32) + (uint32_t)pl;
-#endif
+a0 = a;
+a1 = a 32;
+
+b0 = b;
+b1 = b 32;
+
+v = (uint64_t)a0 * (uint64_t)b0;
+*plow = v;
+*phigh = 0;
+
+v = (uint64_t)a0 * (uint64_t)b1;
+add128(plow, phigh, v 32, v 32);
+
+v = (uint64_t)a1 * (uint64_t)b0;
+add128(plow, phigh, v 32, v 32);
+
+v = (uint64_t)a1 * (uint64_t)b1;
+*phigh += v;
}
+
/* Unsigned 64x64 - 128 multiplication */
-void mulu64(uint64_t *phigh, uint64_t *plow, uint64_t a, uint64_t b)
+void mulu64 (uint64_t *plow, uint64_t *phigh, uint64_t a, uint64_t b)
{
#if defined(__x86_64__)
__asm__ (mul %0\n\t
: =d (*phigh), =a (*plow)
- : a (a), 0 (b)
-);
+ : a (a), 0 (b));
#else
-uint64_t ph, pm1, pm2, pl;
+mul64(plow, phigh, a, b);
+#endif
+#if defined(DEBUG_MULDIV)
+printf(mulu64: 0x%016llx * 0x%016llx = 0x%016llx%016llx\n,
+ a, b, *phigh, *plow);
+#endif
+}
-pl = (uint64_t)((uint32_t)a) * (uint64_t)((uint32_t)b);
-pm1 = (a 32) * (uint32_t)b;
-pm2 = (uint32_t)a * (b 32);
-ph = (a 32) * (b 32);
-
-ph += pm1 32;
-ph += pm2 32;
-pm1 = (uint64_t)((uint32_t)pm1) + (uint64_t)((uint32_t)pm2) + (pl 32);
+/* Signed 64x64 - 128 multiplication */
+void muls64 (uint64_t *plow, uint64_t *phigh, int64_t a, int64_t b)
+{
+#if defined(__x86_64__)
+__asm__ (imul %0\n\t
+ : =d (*phigh), =a (*plow)
+ : a (a), 0 (b));
+#else
+int sa, sb;
-*phigh = ph + (pm1 32);
-*plow = (pm1 32) + (uint32_t)pl;
+sa = (a 0);
+if (sa)
+a = -a;
+sb = (b 0);
+if (sb)
+b = -b;
+mul64(plow, phigh, a, b);
+if (sa ^ sb) {
+neg128(plow, phigh);
+}
+#endif
+#if defined(DEBUG_MULDIV)
+printf(muls64: 0x%016llx * 0x%016llx = 0x%016llx%016llx\n,
+ a, b, *phigh, *plow);
#endif
}
Index: qemu-cvs/target-ppc/op_helper.c
===
--- qemu-cvs.orig/target-ppc/op_helper.c
+++ qemu-cvs/target-ppc/op_helper.c
@@ -217,75 +217,14 @@
/*/
/* Fixed point operations helpers */
#if defined(TARGET_PPC64)
-static void add128 (uint64_t *plow, uint64_t *phigh, uint64_t a, uint64_t b)
-{
-*plow += a;
-/* carry test */
-if (*plow a)
-(*phigh)++;
-*phigh += b;
-}
-
-static void neg128 (uint64_t *plow, uint64_t *phigh)
-{
-
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
Johannes Schindelin schrieb: I think I fixed it. Since I am not your regular Windows user (I only use Windows when I have to), I cannot tell if it works, though. It is here: http://repo.or.cz/w/qemu/dscho.git?a=shortlog;h=diskgeometry Any testing (especially the physical drive on Windows XP) would be very much appreciated. ... Ciao, Dscho With your patch, W2K will still see a wrong disk size. This is caused by the fact that the size of a modern harddisk has nothing to do with tracks per cylinder or sectors per track - it is not simply the product of four values. You can use a disk to some degree even when some part at the end is inaccessible, but it is also possible to destroy it (for example if a partition tool corrects the disk size in the boot sector) or get other kinds of errors. I prefer a patch which gives correct values for all Windows versions and will send one as soon as possible. Even without a patch, the current code in CVS HEAD still allows compilation using MinGW on any Windows. QEMU will also run on the same Windows variants as before. The only thing no longer working on W2K and older variants is physical hard disk access. I think this is better than working with a wrong disk size! Regards, Stefan
Re: [Qemu-devel] qemu host-utils.c
On Wed, 2007-10-24 at 18:37 +0100, Thiemo Seufer wrote: J. Mayer wrote: On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote: I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. I fully agree with this. I still use the same code in the PowerPC op_helper.c file because I never conviced myself that the host_utils version was bug-free. I would likely switch to the common version if I could be sure it cannot lead to any regression. Like this? Questions/Comments I have: - Is the BSD-style copyright still ok for this version? This I cannot tell. Fabrice should say how he feels about it. 1 detail: I just copied Fabrice code from i386 target, then I don't own any copyright on it... - The x86-64 assembler is untested for this version, could you check it works for you? I could check this, as I got an amd64 host. As the optimized version may lead to emit only one or a few host instructions, it may be great to have them be static inline to make gcc able to fully optimize the code. One other point: you may prefer not to change the host-utils API to avoid changes i386 and Mips. It may also be safer, to keep the x86_64 optimized code unchanged. I don't care about the argument order, I can adapt and optimize the code in the PowerPC target for this later. - SPARC and Alpha look like they will break on 32bit hosts, they should do multiplications the same way as the other 64bit targets. I don't think Alpha would not work on 32 bits hosts but I fully agree it should use the same helpers. Especially because it's obvious that umulh is bugged ! -- Jocelyn Mayer [EMAIL PROTECTED]
Re: [Qemu-devel] qemu host-utils.c
Jocelyn Mayer wrote: On Wed, 2007-10-24 at 18:37 +0100, Thiemo Seufer wrote: J. Mayer wrote: On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote: I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. I fully agree with this. I still use the same code in the PowerPC op_helper.c file because I never conviced myself that the host_utils version was bug-free. I would likely switch to the common version if I could be sure it cannot lead to any regression. Like this? Questions/Comments I have: - Is the BSD-style copyright still ok for this version? This I cannot tell. Fabrice should say how he feels about it. 1 detail: I just copied Fabrice code from i386 target, then I don't own any copyright on it... BSD-style license is OK. [...] Fabrice.
Re: [Qemu-devel] [Patch] set boot sequence from command line
Dan Kenigsberg a écrit : Real PCs try to boot from a CD, then try the hard drive, and finally go to the network. And they let their owner change that order. This patch lets Qemu do the same with -boot dcn. I'll be happy to hear comments about it, Personally, I think it's a very good idea. Laurent -- [EMAIL PROTECTED] - Given enough eyeballs, all bugs are shallow E. S. Raymond
Re: [Qemu-devel] [Patch] set boot sequence from command line
Dan Kenigsberg wrote:
Real PCs try to boot from a CD, then try the hard drive, and finally go
to the network. And they let their owner change that order.
This patch lets Qemu do the same with -boot dcn.
I'll be happy to hear comments about it,
Looks good to me. I wrote a very similar patch recently but haven't
gotten around to submitting it. I'm very eager to see this included!
Regards,
Anthony Liguori
Dan.
diff --git a/hw/an5206.c b/hw/an5206.c
index 94ecccb..2134184 100644
--- a/hw/an5206.c
+++ b/hw/an5206.c
@@ -27,7 +27,7 @@ void DMA_run (void)
/* Board init. */
-static void an5206_init(int ram_size, int vga_ram_size, int boot_device,
+static void an5206_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/mcf5208.c b/hw/mcf5208.c
index 993a686..19689ba 100644
--- a/hw/mcf5208.c
+++ b/hw/mcf5208.c
@@ -197,7 +197,7 @@ static void mcf5208_sys_init(qemu_irq *pic)
}
}
-static void mcf5208evb_init(int ram_size, int vga_ram_size, int boot_device,
+static void mcf5208evb_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/palm.c b/hw/palm.c
index 623fcd6..971ff37 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -61,7 +61,7 @@ static void palmte_microwire_setup(struct omap_mpu_state_s
*cpu)
{
}
-static void palmte_init(int ram_size, int vga_ram_size, int boot_device,
+static void palmte_init(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename, const char *cpu_model)
diff --git a/hw/pc.c b/hw/pc.c
index a0c824f..3c552ff 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -152,8 +152,25 @@ static void cmos_init_hd(int type_ofs, int info_ofs,
BlockDriverState *hd)
rtc_set_memory(s, info_ofs + 8, sectors);
}
+/* convert boot_device letter to something recognizable by the bios */
+static int boot_device2nible(char boot_device)
+{
+switch(boot_device) {
+case 'a':
+case 'b':
+return 0x01; /* floppy boot */
+case 'c':
+return 0x02; /* hard drive boot */
+case 'd':
+return 0x03; /* CD-ROM boot */
+case 'n':
+return 0x04; /* Network boot */
+}
+return 0;
+}
+
/* hd_table must contain 4 block drivers */
-static void cmos_init(int ram_size, int boot_device, BlockDriverState
**hd_table)
+static void cmos_init(int ram_size, char *boot_device, BlockDriverState
**hd_table)
{
RTCState *s = rtc_state;
int val;
@@ -184,24 +201,12 @@ static void cmos_init(int ram_size, int boot_device,
BlockDriverState **hd_table
rtc_set_memory(s, 0x34, val);
rtc_set_memory(s, 0x35, val 8);
-switch(boot_device) {
-case 'a':
-case 'b':
-rtc_set_memory(s, 0x3d, 0x01); /* floppy boot */
-if (!fd_bootchk)
-rtc_set_memory(s, 0x38, 0x01); /* disable signature check */
-break;
-default:
-case 'c':
-rtc_set_memory(s, 0x3d, 0x02); /* hard drive boot */
-break;
-case 'd':
-rtc_set_memory(s, 0x3d, 0x03); /* CD-ROM boot */
-break;
-case 'n':
-rtc_set_memory(s, 0x3d, 0x04); /* Network boot */
-break;
-}
+/* set boot devices, and disable floppy signature check if requested */
+rtc_set_memory(s, 0x3d,
+boot_device2nible(boot_device[1]) 4 |
+boot_device2nible(boot_device[0]) );
+rtc_set_memory(s, 0x38,
+boot_device2nible(boot_device[2]) 4 | (fd_bootchk ? 0x0 : 0x1));
/* floppy type */
@@ -663,7 +668,7 @@ static void pc_init_ne2k_isa(NICInfo *nd, qemu_irq *pic)
}
/* PC hardware initialisation */
-static void pc_init1(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init1(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename, int snapshot,
const char *kernel_filename, const char *kernel_cmdline,
const char *initrd_filename,
@@ -947,7 +952,7 @@ static void pc_init1(int ram_size, int vga_ram_size, int
boot_device,
#endif
}
-static void pc_init_pci(int ram_size, int vga_ram_size, int boot_device,
+static void pc_init_pci(int ram_size, int vga_ram_size, char *boot_device,
DisplayState *ds, const char **fd_filename,
int snapshot,
const char *kernel_filename,
@@ -961,7 +966,7 @@ static
Re: [Qemu-devel] [Patch] set boot sequence from command line
On Wed, Oct 24, 2007 at 04:41:20PM -0500, Anthony Liguori wrote: Dan Kenigsberg wrote: Real PCs try to boot from a CD, then try the hard drive, and finally go to the network. And they let their owner change that order. This patch lets Qemu do the same with -boot dcn. I'll be happy to hear comments about it, Looks good to me. I wrote a very similar patch recently but haven't gotten around to submitting it. I'm very eager to see this included! A more or less identical patch to this has been in Xen's fork of QEMU for quite a while works nicely, so it'd definitely be good to have this in the main QEMU codebase. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] [Patch] set boot sequence from command line
On 24/10/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote: Real PCs try to boot from a CD, then try the hard drive, and finally go to the network. And they let their owner change that order. With the difference that on real PCs this is controlled by the BIOS menu rather than a hardware switch, but the latter seems more convenient for qemu. This patch lets Qemu do the same with -boot dcn. I'll be happy to hear comments about it, Dan. diff --git a/hw/an5206.c b/hw/an5206.c index 94ecccb..2134184 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -27,7 +27,7 @@ void DMA_run (void) /* Board init. */ -static void an5206_init(int ram_size, int vga_ram_size, int boot_device, +static void an5206_init(int ram_size, int vga_ram_size, char *boot_device, DisplayState *ds, const char **fd_filename, int snapshot, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) BTW, it may be a good idea to pass all these values (maybe except ds) as a single struct, for purely practical reasons. Regards
Re: [Qemu-devel] [Patch] set boot sequence from command line
On Wed, 2007-10-24 at 23:59 +0200, andrzej zaborowski wrote: On 24/10/2007, Dan Kenigsberg [EMAIL PROTECTED] wrote: Real PCs try to boot from a CD, then try the hard drive, and finally go to the network. And they let their owner change that order. With the difference that on real PCs this is controlled by the BIOS menu rather than a hardware switch, but the latter seems more convenient for qemu. This patch lets Qemu do the same with -boot dcn. I'll be happy to hear comments about it, Dan. diff --git a/hw/an5206.c b/hw/an5206.c index 94ecccb..2134184 100644 --- a/hw/an5206.c +++ b/hw/an5206.c @@ -27,7 +27,7 @@ void DMA_run (void) /* Board init. */ -static void an5206_init(int ram_size, int vga_ram_size, int boot_device, +static void an5206_init(int ram_size, int vga_ram_size, char *boot_device, DisplayState *ds, const char **fd_filename, int snapshot, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) BTW, it may be a good idea to pass all these values (maybe except ds) as a single struct, for purely practical reasons. Regards Maybe the use of several structure may be better: - one could be used to describe the kernel boot (with kernel_filename, kernel_cmdline, initrd_filename) and could be NULL - one for the hardware emulation parameters (ram_size, vga_ram_sze, cpu_model) - one for the emulation parameters if needed (snapshot, ds...) ... It may be more consistent than use a single structure melting misc stuff that are not directly related. One remark about the submited patch: why are the boot order table limited to 3 elements ? There are at least 4 choices available today (floppy, disk, CDROM, network) and maybe more in the future for some architecture (refering to the curently emulated hardware: 2 floppies, 4 IDE devices, n network devices, SCSI storages, ...). I guess it's not a so good idea to override the boot_device table in the machine init routines. Imho, it would better be passed as a const char * argument. For the PowerPC part, there could be a local int boot_device variable that would be initialized to the first argument of the table. And this would not change the NVRAM initialisation API: if this API need to support more than one boot device in the future, it will have to be completelly reworked (for other reasons too), then I would suggest to be conservative and do not change this API at all. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu host-utils.c
On Wed, 2007-10-24 at 18:37 +0100, Thiemo Seufer wrote: J. Mayer wrote: On Wed, 2007-10-24 at 12:20 +0200, Fabrice Bellard wrote: I strongly suggest to reuse my code which was in target-i386/helper.c revision 1.80 which was far easier to validate. Moreover, integer divisions from target-i386/helper.c should be put in the same file. I fully agree with this. I still use the same code in the PowerPC op_helper.c file because I never conviced myself that the host_utils version was bug-free. I would likely switch to the common version if I could be sure it cannot lead to any regression. Like this? Questions/Comments I have: [...] - The x86-64 assembler is untested for this version, could you check it works for you? I did a small test program, comparing the result of the Fabrice implementation and the x86_64 optimized implementation results in signed and unsigned case. I used the code from the CVS from host-utils.c for the optimized case and from target-ppc/op_helper.c for the C code case. For my tests vectors, I first used a walking-one like pattern generation algorithm (including the 0 argument cases) then purely random numbers. I did more than 2^32 tests with no differences between the two implementations. What I suggest, to be safe: - do not change the current host-utils API and keep the x86_64 optimised case as it is. This way, we are sure not to break anything. - just merge Fabrice's code to replace the non-x86_64 code. As using this API could lead to more optimisations in the PowerPC implementation code, I can wait for you to commit this part and remove the private helpers as soon as you'll have commited. I will then also sanitize the Alpha case, which seems broken, even when running on 64 bits hosts. I don't know much for Sparc, then I won't change it. [...] -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] [PATCH] Update i440FX/PIIX3 emulation
The patch below updates the i440FX/PIIX3 emulation. It does:
- Add links to all datasheets containing the specifications
- Combine initialization functions for the PIIX, PIIX3 and PIIX4 chips
- Break apart long lists of magic values and name them
- Set more registers to their default values from the specs
Signed-off-by: Michael Hanselmann [EMAIL PROTECTED]
---
This does not yet remove the workaround introduced by Igor Lvovsky's
patch. However, I'm working on that since it, despite my earlier mail,
seems to help with my ACPI shutdown problem.
Greets,
Michael
Index: hw/piix_pci.c
===
RCS file: /sources/qemu/qemu/hw/piix_pci.c,v
retrieving revision 1.12
diff -u -p -r1.12 piix_pci.c
--- hw/piix_pci.c 20 Oct 2007 20:36:52 - 1.12
+++ hw/piix_pci.c 24 Oct 2007 22:39:41 -
@@ -22,12 +22,37 @@
* THE SOFTWARE.
*/
+/*
+ * Datasheets:
+ * - 82371FB (PIIX) and 82371SB (PIIX3) PCI ISA IDE Xcelerator
+ * http://www.intel.com/design/intarch/datashts/290550.htm
+ * - 82371AB PCI-TO-ISA/IDE Xcelerator (PIIX4)
+ * http://www.intel.com/design/intarch/datashts/290562.htm
+ * - 82371SB (PIIX3) PCIset Specification Update
+ * http://www.intel.com/design/chipsets/specupdt/297658.htm
+ * - 82371EB (PIIX4E) Specification Update
+ * http://developer.intel.com/design/chipsets/specupdt/290635.htm
+ * - 82371AB PIIX4, 82371EB PIIX4E and 82371MB PIIX4M Specification Update
+ * http://www.intel.com/design/chipsets/specupdt/297738.htm
+ * - 440FX PCIset - 82441FX PCI and Memory Controller (PMC) and 82442FX Data
+ * Bus Accelerator (DBX) Datasheet
+ * http://developer.intel.com/design/chipsets/datashts/290549.htm
+ * - 440FX PCIset 82441FX (PMC) and 82442FX (DBX) Specification Update
+ * http://developer.intel.com/design/chipsets/specupdt/297654.htm
+ */
+
#include vl.h
typedef uint32_t pci_addr_t;
#include pci_host.h
typedef PCIHostState I440FXState;
+enum PCIChip {
+PIIX,
+PIIX3,
+PIIX4
+};
+
static void i440fx_addr_writel(void* opaque, uint32_t addr, uint32_t val)
{
I440FXState *s = opaque;
@@ -178,16 +203,52 @@ PCIBus *i440fx_init(PCIDevice **pi440fx_
d = pci_register_device(b, i440FX, sizeof(PCIDevice), 0,
NULL, i440fx_write_config);
-d-config[0x00] = 0x86; // vendor_id
+/* Vendor Identification */
+d-config[0x00] = 0x86; /* Intel */
d-config[0x01] = 0x80;
-d-config[0x02] = 0x37; // device_id
+
+/* Device Identification */
+d-config[0x02] = 0x37;
d-config[0x03] = 0x12;
-d-config[0x08] = 0x02; // revision
+
+/* PCI Command Register */
+d-config[0x04] = 0x06;
+d-config[0x05] = 0x00;
+
+/* PCI Status Register */
+d-config[0x06] = 0x00; /* Default would be 0x80, but we don't support
+ fast back-to-back transactions as described
+ in the 440FX datasheet. */
+d-config[0x07] = 0x02;
+
+/* Revision Identification */
+d-config[0x08] = 0x02;
+
+/* Class Code */
d-config[0x0a] = 0x00; // class_sub = host2pci
d-config[0x0b] = 0x06; // class_base = PCI_bridge
-d-config[0x0e] = 0x00; // header_type
-d-config[0x72] = 0x02; /* SMRAM */
+/* Header Type */
+d-config[0x0e] = 0x00;
+
+/* PMC Configuration */
+d-config[0x50] = 0x02;
+d-config[0x51] = 0x00;
+
+/* DBX Buffer Control */
+d-config[0x53] = 0x80;
+
+/* DRAM Control */
+d-config[0x57] = 0x01;
+
+/* DRAM Timing */
+d-config[0x58] = 0x10;
+
+/* CPU Latency Timer */
+d-config[0x71] = 0x10;
+
+/* System Management RAM Control */
+d-config[0x72] = 0x02;
register_savevm(I440FX, 0, 1, i440fx_save, i440fx_load, d);
*pi440fx_state = d;
@@ -208,7 +269,7 @@ static void piix3_set_irq(qemu_irq *pic,
{
int i, pic_irq, pic_level;
-piix3_dev-config[0x60 + irq_num] = ~0x80; // enable bit
+piix3_dev-config[0x60 + irq_num] = ~0x80;
pci_irq_levels[irq_num] = level;
/* now we change the pic irq level according to the piix irq mappings */
@@ -226,160 +287,195 @@ static void piix3_set_irq(qemu_irq *pic,
}
}
-static void piix3_reset(PCIDevice *d)
+static void piix_save(QEMUFile* f, void *opaque)
{
-uint8_t *pci_conf = d-config;
+PCIDevice *d = opaque;
+pci_device_save(d, f);
+}
-pci_conf[0x04] = 0x07; // master, memory and I/O
-pci_conf[0x05] = 0x00;
-pci_conf[0x06] = 0x00;
-pci_conf[0x07] = 0x02; // PCI_status_devsel_medium
-pci_conf[0x4c] = 0x4d;
-pci_conf[0x4e] = 0x03;
-pci_conf[0x4f] = 0x00;
-pci_conf[0x60] = 0x80;
-pci_conf[0x69] = 0x02;
-pci_conf[0x70] = 0x80;
-pci_conf[0x76] = 0x0c;
-pci_conf[0x77] = 0x0c;
-pci_conf[0x78] = 0x02;
-pci_conf[0x79] = 0x00;
-pci_conf[0x80] = 0x00;
-pci_conf[0x82] = 0x00;
-pci_conf[0xa0] = 0x08;
-pci_conf[0xa2] = 0x00;
-pci_conf[0xa3] = 0x00;
-
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
Hi, On Wed, 24 Oct 2007, Stefan Weil wrote: Johannes Schindelin schrieb: I think I fixed it. Since I am not your regular Windows user (I only use Windows when I have to), I cannot tell if it works, though. It is here: http://repo.or.cz/w/qemu/dscho.git?a=shortlog;h=diskgeometry Any testing (especially the physical drive on Windows XP) would be very much appreciated. ... Ciao, Dscho With your patch, W2K will still see a wrong disk size. Funny. I thought that since kazu did the original patch, and kazu is a Windows user, that it worked at _some_ stage. Also I have to note that IOCTL_DISK_GET_DRIVE_GEOMETRY is a Windows 2000 feature, so unfortunately there is really no backwards compatibility to Windows 95/98/ME. This is caused by the fact that the size of a modern harddisk has nothing to do with tracks per cylinder or sectors per track - it is not simply the product of four values. Since it obviously worked in one setting, there might be a chance that it is fixable. Could you be a little bit more specific in what is going wrong? I.e. what is the real size, and what are the four values? Even without a patch, the current code in CVS HEAD still allows compilation using MinGW on any Windows. Yes, but a setup that was evidently working before was broken. Ciao, Dscho
