TI中文支持网工程师，您好！
我使用Appro的DM368 IPNC，由于板子没有拉出串口启动开关，而且CCS烧写的效率又太低，所以我尝试使用SD卡烧写uboot和ubl文件，然后再从nand启动。 我参考了TI Wiki上的SD card boot and flashing tool for DM355 and DM365来制作启动的SD卡，这些过程都还算顺利。
我把SD卡插入板子，并从SD卡启动，选择“2-install”，然后从nand启动，但是报错No ETH PHY detected!!!，具体信息如下：
DM36x initialization passed!
TI UBL Version: 1.50
Booting Catalog Boot Loader
BootMode = NAND
Starting NAND Copy…
Valid magicnum, 0xA1ACED66, found in block 0x00000019.
DONE
Jumping to entry point at 0x81080000.
U-Boot 1.3.4 (May 22 2009 – 11:25:39)
I2C: ready
DRAM: 128 MB
NAND: NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
NAND device: Manufacturer ID: 0xec, Chip ID: 0xf1 (Samsung NAND 128MiB 3,3V 8-bit)
Bad block table found at page 65472, version 0x01
Bad block table found at page 65408, version 0x01
256 MiB
*** Warning – bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
EEPROM @ 0x50 read FAILED!!!
No ETH PHY detected!!!
ethernet init failed!
想请教工程师，这个问题应该如何解决？有什么建议吗？谢谢！！！
Eason Wang：
你通过SD烧写的这个uImage是否确认和通过CCS烧写到nand的出自同一个版本？
你描述的现象比较奇怪，假设烧写是成功的，那么软件一样没有理由不认到phy的。
建议你回去用CCS烧写看看是否有此问题？
PHY找不找的到主要还是看PHY ID通常在PHY外面由跳线决定。
你通过SD烧写nand后从nand启动，是否复位多次也都是一样的情况？是否有试过断电重启？
weidong yao：
回复 Eason Wang:
感谢您的回复，我觉得还没有涉及到uImage，应该还是uboot和ubl的问题，因为还没有到内核启动的地方，是在uboot启动时就出问题了。
通过SD烧写的uboot和ubl文件和通过CCS烧写到nand的uboot和ubl文件是不一样的。
因为通过CCS烧写的ubl和uboot是板子配套的RDK里就有的，而我用这两个文件制作的sd卡启动就会出新的问题，串口信息如下：
DM36x initialization passed!TI UBL Version: 1.50Booting Catalog Boot LoaderBootMode = NANDStarting NAND Copy…Valid magicnum, 0xA1ACED66, found in block 0x00000019. DONEJumping to entry point at 0x81080000.
（就没有下文了）
而如果我使用sd卡制作工具自带的ubl和uboot来制作启动卡，就会出现”No ETH PHY detected!!!“，像我最开始描述的那样。
我断电重启过很多次，结果也是一样的。
另外，我使用的是appro的dm368板子，不是evm，而sd卡制作工具里原有的ubl和uboot是针对dm365evm的，这可能导致No ETH PHY detected!!!错误吗？
想请教一下您的看法
Eason Wang：
回复 weidong yao:
不好意思，前面uImage是笔误。
No eth phy detect这句，其实只是MDIO去和Phy进行通信的一个标志，可以认为是mac和phy之间配置是通了。这个不通，一般的原因就是phy id（phy addr）不匹配。
EVM和APPRO的机器，PHY ADDR是不同的。EVM是0，而Appro是1.
建议你可以检查一下Phy芯片上phy id的管脚是否做了上下拉，对应的phy id到底是什么
weidong yao：
回复 Eason Wang:
恩，之前我没有注意过这个问题，我会让做硬件的同事帮我确认一下您讲的phy id问题。
那如何解决这个问题呢？修改EVM的uboot source可以吗？
我注意到TI的另一个帖子有相似的问题，http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/p/108996/1184605.aspx#1184605
那个帖子最后一个回复是我发的，这个帖子是修改的
board/davinci/dm365evm.c
/* Configure PINMUX 3 to enable EMAC pins */ writel((readl(PINMUX3) | 0x1affff), PINMUX3); writel(0x00000015, PINMUX2);// use GPIO 57 – 64 加了这一句
但在这个问题里边是GPIO60连接了ETH PHY的复位引脚，而appro的片子是GPIO50连接了ETH PHY的复位引脚，所以想请教您，
如果我想尝试这种方法，writel(0x00000015, PINMUX2);这句应该如何修改呢？或者说您有更方便可行的方法？
谢谢！
Eason Wang：
回复 weidong yao:
如果假设是Reset导致的问题，我想你可以简单地断开reset，或者手动进行reset。
这边我个人认为phy id是明显不对的。
weidong yao：
回复 Eason Wang:
嗯，如果说这个修改只是和reset有关的话，那成功的可能性也不会太大，但是也可以试一下。
另外，您讲的phy id不对，我觉得挺有道理的，但是因为我之前没有怎么了解过uboot和ubl的具体代码，所以我不太清楚这个应该怎么修改呢？
您能给一些建议吗？
user4046722：
回复 weidong yao:
Jumping to entry point at 0x81080000.
我也是到这里不动了
