mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

[Mark A. Greer]

>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.

You mean in the arch/ppc/boot/simple code, right?  You may need to do something like what is in arch/ppc/boot/simple/misc-ev64260.S to move the dev windows for your uart (if you're using an external uart).  I successfully change the internal registers base addr on the ev64260.

>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.

Strange...according to the manual, you figure it out the same way no matter what bridge it is and it works for the 260 on my ev64260.  Are you sure your setup_info is correct?

>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'.

Yes, 20 bits in the reg starting at bit 0 (LSB) correspond to bits 35:16 of the window.  As long as the 'base' you pass into mv64x60_set_32bit_window() is correct, it should work I think (or be close)--but, of course, I haven't tested it yet :)

Would you turn on DEBUG and send me the dump (along with your setup_info) or give me a reg dump from you bdi (or whatever) or a dump of what's in __log_buf.

>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() :)

Well, I've been burned in the past by "dangling windows" so I was trying to be as safe as possible.  BTW, prink() isn't atually the issue since console_init() isn't called for some time after setup_arch().  However, it is an issue for progress & KGDB.  Good point, though, I missed that one.  What if we extend the setup_info to include dev bus windows and make a routine to set those up when we're setting up the pci windows??

>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?

Okay, I think we're in agreement.  Just to make sure, the solution is to add an array to setup_info that contains the dev bus window ranges and have the core code set those up when its setting up the PCI windows.  Agree?

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

You must have some other issue.  printk() isn't going to actually try to access the uart/mpsc until console_init() is called in start_kernel().  Before console_init() is called, the msgs are just being put into __log_buf.  If you are panic'ing in console_init() then you may be missing a window setup call in your board's setup_arch routine or the address you specified for the uart is wrong (or something like that).  If you're using progress or KGDB, that's a different story.

Mark


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

Re: mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

[David Woodhouse]

On Tue, 2004-06-29 at 15:12 -0700, Mark A. Greer wrote:
> You mean in the arch/ppc/boot/simple code, right?  You may need to do
> something like what is in arch/ppc/boot/simple/misc-ev64260.S to move
> the dev windows for your uart (if you're using an external uart).  I
> successfully change the internal registers base addr on the ev64260.

No, the UART is fine (except if we play with its windows as discussed
later). It's the GT64360 which isn't where it should be. I'm told that
sometimes they don't accept being moved more than once -- and I'm happy
enough with it at 0xEFF00000 where it starts off anyway; it's just that
I inherited the default setting of 0xF1000000 for
CONFIG_GT64x60_NEW_BASE.

> >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.
>
> Strange...according to the manual, you figure it out the same way no
> matter what bridge it is and it works for the 260 on my ev64260.  Are
> you sure your setup_info is correct?

Well I can see all the other devices on the PCI bus, and when I boot the
2.4 kernel it doesn't seem to have a device 0 either. So yes, fairly
sure. I'm staring at the docs trying to find out if there's a bit in a
register somewhere which makes the chip hide from its own PCI buses.

> >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'.
>
> Yes, 20 bits in the reg starting at bit 0 (LSB) correspond to bits
> 35:16 of the window.  As long as the 'base' you pass into
> mv64x60_set_32bit_window() is correct, it should work I think (or be
> close)--but, of course, I haven't tested it yet :)
>
> Would you turn on DEBUG and send me the dump (along with your
> setup_info) or give me a reg dump from you bdi (or whatever) or a dump
> of what's in __log_buf.

It used to say this:

set 32bit window: 4, base: 0xe0010000, size: 0x10000, other: 0x0
shift right val: 0xe0010000, num_bits: 20 == 0xe0010
would change base_reg from 0000e001 to 000e0010

... and then nothing else, because it had just broken the UART.

Now with base_bits == 16 it says this:

set 32bit window: 4, base: 0xe0010000, size: 0x10000, other: 0x0
shift right val: 0xe0010000, num_bits: 16 == 0xe001
would change base_reg from 0000e001 to 0000e001


> >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() :)
>
> Well, I've been burned in the past by "dangling windows" so I was
> trying to be as safe as possible.  BTW, prink() isn't atually the
> issue since console_init() isn't called for some time after
> setup_arch().

It's definitely printk. I don't have a hardware debugger so I don't like
waiting till console_init() - I register a console in platform_init().

> Okay, I think we're in agreement.  Just to make sure, the solution is
> to add an array to setup_info that contains the dev bus window ranges
> and have the core code set those up when its setting up the PCI
> windows.  Agree?

Possibly. Although it seems like overkill -- we could live with just a
bitmap of those windows we want the init to leave as they were -- we
don't need it to set _everything_ up for us; just not destroy the
windows we're actually using right now.

> >I could register my console later, I suppose, and live without printk
> >until after setup_arch()... but that sucks.
>
> You must have some other issue.  printk() isn't going to actually try
> to access the uart/mpsc until console_init() is called in
> start_kernel().

Console_init() is just an earlier round of initcalls than the normal
ones, and there's absolutely no need to wait that long. For debugging
early boot crashes, add something like this to gen550_dbg.c and call
gen550_console_register() in platform_init()...

#include <linux/console.h>
static void gen550_console_write(struct console *con, const char *s, unsigned n) {
        unsigned int progress_debugport;
        int i;

        progress_debugport = serial_init(1, NULL);

        for(i=0; i<n; i++) {
                if (s[i] == 10)
                serial_putc(progress_debugport, 13);
                serial_putc(progress_debugport, s[i]);
        }
}

struct console gen550_console = {
        .name = "gen550",
        .write = gen550_console_write,
        .flags = CON_PRINTBUFFER,
        .index = -1
};

void gen550_console_register(void)
{
        register_console(&gen550_console);
}


--
dwmw2


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

Re: mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

[David Woodhouse]

More progress... the IRQ code works a bit better if it's ic_bh->v_addr
is at offset zero in the chip instead of the 0xc18 which is correct only
for the GT64260. The host bridge itself appears on the bus as device #3,
which is why we couldn't autodetect it by looking at vendor/device of
device #0.

∃ an Ethernet driver for the MV64340 (the MIPS version of the chip). It
doesn't use OCP though -- there's no OCP on MIPS. Can someone explain
why OCP is used instead of the generic platform_device functionality
provided by the kernel? Should we convert MIPS to OCP?

--
dwmw2


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

Re: mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

[Matt Porter]

On Thu, Jul 01, 2004 at 03:13:21PM +0100, David Woodhouse wrote:
> ∃ an Ethernet driver for the MV64340 (the MIPS version of the chip). It
> doesn't use OCP though -- there's no OCP on MIPS. Can someone explain
> why OCP is used instead of the generic platform_device functionality
> provided by the kernel? Should we convert MIPS to OCP?

OCP is used because it is simply wrapping a standard API around a
standard LDM "bus".  platform devices try to make non-hardware-scan
capable devices a special case.  OCP provides a standard way to get
at all platform specific information that a driver needs rather
than just a few things like platform devices currently do
(io, mem, irq resources).

One of the goals is to extend to allow hierarchical PM and hotplug
in OCP, its a standard bus now, but it's a flat list of devices
on the "bus".  In reality, SoCs that have internal PM/hotplug
capabilities have a hierarchical set of buses that should be
represented to properly manage this. Eventually, the idea is
to have OCP instantiate a tree of these dumb devices.

"We" should probably convert MIPS, ARM, SH, etc. to OCP, but
it only recently got rewritten (it's been around for ages in
PPC) in 2.4 and ported to 2.6.

-Matt

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

Re: mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

[Mark A. Greer]

David Woodhouse wrote:

>More progress... the IRQ code works a bit better if it's ic_bh->v_addr
>is at offset zero in the chip instead of the 0xc18 which is correct only
>for the GT64260.
>
Yep.  Added to the list.

> The host bridge itself appears on the bus as device #3,
>which is why we couldn't autodetect it by looking at vendor/device of
>device #0.
>
Ah, I see the problem.  PCI regs are being accessed before
mv64x60_enumerate_buses() is called which sets the hose bus & device
numbers.  Actually, I never expected fw to ever change the dev number
from zero so I was only really concerned about setting the bus number in
that routine.  For some reason, your firmware must be changing it to 3.

FYI, look at the "PCI P2P Configuration" register
(MV64x60_PCI[01]_P2P_CONFIG (0x1d14/0x1d94)).  Apparently your firmware
sets the device number of your hoses to 3 for some reason (default is 0
for PCI, 0x1f for PCI-X).

Added to the list.

>
>∃ an Ethernet driver for the MV64340 (the MIPS version of the chip). It
>doesn't use OCP though -- there's no OCP on MIPS. Can someone explain
>why OCP is used instead of the generic platform_device functionality
>provided by the kernel? Should we convert MIPS to OCP?
>
>
>
I think Matt answered this one.

Mark


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

Re: mv6360 support in mv64x60.c (was Re: GT64260_eth (Ethernet) Driver)

[Mark A. Greer]

David Woodhouse wrote:

>On Thu, 2004-07-01 at 12:10 -0700, Mark A. Greer wrote:
>
>
>>FYI, look at the "PCI P2P Configuration" register
>>(MV64x60_PCI[01]_P2P_CONFIG (0x1d14/0x1d94)).  Apparently your firmware
>>sets the device number of your hoses to 3 for some reason (default is 0
>>for PCI, 0x1f for PCI-X).
>>
>>
>
>Aha -- that's what I spent my last quarter of an hour at work yesterday
>looking for in the documentation. Thanks.
>
>I made mv64x60_get_type() read the register in question and query the
>correct device for ident.
>
k

>
>Here's what I have working at the moment -- sorry, it's a bit untidy
>still but the weekend calls... :)
>
heh

>
>Don't look too hard at the board code yet; it's still a hacked up hybrid
>of your ev64260 code and the timesys 2.4 port.
>

Okay, I skimmed it an saw what you did.  I'll take a closer on Tues but
64x60 changes look okay (I'm assuming your gen550 & serial changes
aren't meant to go into this tree).

I just pushed an updated mpsc driver that works okay for me.  Well...the
first port does; the second port hangs the system but its good enough to
allow me to work on my 64360 boards.  I will fix the second port.

Thanks for the patch & have a good weekend.

Mark


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