DM9000 network card driver

Hi,

I think this fell through the cracks, so here it is again.

The Davicom DM9000 10/100 Ethernet controller.

This driver supplies an MMIO based DM9000 interface which can be instantiated in the emulation's memory map to provide an ethernet interface for ARM "local-bus" type systems.

I believe I covered all previously raised objections.

Regards,

Daniel.

Daniel Silverstone                              http://www.simtec.co.uk/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895

The Davicom DM9000 10/100 Ethernet controller.

This driver supplies an MMIO based DM9000 interface which can be instantiated in the emulation's memory map to provide an ethernet interface for ARM "local-bus" type systems.

 Makefile.target |    2 
 hw/devices.h    |    7 
 hw/dm9000.c     |  631 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 639 insertions(+), 1 deletion(-)

=== modified file 'Makefile.target'

@@ -599,7 +599,7 @@
 ifeq ($(TARGET_BASE_ARCH), arm)
 OBJS+= integratorcp.o versatilepb.o ps2.o smc91c111.o arm_pic.o arm_timer.o
 OBJS+= arm_boot.o pl011.o pl031.o pl050.o pl080.o pl110.o pl181.o pl190.o
-OBJS+= versatile_pci.o ptimer.o
+OBJS+= versatile_pci.o ptimer.o dm9000.o
 OBJS+= realview_gic.o realview.o arm_sysctl.o mpcore.o
 OBJS+= armv7m.o armv7m_nvic.o stellaris.o pl022.o stellaris_enet.o
 OBJS+= pl061.o

=== modified file 'hw/devices.h'

@@ -3,6 +3,13 @@
 
 /* Devices that have nowhere better to go.  */
 
+/* dm9000.c */
+#ifdef NEED_CPU_H
+/* This ifdef is present because target_phys_addr_t comes from cpu-defs.h */
+void dm9000_init(NICInfo *nd, target_phys_addr_t base_addr, uint32_t addr_offset, 
+                 uint32_t data_offset, qemu_irq irq);
+#endif
+
 /* smc91c111.c */
 void smc91c111_init(NICInfo *, uint32_t, qemu_irq);
 

=== added file 'hw/dm9000.c'

I don't see any replies to this -- it's possible that my list subscription was playing up at the time, so I thought I'd re-poke about it.

Basically I'm desperate to know if I'm even going the right way in my patches -- am I getting them to a state where they could be merged, or am I wasting my time? Is there an FAQ I need to read which will tell me how to present these patches in a way which is easier for you all to deal with them?

I'm just somewhat disheartened that I see patches turn up and get discussed strongly, and then the updated patches end up being merged, where after the initial discussion, this patch kinda got dropped on the floor without an explicit "no" or anything; sitting for two weeks untouched on-list.

I appreciate that you're all busy, so if the answer is simply "You're on the list, just it'll be a while" then at least I can carry that back to my boss who wants to know how it's going getting these patches to you.

Regards,

Daniel.

Daniel Silverstone                              http://www.simtec.co.uk/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895

Well, for example I could comment on the patches from general point of view (as I seem to have more time in my hands than some), but then I don't usually have any means to check if the emulator (or the device) in question even works with patch applied, or whether the patch makes sense from the machine architecture POV. For that, the maintainer should OK the patch.

Your patch looks very clean. I wouldn't use devices.h for the prototype, but instead some board file (for example arm-misc.h).

The device is not used by any board, so it's not possible even for the maintainer to test the patch.

As there is a reset function already, it should not be too difficult to register that for system_reset use.

Save/load functions would be nice, though IIRC ARM boards/devices don't have any yet.

I think I was told to use devices.h quite a while back. It's not appropriate to put it in arm-misc.h since the device itself has no specific isolation in ARM stuff. Despite being made to put the HW in the ARM HW bits of the Makefile.

It is used by the board I am trying to get all the patches up-to-snuff for.

Can you explain what you mean by that?

Some do, some don't -- a portion of what I have already has save/load support, but this is one device I've not done it for yet. I will continue to look at that.

Thank you very much for your feedback. Hopefully if you can explain what this system_reset stuff is, I can get that done and punt a fresh patch to the list.

Regards,

Daniel.

Daniel Silverstone                              http://www.simtec.co.uk/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895

I see. Then devices.h seems correct. I was wondering about NEED_CPU stuff.

Maybe you could add it as an ISA device to PC (pc.c) and see if it works?

Just add a line like
qemu_register_reset(dm9000_hard_reset, state);
to dm9000_init().

Then if the machine gets reset by monitor command "system_reset" or a hardware device, the reset function will be called to make the device state predictable like on a real machine.