Re: [Etherboot-developers] Re: AW: [Etherboot-users] Problems to compile Etherboot 5.3.8

[Timothy L. <tl...@ro...>]

On Tue, 2004-07-27 at 10:05, Marty Connor wrote:
> This is interesting. I need to look more closely at the driver, but 
> this is worrisome:
> 
> static struct pcnet32_access pcnet32_wio = {
>        read_csr:pcnet32_wio_read_csr,
>        write_csr:pcnet32_wio_write_csr,
>        read_bcr:pcnet32_wio_read_bcr,
>        write_bcr:pcnet32_wio_write_bcr,
>        read_rap:pcnet32_wio_read_rap,
>        write_rap:pcnet32_wio_write_rap,
>        reset:pcnet32_wio_reset
> };

Not worrisome, just a pain to figure out what it is doing.  For some
reason the linux driver writer decided to create a structure of pointers
to the read/write procedures.  It caused me some greif but not enough to
change it.

> static void pcnet32_wio_write_csr(unsigned long addr, int index, u16 
> val)
> {
>          outw(index, addr + PCNET32_WIO_RAP);
>          outw(val, addr + PCNET32_WIO_RDP);
> }
> 
> Hmm, that looks a lot like address arithmetic to me... really seems 
> like we need a couple of virt_to_bus() calls here...

No, if memory serves and I would not be surprised if it doesn't the chip
requires you to tell it which register you are writing to before sending
the data.  

> and later calls like:
> 
>          a->write_csr(ioaddr, 1, (virt_to_bus(&lp->init_block)) & 
> 0xffff);
>          a->write_csr(ioaddr, 2, (virt_to_bus(&lp->init_block)) >> 16);
> 
> Ignoring the extra parens, shouldn't all of the address arithmetic be 
> inside the virt_to_bus calls? Maybe it will work in either case, but it 
> seems kind of dangerous, at first glance, since modification of the 
> address is occurring after virt_to_bus is invoked.

No, as ken said, the chip is requiring it in two 16bit addresses.  The
linux driver does not use virt_to_bus for these calls but does the same
thing with the masking and bit shifting.  I don't remember why I used
the virt_to_bus but I must have had a reason.

> I'll see if I have a card to test with, but I really should start 
> getting 5.3.9 ready to go. Anybody else have the time and inclination 
> to look into this?  We've definitely got someone willing and able to 
> help us debug, and that's a great help.

I am currently on vacation but if I get some time I will take a look.  I
worked with Phil for a bit a few weeks ago.  The problem is that the
driver works fine for my cards (same pci ids) but does not work for
Phil.  Without access to the card it will be painful.  Still, I will
take a look.

Tim