From: Richard Retanubun <RichardRetanubun@RuggedCom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Net: UEC: Question about (R)TBI interface initialization in u-boot.
Date: Wed, 27 May 2009 18:15:49 -0400 [thread overview]
Message-ID: <4A1DBB95.60109@RuggedCom.com> (raw)
Hello,
I am working on an 8360e platform, bringing up a RTBI interface on UCC1 connected as a FIXED_PHY_PORT (smi addr 8) to a switch chip port.
Question 1a
===========
In uec.c::uec_startup, there is this logic
if (enet_interface == ENET_1000_TBI ||
enet_interface == ENET_1000_RTBI) {
utbipar |= (uec_info->phy_address + uec_info->uf_info.ucc_num)
<< UTBIPAR_PHY_ADDRESS_SHIFT;
} else {
utbipar |= (0x10 + uec_info->uf_info.ucc_num)
<< UTBIPAR_PHY_ADDRESS_SHIFT;
}
With UCC1 (devnum = 0) I am hitting a bug here I think, because I am using UCC1 (devnum 0) my utbipar is set to (8+0)
which is the same as my fixed-port phy. The tbi controller (see section 30.11.7 on the 8360 reference manual) returns 0x0000
on its ID registers (register offset 2 and 3). This prevents the fixed-phy-port detection to finish and I got detected as a generic MII instead.
If the intent here is to make utibipar and the actual phy address different, can the logic be:
utbipar |= (uec_info->phy_address + uec_info->uf_info.ucc_num + 1) << UTBIPAR_PHY_ADDRESS_SHIFT;
to handle the case when ucc_num = 0 -----------------------------^
Question 1b
===========
on the else cause, when the interface is NOT (R)TBI, why is utbipar set at 0x10 offset from the UCC_num ?
Since the tbi controller is internal per UEC and responds in-precedent to any external PHY, keeping it@0x1F (the default)
will make sure it stays out of everyone's way and not impose additional PHY address selection restrictions (other than NOT being 0x1F)
on the HW design, no?
Question 2
==========
I got my RTBI interface working after modifying the TBICON register to match our hardware, now I am looking for a way to add support for it.
Is this a good approach?:
in uccf.h, make:
=================================
typedef struct ucc_tbireg {
unsigned short cr,
unsigned short sr,
...
} ucc_tbireg_t;
=================================
then add it as a member for typedef struct uec_info in uec.h
=================================
then fill it in during the initialization of the static UEC instantiation:
static uec_info_t eth2_uec_info = {
#if (CONFIG_SYS_UEC2_INTERFACE_MODE == ENET_1000_RTBI) || (CONFIG_SYS_UEC2_INTERFACE_MODE == ENET_1000_TBI)
.tbi_info = {
.cr = CONFIG_SYS_UEC2_TBI_CR,
.ana = CONFIG_SYS_UEC2_TBI_ANA,
....
},
#endif
=================================
Then process it during uec_startup, with values of "0x0" meaning do-not-modify (we can even add bitmasks to mpc83xx.h a'la DDRCDR or so).
=================================
If any of these have a hope of being mainlined, I can work out a patch (I can only test for RTBI though, since that is the only connection I got)
but the TBI registers should apply regardless.
Thanks very much for everyone's time!
- Richard.
reply other threads:[~2009-05-27 22:15 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4A1DBB95.60109@RuggedCom.com \
--to=richardretanubun@ruggedcom.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