am3354+AR8031组成的以太网 仍然是只能发送 无法接收数据包

am335x是否和phy一样有loopback功能？寄存器是哪个呢？

我已经找到LOOPBACK这个寄存器了。是0x4A100D84的bit1位。

我将bit1置1后，可以接收到自身发送的数据帧。

鉴于以上的测试，总结了一下，感觉是从AM335x到AR8031这里有问题，今天又在WINCE下将PinMux读取出来与在Starterware下的寄存器做对比，未发现什么异常，将WINCE下的PinMux的寄存器的数据更改到Starterware下，仍然只能发送 无法接收。所以感觉问题可能出在AR8031的寄存器上。现在想读取一下AR8031的寄存器。

请教一下，怎么在wince，linux或者安卓下，读取AR8031的寄存器的数据？有没有什么简单的方法可以在操作系统运行的过程中读取AR8031的寄存器？

这个可能是要增加一个类似驱动层的IOCTL命令，通过MDIO读取PHY内部的寄存器

感觉又不像是AR8031的问题，因为我用starter kit读取AR8031的寄存器 对比过了。没有什么区别。问题还能出在哪里呢？难道starter kit的8031和我的8031不一样？

你用的是千兆以太网RGMII模式吗？

如果是的话，建议你试一下：

1.修改Control Module的0x650的gmii_sel中的第5或者4比特，增加internal delay；

2. PHY端的也有个rx delay的配置，需要查一下phy端的手册，加上这个delay配置，进行测试。

我之前的一个客户遇到的情况是百兆收发正常，但是千兆只能发，不能收。解决方法用的是上述2。

按照您的方法：

1.将44E10650的BIT4和BIT5修改为1或者0，仍无法接收。

2.将PHY的rx delay 配置为使能或者禁止 ，仍无效果。

请问，是否还有其他原因呢？

对于PHY的RX delay配置成为使能这个测试，确认生效了吗？可以回读一下相关寄存器的值确认一下吗？

接收数据的软件配置话，能否确认相关管脚有没有在pinmux的配置上面做receive enable？

对于PHY的RX delay配置成为使能这个测试，确认生效了吗？可以回读一下相关寄存器的值确认一下吗？

答：根据手册

  读取这个寄存器的数据为0x82EE

 发现当硬件复位或者启动的时候  这个寄存器就是0X82EE了。我试着将这个寄存器改为0x02EE，也是不能接收数据。

接收数据的软件配置话，能否确认相关管脚有没有在pinmux的配置上面做receive enable？

答：您讲的在pinmux上面做receive enable 是如何操作呢？我没有找到相关的寄存器。

 我在offset650的BIT4和BIT5都设置为1后，无效果，设置为0后，仍然没有效果。

请解答一下，感谢！

您的意思是在pinmux配置管脚的时候要把receive enable 置1吗？我的是RGMII模式，需要把RXD【0-3】这4个管脚以及RXDV  总共5个管脚的BIT5都置1吗？

哦。。。我已经看到了   在starterware里面已经bit5=1了。  因为我用starter kit 跑的starterware是一样的。并且我在CPSWPinMuxSetup函数中已经看到了，并且配置成1了。

void CPSWPinMuxSetup(void)
{
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(0)) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(1)) =
CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(2)) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(3)) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(4)) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(5)) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(6)) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(7)) =
CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(8)) =
CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(9)) =
CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(10)) =
CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(11)) =
CONTROL_CONF_GPMC_AD0_CONF_GPMC_AD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_COL) =
CONTROL_CONF_MII1_COL_CONF_MII1_COL_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_CRS) =
CONTROL_CONF_MII1_CRS_CONF_MII1_CRS_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXERR) =
CONTROL_CONF_MII1_RXERR_CONF_MII1_RXERR_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXEN) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXDV) =
CONTROL_CONF_MII1_RXDV_CONF_MII1_RXDV_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD3) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD2) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD1) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXD0) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_TXCLK) =
CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXCLK) =
CONTROL_CONF_MII1_RXCLK_CONF_MII1_RXCLK_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD3) =
CONTROL_CONF_MII1_RXD3_CONF_MII1_RXD3_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD2) =
CONTROL_CONF_MII1_RXD2_CONF_MII1_RXD2_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD1) =
CONTROL_CONF_MII1_RXD1_CONF_MII1_RXD1_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_RXD0) =
CONTROL_CONF_MII1_RXD0_CONF_MII1_RXD0_RXACTIVE
| CPSW_RGMII_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_RMII1_REFCLK) =
CONTROL_CONF_RMII1_REFCLK_CONF_RMII1_REFCLK_RXACTIVE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MDIO_DATA) =
CONTROL_CONF_MDIO_DATA_CONF_MDIO_DATA_RXACTIVE
| CONTROL_CONF_MDIO_DATA_CONF_MDIO_DATA_PUTYPESEL
| CPSW_MDIO_SEL_MODE;
HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MDIO_CLK) =
CONTROL_CONF_MDIO_CLK_CONF_MDIO_CLK_PUTYPESEL
| CPSW_MDIO_SEL_MODE;
}

请问是否还有其他的地方需要做配置的？

我用Starter Kit的硬件测试源码测试了一下LOOPBACK功能。在10M情况下，mac内部loopback，PHY内部loopback，PHY外部loopback，都可以测试通过。但是100M和1000M都是只有MAC内部loopback可以测试通过，PHY内部和外部loopback都是失败的。

总结一下，只有10M是可以的，100和1000都失败。请教一下原因在什么地方呢？感觉还是am335x配置的有问题。求答复！

看你前面的描述，你已经dump过Linux和starterware下，关于EMAC和PHY的寄存器值，是把所有的值都做了比对，配置都是一样的？

PINMUX检查了没有问题，control module下面的gmii_sel中的配置也查了？没问题？PHY_ID的设置应该没问题（如果出问题了，你是找不到网卡，10M也无法ping通的）。还有就是RX delay的设置，已经生效问题。上述的这些都确认了，软件上面貌似没有其他的点了。

首先感谢您的回答，这么晚了，辛苦啦！

  我先给您屡一下我所有的操作:

1，我将开发板启动WINCE系统，将开发板与电脑连接，通讯正常。

2.在WINCE下，用寄存器读写软件，将CPSW_SS，CPSW_PORT，CPSW_CPDMA，CPSW_STATS，CPSW_STATERAM，CPSW_CPTS，CPSW_ALE，CPSW_SL1，CPSW_SL2，CPSW_WR，以及Control Module的Offset 650还有pinmux的寄存器读取出来。同样，也在starterware下，在运行完以太网初始化以后，加入代码将刚才的寄存器通过串口打印出来，与刚才WINCE的结果做对比，有个别寄存器有区别。

3.我将有区别的寄存器提取出来，在WINCE下，将starterware的数据写入寄存器，WINCE还是正常收发。

4.在starterware下，将WINCE的数据写入寄存器，仍然只能发不能收。

至此，考虑可能AR8031寄存器配置有问题:

1.在Starterware下，在初始化以太网以后，加入代码，将AR8031的32个寄存器全部打印出来。

2.由于在WINCE下，不知如何读取AR8031的寄存器，所以把目标转向了uboot，因为启动uboot后，使用uboot可以ping通电脑，我认为他的以太网部分是正常的。

3.在uboot下，使用mw.l 和md.l修改寄存器指令，模拟通过MDIO读取AR8031的函数，操作寄存器0x4A101080这个寄存器，顺利将AR8031的寄存器读出，与starterware读取的结果做对比，同样也是个别寄存器有区别。

4.像前面一样，将两数据对调后，仍然没有任何效果。至此，感觉又排除了AR8031寄存器配置有问题的可能性。有点想疯掉的感觉！！！

无奈，只好将starter kit 请出来了:

1.运行同一个代码，将以上提到的寄存器打印出来，做对比，结果惊人的一致啊！可是starter kit竟能收发自如。

2.突然有一天，在官网上面看到了starter kit的一个测试代码，主要是通过loopback测试网卡，将其移植成CCS的工程文件，并且编译出.out文件，测试了一下，starter kit 10M 100M 1000M全部漂亮的passed。而我的开发板10M 可以passed但是100M  1000M都失败了。

现在我迷茫了，不知是否我的思路存在问题？或者我哪里还有做的不够严谨的地方？还是有我没有想到的寄存器？

麻烦您来指点迷津！万分感谢！

会否可能硬件电路上有问题，或者芯片的版本或批次问题呢

首先，硬件应该没有问题  ，不然WINCE下应该无法接收。第二如果是芯片版本或者批次的问题，我感觉可能性不大吧 。这要问一下TI的工作人员了。

AR8031是我们demo板上用的，我们的BSP基于demo板也已经做过测试了，如果软件没什么改动，应该和驱动关系不大。

我们的芯片无论什么版本，以太网这部分没有任何变化的。我觉得还是不能排除硬件的问题，千兆以太网PHY对布线要求很高的，如果电容电阻用错也是不能正常工作的

那请教为何我在WINCE和uboot linux 安卓下  都可以呢？如果硬件有问题，在OS下  应该也不行吧。

根据你的描述，还是建议对照starter kit检查一下硬件。

starterware上面的以太网通信程序和OS的还是不一样的，也许staterware上的测试程序暴露了硬件上的某些缺陷。

我还是感觉不是硬件的问题，应该是寄存器设置的问题。我又做了如下的操作：

1在SD卡上面.运行U-BOOT

2.此时用CCS连接仿真器

3.暂停CPU

4.将.out文件下载进去。

5.10M 100M 1000M都可以正常收发。

所以，我感觉是先运行UBOOT，将某个寄存器配置好了，再运行starterware的代码就可以了。看来还得从寄存器上面入手，但是现在迷茫了，不知道有哪些寄存器是uboot初始化过的，请教如何才能将uboot以太网部分初始化的寄存器打印出来呢？

U-boot里面有通过串口打印信息的函数，直接调用函数把CPSW里的寄存器值打印出来就可以了。

不知道什么原因，我写的问题贴子会被自动删除，以前从为没有发表过。

借兄弟的问题这里，我得新贴一下内容：

问题：AM335x的网络驱动中用到了定时器5和定时器6资源，能否更换这二个定时器资源？

在AM335x处理器的网络驱动中，文件名称是driver/net/cpsw.c或者driver/net/ethernet/ti/cpsw.c，这个文件中使用到了二个定时器，用于当作interrupt pacing，它所用的定时器编号分别是5和6 ，有如下的宏定义：

#define CPSW_RX_TIMER_REQ 5
#define CPSW_TX_TIMER_REQ 6

现在的问题是能不能将它们修改成：

#define CPSW_RX_TIMER_REQ 4
#define CPSW_TX_TIMER_REQ 7

我修改后测试，网口就不通了，不知道是什么原因？请问有谁清楚这个问题，谢谢！

你好，我现在也遇到这样的问题，请问下你再pll ddr初始化的时候有哪些地方配置不全？

我在SPL阶段使用的是TI官网提供的starterware 的BootLoader，但是由于时移植到自己的板上，我直接屏蔽掉了一些关于电源OOP配置的东西，

在自己的板上也可以成功运行起来，我不知道是不是这里的问题，所以请问下在你的工程中PLL DDR配置是怎样配置的？