Driver for FECs on motorola DUET (87x/88x)

Hello

The attached patch is a driver for both the FECs on the new motorola 87x/88x processors.

I first tried to modified the old FEC driver but due to hardware peculiarities and the large modification needed I decided to create a new driver based on the old one.

The main features of the driver are:

o Supports correctly both FECs.
o Easier way to add new boards.
o MII ethtool support.
o NAPI support.
o Support polling mode of link changes even with generic phys.
o No fixed receive ethernet buffers zero copy receive, based on the work of Joakim Tjernlund.
o Copy small received frames to reduce memory consumption.
o I think it will be easier to port to 2.6. Haven't yet a chance to try it though.

The major changes were:

o Moved location to drivers/net
o It is now a whole subdirectory instead of just one file.
o MII no longer interrupt driven.

Note that the board which uses it is not in the tree since it depends on other patches that were rejected for 2.4. However it is trivial to add more boards.

Please take a look and comment.

Regards

Pantelis

To start with, I think you should fix the Machine Check exception in head_8xx.S to get proper error reporting. I think it should be:

	. = 0x200

MachineCheck:
EXCEPTION_PROLOG
mfspr r4,DAR
stw r4,_DAR(r11)
mfspr r5,DSISR
stw r5,_DSISR(r11)
addi r3,r1,STACK_FRAME_OVERHEAD
EXC_XFER_EE(0x200, MachineCheckException)

Does init crash or just hang?
If it hangs, it may be a TLB problem.

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

It crashes and the backtrace seems sane.

Regards

Pantelis

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

Progress report.

Got it to move even further.

No longer crashes but it seems stuck in something related to the serial console.

Still responds to pings, so I'm very hopefull.

Come Monday I'll probably get it to work...

Regards

Pantelis

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

Great!

If you are going to mess with the 8xx_io/uart.c, you might want to port this from 2.4:
http://ppc.bkbits.net:8080/linuxppc-2.4/diffs/arch/ppc/8xx_io/[email protected]?nav=index.html|src/.|src/arch|src/arch/ppc|src/arch/pp
c/8xx_io|hist/arch/ppc/8xx_io/uart.c

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

:P

I know, I tried to port it over but it's a mess. Things have changed dramatically in the serial subsystem in 2.6.

I'm not sure that I will avoid rewritting the serial driver.

Regards

Pantelis

Regards

Pantelis

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

I'd prefer asking Kumar Gala for the re-written serial driver he did for cpm2, and either copying that and making it work for cpm1 (8xx) or adding cpm1 support cleanly into it. I can provide an older, but working on some variant of 2.4, serial driver vs the drivers/serial infrastructure as well, if needed (I didn't write it, fwiw).

--
Tom Rini
http://gate.crashing.org/~trini/

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

I have some ideas. There are some "generic" functions doing some lazy processing that isn't likely to be valid on the 8xx, in particular the way demand zero pages are handled. Anyway, that's as far as I've traced it. Sometimes it appears to work, but it could be that what is happening still isn't correct, it just doesn't crash/hang. There are few other things that caught my attention where we used to execute generic PPC MM code without any ill side effects, but when these were ported to 2.6 we are now doing the wrong things on the 8xx. We just have to work our way though it with some applications and testing.

	-- Dan

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

I have made some progress...

I have ported the CPM UART driver by Kumar Gala to the 8xx.

It works correctly but still the same problem persists...

It correctly mounts the NFS root, and after the first write by init it hangs.

By breaking in using my BDI2000 I see it stuck at default_idle.

Networking & interrupts appear OK, since I can still ping.

It seems that for some reason no user space scheduling takes place.

Apparently the scheduling is controlled by the _TIF_NEED_RESCHED flag which is no where to be found in head_8xx.S.

Before I submerge into the assembly of head_8xx.S does anyone have any ideas?

Regards

Pantelis

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

I just used head.S, which works fine on the 82xx, as a model for the code in head_8xx.S. I've been looking at some "common" PPC cache management functions that I'm not certain are doing the proper thing on the 8xx. I'm suspecting some data corruption problems due to improper effects of cache instructions.

There are some optimizations we can do to head_8xx.S, but I don't think there is anything incorrect in it.

	-- Dan

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

I do think there is something wrong in head_8xx.S. Check
http://lists.linuxppc.org/linuxppc-embedded/200405/msg00109.html
for details.

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

Given that the 860 manual says that the 860 sets DAR and DSISR on a machine check, I think Joakim's patch is desirable. I assume other 8xx processors do also.

Paul.

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

I wonder if this applies to head.S also? I don't have a manual handy, but since the Alignment exceptions are identical, I guess that DAR & DSISR are also set for the CPUs that uses head.S?

Currently only 8xx uses these in the machine check exception, but I think the these registers should be accurate. They may be useful for debugging if nothing else.

Jocke

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

No, the 6xx/7xx/7xxx processors only set SRR0/1 on a machine check.

Paul.

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

i'm definitely interested in what it took for you to get this to work. currently, i've got a perfectly working system, booting a 2.4-based kernel, compiled with ELDK 3.0, on a customized 8xx board. this system uses the now-deprecated "devfs".

i bk-cloned the linuxppc-2.5 tree, did "make menuconfig" as best i could (guessing every so often at some of the new features), compiled a new kernel and, glory be, actually got the new kernel to boot up to the point of trying to start "init", at which point it hung.

i'm using embedded planet's planet core bootloader and, although i'd love to make the switch to u-boot, given that planet core seems to be doing the job at the moment, i think i won't tempt the gods just yet. that's a later project.

given that "devfs" is now technically obsolete, i'm wondering what you did in terms of the kernel configuration, and what you had to do in your root filesystem to effect the switch over to (i'm assuming) sysfs+udev.

mind sharing your .config file for this? i'm not interested in getting every feature of this board to work at the moment -- just getting to the command line prompt would make me happy.

rday

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

I used an NFS mounted root ELDK 3.0 filesystem. By mistake I booted with devfs and everything worked except the telnet networked logins. Did not have time to check why though.

Well you wont get any further than this using the stock kernel.

I had to use my own ethernet and a ported over serial uart driver for CPM2 boards.

Also some tweaking is needed to the irq dispatch and defining out some mmu staff which do not apply for 8xx.

My condolences :)

I did nothing special; it appeared to just work.

Patience, I'll clean the stuff up and post them here.

Regards

Pantelis

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

oh, so devfs, although deprecated, will still work? that's good to know, one less thing i need to fight with.

ok, i'll just hang out and wait for changes to eventually appear. no big rush on my part. thanks.

rday

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