uboot-phytec
Public
Source
committed 1fd92db83d3x
/* * rtl8139.c : U-Boot driver for the RealTek RTL8139 * * Masami Komiya (mkomiya@sonare.it) * * Most part is taken from rtl8139.c of etherboot * *//* rtl8139.c - etherboot driver for the Realtek 8139 chipset ported from the linux driver written by Donald Becker by Rainer Bawidamann (Rainer.Bawidamann@informatik.uni-ulm.de) 1999 This software may be used and distributed according to the terms of the GNU Public License, incorporated herein by reference. changes to the original driver: - removed support for interrupts, switching to polling mode (yuck!) - removed support for the 8129 chip (external MII)*//*********************************************************************//* Revision History *//*********************************************************************//* 28 Dec 2002 ken_yap@users.sourceforge.net (Ken Yap) Put in virt_to_bus calls to allow Etherboot relocation. 06 Apr 2001 ken_yap@users.sourceforge.net (Ken Yap) Following email from Hyun-Joon Cha, added a disable routine, otherwise NIC remains live and can crash the kernel later. 4 Feb 2000 espenlaub@informatik.uni-ulm.de (Klaus Espenlaub) Shuffled things around, removed the leftovers from the 8129 support that was in the Linux driver and added a bit more 8139 definitions. Moved the 8K receive buffer to a fixed, available address outside the 0x98000-0x9ffff range. This is a bit of a hack, but currently the only way to make room for the Etherboot features that need substantial amounts of code like the ANSI console support. Currently the buffer is just below 0x10000, so this even conforms to the tagged boot image specification, which reserves the ranges 0x00000-0x10000 and 0x98000-0xA0000. My interpretation of this "reserved" is that Etherboot may do whatever it likes, as long as its environment is kept intact (like the BIOS variables). Hopefully fixed rtl_poll() once and for all. The symptoms were that if Etherboot was left at the boot menu for several minutes, the first eth_poll failed. Seems like I am the only person who does this. First of all I fixed the debugging code and then set out for a long bug hunting session. It took me about a week full time work - poking around various places in the driver, reading Don Becker's and Jeff Garzik's Linux driver and even the FreeBSD driver (what a piece of crap!) - and eventually spotted the nasty thing: the transmit routine was acknowledging each and every interrupt pending, including the RxOverrun and RxFIFIOver interrupts. This confused the RTL8139 thoroughly. It destroyed the Rx ring contents by dumping the 2K FIFO contents right where we wanted to get the next packet. Oh well, what fun. 18 Jan 2000 mdc@thinguin.org (Marty Connor) Drastically simplified error handling. Basically, if any error in transmission or reception occurs, the card is reset. Also, pointed all transmit descriptors to the same buffer to save buffer space. This should decrease driver size and avoid corruption because of exceeding 32K during runtime. 28 Jul 1999 (Matthias Meixner - meixner@rbg.informatik.tu-darmstadt.de) rtl_poll was quite broken: it used the RxOK interrupt flag instead of the RxBufferEmpty flag which often resulted in very bad transmission performace - below 1kBytes/s.*//* PCI Tuning Parameters Threshold is bytes transferred to chip before transmission starts. *//* In bytes, rounded down to 32 byte units. *//* Rx buffer level before first PCI xfer. *//* Maximum PCI burst, '4' is 256 bytes *//* Calculate as 16<<val. */