Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

More information for you.

Attached is a comparison between the Critical link schematics and ours schematics. View this in a PDF reader and choose under menu View>Page display>Two Up to see full schematics.

The green shows the differences. The green on the components means a different value and the reset is the biggest difference since we connected the reset to the system reset and do not have a pull up on it.

Hi John,

I think you need to tie the RESET line on the phy to the MII_RESET_N signal. The SYS_RESET_N does not get asserted in u-Boot (or the baseline kernel, as neither the SPI or audio device support has been tested and released yet --- soon I hope). Unless you gracefully reset the PHY, that part does not come up reliably from power up. I would recommend tacking both a pullup resistor and the MII_RESET_N signal to the PHY. I think this will resolve the problem.

Did you leave off C216? (green highlight)? You may need that one as well.

-Mike

Mike,

The green on the component means I used a different value cap or resistor. C216 is there but I used a 1uF ceramic Cap instead of the 0.1uF. I must have saw that in the TLK100 spec otherwise I would not have made it different. The cap I used is an 0402 so I can easily change it to a 0.1uF if needed.

I suspected it was because of the reset. It is a pretty simple change for me to make a cut and add a jumper to connect the MII_RESET_N which comes form the MityDSP connector pin 54 instead of pin 52.

Does this MII_RESET_N need a pullup? Because I do not have a pullup on this line.

thanks for the very quick response.

John

yes. you should add a pull-up.

OK I made all the changes and it still does not work. I now think there are only two difference between out circuits:

1) pull up resistor values mine 4.75K and yours 2.2K

2) I grounded the Ethernet connector shield/cover and you did not.

Do you think either of these two could be the problem?

Can you dump out the text from the boot sequence? Does the u-Boot locate the PHY (via the MDIO scan)?

-Mike

I saw this among the test

EMAC: MII PHY configured, RMII PHY will not be functional

I attached the whole text

That message is OK. You can set up ethernet to use MII or RMII (but not both, and you're using MII).

It looks like it found the phy via MDIO OK and it is trying to get a dhcp address and failing.

You might try:

root@mitydsp:~#  ifconfig -a

and see if eth0 is there but not "UP". That may be the case if it wasn't able to get a DHCP address.

Can you "ping", etc. using u-Boot?

if you can use a fixed address, try something like:

root@mitydsp:~#  ifconfig eth0 192.168.0.youipaddress netmask 255.255.255.0 
root@mitydsp:~#  ifconfig eth0 up

-Mike

hey would it be possible that we talk on the phone?

858-254-0008

Does the Ethernet on the MityDSP need to be initialized for each new TLK100 it gets plugged into? This one was initialized when plugged into one of the Critial Link boards and never reinitialized. When I first plugged it into the Critial Link baord the Ethernet did not work until our software guy told me a series of commands to set environment variable and some other stuff. Does this need to be done each time the MityDSP gets plugged into a new development board with a new TLK100 phy on it?

What were the software commands? If they involved setting the peripheral configuration in u-Boot, then they only need to be run once (assuming a "config save" was performed).

I guess I'm not sure I understand what you did to fix the issue.

-Mike

I didn't write them down I just typed them when he told me to. This was in u-boot. Once I typed them in I could ping in uboot I didn't get it to work yet in our control board but if I plug it into your development it works fine.

Here is the ip addrs when plugged into the Critial Link and IT WORKS
Critical Link dev IT WORKS
root@mityomapl138:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:50:c2:bf:83:24 brd ff:ff:ff:ff:ff:ff
inet 172.16.1.37/16 scope global eth0

Here is the ip addrs (same exact MityDSP Board) when plugged into the Cianna Control and IT Doesnt WORK
Cianna Control BRD Doesn't work
mityomapl138 login: root
root@mityomapl138:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:50:c2:bf:83:24 brd ff:ff:ff:ff:ff:ff
inet 169.254.7.210/16 brd 169.254.255.255 scope link eth0:avahi

Why is the IP address different when I plug the MityDSP into a different carrier board? Isn't this saved in FLASH and should be the same every time it boots?

Hi John,

It looks like the OMAP MII interface is not making it to your network. The 169.254.X.X network means that the OMAP tried to use DHCP to get a network address, but was unable to find a DHCP server and get a response. After a short period, the DHCP process times out and it uses another protocol to "just pick" an address and let the boot process proceed (Automatic Private IP Addressing - APIPA).

So. Either the MII interface between the MityDSP-L138F (the OMAP) and the TLK100 isn't hooked up right, or the TLK100 interface through the magnetics to your local area network isn't hooked up right.

I don't see anything obvious at the moment.

Looking at your original schematic, I do see you have some circuitry hooked to the JTAG interface of the TLK100. Are R65-R68 or the JTAG connector installed?

You might try running wireshark (or other ethernet snooper) and seeing if the DHCP request packets are making it onto the wire from the OMAP while installed on your board. If you see the packets, then the problem can be narrowed to the receive side of the circuitry.

You might also double check that the reset line is being deasserted by the OMAP (though if the PHY probing works, I don't think that's it).

-Mike

The JTAG R's and connector are not installed.

I have the ethernet connected to my home switch.

I set the Ip address to a fixed value the was not used on my network, that is where the 172.15.1.37 came from. It is not that on the Cianna board but it is on the Critical link board. Why is it different between the two isn't this value saved in FLASH on the MityDsp?

Power up the unit in your board. Stop at u_boot and type:

u-Boot > printenv 
u-Boot > bootm

and send me or post all of the text output, please.

Mike,

After talking this out with our software guy we are convinced its as your said,one of two things. The connection form the TLK100 to the Ethernet or a configuration pullup that configured it wrong on power up. The board does not get the link light ever while your board gets it with or without the MityDsp plugged in.

I did notice that the SPEC for the RJ45 magnetics (Pulse Eng Doc J426.B dated 4/09) shows Pin 11 and 12 swapped from the way you and I pinned it out. But it works on your board with the LED

Here it is:

U-Boot > printenv
bootcmd=sf probe 0;sf read 0xc0700000 0x100000 0x280000;bootm 0xc0700000
bootdelay=3
baudrate=115200
bootfile="uImage"
flashuboot=tftp 0xc0700000 mityomap/u-boot-ubl.bin; sf probe 0; sf erase 0x10000
0x80000; sf write 0xc0700000 0x10000 ${filesize}
flashkernel=tftp 0xc0700000 mityomap/uImage; sf probe 0; sf erase 0x100000 0x280
000; sf write 0xc0700000 0x100000 ${filesize}
flashrootfs=tftp 0xc0000000 mityomap/mityomap-base-mityomapl138.jffs2; nand eras
e 0 0x08000000; nand write.jffs2 0xc0000000 0 ${filesize}
serverip=192.168.0.23
autoload=no
mtdids=nand0=nand
mtdparts=mtdparts=nand:128M(rootfs),-(userfs)
bootargsbase=mem=96M console=ttyS1,115200n8
flashargs=setenv bootargs ${bootargsbase} ${mtdparts} root=/dev/mtdblock0 rw roo
tfstype=jffs2
ethaddr=00:50:c2:bf:df:ff
bootargs=mem=96M console=ttyS1,115200n8 mtdparts=nand:128M(rootfs),-(userfs) roo
t=/dev/mtdblock0 rw rootfstype=jffs2
netmask=255.255.0.0
ipaddr=172.16.1.37
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 2009.11-00162-g649c446 (Jun 28 2010 - 08:12:30)

Environment size: 1031/65532 bytes
U-Boot > bootm
Wrong Image Format for bootm command
ERROR: can't get kernel image!
U-Boot >

Mike

Just to be sure can you tell me how you pinned out the PCB footprint. Does it match this picture looking from the top or component side of the board?

John

Mike,

FYI It was the bias resistor. There was a type in the BOM and a 49.9K was installed instead of a 4.99K. Once I replaced this everything worked fine.

John