GT64260_eth (Ethernet) Driver

GT64260_eth (Ethernet) Driver

[Dieu Morales]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1427 bytes --]


Greetings, I am working with the latest 2.6.7 kernel
source on a ppc radstone PPC7A board and was curious
if anyone was in the process or planned on porting the
gt64260_eth driver to support the 2.6.x kernel.

Not being familiar with the gt64260 Ethernet device or
code, I plan to take it line by line. I have attempted
to use the driver from the ppc.bkbits.net 2.4
development tree and currently have only changed the
dev = init_etherdev(dev, sizeof (gt_eth_priv));
to
dev = alloc_etherdev(sizeof (gt_eth_priv_struct ));
Shortly after, when attempting to allocate the Tx and
Rx page buffers, I get an exception in the
uncachedPages function.  I have traced the problem to
the pmd_presentò(*pmd) function in va_to_pte(addr)
returning 0.  I dumped the values of pmd, init_mm, and
pmd in the va_to_pte() and the values seemed O.K., so
I commented out the pmd_presentò(*pmd) check but was
once again stopped by the pte_present(*pte) check.  I
have seen the driver operate under 2.4.26 dev tree
from ppc.bkbits.net where this problem does not occur.
One difference I have noticed is that during
initialization of the 2.6.7 kernel, I do not get the
following output.
Buffer-cache hash table entries:
Page-cache hash table entries:
The filemap.c, where the "Page-cache " printk resides
in 2.4, looks heavily reworked, so I don't suspect
this is an issue?

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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

Dieu Morales wrote:

>Greetings, I am working with the latest 2.6.7 kernel
>source on a ppc radstone PPC7A board and was curious
>if anyone was in the process or planned on porting the
>gt64260_eth driver to support the 2.6.x kernel.
>
>Not being familiar with the gt64260 Ethernet device or
>code, I plan to take it line by line. I have attempted
>to use the driver from the ppc.bkbits.net 2.4
>development tree and currently have only changed the
>dev = init_etherdev(dev, sizeof (gt_eth_priv));
>to
>dev = alloc_etherdev(sizeof (gt_eth_priv_struct ));
>Shortly after, when attempting to allocate the Tx and
>Rx page buffers, I get an exception in the
>uncachedPages function.  I have traced the problem to
>the pmd_presentò(*pmd) function in va_to_pte(addr)
>returning 0.  I dumped the values of pmd, init_mm, and
>pmd in the va_to_pte() and the values seemed O.K., so
>I commented out the pmd_presentò(*pmd) check but was
>once again stopped by the pte_present(*pte) check.  I
>have seen the driver operate under 2.4.26 dev tree
>from ppc.bkbits.net where this problem does not occur.
>One difference I have noticed is that during
>initialization of the 2.6.7 kernel, I do not get the
>following output.
>Buffer-cache hash table entries:
>Page-cache hash table entries:
>The filemap.c, where the "Page-cache " printk resides
>in 2.4, looks heavily reworked, so I don't suspect
>this is an issue?
>
>
Dieu,

You should sync up with Brian Waite (look at CC: list) who has been
looking at writing a new enet driver for the 2.6 kernel using the latest
bridge support code.  You can get a look at the latest support code by
cloning bk://source.mvista.com/linux-2.5-marvell.  Note the the mpsc
driver that's there still isn't working correctly.

Mark


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

Re: GT64260_eth (Ethernet) Driver

[David Woodhouse]

You are lost in a twisty maze of BK trees, all alike.

On Wed, 2004-06-23 at 15:39 -0700, Mark A. Greer wrote:
> You should sync up with Brian Waite (look at CC: list) who has been
> looking at writing a new enet driver for the 2.6 kernel using the latest
> bridge support code.  You can get a look at the latest support code by
> cloning bk://source.mvista.com/linux-2.5-marvell.  Note the the mpsc
> driver that's there still isn't working correctly.

Ooh look another one. What's in here that merits it having its own tree
and prevents it from being accepted upstream?

Please be as specific as you can -- my task for the next few weeks
involves making Dy-4 DMV-182 support happen.

--
dwmw2


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

Re: GT64260_eth (Ethernet) Driver

[Brian Waite]

I think this is just a "sprout" Basically, Mark started an entire code
refactor for the 2.6 kernel. I started bugging him so he put up a terr where
we can colaborate on getting the code to a working state.
I don't think it is expected t live any longer than hey all the peices work
and boot a board. Today I don't think we have that. Ethernet driver and MPSC
driver are the 2 major sticking points right now.

Thanks
Brian

On Thursday 24 June 2004 04:37 am, David Woodhouse wrote:
> You are lost in a twisty maze of BK trees, all alike.
>
> On Wed, 2004-06-23 at 15:39 -0700, Mark A. Greer wrote:
> > You should sync up with Brian Waite (look at CC: list) who has been
> > looking at writing a new enet driver for the 2.6 kernel using the latest
> > bridge support code.  You can get a look at the latest support code by
> > cloning bk://source.mvista.com/linux-2.5-marvell.  Note the the mpsc
> > driver that's there still isn't working correctly.
>
> Ooh look another one. What's in here that merits it having its own tree
> and prevents it from being accepted upstream?
>
> Please be as specific as you can -- my task for the next few weeks
> involves making Dy-4 DMV-182 support happen.

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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

David Woodhouse wrote:

>You are lost in a twisty maze of BK trees, all alike.
>
>On Wed, 2004-06-23 at 15:39 -0700, Mark A. Greer wrote:
>
>
>>You should sync up with Brian Waite (look at CC: list) who has been
>>looking at writing a new enet driver for the 2.6 kernel using the latest
>>bridge support code.  You can get a look at the latest support code by
>>cloning bk://source.mvista.com/linux-2.5-marvell.  Note the the mpsc
>>driver that's there still isn't working correctly.
>>
>>
>
>Ooh look another one. What's in here that merits it having its own tree
>and prevents it from being accepted upstream?
>
It doesn't "merit" its own tree; it has its own tree because the code is
not yet ready to be passed upstream but others need to see the code.  If
you don't want to deal with the code in this tree, don't.  When it is
ready, and eventually [hopefully] accepted into the kernel.org tree,
this tree will disappear.

>
>Please be as specific as you can -- my task for the next few weeks
>involves making Dy-4 DMV-182 support happen.
>

This tree has a complete rewrite of the core code.  Look at
arch/ppc/syslib/.

Mark


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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

Mark A. Greer wrote:

>
>   If you don't want to deal with the code in this tree, don't.

As I read this again, I realize that I sound sarcastic.  I didn't mean
to.  My apologies.

Mark


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

Re: GT64260_eth (Ethernet) Driver

[David Woodhouse]

On Thu, 2004-06-24 at 11:46 -0700, Mark A. Greer wrote:
> >Ooh look another one. What's in here that merits it having its own tree
> >and prevents it from being accepted upstream?
> >
> It doesn't "merit" its own tree; it has its own tree because the code is
> not yet ready to be passed upstream but others need to see the code.  If
> you don't want to deal with the code in this tree, don't.  When it is
> ready, and eventually [hopefully] accepted into the kernel.org tree,
> this tree will disappear.

Oh, I definitely want to deal with this tree :)

Do you have a brief list of what still offends you about this rewritten
code, such that you haven't sent it yet? Especially those parts which I
could usefully address myself.

I note there are no platforms actually present which use the 64360.
There's Artesyn Katana support in Kconfig but no actual platform support
for that unless I'm being particularly dim today.

Is the 64360 support expected to work? Is there an older known-working
tree for 64360? I'm looking at the Timesys 2.4 port for the Dy-4
DMV-182, but that doesn't actually seem to boot on my DMV-182 so I lack
confidence in the wisdom of using that as any form of reference ;)

--
dwmw2


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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

David Woodhouse wrote:

>On Thu, 2004-06-24 at 11:46 -0700, Mark A. Greer wrote:
>
>
>>>Ooh look another one. What's in here that merits it having its own tree
>>>and prevents it from being accepted upstream?
>>>
>>>
>>>
>>It doesn't "merit" its own tree; it has its own tree because the code is
>>not yet ready to be passed upstream but others need to see the code.  If
>>you don't want to deal with the code in this tree, don't.  When it is
>>ready, and eventually [hopefully] accepted into the kernel.org tree,
>>this tree will disappear.
>>
>>
>
>Oh, I definitely want to deal with this tree :)
>
>Do you have a brief list of what still offends you about this rewritten
>code, such that you haven't sent it yet? Especially those parts which I
>could usefully address myself.
>
I don't have a good list but a couple things are a) I vaguely remember
thinking, "Ooh, I need to put 'this' in there for the 64360" but haven't
gone back thru the existing 360 code to see what that is; and b) I
change the .paddr field in the ocp to vaddrs, I need to undo that.
There are also a few hacks that I need to clean up but mostly, what I'm
hoping for are a) more eyeballs to critique the code, b) much more
testing of the code, c) ocp-ified drivers (i2c, 10/100 enet for 260,
10/100/1000 enet for >= 360 (maybe then can be combined?), and mpsc)
that are accepted by the respective gatekeepers for those types of drivers.

Would you mind looking at the code, giving me feedback ("this totally
sucks and needs to be thrown out" is perfectly valid) and looking for
things I may have missed?  There are a lot of registers and a lot of
bits & pieces to these things so its easy to miss something--or, maybe
you just don't like how I did it.  If you don't have major objections to
the core code, we need enet driver(s) and an i2c driver (there are
existing drivers for all of these already but they need to be ported or
possibly rewritten).

The main core code is in arch/ppc/syslib/mv64x60.c, mv64x60_ocp.c,
gt64260_pic.c, and mv64360_pic.c (untested).  I'm working on an mpsc
driver that fits under rmk's new serial infrastructure.  Its in
drivers/serial/mpsc/*.  I've made several changes to it since my last
push so I'll push again early next week when I have it working better.
An existing 64260 enet driver can be found in the linuxppc_2_4_devel
tree, an existing 64360 enet driver can be found in the
linuxppc_2_4_galileo tree (see below), and I've seen a i2c driver for
the 64360 (same ctlr as the 260, I *think*) that I can dig up.

>
>I note there are no platforms actually present which use the 64360.
>There's Artesyn Katana support in Kconfig but no actual platform support
>for that unless I'm being particularly dim today.
>
You note correctly.  I haven't tested any 64360 boards yet.  All of the
ones I have use the mpsc and I'm still shaking bugs out of that driver
so I can't test any them yet.  My first 64360 board to test will likely
be the Katana 750i.

>Is the 64360 support expected to work? Is there an older known-working
>tree for 64360? I'm looking at the Timesys 2.4 port for the Dy-4
>DMV-182, but that doesn't actually seem to boot on my DMV-182 so I lack
>confidence in the wisdom of using that as any form of reference ;)
>
Yes, there is code that Rabeeh Khoury from Marvell wrote and put into
[yet] another tree, bk://source.mvista.com/linuxppc_2_4_galileo.  Yes, I
know, yet another tree.  Basically, I was asleep at the switch and
didn't have that tree locked down before the code was pushed into
there.  That tree still exists because it has the 64360 code and it has
work Troy B. did for the Motorola MVP platform but I haven't heard
anything about that for a good 2 year so...

Once everyone is happy with the code and we've done some serious
testing, we can push the core code in and the drivers can go in as they
become available.  After that, we can finally get rid of these other 2
trees and never see them again.  Sound like a plan?

Mark


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

Re: GT64260_eth (Ethernet) Driver

[David Woodhouse]

On Fri, 2004-06-25 at 15:05 -0700, Mark A. Greer wrote:
> Would you mind looking at the code, giving me feedback ("this totally
> sucks and needs to be thrown out" is perfectly valid) and looking for
> things I may have missed?

For one, pci_auto sucks and needs to be thrown out. If the generic Linux
PCI resource assignment is broken, fix it rather than reimplementing it.
I'd also like to ditch the typedefs (use struct mv64x60_setup_info
instead of mv64x60_setup_info_t etc.).

Further than that I haven't noticed much yet -- my Friday ended before I
got the machine to boot. I think I relocated the chip to the wrong
address, because first the memory probe returned zero and then the PCI
idents were all 0xFFFF. I'll play some more on Monday.

Thanks for the pointers.

--
dwmw2


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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

David Woodhouse wrote:

>On Fri, 2004-06-25 at 15:05 -0700, Mark A. Greer wrote:
>
>
>>Would you mind looking at the code, giving me feedback ("this totally
>>sucks and needs to be thrown out" is perfectly valid) and looking for
>>things I may have missed?
>>
>>
>
>For one, pci_auto sucks and needs to be thrown out. If the generic Linux
>PCI resource assignment is broken, fix it rather than reimplementing it.
>
Point taken.  I'll put it on the list but since its useful for testing
right now, I make it a lower priority.

>I'd also like to ditch the typedefs (use struct mv64x60_setup_info
>instead of mv64x60_setup_info_t etc.).
>
Ahh, G*d I hate that...struct aaa, struct bbb, struct ccc all over the
place when its not necessary & adds no value.  Anyway, I will do that.

>
>Further than that I haven't noticed much yet -- my Friday ended before I
>got the machine to boot. I think I relocated the chip to the wrong
>address, because first the memory probe returned zero and then the PCI
>idents were all 0xFFFF. I'll play some more on Monday.
>
>Thanks for the pointers.
>

Sure.  Let me know how it goes.

Mark


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

Re: GT64260_eth (Ethernet) Driver

[Paul Mackerras]

Mark A. Greer writes:

> Ahh, G*d I hate that...struct aaa, struct bbb, struct ccc all over the
> place when its not necessary & adds no value.  Anyway, I will do that.

It does make things clearer for the reader - when you see a
declaration "struct foo bar;" you know that it is a struct, but if you
see "foo_t bar;" you have no clue what sort of thing it is without
going and looking elsewhere.

The other advantage to using "struct" is that it can help straighten
out include file messes.  If you have a header where you need to
declare a function that takes a foo_t *, you have no choice but to
#include <foo.h>, or whatever the header is that defines foo_t.  That
can easily lead to messes where foo.h needs to include other things
which end up including everything plus the kitchen sink.  If you
instead declare your function as taking a struct foo *, then you can
solve the problem by simply putting a "struct foo;" declaration in
your header, and then you don't need to #include <foo.h>.

Paul.

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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

Paul Mackerras wrote:

>Mark A. Greer writes:
>
>
>
>>Ahh, G*d I hate that...struct aaa, struct bbb, struct ccc all over the
>>place when its not necessary & adds no value.  Anyway, I will do that.
>>
>>
>
>It does make things clearer for the reader - when you see a
>declaration "struct foo bar;" you know that it is a struct, but if you
>see "foo_t bar;" you have no clue what sort of thing it is without
>going and looking elsewhere.
>
Yes but chances are you're going to look it up anyway (no matter what
type of creature it is).  Plus with cscope or something similar its
pretty quick/easy to look it up.

>The other advantage to using "struct" is that it can help straighten
>out include file messes.  If you have a header where you need to
>declare a function that takes a foo_t *, you have no choice but to
>#include <foo.h>, or whatever the header is that defines foo_t.  That
>can easily lead to messes where foo.h needs to include other things
>which end up including everything plus the kitchen sink.  If you
>instead declare your function as taking a struct foo *, then you can
>solve the problem by simply putting a "struct foo;" declaration in
>your header, and then you don't need to #include <foo.h>.
>
>

Hmm, it seems like the real problem in this example is that the include
files are not written and/or split out well.  Isn't your "struct foo;"
example just a hack to work around that?  Or am I not getting it?
Anyway, I'll use "struct foo;"s from now on (and get rid of the
typedef's I already have).

Mark


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

Re: GT64260_eth (Ethernet) Driver

[Dieu Morales]

All,
I have had some success with making the gt64260_eth.c
driver from the 2.4.26 dev tree work with the 2.6.7
kernel.  I am able to see the ARP request and response
messages via a network analyzer. However, the response
messages appear not to generate an interrupt and I
eventually timeout when mounting an NFS file system.
My hardware maps a multi purpose pin from the
Discovery 64260 to a cascaded pair of i8259's for all
Ethernet and serial interrupts.  It is mapped to IRQ
15 using INT E which is initialized by my ppcboot
bootloader using the pciWriteConfigRegByte function.
Also, I receive interrupts fine for the keyboard and
mouse, so I feel all is OK with the i8259 driver
etc... I do not have a 64260 dev manual so I am
unclear if there is any special software
initialization needed for my configuration that must
take place in gt64260_eth.c or ev64260_setup.c or if I
am simply overlook something .   A few areas of
interest were:

In gt64260_eth.c

/*
 * enable relevant interrupts on GT
*/
gt_write(GT64260_ENET_E0IMR + gap, 0xb0ff010d);

In ev64260_setup.c.

/* Set MPSC Multiplex RMII */
/* NOTE: ethernet driver modifies bit 0 and 1 */
gt_write(GT64260_MPP_SERIAL_PORTS_MULTIPLEX,
0x00001102);

Any insight is always appreciated.

Thanks,
Michael Morales


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

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

Dieu Morales wrote:

>All,
>I have had some success with making the gt64260_eth.c
>driver from the 2.4.26 dev tree work with the 2.6.7
>kernel.  I am able to see the ARP request and response
>messages via a network analyzer. However, the response
>messages appear not to generate an interrupt and I
>eventually timeout when mounting an NFS file system.
>My hardware maps a multi purpose pin from the
>Discovery 64260 to a cascaded pair of i8259's for all
>Ethernet and serial interrupts.  It is mapped to IRQ
>15 using INT E which is initialized by my ppcboot
>bootloader using the pciWriteConfigRegByte function.
>Also, I receive interrupts fine for the keyboard and
>mouse, so I feel all is OK with the i8259 driver
>etc... I do not have a 64260 dev manual so I am
>unclear if there is any special software
>initialization needed for my configuration that must
>take place in gt64260_eth.c or ev64260_setup.c or if I
>am simply overlook something .   A few areas of
>interest were:
>
>In gt64260_eth.c
>
>/*
> * enable relevant interrupts on GT
>*/
>gt_write(GT64260_ENET_E0IMR + gap, 0xb0ff010d);
>
>In ev64260_setup.c.
>
>/* Set MPSC Multiplex RMII */
>/* NOTE: ethernet driver modifies bit 0 and 1 */
>gt_write(GT64260_MPP_SERIAL_PORTS_MULTIPLEX,
>0x00001102);
>
>Any insight is always appreciated.
>
>

You have some very bizarre hardware.  Did your hardware guys *really*
put a pair of 8259's between the intr cltr on the hostbridge and the
processor???

Anyway, I perused the manual just in case but I don't see any way that
you can route enet/mpsc/sdma interrupts out MPP/GPP pins.  I could be wrong.

So, if you can actually convince the 64260 to route enet/mpsc/sdma intr
out that pin, you'll have to request the proper irq in your driver.
 From your description, it sounds like 15.  And, yes, you will have to
configure things in the 64260 to set up the routing and edge/level
sensitivity.

You will need a manual.  There's almost no hope without out one.  That
probably means signing an NDA with Marvell.

Let me know if you get it to work.  I'll be impressed, not to mention
surprised...

Mark


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

Re: GT64260_eth (Ethernet) Driver

[David Woodhouse]

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/

BAT mapping

[Linh Dang]

Hi,

I'm porting Linux to our proprietary boards. it's 7447-based with
gt64260 bridge. We used vanilla 2.6.7 from kernel.org. It worked out
well (2 person/grunt/slave-dats to get it linux booted and with
nfs/telnet/gdb...) thank you very much for your work.

In the porting process, we change the bat mapping to used all the 8
DBAT registers. our new algorithm is quite generic and will work for
cpu without hi_bats as well. My question is why it was NOT done this
way but hard-coded to bat2 and bat3. Am I missing some subtle things?

Thanx

--
Linh Dang


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

Re: BAT mapping

[Linh Dang]

this the hibats mapping patch. I have to manually edit out things that
are only relevant on our board.

--- 2.6.7/linux/arch/ppc/mm/pgtable.c Fri, 18 Jun 2004 13:35:07 -0400 linhd (k26/O/c/1_pgtable.c 1.1 644)
+++ local-2.6.7/arch/ppc/mm/pgtable.c Thu, 24 Jun 2004 15:24:06 -0400 linhd (k26/O/c/1_pgtable.c 1.3 644)
@@ -34,9 +34,11 @@

 #include "mmu_decl.h"

+extern int bat_map_io_succeed(unsigned long virt, phys_addr_t phys,
+                              unsigned int  size, int flags);
+
 unsigned long ioremap_base;
 unsigned long ioremap_bot;
-int io_bat_index;

 #if defined(CONFIG_6xx) || defined(CONFIG_POWER3)
 #define HAVE_BATS	1
@@ -297,9 +299,6 @@
 	}
 }

-/* is x a power of 2? */
-#define is_power_of_2(x)	((x) != 0 && (((x) & ((x) - 1)) == 0))
-
 /*
  * Set up a mapping for a block of I/O.
  * virt, phys, size must all be page-aligned.
@@ -317,13 +316,9 @@
 	/*
 	 * Use a BAT for this if possible...
 	 */
-	if (io_bat_index < 2 && is_power_of_2(size)
-	    && (virt & (size - 1)) == 0 && (phys & (size - 1)) == 0) {
-		setbat(io_bat_index, virt, phys, size, flags);
-		++io_bat_index;
+        if (bat_map_io_succeed(virt, phys, size, flags))
 		return;
-	}
 #endif /* HAVE_BATS */

 	/* No BATs available, put it in the page tables. */
--- 2.6.7/linux/arch/ppc/mm/ppc_mmu.c Fri, 18 Jun 2004 13:35:07 -0400 linhd (k26/O/c/2_ppc_mmu.c 1.1 644)
+++ local-2.6.7/arch/ppc/mm/ppc_mmu.c Tue, 29 Jun 2004 11:11:15 -0400 linhd (k26/O/c/2_ppc_mmu.c 1.3 644)
@@ -40,6 +40,17 @@
 unsigned long Hash_size, Hash_mask;
 unsigned long _SDR1;

+
+#define PPC32_MAX_BAT_PAIRS 8   /* maximum 8  dbats and 8  ibats */
+
+unsigned cpu_num_bat_pairs = 4; /* the actual number of bat pairs for
+                                 * this CPU. default to 4 for most
+                                 * ppc32  */
+
+unsigned cpu_num_ram_bats;
+
+int io_bat_index;               /* the 1st bat for I/O mapping */
+
 union ubat {			/* BAT register values to be loaded */
 	BAT	bat;
 #ifdef CONFIG_PPC64BRIDGE
@@ -47,13 +58,14 @@
 #else
 	u32	word[2];
 #endif
-} BATS[4][2];			/* 4 pairs of IBAT, DBAT */
+} BATS[PPC32_MAX_BAT_PAIRS][2];			/* 8 pairs of IBAT, DBAT */

 struct batrange {		/* stores address ranges mapped by BATs */
 	unsigned long start;
 	unsigned long limit;
 	unsigned long phys;
-} bat_addrs[4];
+} bat_addrs[PPC32_MAX_BAT_PAIRS];
+

 /*
  * Return PA for this VA if it is mapped by a BAT, or 0
@@ -61,7 +73,7 @@
 unsigned long v_mapped_by_bats(unsigned long va)
 {
 	int b;
-	for (b = 0; b < 4; ++b)
+	for (b = 0; b < cpu_num_bat_pairs; ++b)
 		if (va >= bat_addrs[b].start && va < bat_addrs[b].limit)
 			return bat_addrs[b].phys + (va - bat_addrs[b].start);
 	return 0;
@@ -73,7 +85,7 @@
 unsigned long p_mapped_by_bats(unsigned long pa)
 {
 	int b;
-	for (b = 0; b < 4; ++b)
+	for (b = 0; b < cpu_num_bat_pairs; ++b)
 		if (pa >= bat_addrs[b].phys
 	    	    && pa < (bat_addrs[b].limit-bat_addrs[b].start)
 		              +bat_addrs[b].phys)
@@ -81,14 +93,35 @@
 	return 0;
 }

+
+int
+bat_map_io_succeed(unsigned long virt, phys_addr_t phys,
+                   unsigned int size, int flags)
+{
+/* is x a power of 2? */
+#define is_power_of_2(x)	((x) != 0 && (((x) & ((x) - 1)) == 0))
+
+#if defined(CONFIG_6xx) || defined(CONFIG_POWER3)
+        if (io_bat_index < cpu_num_bat_pairs && is_power_of_2(size)
+                 && (virt & (size - 1)) == 0 && (phys & (size - 1)) == 0) {
+		setbat(io_bat_index, virt, phys, size, flags);
+		++io_bat_index;
+                return 1;
+	}
+#endif
+        return 0;
+}
+
+
 unsigned long __init mmu_mapin_ram(void)
 {
 #ifdef CONFIG_POWER4
 	return 0;
 #else
-	unsigned long tot, bl, done;
+	unsigned long tot, bl, done = 0;
 	unsigned long max_size = (256<<20);
 	unsigned long align;
+        unsigned i;

 	if (__map_without_bats)
 		return 0;
@@ -103,24 +136,29 @@
 	if (align && align < max_size)
 		max_size = align;

+        cpu_num_ram_bats = cpu_num_bat_pairs / 2;
+/*         if (cpu_num_bat_pairs > 4) */
+/*                 cpu_num_ram_bats++; */
+
+        /*
+         * cpu_num_ram_bats bats registers from bat0 will be used to
+         * map ram. the rest will be used to map I/O
+         */
+
 	tot = total_lowmem;
-	for (bl = 128<<10; bl < max_size; bl <<= 1) {
-		if (bl * 2 > tot)
-			break;
-	}

-	setbat(2, KERNELBASE, PPC_MEMSTART, bl, _PAGE_RAM);
-	done = (unsigned long)bat_addrs[2].limit - KERNELBASE + 1;
-	if ((done < tot) && !bat_addrs[3].limit) {
-		/* use BAT3 to cover a bit more */
-		tot -= done;
-		for (bl = 128<<10; bl < max_size; bl <<= 1)
-			if (bl * 2 > tot)
-				break;
-		setbat(3, KERNELBASE+done, PPC_MEMSTART+done, bl, _PAGE_RAM);
-		done = (unsigned long)bat_addrs[3].limit - KERNELBASE + 1;
+        for (i = 0, bl = 1UL << __ilog2(tot - done);
+
+             i < cpu_num_ram_bats && done < tot && bat_addrs[i].limit == 0;
+
+             i++, bl = 1UL << __ilog2(tot - done))
+        {
+                setbat(i, KERNELBASE+done, PPC_MEMSTART+done, bl, _PAGE_RAM);
+                done = (unsigned long) bat_addrs[i].limit - KERNELBASE + 1;
 	}

+        io_bat_index = i;       /* set the 1st bat used for I/O mapping */
+
 	return done;
 #endif
 }
@@ -203,7 +241,16 @@
 		return;
 	}

+        if (cur_cpu_spec[0]->cpu_features & CPU_FTR_HAS_HIGH_BATS)
+        {
+                cpu_num_bat_pairs = 8;
+                if ( ppc_md.progress ) ppc_md.progress("cpu has hi bat registers", 8);
+        }
+
+        if ( ppc_md.progress ) ppc_md.progress("num bat pairs:", cpu_num_bat_pairs);
+
+
 	if ( ppc_md.progress ) ppc_md.progress("hash:enter", 0x105);

 #ifdef CONFIG_PPC64BRIDGE
--- 2.6.7/linux/arch/ppc/kernel/head.S Fri, 18 Jun 2004 13:35:07 -0400 linhd (k26/P/c/20_head.S 1.1 644)
+++ local-2.6.7/arch/ppc/kernel/head.S Thu, 24 Jun 2004 15:25:46 -0400 linhd (k26/P/c/20_head.S 1.2 644)
@@ -1328,7 +1328,13 @@
 	LOAD_BAT(1,r3,r4,r5)
 	LOAD_BAT(2,r3,r4,r5)
 	LOAD_BAT(3,r3,r4,r5)
+BEGIN_FTR_SECTION
+	LOAD_BAT(4,r3,r4,r5)
+	LOAD_BAT(5,r3,r4,r5)
+	LOAD_BAT(6,r3,r4,r5)
+	LOAD_BAT(7,r3,r4,r5)
+END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)
 #endif /* CONFIG_POWER4 */
 	blr

--- 2.6.7/linux/arch/ppc/kernel/cpu_setup_6xx.S Fri, 18 Jun 2004 13:35:07 -0400 linhd (k26/P/c/32_cpu_setup_ 1.1 644)
+++ local-2.6.7/arch/ppc/kernel/cpu_setup_6xx.S Thu, 24 Jun 2004 09:00:55 -0400 linhd (k26/P/c/32_cpu_setup_ 1.2 644)
@@ -223,6 +223,10 @@
 	oris	r11,r11,HID0_DPM@h	/* enable dynamic power mgmt */
 END_FTR_SECTION_IFCLR(CPU_FTR_NO_DPM)

+BEGIN_FTR_SECTION
+        oris     r11,r11,HID0_HIGH_BAT@h
+END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)
+
 	/* All of the bits we have to clear....
 	 */
 	li	r3,HID0_SPD | HID0_NOPDST | HID0_NOPTI

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

GT64260_eth (Ethernet) Driver

[Earl Olsen]

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


Dieu:

I saw that you had a problem with uncachedPages in gt64260_eth.c.
I'm having the same problem you describe.  Did you ever get this
resolved?

Thanks for any help


--
Earl Olsen
Senior Software Engineer
Dilithium Networks, Inc.
TEL:+1 707-792-3925
earl.olsen@dilithiumnetworks.com
www.dilithiumnetworks.com

Communications for a Borderless World

This electronic message from Dilithium Networks contains information
which may be privileged or confidential. It is intended to be for the
use of the recipient(s) named above. If you are not the intended
recipient please return the message to the sender by replying to it and
then delete the message from your computer. Dilithium Networks shall not
be held liable to any person resulting from the use of any information
contained in this e-mail and shall not be liable to any person who acts
or omits to do anything in reliance upon it. Dilithium Networks does not
accept responsibility for changes made to this message after it was
sent.


[-- Attachment #2: Type: text/html, Size: 2178 bytes --]

GT64260_eth (Ethernet) Driver

[Earl Olsen]

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


Does anybody know if this issue was solved?
I'm running into the exact same problem with 2.6.10.

Thanks


Dieu Morales wrote:

>Greetings, I am working with the latest 2.6.7 kernel
>source on a ppc radstone PPC7A board and was curious
>if anyone was in the process or planned on porting the
>gt64260_eth driver to support the 2.6.x kernel.
>
>Not being familiar with the gt64260 Ethernet device or
>code, I plan to take it line by line. I have attempted
>to use the driver from the ppc.bkbits.net 2.4
>development tree and currently have only changed the
>dev = init_etherdev(dev, sizeof (gt_eth_priv));
>to
>dev = alloc_etherdev(sizeof (gt_eth_priv_struct ));
>Shortly after, when attempting to allocate the Tx and
>Rx page buffers, I get an exception in the
>uncachedPages function.  I have traced the problem to
>the pmd_presentò(*pmd) function in va_to_pte(addr)
>returning 0.  I dumped the values of pmd, init_mm, and
>pmd in the va_to_pte() and the values seemed O.K., so
>I commented out the pmd_presentò(*pmd) check but was
>once again stopped by the pte_present(*pte) check.  I
>have seen the driver operate under 2.4.26 dev tree
>from ppc.bkbits.net where this problem does not occur.
>One difference I have noticed is that during
>initialization of the 2.6.7 kernel, I do not get the
>following output.
>Buffer-cache hash table entries:
>Page-cache hash table entries:
>The filemap.c, where the "Page-cache " printk resides
>in 2.4, looks heavily reworked, so I don't suspect
>this is an issue?
>
>
Dieu,

You should sync up with Brian Waite (look at CC: list) who has been
looking at writing a new enet driver for the 2.6 kernel using the latest
bridge support code.  You can get a look at the latest support code by
cloning bk://source.mvista.com/linux-2.5-marvell.  Note the the mpsc
driver that's there still isn't working correctly.

Mark


--
Earl Olsen
Senior Software Engineer
Dilithium Networks, Inc.
TEL:+1 707-792-3925
earl.olsen@dilithiumnetworks.com
www.dilithiumnetworks.com

Communications for a Borderless World

This electronic message from Dilithium Networks contains information which may be privileged or confidential. It is intended to be for the use of the recipient(s) named above. If you are not the intended recipient please return the message to the sender by replying to it and then delete the message from your computer. Dilithium Networks shall not be held liable to any person resulting from the use of any information contained in this e-mail and shall not be liable to any person who acts or omits to do anything in reliance upon it. Dilithium Networks does not accept responsibility for changes made to this message after it was sent.


[-- Attachment #2: Type: text/html, Size: 4432 bytes --]

Re: GT64260_eth (Ethernet) Driver

[Brian Waite]

On Tuesday 20 September 2005 12:02 pm, Earl Olsen wrote:
> Does anybody know if this issue was solved?
> I'm running into the exact same problem with 2.6.10.
>
> Thanks
>
> Dieu Morales wrote:
> >Greetings, I am working with the latest 2.6.7 kernel
> >source on a ppc radstone PPC7A board and was curious
> >if anyone was in the process or planned on porting the
> >gt64260_eth driver to support the 2.6.x kernel.
2.6.7 is a really early version. I don't know of any working Marvel 64260 o=
r=20
64360 code in this time frame. I do know that the 64360 was patched to=20
mainline at ~2.6.13. Since then all real Marvel work should have been done =
on=20
mainline. I'd reccommend moving forward.
> >
> >Not being familiar with the gt64260 Ethernet device or
> >code, I plan to take it line by line.=20
That is probably a mistake for a number of reasons. First,  you will not be=
=20
able to get this into the mainline because it does not use the=20
platform_device structures like the Marvell 64360 ethernet device. Secondly=
,=20
most of the developers doing Marvell work, are using the 64360 chipset. I'd=
=20
reccommend using a newer kernel and backporting the 64360 ethernet code to=
=20
64260. I just looked at my baseline tree (2.6.12-rc1) and see the only=20
platform using the 64260 chip, besides the eval board, was the cpci690.c. I=
=20
would look and see ifthis is still a working platform and base your platfor=
m=20
code off of that.

> >I have attempted=20
> >to use the driver from the ppc.bkbits.net 2.4
> >development tree and currently have only changed the
> >dev =3D init_etherdev(dev, sizeof (gt_eth_priv));
> >to
> >dev =3D alloc_etherdev(sizeof (gt_eth_priv_struct ));
> >Shortly after, when attempting to allocate the Tx and
> >Rx page buffers, I get an exception in the
> >uncachedPages function.  I have traced the problem to
> >the pmd_present=C3=B2(*pmd) function in va_to_pte(addr)
> >returning 0.  I dumped td the values seemed O.K., so
> >I commented out the pmd_present=C3=B2(*pmd) check but was
> >once again stopped by the pte_present(*pte) check.  I
> >have seen the driver operate under 2.4.26 dev tree
> >from ppc.bkbits.net where this problem does not occur.
> >One difference I have noticed is that during
> >initialization of the 2.6.7 kernel, I do not get the
> >following output.
> >Buffer-cache hash table entries:
> >Page-cache hash table entries:
> >The filemap.c, where the "Page-cache " printk resides
> >in 2.4, looks heavily reworked, so I don't suspect
> >this is an issue?
>
> Dieu,
>
> You should sync up with Brian Waite (look at CC: list) who has been
> looking at writing a new enet driver for the 2.6 kernel using the latest
> bridge support code.  You can get a look at the latest support code by
> cloning bk://source.mvista.com/linux-2.5-marvell. =20
No. Only use mainline kernel.org for latest support. Nothing else is workin=
g=20
100%. In the kernel.org tree the MPSC driver is working along with the 360=
=20
ethernet device.=20

> Note the the mpsc=20
> driver that's there still isn't working correctly.
I haven't loked at the 64260 for well over a year since we went to the 6436=
0.=20
The 260 was just too bad in too many respects. I was willing to test the 26=
0=20
code with my old hardware if there was a merged driver and even develop the=
=20
merged driver, but it became obvious the merged driver was going to be ugly


Thanks
Brian

Re: GT64260_eth (Ethernet) Driver

[Mark A. Greer]

On Tue, Sep 20, 2005 at 01:13:48PM -0400, Brian Waite wrote:
> On Tuesday 20 September 2005 12:02 pm, Earl Olsen wrote:
> platform using the 64260 chip, besides the eval board, was the cpci690.c. I 
> would look and see ifthis is still a working platform and base your platform 
> code off of that.

The cpci690 is a working platform but it does not use the embedded enet
ctlr because there is no driver.

> > Dieu,
> >
> > You should sync up with Brian Waite (look at CC: list) who has been
> > looking at writing a new enet driver for the 2.6 kernel using the latest
> > bridge support code.  You can get a look at the latest support code by
> > cloning bk://source.mvista.com/linux-2.5-marvell.  
> No. Only use mainline kernel.org for latest support. Nothing else is working 
> 100%. In the kernel.org tree the MPSC driver is working along with the 360 
> ethernet device. 

This is from a very, very old email that is no longer accurate.  It
should be ignored.  This is no tree except the mainline/mm tree and there
is not gt64260 enet driver in the mainline/mm tree (that I know of).

> > Note the the mpsc 
> > driver that's there still isn't working correctly.
> I haven't loked at the 64260 for well over a year since we went to the 64360. 
> The 260 was just too bad in too many respects. I was willing to test the 260 
> code with my old hardware if there was a merged driver and even develop the 
> merged driver, but it became obvious the merged driver was going to be ugly

Ditto.

Mark