[Qemu-devel] Updated 3c509 NIC patch.

[Qemu-devel] Updated 3c509 NIC patch.

[Karel Gardas]

Hello,

I would like to ask if anybody here does have an updated 3c509 MIC patch
as available on: http://www.dad-answers.com/qemu/patches/3COM_NIC-ISA-PnP/
?

I've tried to find the right point in CVS to apply this patch, and then
update CVS, but unfortunatelly resulting qemu crashes on network
initializatoin if I understand it well:

#0  0x00000000 in ?? ()
#1  0x0804c0f5 in qemu_add_read_packet (nd=0x8266b68,
fd_can_read=0x807f150 <tcm509_can_receive>,
    fd_read=0x807f150 <tcm509_can_receive>, opaque=0x807f150) at
/home/karel/cvs/qemu/qemu-3c509-cvs-update/vl.c:1351
#2  0x0807fa01 in pnp_3c509b_init (base=1, irq=150525419, nd=0x8266b68)
    at /home/karel/cvs/qemu/qemu-3c509-cvs-update/hw/3c509b.c:1124
#3  0x0806b60e in pc_init (ram_size=33554432, vga_ram_size=4194304,
boot_device=134738256, ds=0x80df660, fd_filename=0xbfffebec,
    snapshot=0, kernel_filename=0x0, kernel_cmdline=0x807f150
"\213D$\004\213\220", initrd_filename=0x0)
    at /home/karel/cvs/qemu/qemu-3c509-cvs-update/hw/pc.c:543
#4  0x0804ebd0 in main (argc=26, argv=0xbffff004) at
/home/karel/cvs/qemu/qemu-3c509-cvs-update/vl.c:3384


Thanks,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Antony T Curtis]

On Wed, 2005-01-19 at 11:51 +0100, Karel Gardas wrote:
> Hello,
> 
> I would like to ask if anybody here does have an updated 3c509 MIC patch
> as available on: http://www.dad-answers.com/qemu/patches/3COM_NIC-ISA-PnP/
> ?
> 
> I've tried to find the right point in CVS to apply this patch, and then
> update CVS, but unfortunatelly resulting qemu crashes on network
> initializatoin if I understand it well:

Hmm... I haven't updated the 3c509b or the PnP patches because I thought
there was little/no interest. I'll dig through my repositories and see
if I can refresh them, as I expect there has been a lot of change in 6
months.

Regards,

Antony,

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Antony T Curtis]

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

Hi,

I have updated the patch... but I have not tested them.

For the 3c509b support, the isapnp patch should be applied first.

On Wed, 2005-01-19 at 11:51 +0100, Karel Gardas wrote:
> Hello,
> 
> I would like to ask if anybody here does have an updated 3c509 MIC patch
> as available on: http://www.dad-answers.com/qemu/patches/3COM_NIC-ISA-PnP/
> ?

<snip>

Regards,

	Antony

[-- Attachment #2: qemu-3c509b.20050119.patch.gz --]
[-- Type: application/x-gzip, Size: 8721 bytes --]

[-- Attachment #3: qemu-isapnp.20050119.patch.gz --]
[-- Type: application/x-gzip, Size: 9716 bytes --]

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Karel Gardas]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1732 bytes --]


Hi,

your patches do not compile cleanly. Attached patch solves these two minor
issues. Also while starting, it crashes with this trace.

(gdb) r
Starting program:
/home/karel/usr/src/cvs/qemu/qemu-3c509-antony-update-fix/i386-softmmu/qemu
-fda /tmp/grub-boot2.flp -hda /mnt/karel/rtems.img -boot a -3c509b
[Thread debugging using libthread_db enabled]
[New Thread 1024 (LWP 28669)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 28669)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x08084fff in pnp_3c509b_init (base=1, irq=1, nd=0x8283068)
    at /home/karel/cvs/qemu/qemu-3c509-antony-update-fix/hw/3c509b.c:1124
#2  0x0806f839 in pc_init (ram_size=134217728, vga_ram_size=4194304,
boot_device=97, ds=0x80fbdc0, fd_filename=0xbfffe9dc,
    snapshot=0, kernel_filename=0x0, kernel_cmdline=0x8283068 "",
initrd_filename=0x0)
    at /home/karel/cvs/qemu/qemu-3c509-antony-update-fix/hw/pc.c:558
#3  0x0804e3a3 in main (argc=8, argv=0xbffff104) at
/home/karel/cvs/qemu/qemu-3c509-antony-update-fix/vl.c:3663
(gdb)


I think this is the same trace as I obtained with my CVS updated tree.

Thanks,
Karel

On Wed, 19 Jan 2005, Antony T Curtis wrote:

> Hi,
>
> I have updated the patch... but I have not tested them.
>
> For the 3c509b support, the isapnp patch should be applied first.
>
> On Wed, 2005-01-19 at 11:51 +0100, Karel Gardas wrote:
> > Hello,
> >
> > I would like to ask if anybody here does have an updated 3c509 MIC patch
> > as available on: http://www.dad-answers.com/qemu/patches/3COM_NIC-ISA-PnP/
> > ?
>
> <snip>
>
> Regards,
>
> 	Antony
>

--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com



[-- Attachment #2: Type: TEXT/PLAIN, Size: 967 bytes --]

diff -ru qemu-3c509-antony-update/hw/3c509b.c qemu-3c509-antony-update-fix/hw/3c509b.c
--- qemu-3c509-antony-update/hw/3c509b.c	Wed Jan 19 18:40:17 2005
+++ qemu-3c509-antony-update-fix/hw/3c509b.c	Wed Jan 19 19:14:25 2005
@@ -333,7 +333,7 @@
     d->tx_status[d->tx_tail++] = 0x80 | (d->txbuffer[0] & 0x8000? 0x40 : 0);
     if (d->tx_tail >= TCM_STATUS_SIZE)
         d->tx_tail = 0;
-    if (TCM_STAT_ENABLE(d)) {
+    if (TCM_STAT_ENABLED(d)) {
         if (((d->tx_bytes < 0x8000) && (d->tx_bytes + size)) ||
             (d->tx_frames == 0x80))
             d->status |= 0x0080;
diff -ru qemu-3c509-antony-update/vl.h qemu-3c509-antony-update-fix/vl.h
--- qemu-3c509-antony-update/vl.h	Wed Jan 19 18:40:19 2005
+++ qemu-3c509-antony-update-fix/vl.h	Wed Jan 19 18:43:12 2005
@@ -680,7 +680,7 @@
 
 /* 3c509b.c */
 
-extern int tcm509b_enable;
+extern int tcm509b_enabled;
 
 void pnp_3c509b_init(int base, int irq, NetDriverState *nd);
 

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Antony T Curtis]

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

On Thu, 2005-01-20 at 10:31 +0100, Karel Gardas wrote:
> On Wed, 19 Jan 2005, Antony T Curtis wrote:
> 
> > Hi,
> >
> > I think I have found the bug... will be making a new patch soon.
> 
> Great! Thanks!

Actually, I have not only found the bug you encountered, but I have
found some other bugs in the implementation.

I have also implemented a "info pnp" command.

I have tested it with the following guests: FreeBSD 4, NetBSD 2 and
Linux (Mandrake 8) with up to 4 NICs configured (dummynet).

Hope this works for you,

> Karel
> --
> Karel Gardas                  kgardas@objectsecurity.com
> ObjectSecurity Ltd.           http://www.objectsecurity.com
> 
-- 
Antony T Curtis, BSc.                   UNIX, Linux, *BSD, Networking
antony.t.curtis@ntlworld.com            C++, J2EE, Perl, MySQL, Apache
                                        IT Consultancy.

[-- Attachment #2: qemu-3c509b.20050120.patch.gz --]
[-- Type: application/x-gzip, Size: 8863 bytes --]

[-- Attachment #3: qemu-isapnp.20050120.patch.gz --]
[-- Type: application/x-gzip, Size: 11828 bytes --]

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Karel Gardas]

On Thu, 20 Jan 2005, Antony T Curtis wrote:

> On Thu, 2005-01-20 at 10:31 +0100, Karel Gardas wrote:
> > On Wed, 19 Jan 2005, Antony T Curtis wrote:
> >
> > > Hi,
> > >
> > > I think I have found the bug... will be making a new patch soon.
> >
> > Great! Thanks!
>
> Actually, I have not only found the bug you encountered, but I have
> found some other bugs in the implementation.
>
> I have also implemented a "info pnp" command.
>
> I have tested it with the following guests: FreeBSD 4, NetBSD 2 and
> Linux (Mandrake 8) with up to 4 NICs configured (dummynet).

It seems you have not fixed one of issue I've discivered and fixed in my
patch:

ar rcs libqemu.a exec.o translate-all.o cpu-exec.o translate.o op.o
helper.o helper2.o translate-copy.o disas.o  i386-dis.o
gcc  -o qemu vl.o osdep.o block.o readline.o monitor.o pci.o console.o
block-cow.o block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o
ide.o ne2000.o pckbd.o vga.o sb16.o dma.o audio.o noaudio.o wavaudio.o
sdlaudio.o ossaudio.o fdc.o mc146818rtc.o serial.o i8259.o i8254.o pc.o
cirrus_vga.o mixeng.o apic.o parallel.o pnp.o 3c509b.o gdbstub.o sdl.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 -L/usr/lib -lSDL -lpthread -lutil
3c509b.o(.text+0x10df): In function `tcm509_ioport_write':
/home/karel/cvs/qemu/qemu-3c509-new-anotny-fixes/hw/3c509b.c:336:
undefined reference to `TCM_STAT_ENABLE'
collect2: ld returned 1 exit status
make[1]: *** [qemu] Error 1
make[1]: Leaving directory
`/home/karel/usr/src/cvs/qemu/qemu-3c509-new-anotny-fixes/i386-softmmu'
make: *** [all] Error 1


Anyway, I'm curious how have you made it working under NetBSD 2.0. I'm
just trying boot1/2.fs and bootlap1/2.fs floppies sets but 3c509 is
detected only in the first and it is detected on the wrong addr/irq.

The reason why I'm trying this is that I'm not able to get 3c509 working
under RTEMS, which is my goal, since ne2k emulation does not work well for
RTEMS 4.6.x

Thanks,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Antony T Curtis]

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

On Thu, 2005-01-20 at 16:07 +0100, Karel Gardas wrote:
> On Thu, 20 Jan 2005, Antony T Curtis wrote:
> 
> > On Thu, 2005-01-20 at 10:31 +0100, Karel Gardas wrote:
> > > On Wed, 19 Jan 2005, Antony T Curtis wrote:
> > >
> > > > Hi,
> > > >
> > > > I think I have found the bug... will be making a new patch soon.
> > >
> > > Great! Thanks!
> >
> > Actually, I have not only found the bug you encountered, but I have
> > found some other bugs in the implementation.
> >
> > I have also implemented a "info pnp" command.
> >
> > I have tested it with the following guests: FreeBSD 4, NetBSD 2 and
> > Linux (Mandrake 8) with up to 4 NICs configured (dummynet).
> 
> It seems you have not fixed one of issue I've discivered and fixed in my
> patch:

<snip>

Oops, I forgot to copy that file over from my working directory. Have
attached an updated diff.

> Anyway, I'm curious how have you made it working under NetBSD 2.0. I'm
> just trying boot1/2.fs and bootlap1/2.fs floppies sets but 3c509 is
> detected only in the first and it is detected on the wrong addr/irq.

It simply auto-detected it and worked. Some operating systems will
reprogram a ISA-PnP device to use different resources than what they
start with - so the port/irq it appears on after the PnP isolation
process may appear to be 'wrong'. Don't worry, it is normal.

Operating systems when using ISA-PnP should...
1. detect and then 'turn off' all ISA-PnP devices.
2. detect all non PnP devices and setup drivers.
3. 'turn on' one ISA-PnP device at a time making sure it doesn't
conflict with existing devices IO/IRQ space, reconfiguring where
neccessary.

> The reason why I'm trying this is that I'm not able to get 3c509 working
> under RTEMS, which is my goal, since ne2k emulation does not work well for
> RTEMS 4.6.x

Hmm... Looking at some RTEMS source code, I have found:

> printf("ep%d: 3c5x9 at 0x%x in PnP mode. Disable PnP mode!\n",
>                                 is->id_unit, IS_BASE );

That seems to indicate that RTEMS uses the deprecated 3Com-specific
detection, and not the ISA-PnP isolation method.

Which gives 2 options... either modify RTEMS to understand PnP 3c509...
or implement the 3Com detection method. The 3Com method requires the
device to "monitors all write access to I/O port 01x0h where x is any
hex digit." That is non-trivial for a QEmu driver to do cleanly. (which
is the reason why I didn't implement it)

I would say that your safest and most easiest way forward is to use the
3c509 in it's "powered on" configuration, and set the RTEMS driver to
use it at that IO/IRQ without the automagic probe.

> Thanks,
> Karel
> --
> Karel Gardas                  kgardas@objectsecurity.com
> ObjectSecurity Ltd.           http://www.objectsecurity.com
> 
-- 
Antony T Curtis, BSc.                   UNIX, Linux, *BSD, Networking
antony.t.curtis@ntlworld.com            C++, J2EE, Perl, MySQL, Apache
+44-(118)-377-3247                      IT Consultancy.

[-- Attachment #2: qemu-3c509b.20050120b.patch.gz --]
[-- Type: application/x-gzip, Size: 8906 bytes --]

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Karel Gardas]

On Thu, 20 Jan 2005, Antony T Curtis wrote:

> > Anyway, I'm curious how have you made it working under NetBSD 2.0. I'm
> > just trying boot1/2.fs and bootlap1/2.fs floppies sets but 3c509 is
> > detected only in the first and it is detected on the wrong addr/irq.
>
> It simply auto-detected it and worked. Some operating systems will
> reprogram a ISA-PnP device to use different resources than what they
> start with - so the port/irq it appears on after the PnP isolation
> process may appear to be 'wrong'. Don't worry, it is normal.
>
> Operating systems when using ISA-PnP should...
> 1. detect and then 'turn off' all ISA-PnP devices.
> 2. detect all non PnP devices and setup drivers.
> 3. 'turn on' one ISA-PnP device at a time making sure it doesn't
> conflict with existing devices IO/IRQ space, reconfiguring where
> neccessary.

OK, Thanks for nice explanation.

> > The reason why I'm trying this is that I'm not able to get 3c509 working
> > under RTEMS, which is my goal, since ne2k emulation does not work well for
> > RTEMS 4.6.x
>
> Hmm... Looking at some RTEMS source code, I have found:
>
> > printf("ep%d: 3c5x9 at 0x%x in PnP mode. Disable PnP mode!\n",
> >                                 is->id_unit, IS_BASE );
>
> That seems to indicate that RTEMS uses the deprecated 3Com-specific
> detection, and not the ISA-PnP isolation method.
>
> Which gives 2 options... either modify RTEMS to understand PnP 3c509...
> or implement the 3Com detection method. The 3Com method requires the
> device to "monitors all write access to I/O port 01x0h where x is any
> hex digit." That is non-trivial for a QEmu driver to do cleanly. (which
> is the reason why I didn't implement it)

Interesting, now I've scanned over the detection code
(ep_look_for_board_at) and found some:

                outb(id_port, 0);
                outb(id_port, 0);

where id_port is:

#ifdef PC98
#define ELINK_ID_PORT   0x71d0
#else
#define ELINK_ID_PORT   0x110
#endif


which looks excactly as the method you describe.

> I would say that your safest and most easiest way forward is to use the
> 3c509 in it's "powered on" configuration, and set the RTEMS driver to
> use it at that IO/IRQ without the automagic probe.

I will certainly give it a try.

Thanks a lot,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Karel Gardas]

On Thu, 20 Jan 2005, Karel Gardas wrote:

> > I would say that your safest and most easiest way forward is to use the
> > 3c509 in it's "powered on" configuration, and set the RTEMS driver to
> > use it at that IO/IRQ without the automagic probe.
>
> I will certainly give it a try.

Well, it seems I've got things to the shape when initialization and driver
attaching goes well and RTEMS seems to got it.
Unfortunatelly, when trying to open connection from host to guest while
using proper user-net command-line parameters, I see this debug output
comming from Qemu:

tcm509_receive: size=58
packet dhost=00:00:00:00:00:00, padr=21:03:76:12:09:75
padr_match result=0 (rx_filter=0x0007)

That's just snipped from more such lines, basically they just repeat.

>From looking into the source code, it seems dhost is destination host
ethernet address and I just wonder why is it set to zeros when it should
be 21:03:76:12:09:75. Do you think I should blame my changes or better
overlooking of some places where I should setup ethernet address in the
RTEMS driver, or is this just another issue with your 3c509 emulation?

Thanks,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Antony T Curtis]

On Thu, 2005-01-20 at 21:15 +0100, Karel Gardas wrote:
> On Thu, 20 Jan 2005, Karel Gardas wrote:
> 
> > > I would say that your safest and most easiest way forward is to use the
> > > 3c509 in it's "powered on" configuration, and set the RTEMS driver to
> > > use it at that IO/IRQ without the automagic probe.
> >
> > I will certainly give it a try.
> 
> Well, it seems I've got things to the shape when initialization and driver
> attaching goes well and RTEMS seems to got it.
> Unfortunatelly, when trying to open connection from host to guest while
> using proper user-net command-line parameters, I see this debug output
> comming from Qemu:
> 
> tcm509_receive: size=58
> packet dhost=00:00:00:00:00:00, padr=21:03:76:12:09:75
> padr_match result=0 (rx_filter=0x0007)
> 
> That's just snipped from more such lines, basically they just repeat.

You have the debug code enabled. You should undef TCM_DEBUG

Are you able to set an IP address and get it talking?

<snip>

> From looking into the source code, it seems dhost is destination host
> ethernet address and I just wonder why is it set to zeros when it should
> be 21:03:76:12:09:75. Do you think I should blame my changes or better
> overlooking of some places where I should setup ethernet address in the
> RTEMS driver, or is this just another issue with your 3c509 emulation?
> 
> Thanks,
> Karel
> --
> Karel Gardas                  kgardas@objectsecurity.com
> ObjectSecurity Ltd.           http://www.objectsecurity.com
> 
-- 
Antony T Curtis, BSc.                   UNIX, Linux, *BSD, Networking
antony.t.curtis@ntlworld.com            C++, J2EE, Perl, MySQL, Apache
                                        IT Consultancy.

Re: [Qemu-devel] Updated 3c509 NIC patch.

[Karel Gardas]

On Thu, 20 Jan 2005, Antony T Curtis wrote:

> On Thu, 2005-01-20 at 21:15 +0100, Karel Gardas wrote:
> > On Thu, 20 Jan 2005, Karel Gardas wrote:
> >
> > > > I would say that your safest and most easiest way forward is to use the
> > > > 3c509 in it's "powered on" configuration, and set the RTEMS driver to
> > > > use it at that IO/IRQ without the automagic probe.
> > >
> > > I will certainly give it a try.
> >
> > Well, it seems I've got things to the shape when initialization and driver
> > attaching goes well and RTEMS seems to got it.
> > Unfortunatelly, when trying to open connection from host to guest while
> > using proper user-net command-line parameters, I see this debug output
> > comming from Qemu:
> >
> > tcm509_receive: size=58
> > packet dhost=00:00:00:00:00:00, padr=21:03:76:12:09:75
> > padr_match result=0 (rx_filter=0x0007)
> >
> > That's just snipped from more such lines, basically they just repeat.
>
> You have the debug code enabled. You should undef TCM_DEBUG

No, I'm glad there is any NIC debugging for such RTEMS experiments, the
only issue is that something is working with wrong ethernet address and it
seems RTEMS isn't it -- i.e. I've invoked some RTEMS etherenet statistics
and it also contains right eth address.

> Are you able to set an IP address and get it talking?

No, I'm not. Either I setup it manually and it does not work, or I try to
use DHCP w/o success. I've also tried to use DHCP with NetBSD 2.0
boot1/2.fs floppies but also w/o success, i.e. ``No DHCPOFFERS received.''

Thanks,
Karel
--
Karel Gardas                  kgardas@objectsecurity.com
ObjectSecurity Ltd.           http://www.objectsecurity.com