TWR-VF65GS10-KIT and networking out of the box

cancel
Showing results for 
Search instead for 
Did you mean: 

TWR-VF65GS10-KIT and networking out of the box

Jump to solution
1,375 Views
Contributor II

I have just received the TWR-VF65GS10-KIT that included the Vybrid board (Rev H) and the TWR-SER board (Rev G) and wondering if Ethernet should be fully functional right out of the box without changing any jumper settings. I am trying to use ping from within uboot first and then load using tftp but I am running into some difficulties.

Test case 1:

The kit came with U-Boot 2013.07-00004-gaae4ee8 (Jun 05 2014 - 16:00:42) and after configuring the MAC address to match the sticker on the back side of the TWR-SER board, I can see that the Ethernet LEDs come on but I am unable to ping out.

Test case 2:

After reading some other entries on this forum I configured my TWR-SER board to J2: 3-4, J3: 2-3, J12: 9-10 to enable RMII to match what I think the rev H Vybrid board is expecting. After this uboot produces no networking LEDs indicating that the configuration is probably worse than Test case 1.

After this I booted up the rootfs on the SD card (that came preset) and experienced the same from within the Linux kernel (Test Case 1 produces Ethernet LEDs, but not functioning, Test Case 2 produces no Ethernet LEDs).

So my question is this, is networking with the described mix of SW and HW revisions supported? If yes, what am I doing wrong? Where is it documented?

I have also tried using the Open SDA connection but found it unreliable and switched over to use the real serial port to connect to my terminal program on my PC.

The version of Linux that was present on the SD card:

Linux version 3.0.15-ts-armv7l (freescale@ubuntu) (gcc version 4.7.3 (Timesys 20140113) ) #2 Tue Jun 10 08:18:57 CEST 2014

the version of uboot:

U-Boot 2013.07-00004-gaae4ee8 (Jun 05 2014 - 16:00:42)

Here is my uboot environment:

=> printenv

baudrate=115200

boot_fdt=try

bootargs=mem=128M console=ttymxc1,115200 root=/dev/mmcblk0p2 rw rootwait

bootcmd=run load_image2; run load_m4; run run_m4; run run_linux

bootdelay=1

bootscript=echo Running bootscript from mmc ...; source

console=ttymxc1

ethact=FEC

ethaddr=00:04:9F:02:F8:38

fdt_addr=0x81000000

fdt_file=vf610-twr.dtb

fdt_high=0xffffffff

initrd_high=0xffffffff

ip_dyn=yes

ipaddr=10.0.152.124

load_image2= mmc rescan; fatload mmc 0:1 0x86000000 logo.bmp

load_m4=mmc rescan; fatload mmc 0:1 0x3f000000 accelerometer_example_twrvf65gs10_m4.bin

loadaddr=0x80010000

loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};

loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}

loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}

mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}

mmcboot=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootm ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootm; else echo WARN: Cannot load the DT; fi; fi; else bootm; fi;

mmcdev=0

mmcpart=1

mmcroot=/dev/mmcblk0p2 rootwait rw

netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp

netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; ${get_cmd} ${uimage}; if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if ${get_cmd} ${fdt_addr} ${fdt_file}; then bootm ${loadaddr} - ${fdt_addr}; else if test ${boot_fdt} = try; then bootm; else echo WARN: Cannot load the DT; fi; fi; else bootm; fi;

run_linux=mmc rescan; fatload mmc 0:1 0x80010000 uImage-3.0-ts-armv7l; bootm 0x80010000

run_m4=mw.l 0x4006e028 0x3f000485; mw.l 0x4006b08c 0x00015a5a

script=boot.scr

stderr=serial

stdin=serial

stdout=serial

uimage=uImage

update_sd_firmware=if test ${ip_dyn} = yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi; if mmc dev ${mmcdev}; then if ${get_cmd} ${update_sd_firmware_filename}; then setexpr fw_sz ${filesize} / 0x200; setexpr fw_sz ${fw_sz} + 1; mmc write ${loadaddr} 0x2 ${fw_sz}; fi; fi

update_sd_firmware_filename=u-boot.imx

Environment size: 2288/8188 bytes

Labels (3)
Tags (1)
1 Solution
260 Views
NXP Employee
NXP Employee

Hi Laszlo/Jack,

the issue is in reset sequence. Reset on rev.H is longer then of rev.G of TWR-VF65. The PHY on TWR-SER goes out of reset much earlier -> timeout run out.

Main issue is that RESET on TWR-SER is not connected to RESET_B on elevator and then to TWR-VF65.

Until we find some more sophisticated solution, you can prolong reset on TWR-SER by increase capacity of C3 by solder another capacitor 33uF on top of current one (total more than 36uF)  or  change R7 similarly.

/Jiri

View solution in original post

13 Replies
260 Views
Contributor III

Hi Laszlo,

I am now using TWR-VF65GS10 too, and I can also boot out-of-box example from uboot(SD card)

I saw that you can key command to the target (TWR-VF65GS10) to see its network status

I was wondering how did you do that? using DS-5? or just SSH into the board?

Thanks,

0 Kudos
260 Views
Senior Contributor V

Dear Laszlo,

Are you aware of Timesys Linux 3.13 Alpha 1.2 Release for Vybrid Tower Available, please?

As a hardware person, I can also refer you to the latest TWR-VF65GS10 User Guide - you might find something useful there.

timesyssupport, may you comment on the software aspects, please?

Regards, Naoum Gitnik.

0 Kudos
260 Views
Contributor II

Yes, I am aware of the new release of the Timesys Linux for Vybrid. Unfortunately, nothing indicates that anything changed regarding the Ethernet implementation or uboot, so unless I am specifically told that this new release resolves the issues experienced, I do not want to waste my time on it. Is uboot part of the release?

Are you able to run the same setup (rev H of the Vybrid board) and see if you can get uboot to ping? Am I the only one who tried this configuration?

0 Kudos
260 Views
Senior Contributor V

Dear Jiri Kotzian , may you comment on this, please?

Thanks, Naoum Gitnik.

0 Kudos
260 Views
NXP Employee
NXP Employee

Hi Laszlo,

welcome.

Setting of TWR-SER  J2: 3-4 (50MHz), J12: 9-10 (RMII), J3: 2-3 (50MHz to CLOCKIN0) is necessary.

Changing of MAC is not required. Honestly I have never done it.

On SD card is OOBE demo which you are evidently using. This demo set

s IP address to 192.168.1.3. (configured in /etc/network/interfaces)

Question which may help:

Q0: Check orientation of your tower modules. Module side with white line have to be plugged into primary elevator (white connectors)

pastedImage_8.png

Q1: Do you use also TWR-LCD-RGB?

Q2: Do you use dual head connector and both USB A connectors are plugged in?

Q3: Do you use microUSB connected to J3 on Vybrid tower module for communication and also powering?

Q4: Did Linux with OOBE application booted for you (on console via OpenSDA) so you see this text?

-------------

| VYBRID OOBE |

-------------

For all feature use TWR-VF65GS1 with TWR-ELEV and TWR-SER(2)

- measure data on CM4 core and sends it to CA5 core by MCC

- the data are shown on the display

- runs web WebGL server with accelerometer data

- using static ip adress 192.168.1.3

- for dhpc modify /etc/network/interfaces in RFS

- plays videos

- control LEDs based on accelerometer data

Welcome to the Vybrid world: Rich Applications in Real Time

more on www.freescale.com/vybrid

...

...

..

/Jiri

0 Kudos
260 Views
Contributor II

Jiri,

Thank you for your response.

A0: All is plugged as required and showing on your picture above, the white lines match the white edge connectors

A1: The TWR-VF65GS10-KIT does not come with the TWR-LCD-RGB so I do not have one connected. My setup is exactly as you have it pictured in your post above.

A2: Yes

A3: Yes, the elevator boards, TWR_SER and Vybrid CPU boards 3V3 and 5V LEDs are all on. I have switched over to use the real serial port by changing J23 on the Vybrid board to 1-2, 3-4, 7-8, 9-10. So J3 on the Vybrid board is used for power only

A4: Yes, the OOBE app is booted and seems to be functioning, just fine, the 4 LEDs are turning on/off as I tilt the Tower and the console shows a bunch of "CA5: received: -1,0,63,51"

My ultimate goal is to have a development environment set up using uboot that TFTP (Ethernet) loads a kernel image that uses an NFS mounted root file system that I build from scratch.

As I described in my original post, the first issue I ran into is that with the jumper configuration you describe and using uboot Ethernet does not seem to work at all so I cannot ping from uboot, or use it to TFTP boot my kernel image. So, if you stop the automatic boot up and you use uboot, can you ping out of the Tower?

As I described in my original post, the second issue I ran into is that once I let the system boot up (i.e. I do not stop uboot), Ethernet does not seem to come up and work from within Linux either. The Linux ifconfig utility does not return anything as Ethernet is not up and running. I also attempted to manually bring up Ethernet:

# ip link set dev eth0 up

eth0: Freescale FEC PHY driver [Micrel KS8041] (mii_bus:phy_addr=1:00, irq=-1)

and then

# ifconfig

eth0      Link encap:Ethernet  HWaddr 38:F8:02:9F:04:00

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

This shows the MAC address I set in uboot but as evidenced by the zero values for all statistics there is no actual Ethernet connection established. ifconfig returns zeros every time it is invoked. Further more, the interface is not even connected at the physical level as the connection/activity LEDs on the Ethernet connector and also on my switch are off.

Additional info: I have two of these tower kits for my team of engineers to work on, but both of them exhibit the same exact behavior, so I highly doubt that I just have a defective TWR-VF65GS10-KIT.

I would like to focus on the first problem: uboot and Ethernet. Is the version of uboot that comes pre-programmed with the TWR-VF65GS10-KIT (revision H) capable of using Ethernet at all?  Can you ping from your uboot using TWR-VF65GS10-KIT (revision H)?

0 Kudos
260 Views
Senior Contributor II

Hello Laszlo,

Can you try using U-Boot 2011.12, rather than U-Boot 2013.07, if you are using the TWR-SER board? There may be an issue with TWR-SER's ethernet in U-Boot 2013.07 that does not exist in U-Boot 2011.12.

I have attached a U-Boot 2011.12 binary you can flash to your microSD card. Flashing instructions can be located at the following document (steps 1-5):

Timesys Getting Started Guide and Booting the Freescale Vybrid TWR-VF65GS10 | Timesys Embedded Linux

Thanks,

Timesys Support

0 Kudos
260 Views
Contributor II

timesyssupport,

I seem to have the same problem with uboot 2011.12, here is my uboot console output (BTW, why does the CPU line say 0 MHz?):

U-Boot 2011.12 (Oct 17 2013 - 16:23:53)

CPU:   Freescale VyBrid 600 family rev1.3 at 0 MHz

Board: Vybrid

DRAM:  128 MiB

WARNING: Caches not enabled

NAND:  256 MiB

MMC:   FSL_SDHC: 0

In:    serial

Out:   serial

Err:   serial

Net:   Link UP timeout

FEC0, FEC1

Vybrid U-Boot > printenv

baudrate=115200

bootdelay=3

eth1addr=00:e0:0c:bc:e5:61

ethact=FEC0

ethaddr=00:e0:0c:bc:e5:60

gatwayip=10.0.152.1

ipaddr=10.0.152.124

loadaddr=0x80010000

mem=129024k

netmask=255.255.252.0

serverip=10.0.152.120

stderr=serial

stdin=serial

stdout=serial

Environment size: 279/8188 bytes

Vybrid U-Boot > ping 10.0.152.120

Link UP timeout

Using FEC0 device

TX timeout

TX timeout

TX not ready

TX timeout

TX not ready

TX timeout

ARP Retry count exceeded; starting again

Link UP timeout

ping failed; host 10.0.152.120 is not alive

Vybrid U-Boot >

I also tried FEC1:

Vybrid U-Boot > mii device FEC1

Link UP timeout

Vybrid U-Boot > ping 10.0.152.120

Link UP timeout

Using FEC1 device

TX timeout

TX timeout

TX not ready

TX timeout

TX not ready

TX timeout

ARP Retry count exceeded; starting again

Link UP timeout

ping failed; host 10.0.152.120 is not alive

Vybrid U-Boot >

0 Kudos
260 Views
Senior Contributor I

"I seem to have the same problem with uboot 2011.12, here is my uboot console output (BTW, why does the CPU line say 0 MHz?):"

They fixed that in version 2013.07. This is what I see now:

CPU:   Freescale Vybrid 600 family rev1.2 at 396 MHz

0 Kudos
260 Views
NXP Employee
NXP Employee

Hi Laszlo/Jack,

It is not issue of uBoot. Uboot 2011 is obsolete - for OOBE demo is used 2013.

Issue replicated:

TWR-VF65 rev.H + TWR-SER2 Ethernet is OK

TWR-VF65 rev.H + TWR-SER is not working LEDs on connector are off - investigating...

TWR-VF65 rev.G + TWR-SER Ethernet is OK (the same OOBE demo)

/Jiri

0 Kudos
261 Views
NXP Employee
NXP Employee

Hi Laszlo/Jack,

the issue is in reset sequence. Reset on rev.H is longer then of rev.G of TWR-VF65. The PHY on TWR-SER goes out of reset much earlier -> timeout run out.

Main issue is that RESET on TWR-SER is not connected to RESET_B on elevator and then to TWR-VF65.

Until we find some more sophisticated solution, you can prolong reset on TWR-SER by increase capacity of C3 by solder another capacitor 33uF on top of current one (total more than 36uF)  or  change R7 similarly.

/Jiri

View solution in original post

260 Views
Contributor II

Jiri,

Thank you for the answer. I added 4x 10uF caps to C3 and now Ethernet works. This is a good temporary solution (it works for me :-) ). I am eager to see what your "sophisticated" solution will be.

0 Kudos
260 Views
NXP Employee
NXP Employee

Hi Laszlo,

more sophisticated solutions are:

  1. software reset using MDIO,
    for example on www.fnet.sf.net function fnet_fec_mii_write(ethif, FNET_FEC_MII_REG_CR, FNET_ETH_MII_REG_CR_RESET);
  2. reset of TWR-SER is connected to PTE3 of TWR-VF65. So you can reset it from user SW manually.
  3. last possible option is to remove U25 (350ms) and use previous reset circuit on TWR-VF65 4k7 + 100n (reason of usage U25 was incompatible SD cards - they need more time between power up and start of communication)

/Jiri