
On 21:04 Sat 18 Jul , Mike Frysinger wrote:
Signed-off-by: Mike Frysinger vapier@gentoo.org
Ben: some things to note:
- i adopted Jean's proposed naming scheme in the CONFIG section
- i deprecated calling the driver-specific entry point "xxx_initialization()" in favor of "xxx_register()" because the former is way too confusing with everyone also having "xxx_init()"
doc/README.drivers.eth | 199 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 199 insertions(+), 0 deletions(-) create mode 100644 doc/README.drivers.eth
diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth new file mode 100644 index 0000000..00b4eb1 --- /dev/null +++ b/doc/README.drivers.eth @@ -0,0 +1,199 @@ +-----------------------
- 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.
+----------------
- CONFIG Options
+----------------
+The common config defines your device should respect (if applicable):
- CONFIG_MII - configure in MII mode
- CONFIG_RMII - configure in RMII mode
how will you deal you on your board you have a MII and a RMII chip used I think need to be configure via drivers specifc CONFIG if your driver can not deal with 2 different instance config or via driver init param
- CONFIG_CMD_MII - support the MII command
+If you want to add config options specific to your driver, you should use the +naming convention:
- CONFIG_NET_<DRIVERNAME>_<OPTION>
+For example, if the APE driver could operate in either 16bit or 32bit mode, +there would probably be the option:
- CONFIG_NET_APE_32BIT - operate in 32bit mode rather than 16bit default
+And to control whether your driver is even enabled, you should use:
- CONFIG_SYS_NET_<DRIVERNAME>
In my proposition CONFIG_SYS_ will be not use for driver enabling but for hardware specific information
+So the APE driver would look like:
- CONFIG_SYS_NET_APE
so it will be CONFIG_NET_APE
+------------------
- 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.
<snip>
+----------------
- 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: +#ifdef 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.
we will rewrite this api when we will push the phylib
Best Regards, J.