On 21:04 Sat 18 Jul , Mike Frysinger wrote: > Signed-off-by: Mike Frysinger <vap...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot