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
