OOBE demo on TWR-VF65GS10-KIT has issues using Timesys LinuxLink build

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

OOBE demo on TWR-VF65GS10-KIT has issues using Timesys LinuxLink build

Jump to solution
2,290 Views
loberlander
Contributor II

Dear Timesys Support,

 

I am using the TWR-VF65GS10-KIT (Rev H) setup and have issues with the OOBE demo. The OOBE demo that is preprogrammed on the SD card seems to be operating as expected, but my "OOBE Demo" Timesys Workorder "template" based recent built image is not running the OOBE test application properly

I get the following on the console:

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

| 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

 

dev: /dev/fb0, alpha=255

dev: /dev/fb1, alpha=0

dev: /dev/fb2, alpha=255

CA5: Start of constructor

Pipeline string is: filesrc location=/home/media/big_buck_bunny_480x272_mpeg4.mov ! queue ! qtdemux ! ffdec_mpeg4 ! videorate drop-only=true ! autoconvert ! fbdevsink device=/dev/fb2

dev: /dev/fb0, alpha=255

CA5: Endpoint is 0,1,1

CA5: End of constructor

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 4

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 6

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 6

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 6

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 6

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 6

CA5: Tx request to 1,0,1 from 0,1,1

CA5:Error: mcc_send error: 6

 

The mcc driver is running as lsmod reports it, but there might not be anybody listening on the other side. Is there a way to figure that out?

 

In addition to the above, it seems that the accelerometer controlled LEDs also have issues. They do not change as I tilt the board.

 

Would you please try the OOBE build (using your template) directly from LinuxLink?

 

I have attached the following 3 files with the console outputs:

- Console_using_NFS.txt : The LinuxLink built image started up through NFS

- Console_using_SD.txt : The LinuxLink built image started up through programming up the SD card

- Console_using_SD_factory.txt : The SD card with the pre-programmed image as it came in the TWR-VF65GS10-KIT (Rev H) kit

Original Attachment has been moved to: Console_using_NFS.txt.zip

Original Attachment has been moved to: Console_using_SD.txt.zip

Original Attachment has been moved to: Console_using_SD_Factory.txt.zip

Labels (3)
0 Kudos
1 Solution
1,644 Views
timesyssupport
Senior Contributor II

Hello Laszlo,

Can you confirm that you have also built and are booting the MQX component to the OOBE demo:

https://linuxlink.timesys.com/docs/wiki/engineering/userguide_vybrid_mcc#Building

https://linuxlink.timesys.com/docs/wiki/engineering/userguide_vybrid_mcc#Out-of-Box-Demo

If the MQX portion has not booted first before Linux, then you will see the error messages outlined in your original post.

Thanks,

Timesys Support

View solution in original post

0 Kudos
10 Replies
1,645 Views
timesyssupport
Senior Contributor II

Hello Laszlo,

Can you confirm that you have also built and are booting the MQX component to the OOBE demo:

https://linuxlink.timesys.com/docs/wiki/engineering/userguide_vybrid_mcc#Building

https://linuxlink.timesys.com/docs/wiki/engineering/userguide_vybrid_mcc#Out-of-Box-Demo

If the MQX portion has not booted first before Linux, then you will see the error messages outlined in your original post.

Thanks,

Timesys Support

0 Kudos
1,644 Views
loberlander
Contributor II

timesyssupport,

No, I have not done any of the MCC steps, I was assuming that you already had an MQX image built and all MCC steps taken care of in your build configuration. It seems that is not the case... Let me go through those steps and see if that resolves the issue.

Thanks,

Laszlo

0 Kudos
1,644 Views
loberlander
Contributor II

timesyssupport,

I have built my oobe_twrvf65gs10_m4.bin as detailed on the pages listed above. The next step is to actually run it...

I am booting my Linux development environment (that contains the OOBE demo as  well as the M4 firmware) using the NFS mounted root file system.

Once the Linux system is up and I try to run the M4 firmware, the following command seems to crash the system:

mqxboot oobe_twrvf65gs10_m4.bin 0x3f000000 0x3f000485

Is there a way to start the oobe_twrvf65gs10_m4.bin firmware after Linux has already started and I have easy access to the files in my rootfs?

Thanks,

Laszlo

0 Kudos
1,644 Views
timesyssupport
Senior Contributor II

Hello Laszlo,

The OOBE demo is intended to have the MQX binary started before Linux loads. So instead of using mqxboot from Linux userspace, you will need to copy the MQX binary directly into SRAM from U-Boot, and start MQX in U-Boot before Linux loads. The following document outlines this procedure:

https://linuxlink.timesys.com/docs/wiki/engineering/userguide_vybrid_mcc#Out-of-Box-Demo

Thanks,

Timesys Support

1,644 Views
loberlander
Contributor II

timesyssupport

Loading and starting MQX from uboot before starting Linux works as described. I was just trying to see if there was a way to start the OOBE MQX firmware directly from my NFS based rootfs. If it was not designed to do that and there is not an easy way that is fine.

Thank you for all your help, I think I am satisfied with all the answers and we can consider this issue resolved.

Laszlo

0 Kudos
1,644 Views
timesyssupport
Senior Contributor II

Hi Laszlo,

Understood. You are correct - the OOBE demo at its current state was not designed to have the boot order reversed, and needs to be in the order MQX --> Linux. Let me know if you have any other questions.

Thanks,

Timesys Support

1,644 Views
jackblather
Senior Contributor I

Make sure the jump address (*0x3f00_0485") is correct. Perhaps you're jumping to the wrong address?

Another way to determine what is causing the system crash is to use the DS-5 debugger and single step through the oobedemo code and see where it dies.

0 Kudos
1,644 Views
timesyssupport
Senior Contributor II

Hello Laszlo,

We have run a build and will be boot testing here on our Tower kit to determine what the issue may be. Please allow us time to boot test and review.

Regards,

Timesys Support

0 Kudos
1,644 Views
karina_valencia
NXP Apps Support
NXP Apps Support

timesyssupport do you have an update?

0 Kudos
1,644 Views
naoumgitnik
Senior Contributor V

Dear timesyssupport,

May you provide consultation on your software, please?

Thanks, Naoum Gitnik.

0 Kudos