Re: [Qemu-devel] [patch] More PCI ethernet emulations

Re: [Qemu-devel] [patch] More PCI ethernet emulations

[Ben Taylor]

---- Stefan Weil <weil@mail.berlios.de> wrote: 
> Hi,
> 
> File eepro100.tar.bz2 (added to this mail) contains everything
> needed to add 3 new PCI network device (all similar to EEPRO100):
> 
> eepro100.patch:
>     Makefile.target:
>         added two binaries needed for EEPRO100
>         split entries for PCI network devices (1 line / entry, better
> merging with CVS)
>     vl.h:
>        added prototypes for EEPRO100
>     hw/pci.c:
>        added new PCI network models: i82551, i82557b, i82559er
> 
> hw/eepro100.c:
>     EEPRO100 PCI network emulation
> 
> hw/eeprom93xx.c, hw/eeprom93xx.h:
>     EEPROM emulation, needed for EEPRO100 (and others)
> 
> I just finished running these tests using a PC host running Debian GNU
> Linux:
> 
> * compilation for all QEMU target architectures: ok
> * cross compilation (Windows) for all QEMU target architectures: ok
> * functional test: ok
> 
> The last test was started like this:
> 
> i386-softmmu/qemu -L pc-bios --net nic,model=i82559er --net tap /dev/hda
> --snapshot
> 
> Networking was tested using ping and ssh connection from emulated system
> to host.
> 
> I did not apply your patch, because I cannot test it (it needs a system with
> different endianess). Your feedback is welcome
> 
I have a question.  in eepro100_write2, I see a word (16-bits) being
passed in, but only the low part of the word gets written to the eeprom.
Since it's a word write, shouldn't it be writing both bytes to the eeprom?

Ben

Re: [Qemu-devel] [patch] More PCI ethernet emulations

[Stefan Weil]

Good question. I stumbled about this, too, when I looked
at the code how I could apply your patch. Some months
had past since I wrote it :-)

The code writes to a serial EEPROM, so the 16 bits are
sent using only a clock and a single data bit. The
EEPROM emulation then takes the single bits and puts
them together.

The function gets a byte which contains clock, data and
two other significant bits, and 4 bits which are always 0.

When called with a word, only one byte is needed.
Maybe it is the wrong one - if you work with different
endianess.

I'l have a look at the other problems next weekend.

Stefan

Ben Taylor wrote:
> I have a question. in eepro100_write2, I see a word (16-bits) being
> passed in, but only the low part of the word gets written to the eeprom.
> Since it's a word write, shouldn't it be writing both bytes to the eeprom?
>
> Ben

Re: [Qemu-devel] [patch] More PCI ethernet emulations

[Thiemo Seufer]

Stefan Weil wrote:
> Good question. I stumbled about this, too, when I looked
> at the code how I could apply your patch. Some months
> had past since I wrote it :-)
> 
> The code writes to a serial EEPROM, so the 16 bits are
> sent using only a clock and a single data bit. The
> EEPROM emulation then takes the single bits and puts
> them together.
> 
> The function gets a byte which contains clock, data and
> two other significant bits, and 4 bits which are always 0.
> 
> When called with a word, only one byte is needed.
> Maybe it is the wrong one - if you work with different
> endianess.

The card is detected on ppc/Linux emulating mipsel/Linux, but
no interface is configured. It works on x86/Linux emulating
mipsel/Linux.


Thiemo

[Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

[Stefan Weil]

[-- Attachment #1: Type: text/plain, Size: 178 bytes --]

Hello,

here is a patch which makes VGA usable for Malta MIPS32 in big endian
mode. I don't know whether other big endian emulations need a
patch for VGA, too.

Regards
Stefan



[-- Attachment #2: vga.patch --]
[-- Type: text/x-diff, Size: 1190 bytes --]

Index: hw/vga_template.h
===================================================================
RCS file: /sources/qemu/qemu/hw/vga_template.h,v
retrieving revision 1.13
diff -u -b -B -r1.13 vga_template.h
--- hw/vga_template.h	11 May 2006 21:54:44 -0000	1.13
+++ hw/vga_template.h	14 Jun 2007 20:10:25 -0000
@@ -327,6 +327,16 @@
     palette = s1->last_palette;
     width >>= 3;
     for(x = 0; x < width; x++) {
+#if defined(TARGET_WORDS_BIGENDIAN)
+        ((PIXEL_TYPE *)d)[3] = palette[s[0]];
+        ((PIXEL_TYPE *)d)[2] = palette[s[1]];
+        ((PIXEL_TYPE *)d)[1] = palette[s[2]];
+        ((PIXEL_TYPE *)d)[0] = palette[s[3]];
+        ((PIXEL_TYPE *)d)[7] = palette[s[4]];
+        ((PIXEL_TYPE *)d)[6] = palette[s[5]];
+        ((PIXEL_TYPE *)d)[5] = palette[s[6]];
+        ((PIXEL_TYPE *)d)[4] = palette[s[7]];
+#else
         ((PIXEL_TYPE *)d)[0] = palette[s[0]];
         ((PIXEL_TYPE *)d)[1] = palette[s[1]];
         ((PIXEL_TYPE *)d)[2] = palette[s[2]];
@@ -335,6 +345,7 @@
         ((PIXEL_TYPE *)d)[5] = palette[s[5]];
         ((PIXEL_TYPE *)d)[6] = palette[s[6]];
         ((PIXEL_TYPE *)d)[7] = palette[s[7]];
+#endif
         d += BPP * 8;
         s += 8;
     }

Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

[Fabrice Bellard]

The problem must come from somewhere else. VGA (as any other device) 
must not depend on the target CPU endianness (note that the endianness 
tests in the memory handlers are only necessary because the bus API is 
still incomplete).

Regards,

Fabrice.

Stefan Weil wrote:
> Hello,
> 
> here is a patch which makes VGA usable for Malta MIPS32 in big endian
> mode. I don't know whether other big endian emulations need a
> patch for VGA, too.
> 
> Regards
> Stefan
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: hw/vga_template.h
> ===================================================================
> RCS file: /sources/qemu/qemu/hw/vga_template.h,v
> retrieving revision 1.13
> diff -u -b -B -r1.13 vga_template.h
> --- hw/vga_template.h	11 May 2006 21:54:44 -0000	1.13
> +++ hw/vga_template.h	14 Jun 2007 20:10:25 -0000
> @@ -327,6 +327,16 @@
>      palette = s1->last_palette;
>      width >>= 3;
>      for(x = 0; x < width; x++) {
> +#if defined(TARGET_WORDS_BIGENDIAN)
> +        ((PIXEL_TYPE *)d)[3] = palette[s[0]];
> +        ((PIXEL_TYPE *)d)[2] = palette[s[1]];
> +        ((PIXEL_TYPE *)d)[1] = palette[s[2]];
> +        ((PIXEL_TYPE *)d)[0] = palette[s[3]];
> +        ((PIXEL_TYPE *)d)[7] = palette[s[4]];
> +        ((PIXEL_TYPE *)d)[6] = palette[s[5]];
> +        ((PIXEL_TYPE *)d)[5] = palette[s[6]];
> +        ((PIXEL_TYPE *)d)[4] = palette[s[7]];
> +#else
>          ((PIXEL_TYPE *)d)[0] = palette[s[0]];
>          ((PIXEL_TYPE *)d)[1] = palette[s[1]];
>          ((PIXEL_TYPE *)d)[2] = palette[s[2]];
> @@ -335,6 +345,7 @@
>          ((PIXEL_TYPE *)d)[5] = palette[s[5]];
>          ((PIXEL_TYPE *)d)[6] = palette[s[6]];
>          ((PIXEL_TYPE *)d)[7] = palette[s[7]];
> +#endif
>          d += BPP * 8;
>          s += 8;
>      }
> 

Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

[Fabrice Bellard]

I realize that the other pixel formats are buggy too, so at least your 
patch is consistent with what is already coded !

I guess the problem is in the VGA memory handlers. Otherwise it means 
that there is a (Cirrus)VGA configuration register to change the 
endianness of the frame buffer. In such case, it must be emulated correctly.

Regards,

Fabrice.

Stefan Weil wrote:
> Hello,
> 
> here is a patch which makes VGA usable for Malta MIPS32 in big endian
> mode. I don't know whether other big endian emulations need a
> patch for VGA, too.
> 
> Regards
> Stefan
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: hw/vga_template.h
> ===================================================================
> RCS file: /sources/qemu/qemu/hw/vga_template.h,v
> retrieving revision 1.13
> diff -u -b -B -r1.13 vga_template.h
> --- hw/vga_template.h	11 May 2006 21:54:44 -0000	1.13
> +++ hw/vga_template.h	14 Jun 2007 20:10:25 -0000
> @@ -327,6 +327,16 @@
>      palette = s1->last_palette;
>      width >>= 3;
>      for(x = 0; x < width; x++) {
> +#if defined(TARGET_WORDS_BIGENDIAN)
> +        ((PIXEL_TYPE *)d)[3] = palette[s[0]];
> +        ((PIXEL_TYPE *)d)[2] = palette[s[1]];
> +        ((PIXEL_TYPE *)d)[1] = palette[s[2]];
> +        ((PIXEL_TYPE *)d)[0] = palette[s[3]];
> +        ((PIXEL_TYPE *)d)[7] = palette[s[4]];
> +        ((PIXEL_TYPE *)d)[6] = palette[s[5]];
> +        ((PIXEL_TYPE *)d)[5] = palette[s[6]];
> +        ((PIXEL_TYPE *)d)[4] = palette[s[7]];
> +#else
>          ((PIXEL_TYPE *)d)[0] = palette[s[0]];
>          ((PIXEL_TYPE *)d)[1] = palette[s[1]];
>          ((PIXEL_TYPE *)d)[2] = palette[s[2]];
> @@ -335,6 +345,7 @@
>          ((PIXEL_TYPE *)d)[5] = palette[s[5]];
>          ((PIXEL_TYPE *)d)[6] = palette[s[6]];
>          ((PIXEL_TYPE *)d)[7] = palette[s[7]];
> +#endif
>          d += BPP * 8;
>          s += 8;
>      }
> 

Re: [Qemu-devel] [Bug][Patch] Cirrus-VGA for Malta

[Derek Fawcus]

On Mon, Sep 24, 2007 at 11:22:30PM +0200, Fabrice Bellard wrote:
> I realize that the other pixel formats are buggy too, so at least your 
> patch is consistent with what is already coded !
> 
> I guess the problem is in the VGA memory handlers. Otherwise it means 
> that there is a (Cirrus)VGA configuration register to change the 
> endianness of the frame buffer. In such case, it must be emulated correctly.

I don't know about a register (w/o reading the docs),  but I seem to recall
that it does have a second PCI FB window which is byte swapped specifically
for BE machines...

DF

Re: [Qemu-devel] [patch] More PCI ethernet emulations

[Stefan Weil]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

Hi,

File eepro100.tar.bz2 (added to this mail) contains everything
needed to add 3 new PCI network device (all similar to EEPRO100):

eepro100.patch:
    Makefile.target:
        added two binaries needed for EEPRO100
        split entries for PCI network devices (1 line / entry, better
merging with CVS)
    vl.h:
       added prototypes for EEPRO100
    hw/pci.c:
       added new PCI network models: i82551, i82557b, i82559er

hw/eepro100.c:
    EEPRO100 PCI network emulation

hw/eeprom93xx.c, hw/eeprom93xx.h:
    EEPROM emulation, needed for EEPRO100 (and others)

I just finished running these tests using a PC host running Debian GNU
Linux:

* compilation for all QEMU target architectures: ok
* cross compilation (Windows) for all QEMU target architectures: ok
* functional test: ok

The last test was started like this:

i386-softmmu/qemu -L pc-bios --net nic,model=i82559er --net tap /dev/hda
--snapshot

Networking was tested using ping and ssh connection from emulated system
to host.

I did not apply your patch, because I cannot test it (it needs a system with
different endianess). Your feedback is welcome

Stefan





Ben Taylor wrote:
> ---- Stefan Weil <berlios@weilnetz.de> wrote:
>> Hello,
>>
>> these new ethernet drivers for QEMU are now available:
>>
>> Intel 8255x ("E100", "EEPRO100"):
>> http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eepro100.c?op=file
>
> Having been through this with the rlt8139.c driver,
>
> I can expect that the area around:
>
> static void nic_selective_reset(EEPRO100State * s)
> {
> size_t i;
> uint16_t *eeprom_contents = eeprom93xx_data(s->eeprom);
> //~ eeprom93xx_reset(s->eeprom);
> memcpy(eeprom_contents, s->macaddr, 6);
>
> will need to change the memcpy to something like:
>
> s->macaddr[0] = eeprom_contents[0] || eeprom_contents[1]<<8;
> s->macaddr[2] = eeprom_contents[2] || eeprom_contents[3]<<8;
> s->macaddr[4] = eeprom_contents[4] || eeprom_contents[5]<<8;
>
> I'll try to give it whack tommorow. Do you have some glue on the
> Makefile.target?
>
> Ben
>
>
> Both drivers use a new EEPROM driver:
> http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eeprom93xx.c?op=file
> http://svn.berlios.de/wsvn/ar7-firmware/qemu/trunk/hw/eeprom93xx.h?op=file
>
> This EEPROM driver can be shared by any other device which needs
> an EEPROM, for example replace the driver for RTL8139 or add an
> EEPROM to cirrus vga or other ethernet cards.
>
> I estimate the status of the EEPROM driver to be stable.
> Fabrice, maybe this part can be integrated in QEMU head.
>
> Both ethernet drivers work with QEMU head and Linux on x86 host / guest,
> but have known endianess issues (they will at least need fixes for big
> endian hosts) and are experimental. I am still working on them.
>
> Feedback and bug fixes are welcome.
>
> Regards
> Stefan

[-- Attachment #2: eepro100.tar.bz2 --]
[-- Type: application/octet-stream, Size: 14485 bytes --]