Re: GT64260_eth (Ethernet) Driver

[David Woodhouse <dwmw2@infradead.org>]

On Fri, 2004-06-25 at 17:07 -0700, Mark A. Greer wrote:
> Let me know how it goes.

I have memory probing working at last. I don't quite understand what I
was doing wrong there -- I think I was just being stupid and/or the code
to move the GT64x60 internal registers doesn't work. If I leave it where
the bootloader put it, it's OK.

Automatic detection of the chip type still isn't working, because it
tries to work it out from its own PCI ident, but the MV64360 doesn't
seem to appear on the PCI bus -- there _is_ no device 0.

The memory windows aren't right -- you have base_bits == 20 but those 20
bits actually hold bits 16-35 of the address. That's not a typo, so
setting base_bits to 16 seems to be the correct thing to do unless we're
going to handle 'extended address mode'.

Also we disable all the memory windows for I/O and only re-enable them
later. That breaks if we actually try to access any of the I/O in the
meantime -- which we do if we enable MV64x60 debugging, because it keeps
calling printk() :)

Is there a reason we need to disable the windows? Could we pass an array
of the desired settings to mv64x60_init() and have them set up
immediately, rather than just disabled and then fixed again later?

I could register my console later, I suppose, and live without printk
until after setup_arch()... but that sucks.

--
dwmw2


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/