cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
434 Views
Registered: ‎01-09-2019

displayPort 1.2 Rx subsystem : TP1 failed

Jump to solution

Hello,

We bought displayPort 1.2 Rx/Tx subsystem but we have still an issue with Rx part.

On ZCU102 board, our design (based on your displayPort 1.2 Rx subsystem reference design ) works fine with Xilinx's example software .

 Now, we are trying to port same design on our real time operating system (workspace is identical than BM, same DP source, cable, boards, ...).

Although the bare metal version works fine, we don't achieve TP2 stub callback with the RTOS version.

We catch TP1 callback interrupt and lock the DP159 PLL but the result seems not good, and the system try another configuration (rate and lane count)  without no more success.

Could you please help us to verify some parts of our design to find where the problem is located ?

Thank you in advance for your help.

Hervé

0 Kudos
Reply
1 Solution

Accepted Solutions
238 Views
Registered: ‎01-09-2019

Hello Florent

The problem was located in usleep() function which is called in different places in the XILINX DP drivers.

The implementation of the usleep function in our RTOS is based on the system tick which is 1 ms.

After code modification using an accurate suspend function, the DP Rx subsystem  seems to work correctly with our operating system.

Thank you for your help

 

Hello Watari,

Both applications (BM and RTOS) are using A53 cores.

Main differences are virtual memory, and interrupt handling.

 

BRGD

Hervé

View solution in original post

5 Replies
florentw
Moderator
Moderator
372 Views
Registered: ‎11-09-2015

Hi herve.langlais@technicatome.com 

I have seen a case for which TP1 was failing with some DP159. At the time TI was not able to give a reason why it was happening.

The fix at the time was to have a counter to make sure the PLL from the DP159 was stable:

https://github.com/Xilinx/embeddedsw/blob/f975a0ea90930587ab55e4d920a31950bd373fa8/XilinxProcessorIPLib/drivers/dp12rxss/src/xdprxss_dp159.c#L339

I worked in all the cases on Xilinx boards with the example design but the counter had to be tuned on a customer board.

So you can try to modify this value, XDPRXSS_DP159_LOCK_WAIT. Try lower and higher values. It might not be the issue but might be a good thing to try first.

I assume you do not have any AUX analyzer? Could you maybe see if it is possible for you to rent one somehow if the above tweak is not working? It might really help to identify what is really happening during the training.

Also, did you try sources from different vendors to see if some are working?


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
340 Views
Registered: ‎01-09-2019

Thank you Florent for your answer.

 

We use hardware configuration of Xilinx's reference design (ZCU102 + Inrevium's FMC DP) and not a custom board.

ZCU102 and DP boards are the same between test in bare metal and test with our RTOS. DP source is also the same.

The only hardware difference is the boot from JTAG (BM) or from SD (RTOS).

 

In RTOS configuration, DP159 PLL is well locked after the first preferred  configuration (4 Lanes and 5.4 Gbps).

But it seems that the TP1 are not correct, because the TP1 callback is called with other parameters (symbols errors).

In BM configuration, only the first configuration is tested and the test patterns are OK.

 

In our mind the difference is located in the software, but we are looking for a clue to find these  differences.

The main difference between both codes (RTOS and BM) are:

- RTOS is using virtual memory and interrupt is first handled by the RTOS before calling the BSP interrupt handler.

   Of course in the RTOS version, we don’t initialize interrupt controller as the BARE METAL code do.

- Timer function is done by RTOS for delay insertion.

 

BRGD

Hervé

0 Kudos
Reply
florentw
Moderator
Moderator
332 Views
Registered: ‎11-09-2015

Hi herve.langlais@technicatome.com 

The issue I mentioned was only seen on customer board. However, this was linked some DP159 chips. So it might be happening depending on the configuration.

Xilinx is only testing with the baremetal example/drivers so changing to RTOS might have in impact.

I do not believe that the booting method will have an impact but you could always try to boot the baremetal application from SD Card.

About the PLL lock, keep in mind that the DP159 will generate a different clock for each line rate configuration. So there will be multiple locks.

One other thing you could try is changing the value of the AUX DEFER in reg 0x004. I would say try reducing it (based on your description for the RTOS that the interrupt is first handled by RTOS) but try to increase it as well (here an AUX log could potentially help to see if that has an impact)


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Reply
watari
Teacher
Teacher
275 Views
Registered: ‎06-16-2013

Hi herve.langlais@technicatome.com 

 

It's an interesting issue for me.

So, I just ask the following question to investigate route cause.

 

Q1) Who handle this DP Rx driver ? Cortex-A53 (What is CPU number ? 0 or 1 or 2 or 3) ? Cortex-R5 (What is CPU number ? 0 or 1) ? additional MB ?

Q2) What are different points between RTOS and BM ?

 

I suspect performance of CPU during link training phase.

But I couldn't get confirmation form this topic...

 

Best regards,

239 Views
Registered: ‎01-09-2019

Hello Florent

The problem was located in usleep() function which is called in different places in the XILINX DP drivers.

The implementation of the usleep function in our RTOS is based on the system tick which is 1 ms.

After code modification using an accurate suspend function, the DP Rx subsystem  seems to work correctly with our operating system.

Thank you for your help

 

Hello Watari,

Both applications (BM and RTOS) are using A53 cores.

Main differences are virtual memory, and interrupt handling.

 

BRGD

Hervé

View solution in original post