Re: [U-Boot-Users] [PATCH 2/2 (resubmit)] NET: Add Ethernet 1000BASE-X support for PPC4xx
Ben Warren wrote:
Larry Johnson wrote:
Hi Ben,
Thank you for your comments. See below...
Ben Warren wrote:
Larry,
I think this can be simplified a bit. More later on...
Larry Johnson wrote:
This patch adds a new switch: "CONFIG_PHY_DYNAMIC_ANEG". When this symbol is defined, the PHY will advertise it's capabilities for autonegotiation based on the capabilities shown in the PHY's status registers, including 1000BASE-X. When "CONFIG_PHY_DYNAMIC_ANEG" is not defined, the PHY will advertise hard-coded capabilities, as before.
Signed-off-by: Larry Johnson lrj@acm.org
common/miiphyutil.c | 155 +++++++++++++++++++++++++++++++++------------------ include/miiphy.h | 21 +++++++ 2 files changed, 121 insertions(+), 55 deletions(-)
diff --git a/common/miiphyutil.c b/common/miiphyutil.c index 58ebc5e..b2f62d0 100644 --- a/common/miiphyutil.c +++ b/common/miiphyutil.c @@ -344,101 +344,146 @@ int miiphy_reset (char *devname, unsigned char addr)
/*****************************************************************************
- Determine the ethernet speed (10/100).
*/
- Determine the ethernet speed (10/100/1000). Return 10 on error.
int miiphy_speed (char *devname, unsigned char addr) {
- unsigned short reg;
- u16 bmcr;
#if defined(CONFIG_PHY_GIGE)
- if (miiphy_read (devname, addr, PHY_1000BTSR, ®)) {
printf ("PHY 1000BT Status read failed\n");- } else {
if (reg != 0xFFFF) {if ((reg & (PHY_1000BTSR_1000FD | PHY_1000BTSR_1000HD))!= 0) {return (_1000BASET);}
- u16 btsr;
+#if defined(CONFIG_PHY_DYNAMIC_ANEG)
I don't think you need this CONFIG. It doesn't really do anything.
I only put it in to keep the footprint smaller for boards that aren't using fiber, so I'll get rid if it.
Yeah, and I like that train of thought, but I think clarity wins out here, and I doubt there are that many GigE boards that can't handle a few extra bytes (Don't tell Wolfgang I said that)
[snip]
Hi Ben and Stefan,
Thank you for incorporating my patch, Ben.
I have merged my changes into the PPC4xx "for-1.3.1" branch. When I do the MAKEALL there, the build for Ocotea board fails because the binary is now 0xAC byte too large. What are your opinions on the best way to handle this?
Best regards, Larry
On Wednesday 14 November 2007, Larry Johnson wrote:
Thank you for incorporating my patch, Ben.
I have merged my changes into the PPC4xx "for-1.3.1" branch. When I do the MAKEALL there, the build for Ocotea board fails because the binary is now 0xAC byte too large. What are your opinions on the best way to handle this?
Which gcc version did you use?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan Roese wrote:
On Wednesday 14 November 2007, Larry Johnson wrote:
Thank you for incorporating my patch, Ben.
I have merged my changes into the PPC4xx "for-1.3.1" branch. When I do the MAKEALL there, the build for Ocotea board fails because the binary is now 0xAC byte too large. What are your opinions on the best way to handle this?
Which gcc version did you use?
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
ppc_4xxFP-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)
Best regards, Larry
Hi Larry,
On Wednesday 14 November 2007, Larry Johnson wrote:
I have merged my changes into the PPC4xx "for-1.3.1" branch. When I do the MAKEALL there, the build for Ocotea board fails because the binary is now 0xAC byte too large. What are your opinions on the best way to handle this?
Which gcc version did you use?
ppc_4xxFP-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)
Too bad. I had hoped it was 3.x.
OK, I will take care of it after the merge window opens.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Stefan Roese wrote:
Hi Larry,
On Wednesday 14 November 2007, Larry Johnson wrote:
I have merged my changes into the PPC4xx "for-1.3.1" branch. When I do the MAKEALL there, the build for Ocotea board fails because the binary is now 0xAC byte too large. What are your opinions on the best way to handle this?
Which gcc version did you use?
ppc_4xxFP-gcc (GCC) 4.0.0 (DENX ELDK 4.1 4.0.0)
Too bad. I had hoped it was 3.x.
OK, I will take care of it after the merge window opens.
Best regards, Stefan
Thank you, Stefan.
BTW, I've noticed another issue with the "for-1.3.1" branch: the "diag run cache" command fails on the Sequoia board as well as our prototype Korat 440EPx board. Here's what happens with the current code on Sequoia, in case you haven't seen this yet:
[...] => diag run cache Bad trap at PC: ff75218, SR: 21000, vector=1300 NIP: 0FF75218 XER: 2000005F LR: 0FF752CC REGS: 0ff1c870 TRAP: 1300 DEAR: 10000000 MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 0000003F 0FF1C960 7FFFFFFF 10000000 00000400 00000400 00000020 FFFFFFFF GPR08: 0FFFBFEC 0FF7488C 0000000C 10000000 00000400 00000000 0FFAC400 0FFBF000 GPR16: 15809002 2000C001 C1800002 0FF1CB6A 00000001 00000000 0FF1CC65 00000000 GPR24: 00000600 0000000C 00000000 00000001 0FFA7020 0FF1CF34 0FFACE14 0FF747E0 Call backtrace: 0FF1CA44 0FF700EC 0FF704B0 0FF7807C 0FF76268 0FF76448 0FF63C84 0FF61698 Exception
U-Boot 1.3.0-rc3-gb53313db (Nov 19 2007 - 13:15:08)
CPU: AMCC PowerPC 440EPx Rev. A at 528 MHz (PLB=132, OPB=66, EBC=66 MHz) [...]
Best regards, Larry
Larry Johnson wrote:
[...] BTW, I've noticed another issue with the "for-1.3.1" branch: the "diag run cache" command fails on the Sequoia board as well as our prototype Korat 440EPx board. Here's what happens with the current code on Sequoia, in case you haven't seen this yet:
Sorry, I forgot to mention that this problem does *not* occur with code from the ppc4xx "master" branch.
Best regards, Larry
Larry Johnson wrote:
Ben Warren wrote:
Larry Johnson wrote:
Hi Ben,
Thank you for your comments. See below...
Ben Warren wrote:
Larry,
I think this can be simplified a bit. More later on...
Larry Johnson wrote:
This patch adds a new switch: "CONFIG_PHY_DYNAMIC_ANEG". When this symbol is defined, the PHY will advertise it's capabilities for autonegotiation based on the capabilities shown in the PHY's status registers, including 1000BASE-X. When "CONFIG_PHY_DYNAMIC_ANEG" is not defined, the PHY will advertise hard-coded capabilities, as before.
Signed-off-by: Larry Johnson lrj@acm.org
common/miiphyutil.c | 155 +++++++++++++++++++++++++++++++++------------------ include/miiphy.h | 21 +++++++ 2 files changed, 121 insertions(+), 55 deletions(-)
diff --git a/common/miiphyutil.c b/common/miiphyutil.c index 58ebc5e..b2f62d0 100644 --- a/common/miiphyutil.c +++ b/common/miiphyutil.c @@ -344,101 +344,146 @@ int miiphy_reset (char *devname, unsigned char addr)
/*****************************************************************************
- Determine the ethernet speed (10/100).
*/
- Determine the ethernet speed (10/100/1000). Return 10 on error.
int miiphy_speed (char *devname, unsigned char addr) {
- unsigned short reg;
- u16 bmcr;
#if defined(CONFIG_PHY_GIGE)
- if (miiphy_read (devname, addr, PHY_1000BTSR, ®)) {
printf ("PHY 1000BT Status read failed\n");- } else {
if (reg != 0xFFFF) {if ((reg & (PHY_1000BTSR_1000FD | PHY_1000BTSR_1000HD))!= 0) {return (_1000BASET);}
- u16 btsr;
+#if defined(CONFIG_PHY_DYNAMIC_ANEG)
I don't think you need this CONFIG. It doesn't really do anything.
I only put it in to keep the footprint smaller for boards that aren't using fiber, so I'll get rid if it.
Yeah, and I like that train of thought, but I think clarity wins out here, and I doubt there are that many GigE boards that can't handle a few extra bytes (Don't tell Wolfgang I said that)
[snip]
Hi Ben and Stefan,
Thank you for incorporating my patch, Ben.
I have merged my changes into the PPC4xx "for-1.3.1" branch. When I do the MAKEALL there, the build for Ocotea board fails because the binary is now 0xAC byte too large. What are your opinions on the best way to handle this?
Best regards, Larry
That sucks. I don't have this issue with my setup, but I also don't have anything to do with ppc4xx. Hopefully Stefan can shed some light.
regards, ben
participants (3)
-
Ben Warren -
Larry Johnson -
Stefan Roese