| ----------------------- |
| Ethernet Driver Guide |
| ----------------------- |
| |
| The networking stack in Das U-Boot is designed for multiple network devices |
| to be easily added and controlled at runtime. This guide is meant for people |
| who wish to review the net driver stack with an eye towards implementing your |
| own ethernet device driver. Here we will describe a new pseudo 'APE' driver. |
| |
| ------------------ |
| Driver Functions |
| ------------------ |
| |
| All functions you will be implementing in this document have the return value |
| meaning of 0 for success and non-zero for failure. |
| |
| ---------- |
| Register |
| ---------- |
| |
| When U-Boot initializes, it will call the common function eth_initialize(). |
| This will in turn call the board-specific board_eth_init() (or if that fails, |
| the cpu-specific cpu_eth_init()). These board-specific functions can do random |
| system handling, but ultimately they will call the driver-specific register |
| function which in turn takes care of initializing that particular instance. |
| |
| Keep in mind that you should code the driver to avoid storing state in global |
| data as someone might want to hook up two of the same devices to one board. |
| Any such information that is specific to an interface should be stored in a |
| private, driver-defined data structure and pointed to by eth->priv (see below). |
| |
| So the call graph at this stage would look something like: |
| board_init() |
| eth_initialize() |
| board_eth_init() / cpu_eth_init() |
| driver_register() |
| initialize eth_device |
| eth_register() |
| |
| At this point in time, the only thing you need to worry about is the driver's |
| register function. The pseudo code would look something like: |
| int ape_register(bd_t *bis, int iobase) |
| { |
| struct ape_priv *priv; |
| struct eth_device *dev; |
| |
| priv = malloc(sizeof(*priv)); |
| if (priv == NULL) |
| return 1; |
| |
| dev = malloc(sizeof(*dev)); |
| if (dev == NULL) { |
| free(priv); |
| return 1; |
| } |
| |
| /* setup whatever private state you need */ |
| |
| memset(dev, 0, sizeof(*dev)); |
| sprintf(dev->name, "APE"); |
| |
| /* if your device has dedicated hardware storage for the |
| * MAC, read it and initialize dev->enetaddr with it |
| */ |
| ape_mac_read(dev->enetaddr); |
| |
| dev->iobase = iobase; |
| dev->priv = priv; |
| dev->init = ape_init; |
| dev->halt = ape_halt; |
| dev->send = ape_send; |
| dev->recv = ape_recv; |
| dev->write_hwaddr = ape_write_hwaddr; |
| |
| eth_register(dev); |
| |
| #ifdef CONFIG_CMD_MII) |
| miiphy_register(dev->name, ape_mii_read, ape_mii_write); |
| #endif |
| |
| return 1; |
| } |
| |
| The exact arguments needed to initialize your device are up to you. If you |
| need to pass more/less arguments, that's fine. You should also add the |
| prototype for your new register function to include/netdev.h. |
| |
| The return value for this function should be as follows: |
| < 0 - failure (hardware failure, not probe failure) |
| >=0 - number of interfaces detected |
| |
| You might notice that many drivers seem to use xxx_initialize() rather than |
| xxx_register(). This is the old naming convention and should be avoided as it |
| causes confusion with the driver-specific init function. |
| |
| Other than locating the MAC address in dedicated hardware storage, you should |
| not touch the hardware in anyway. That step is handled in the driver-specific |
| init function. Remember that we are only registering the device here, we are |
| not checking its state or doing random probing. |
| |
| ----------- |
| Callbacks |
| ----------- |
| |
| Now that we've registered with the ethernet layer, we can start getting some |
| real work done. You will need five functions: |
| int ape_init(struct eth_device *dev, bd_t *bis); |
| int ape_send(struct eth_device *dev, volatile void *packet, int length); |
| int ape_recv(struct eth_device *dev); |
| int ape_halt(struct eth_device *dev); |
| int ape_write_hwaddr(struct eth_device *dev); |
| |
| The init function checks the hardware (probing/identifying) and gets it ready |
| for send/recv operations. You often do things here such as resetting the MAC |
| and/or PHY, and waiting for the link to autonegotiate. You should also take |
| the opportunity to program the device's MAC address with the dev->enetaddr |
| member. This allows the rest of U-Boot to dynamically change the MAC address |
| and have the new settings be respected. |
| |
| The send function does what you think -- transmit the specified packet whose |
| size is specified by length (in bytes). You should not return until the |
| transmission is complete, and you should leave the state such that the send |
| function can be called multiple times in a row. |
| |
| The recv function should process packets as long as the hardware has them |
| readily available before returning. i.e. you should drain the hardware fifo. |
| For each packet you receive, you should call the NetReceive() function on it |
| along with the packet length. The common code sets up packet buffers for you |
| already in the .bss (NetRxPackets), so there should be no need to allocate your |
| own. This doesn't mean you must use the NetRxPackets array however; you're |
| free to call the NetReceive() function with any buffer you wish. So the pseudo |
| code here would look something like: |
| int ape_recv(struct eth_device *dev) |
| { |
| int length, i = 0; |
| ... |
| while (packets_are_available()) { |
| ... |
| length = ape_get_packet(&NetRxPackets[i]); |
| ... |
| NetReceive(&NetRxPackets[i], length); |
| ... |
| if (++i >= PKTBUFSRX) |
| i = 0; |
| ... |
| } |
| ... |
| return 0; |
| } |
| |
| The halt function should turn off / disable the hardware and place it back in |
| its reset state. It can be called at any time (before any call to the related |
| init function), so make sure it can handle this sort of thing. |
| |
| The write_hwaddr function should program the MAC address stored in dev->enetaddr |
| into the Ethernet controller. |
| |
| So the call graph at this stage would look something like: |
| some net operation (ping / tftp / whatever...) |
| eth_init() |
| dev->init() |
| eth_send() |
| dev->send() |
| eth_rx() |
| dev->recv() |
| eth_halt() |
| dev->halt() |
| |
| ----------------------------- |
| CONFIG_MII / CONFIG_CMD_MII |
| ----------------------------- |
| |
| If your device supports banging arbitrary values on the MII bus (pretty much |
| every device does), you should add support for the mii command. Doing so is |
| fairly trivial and makes debugging mii issues a lot easier at runtime. |
| |
| After you have called eth_register() in your driver's register function, add |
| a call to miiphy_register() like so: |
| #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) |
| miiphy_register(dev->name, mii_read, mii_write); |
| #endif |
| |
| And then define the mii_read and mii_write functions if you haven't already. |
| Their syntax is straightforward: |
| int mii_read(char *devname, uchar addr, uchar reg, ushort *val); |
| int mii_write(char *devname, uchar addr, uchar reg, ushort val); |
| |
| The read function should read the register 'reg' from the phy at address 'addr' |
| and store the result in the pointer 'val'. The implementation for the write |
| function should logically follow. |