public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] [83xx] Adds two more ethernet interface to 83xx
Date: Thu, 25 Sep 2008 16:42:17 -0400	[thread overview]
Message-ID: <48DBF7A9.3010905@ge.com> (raw)
In-Reply-To: <48DB89C4.3060204@ruggedcom.com>

richardretanubun wrote:
> Added for convenience for other platforms that uses MPC8360 (has 8 UCC).
> 6 eth interface is chosen because the platform I am using combines
> UCC1&2 and UCC3&4 as gigEth and the other 4 UCC as 10/100 Eth.

We are about to fall into a never ending explosion of #define 
CONFIG_ETHnnnADDR.  This is bad.  Very bad.  :-(

Kumar solved this problem WRT cpu/mpc83xx/fdt.c fdt_fixup_ethernet(void 
*fdt) (and other CPUs) by using the device tree to find all the 
ethernets and configure them.
   <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/45554>

Is bdinfo relevant? If not, return;  /* that was easy */

If bdinfo is still relevant, look at how Kumar solved the #define 
explosion in cpu/*/fdt.c.  You should be able to adapt it in the code 
you augmented with CONFIG_ETH[45]ADDR.

Suggestion: Look at changing CONFIG_ETH*ADDR to CONFIG_ETH_FDT where 
that notation indicates the code should find the ethernet info in the 
fdt blob rather than #defines/env variables.

One fly in the ointment is if we don't have a fdt blob to pick the 
ethernet parameters out of.  Perhaps this is because we are going to 
load a fdt blob over the ethernet.  We discussed having a default blob 
(probably the more elegant solution).  A simpler and more "the way it is 
now" solution would be to define a limited number of #define 
CONFIG_ETH*ADDR values (I think 2 would be adequate, but at least limit 
ourselves to the current 4 max).  Then bare board fdt blob loading would 
have to be over one/two/four fixed ethernet ports, but once a valid fdt 
blob was loaded all of the ethernets would be configured properly by u-boot.

> ---
>  README                   |    3 ++
>  common/cmd_bdinfo.c      |   17 +++++++++++++++-
>  common/env_common.c      |    6 +++++
>  common/env_embedded.c    |    6 +++++
>  cpu/mpc83xx/fdt.c        |    3 +-
>  drivers/qe/uec.c         |   48 +++++++++++++++++++++++++++++++++++++++++++++-
>  include/asm-ppc/u-boot.h |    6 +++++
>  lib_ppc/board.c          |   30 ++++++++++++++++++++++++++++
>  net/eth.c                |    6 +++++
>  tools/env/fw_env.c       |    6 +++++
>  10 files changed, 128 insertions(+), 3 deletions(-)
> 
> diff --git a/README b/README
> index ccd839c..8802304 100644
> --- a/README
> +++ b/README
> @@ -1095,8 +1095,11 @@ The following options need to be configured:
>  
>  - Ethernet address:
>  		CONFIG_ETHADDR
> +		CONFIG_ETH1ADDR
>  		CONFIG_ETH2ADDR
>  		CONFIG_ETH3ADDR
> +		CONFIG_ETH4ADDR
> +		CONFIG_ETH5ADDR

Bleah!  Oh, right, I said that already.

[snip]

> +#if defined(CONFIG_HAS_ETH4)
> +       puts ("\neth4addr    =");
> +       for (i=0; i<6; ++i) {
> +		printf ("%c%02X", i ? ':' : ' ', bd->bi_enet4addr[i]);
> +	}
> +#endif
> +
> +#if defined(CONFIG_HAS_ETH5)
> +       puts ("\neth5addr    =");
> +       for (i=0; i<6; ++i) {
> +		printf ("%c%02X", i ? ':' : ' ', bd->bi_enet5addr[i]);
> +	}
> +#endif
> +

No, don't add more cut'n'pastes.  Bleah!  Use a fdt_*() loop (a'la 
Kumar's code).  This would have to be conditional on CONFIG_LIBFDT since 
not all boards use LIBFDT.  If !defined(CONFIG_LIBFDT), use the existing 
code.

> diff --git a/common/env_common.c b/common/env_common.c
> index 77f9944..0fee3af 100644
> --- a/common/env_common.c
> +++ b/common/env_common.c
> @@ -91,6 +91,12 @@ uchar default_environment[] = {
>  #ifdef	CONFIG_ETH3ADDR
>  	"eth3addr="	MK_STR(CONFIG_ETH3ADDR)		"\0"
>  #endif
> +#ifdef	CONFIG_ETH4ADDR
> +	"eth4addr="	MK_STR(CONFIG_ETH4ADDR)		"\0"
> +#endif
> +#ifdef	CONFIG_ETH5ADDR
> +	"eth5addr="	MK_STR(CONFIG_ETH5ADDR)		"\0"
> +#endif

Bleah!  I would prefer to cut our losses at CONFIG_ETH1ADDR (or 
CONFIG_ETH3ADDR), see lead-in discussion.

> diff --git a/common/env_embedded.c b/common/env_embedded.c
> index 77e5619..e79f843 100644
> --- a/common/env_embedded.c
> +++ b/common/env_embedded.c
> @@ -135,6 +135,12 @@ env_t environment __PPCENV__ = {
>  #ifdef	CONFIG_ETH3ADDR
>  	"eth3addr="	MK_STR(CONFIG_ETH3ADDR)		"\0"
>  #endif
> +#ifdef	CONFIG_ETH4ADDR
> +	"eth4addr="	MK_STR(CONFIG_ETH4ADDR)		"\0"
> +#endif
> +#ifdef	CONFIG_ETH5ADDR
> +	"eth5addr="	MK_STR(CONFIG_ETH5ADDR)		"\0"
> +#endif
>  #ifdef	CONFIG_ETHPRIME
>  	"ethprime="	CONFIG_ETHPRIME			"\0"
>  #endif

Bleah! ...but I repeat myself.

Do we need eth[1-5]?addr env variables?  I don't think so.

If we really do need them, they can be generated from the fdt blob a'la 
Kumar's loop.

> diff --git a/cpu/mpc83xx/fdt.c b/cpu/mpc83xx/fdt.c
> index 39bd9dc..3e3e1c8 100644
> --- a/cpu/mpc83xx/fdt.c
> +++ b/cpu/mpc83xx/fdt.c
> @@ -52,7 +52,8 @@ void ft_cpu_setup(void *blob, bd_t *bd)
>  		fdt_fixup_crypto_node(blob, 0x0204);
>  
>  #if defined(CONFIG_HAS_ETH0) || defined(CONFIG_HAS_ETH1) ||\
> -    defined(CONFIG_HAS_ETH2) || defined(CONFIG_HAS_ETH3)
> +    defined(CONFIG_HAS_ETH2) || defined(CONFIG_HAS_ETH3) ||\
> +    defined(CONFIG_HAS_ETH4) || defined(CONFIG_HAS_ETH5)

Bleah!  I counter-propose a single CONFIG_ETH_FDT.  Alternatively, if 
defined(CONFIG_HAS_ETH0), it is a good bet that you want to call 
fdt_fixup_ethernet(blob); and *that* routine handles up all defined 
ethernet spiggots (thanks, Kumar!).

>  	fdt_fixup_ethernet(blob);
>  #endif
>  
> diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
> index 344c649..e1dec5e 100644
> --- a/drivers/qe/uec.c
> +++ b/drivers/qe/uec.c
> @@ -123,8 +123,54 @@ static uec_info_t eth4_uec_info = {
>  	.enet_interface		= CFG_UEC4_INTERFACE_MODE,
>  };
>  #endif
> +#ifdef CONFIG_UEC_ETH5
> +static uec_info_t eth5_uec_info = {
> +	.uf_info		= {
> +		.ucc_num	= CFG_UEC5_UCC_NUM,
> +		.rx_clock	= CFG_UEC5_RX_CLK,
> +		.tx_clock	= CFG_UEC5_TX_CLK,
> +		.eth_type	= CFG_UEC5_ETH_TYPE,
> +	},
> +#if (CFG_UEC5_ETH_TYPE == FAST_ETH)
> +	.num_threads_tx		= UEC_NUM_OF_THREADS_1,
> +	.num_threads_rx		= UEC_NUM_OF_THREADS_1,
> +#else
> +	.num_threads_tx		= UEC_NUM_OF_THREADS_4,
> +	.num_threads_rx		= UEC_NUM_OF_THREADS_4,
> +#endif
> +	.riscTx			= QE_RISC_ALLOCATION_RISC1_AND_RISC2,
> +	.riscRx			= QE_RISC_ALLOCATION_RISC1_AND_RISC2,
> +	.tx_bd_ring_len		= 16,
> +	.rx_bd_ring_len		= 16,
> +	.phy_address		= CFG_UEC5_PHY_ADDR,
> +	.enet_interface		= CFG_UEC5_INTERFACE_MODE,
> +};
> +#endif
> +#ifdef CONFIG_UEC_ETH6
> +static uec_info_t eth6_uec_info = {
> +	.uf_info		= {
> +		.ucc_num	= CFG_UEC6_UCC_NUM,
> +		.rx_clock	= CFG_UEC6_RX_CLK,
> +		.tx_clock	= CFG_UEC6_TX_CLK,
> +		.eth_type	= CFG_UEC6_ETH_TYPE,
> +	},
> +#if (CFG_UEC6_ETH_TYPE == FAST_ETH)
> +	.num_threads_tx		= UEC_NUM_OF_THREADS_1,
> +	.num_threads_rx		= UEC_NUM_OF_THREADS_1,
> +#else
> +	.num_threads_tx		= UEC_NUM_OF_THREADS_4,
> +	.num_threads_rx		= UEC_NUM_OF_THREADS_4,
> +#endif
> +	.riscTx			= QE_RISC_ALLOCATION_RISC1_AND_RISC2,
> +	.riscRx			= QE_RISC_ALLOCATION_RISC1_AND_RISC2,
> +	.tx_bd_ring_len		= 16,
> +	.rx_bd_ring_len		= 16,
> +	.phy_address		= CFG_UEC6_PHY_ADDR,
> +	.enet_interface		= CFG_UEC6_INTERFACE_MODE,
> +};
> +#endif

Is this in the fdt blob?  If not, we should add it (possibly 
coordinating with the kernel folks.

> -#define MAXCONTROLLERS	(4)
> +#define MAXCONTROLLERS	(6)
>  
>  static struct eth_device *devlist[MAXCONTROLLERS];

Hmmm, I don't have an clever answer for this one.  Looks like we will 
need a MAXCONTROLLERS to make our devlist[].

> diff --git a/include/asm-ppc/u-boot.h b/include/asm-ppc/u-boot.h
> index 54ac01d..7451905 100644
> --- a/include/asm-ppc/u-boot.h
> +++ b/include/asm-ppc/u-boot.h
> @@ -111,6 +111,12 @@ typedef struct bd_info {
>  #ifdef CONFIG_HAS_ETH3
>  	unsigned char   bi_enet3addr[6];
>  #endif
> +#ifdef CONFIG_HAS_ETH4
> +	unsigned char   bi_enet4addr[6];
> +#endif
> +#ifdef CONFIG_HAS_ETH5
> +	unsigned char   bi_enet5addr[6];
> +#endif

More evil.  I would like to se the bd_info struct go away.  Please check 
if anybody really needs bi_enet[0-5]addr after looking into my 
suggestions/objections above.  If we cannot make bd_info go away, we 
should be able to stop making it bigger.

[snipped remainder of the same]

Thanks,
gvb

  parent reply	other threads:[~2008-09-25 20:42 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-25 12:53 [U-Boot] [PATCH] [83xx] Adds two more ethernet interface to 83xx richardretanubun
2008-09-25 19:50 ` Kim Phillips
2008-09-25 20:25   ` richardretanubun
2008-09-25 20:45     ` Kim Phillips
2008-09-25 22:08       ` Wolfgang Denk
2008-09-25 21:44     ` [U-Boot] [PATCH v2] " richardretanubun
2008-09-25 22:24       ` Wolfgang Denk
2008-09-25 22:52         ` richardretanubun
2008-09-25 23:28           ` Wolfgang Denk
2008-09-29 12:43             ` richardretanubun
2008-09-29 13:07               ` Jerry Van Baren
2008-09-29 22:28                 ` [U-Boot] [PATCH v3] " richardretanubun
2008-09-30 16:00                   ` Kim Phillips
2008-09-30 15:58                     ` Jerry Van Baren
2008-09-30 17:02                     ` Ben Warren
2008-10-06  5:12                   ` Ben Warren
2008-10-06 19:31                     ` richardretanubun
2008-10-14  5:53                       ` Ben Warren
2008-09-25 22:24   ` [U-Boot] [PATCH] " Wolfgang Denk
2008-09-25 20:42 ` Jerry Van Baren [this message]
2008-09-25 22:17   ` Wolfgang Denk
2008-09-26  3:44 ` Jerry Van Baren
2008-09-26  5:46   ` Wolfgang Denk
2008-09-26  7:21   ` Ben Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48DBF7A9.3010905@ge.com \
    --to=gerald.vanbaren@ge.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox