VF65GS10 Tower Kit Hangs on Boot Occasionally

[brianbutcher]

Hello,

I have recently downloaded the latest factory along with the 3.13A linux-mx kernel for the VF65GS10 and have experienced what seems to be a hang at boot. The board does boot properly at times and then other times I need to power cycle anywhere from 1 to 10 times before boot proceeds nominally.

I was curious if anyone has experienced this? We were running the 3.0 kernel previously and we did not experience the hang. I suspect it is not a console issue since the linux logo does not display on the screen. I do see the logo during a successful boot. Thanks for your help.

Additional Info:

I just built the RFS and Kernel using the 3.0 kernel and I have not experienced any boot issues.

Console Output:

U-Boot 2013.07 (Dec 07 2015 - 10:52:32)

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

Reset cause: POR

Board: TWR-VF65GS10

DRAM:  128 MiB

WARNING: Caches not enabled

NAND:  256 MiB

MMC:   FSL_SDHC: 0

In:    serial

Out:   serial

Err:   serial

Net:   FEC

Hit any key to stop autoboot:  0

Using FEC device

TFTP from server 192.168.1.1; our IP address is 192.168.1.2

Filename 'uImage'.

Load address: 0x81000000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         ###############

         459 KiB/s

done

Bytes transferred = 3069144 (2ed4d8 hex)

Using FEC device

TFTP from server 192.168.1.1; our IP address is 192.168.1.2

Filename 'twr_vf600.dtb'.

Load address: 0x82000000

Loading: ####

         408.2 KiB/s

done

Bytes transferred = 19242 (4b2a hex)

## Booting kernel from Legacy Image at 81000000 ...

   Image Name:   Linux-3.13.9

   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    3069080 Bytes = 2.9 MiB

   Load Address: 80008000

   Entry Point:  80008000

   Verifying Checksum ... OK

## Flattened Device Tree blob at 82000000

   Booting using the fdt blob at 0x82000000

   Loading Kernel Image ... OK

   Loading Device Tree to 87f38000, end 87f3fb29 ... OK

Starting kernel ...

Ucompressing Linux... done, booting the kernel.

Message was edited by: Brian Butcher

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[timesyssupport]

Hello,

Is this custom hardware, or the TWR-Vybrid evaluation board?

If the hardware is custom, what are the primary changes from the evaluation kit?

Can you provide the bootargs passed to the kernel, and not anything else which may be running at boot time, on the M4 perhaps?

We are not aware of similar behavior with the 3.13, so if there are differences in hardware or modifications made to the code it would be helpful to have an idea.

Thank you,

Timesys Support

[brianbutcher]

Hello,

This is not a custom board. My tower setup consists of the TWR-VF65GS10, TWR-SER2, LCD, Analog Module, and Industrial I/O.

I do not have anything running on the M4. I pulled the factory straight from the git repository and tried the internal 3.13 kernel along with the linux-mx 13.3a kernel and experienced the same hangs on boot. It is fairly frequent. I would say about 50% of my boot hang.

I have tried many configs and I have now moved on to using the 3.0.15 kernel, but I am pretty sure this was the bootargs setting at the time. I can go back to the 3.13 if needed. I did also try micro-sd instead of tftp and that also experienced the hang on boot.

bootargs=mem=128M console=ttyLP1,115200 ip=192.168.1.2:::::eth0:off root=/dev/nfs rw nfsroot=192.168.1.1:/tftpboot/rfs

bootcmd=tftp;tftp 82000000 twr_vf600.dtb;bootm 81000000 - 82000000

Thanks for all of your help.

-Brian

[timesyssupport]

Hi Brian,

I have typically used the following bootargs for network boot with Vybrid Tower running U-Boot 2013.07 and Linux 3.13 without seeing any boot issues:

console=ttyLP1,115200 ip=dhcp root=/dev/nfs rw

The main difference here is that I do not include a mem= bootarg. Try removing this and see if the boot process occurs reliably. If you are still having issues, can you attach the U-Boot image, kernel image, and dtb you are using to boot? I don't have these images immediately available on my end for you to try (that should not cause any boot issues), I can send these beginning of next week if you would like.

Thanks,

Timesys Support

[brianbutcher]

Thank you for your follow up. I have reverted to the 3.0 kernel for the moment while we meet some milestones. I will look into putting back the 3.13 kernel and try it without mem early next week. If I continue to have the same problem I will attach the files. Thanks again.

[karina_valencia]

timesyssupport​ please continue with the follow up.

[davidw_]

Hello,

I am experiencing what seems to be the same issue on our custom hardware based on the Vybrid Tower with recent versions of 3.13 ts-factory kernel. There was no issue with the 3.0 kernel neither. UBoot starts properly, loads kernel image and device tree from NAND, verifies the checksum... "Ucompressing Linux... done, booting the kernel.", the screen flashes all white (it should display custom logo instead) and then it goes dark and there is no output whatsoever until the power is cycled. It happens just sometimes, as you wrote, for no obvious reason. Rarely the display stays white (no logo shown) and the system boots anyway.. that might be a hint?

However this issue is very difficult to debug so we were thinking about using a hardware watchdog as a workaround. Any insight on finding a proper solution would be appreciated.

D.W.

[karina_valencia]

timesyssupport​ can you help to review this case?