Linux/DRA726: Display issues

Michel Catudal

Part Number: DRA726

Tool/software: Linux

Our board uses a DRA726 with 1GB or RAM. I use the splash screen from Venkat

My yocto is based on the automotive SDK 3.02 with EGL updates misc TI fixes, and custom addons for our hardware.

I have enabled QT in yocto so I can use the QT libraries since one customer requires it. So far we have just been using Embedded Wizard.

I have a couple of issues I am trying to figure out.

The programmer doing the QT code told be that he had issues with some missing files so I tested with my board which has a similar installation.

My board uses a 12 inch LCD display while his uses a 7 inch display.

If I have weston running and run a TI example that uses the quickcontrols I have similar errors as he got with his.

He is using the QT creator for his work and the SDK I generated with yocto.

./quickcontrols/controls/texteditor/texteditor.pro
ditor/texteditor6-12inch:/usr/share/qt5/examples# ./quickcontrols/controls/texte
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:42 module "QtQuick.Controls" is not installed
qrc:/qml/main.qml:44 module "QtQuick.Dialogs" is not installed
qrc:/qml/main.qml:42 module "QtQuick.Controls" is not installed
qrc:/qml/main.qml:44 module "QtQuick.Dialogs" is not installed

Ultimately we need to run off the framebuffer without weston since weston takes too long to load. Can you help with that?

When I do "systemctl mask weston" and reboot I ran these to be able to login on the console

/usr/bin/omapconf write 0x58001370 0x0
/usr/bin/modetest

How do you do the same thing without using modetest?

I get this error message a few times

root@actia-dra726-12inch:~# cd [ 602.225910] irq 358: nobody cared (try booting with the "irqpoll)
[ 602.232734] CPU: 0 PID: 504 Comm: kworker/u2:3 Tainted: G           O    4.4.45-actia-RevD-g8991
[ 602.242338] Hardware name: Generic DRA72X (Flattened Device Tree)
[ 602.248459] Backtrace:
[ 602.250929] [<c0013a80>] (dump_backtrace) from [<c0013c7c>] (show_stack+0x18/0x1c)
[ 602.258526] r7:00000166 r6:200f0193 r5:00000000 r4:c08f07cc
[ 602.264236] [<c0013c64>] (show_stack) from [<c02b75ec>] (dump_stack+0x8c/0xa0)
[ 602.271491] [<c02b7560>] (dump_stack) from [<c008389c>] (__report_bad_irq+0x30/0xd4)
[ 602.279261] r7:00000166 r6:00000000 r5:00000000 r4:ef207840
[ 602.284970] [<c008386c>] (__report_bad_irq) from [<c0083cd0>] (note_interrupt+0x2ac/0x2fc)
[ 602.293264] r9:ef207840 r8:00000166 r7:00000166 r6:00000000 r5:00000000 r4:ef207840
[ 602.301072] [<c0083a24>] (note_interrupt) from [<c0081118>] (handle_irq_event_percpu+0x104/0x16)
[ 602.309977] r10:c0911daa r9:ef207840 r8:00000166 r7:00000000 r6:00000000 r5:00000000
[ 602.317865] r4:00000000 r3:00000000
[ 602.321467] [<c0081014>] (handle_irq_event_percpu) from [<c00811b4>] (handle_irq_event+0x40/0x6)
[ 602.330372] r10:00000000 r9:00000039 r8:ef006000 r7:00000000 r6:c08f0a24 r5:ef2078a0
[ 602.338260] r4:ef207840
[ 602.340809] [<c0081174>] (handle_irq_event) from [<c00844e0>] (handle_fasteoi_irq+0xc0/0x194)
[ 602.349364] r7:00000000 r6:c08f0a24 r5:ef2078a0 r4:ef207840
[ 602.355070] [<c0084420>] (handle_fasteoi_irq) from [<c00806f4>] (generic_handle_irq+0x2c/0x3c)
[ 602.363712] r7:00000000 r6:ede9fe10 r5:00000166 r4:c08c0404
[ 602.369418] [<c00806c8>] (generic_handle_irq) from [<c00809cc>] (__handle_domain_irq+0x64/0xbc)
[ 602.378153] [<c0080968>] (__handle_domain_irq) from [<c00094f0>] (gic_handle_irq+0x40/0x7c)
[ 602.386533] r9:00000039 r8:fa213000 r7:fa212000 r6:ede9fcf8 r5:fa21200c r4:c08c68d4
[ 602.394338] [<c00094b0>] (gic_handle_irq) from [<c0014854>] (__irq_svc+0x54/0x90)
[ 602.401849] Exception stack(0xede9fcf8 to 0xede9fd40)
[ 602.406918] fce0:                                                       00000000 c0915180
[ 602.415127] fd00: 00000000 00000000 00000002 00000012 ede9e000 00000000 ef006000 00000039
[ 602.423337] fd20: 00000000 ede9fda4 ede9fda8 ede9fd48 c0038a90 c00385fc 600f0113 ffffffff
[ 602.431544] r9:00000039 r8:ef006000 r7:ede9fd2c r6:ffffffff r5:600f0113 r4:c00385fc
[ 602.439351] [<c0038568>] (__do_softirq) from [<c0038a90>] (irq_exit+0xbc/0x11c)
[ 602.446686] r10:00000000 r9:00000039 r8:ef006000 r7:00000000 r6:00000000 r5:00000012
[ 602.454575] r4:ffffe000
[ 602.457123] [<c00389d4>] (irq_exit) from [<c00809d0>] (__handle_domain_irq+0x68/0xbc)
[ 602.464981] r5:00000012 r4:c08c0404
[ 602.468582] [<c0080968>] (__handle_domain_irq) from [<c00094f0>] (gic_handle_irq+0x40/0x7c)
[ 602.476963] r9:00000039 r8:fa213000 r7:fa212000 r6:ede9fe10 r5:fa21200c r4:c08c68d4
[ 602.484767] [<c00094b0>] (gic_handle_irq) from [<c0014854>] (__irq_svc+0x54/0x90)
[ 602.492276] Exception stack(0xede9fe10 to 0xede9fe58)
[ 602.497345] fe00:                                     ef673dc0 00000002 00000000 0000cd9f
[ 602.505554] fe20: ef673dc0 ee159e00 ee0e0600 ee190c00 c06284f8 00000039 00000000 ede9fe6c
[ 602.513764] fe40: ede9fe70 ede9fe60 c0055454 c062c5f0 600f0013 ffffffff
[ 602.520400] r9:00000039 r8:c06284f8 r7:ede9fe44 r6:ffffffff r5:600f0013 r4:c062c5f0
[ 602.528208] [<c062c5c8>] (_raw_spin_unlock_irq) from [<c0055454>] (finish_task_switch+0x78/0x1f)
[ 602.537119] [<c00553dc>] (finish_task_switch) from [<c06284f8>] (__schedule+0x2e4/0x668)
[ 602.545239] r10:00000000 r9:00000039 r8:ee159e00 r7:00000000 r6:ee0e0600 r5:ee190c00
[ 602.553126] r4:ef673dc0
[ 602.555673] [<c0628214>] (__schedule) from [<c06288d0>] (schedule+0x54/0xc4)
[ 602.562746] r10:ef0a0000 r9:ede2c100 r8:00000088 r7:ede9e000 r6:ef0a0014 r5:ef0a0000
[ 602.570632] r4:ede9e000
[ 602.573181] [<c062887c>] (schedule) from [<c004abec>] (worker_thread+0xd8/0x524)
[ 602.580603] r5:ef0a0000 r4:ef0a0000
[ 602.584202] [<c004ab14>] (worker_thread) from [<c00506ac>] (kthread+0xe4/0xfc)
[ 602.591450] r10:00000000 r9:00000000 r8:00000000 r7:c004ab14 r6:ede2c100 r5:ede57d40
[ 602.599335] r4:00000000
[ 602.601883] [<c00505c8>] (kthread) from [<c000fc98>] (ret_from_fork+0x14/0x3c)
[ 602.609130] r7:00000000 r6:00000000 r5:c00505c8 r4:ede57d40
[ 602.614831] handlers:
[ 602.617112] [<c039287c>] dispc_irq_handler
[ 602.621226] Disabling IRQ #358

IQR #358 is the video

root@actia-dra726-12inch:~# cat /proc/interrupts | grep 358
358: 200001 CBAR 20 Level OMAP DISPC

root@actia-dra726-12inch:~# cat /proc/interrupts
           CPU0
16:          0      CBAR 32 Level     gp_timer
17:          0       GIC 29 Edge      arch_timer
18:     342187       GIC 30 Edge      arch_timer
22:          0      CBAR   4 Level     l3-dbg-irq
23:          0     WUGEN 10 Level     l3-app-irq
25:          1      CBAR 121 Level     talert
27:       1519      CBAR   8 Level     omap-dma-engine
30:        684      CBAR 361 Level     43300000.edma_ccint
32:          0      CBAR 359 Level     43300000.edma_ccerrint
35:          0      CBAR 24 Level     4ae10000.gpio
68:          0      CBAR 25 Level     48055000.gpio
101:          0      CBAR 26 Level     48057000.gpio
134: 184057225      CBAR 27 Level     48059000.gpio
139: 184057225 48059000.gpio   4 Level     egalax_i2c
167:          0      CBAR 28 Level     4805b000.gpio
200:          0      CBAR 29 Level     4805d000.gpio
233:          0      CBAR 30 Level     48051000.gpio
239:          0 48051000.gpio   5 Level     lis2dh_accel
266:          0      CBAR 116 Level     48053000.gpio
301:       1330      CBAR 69 Level     48020000.serial
310:         35      CBAR 255 Level     mbox_ipu2_ipc3x
328:          6      CBAR 108 Level     omap_dmm_irq_handler
329:          2      CBAR 16 Level     SGX ISR
331:        322      CBAR 51 Level     48070000.i2c
332:          0      CBAR 56 Level     48060000.i2c
333:          0      CBAR 57 Level     4807a000.i2c
334:         25      CBAR 55 Level     4807c000.i2c
335:       4077      CBAR 78 Level     mmc0
336:       1180      CBAR 81 Level     mmc1
337:        156      CBAR 89 Level     mmc2
338:          0      CBAR 395 Level     58882000.mmu
339:          0      CBAR 396 Level     55082000.mmu
343:          5      CBAR 72 Level     dwc3-omap
344:          5      CBAR 87 Level     dwc3-omap
345:          0      CBAR 149 Level     48464000.mcasp_tx
346:          0      CBAR 148 Level     48464000.mcasp_rx
348:      98334      CBAR 335 Level     48484000.ethernet
349:       1118      CBAR 336 Level     48484000.ethernet
351:          0      CBAR 354 Level     vpe
355:         20      CBAR 46 Level     4b101000.sham
356:          0      CBAR 47 Level     48090000.rng
358:     200001      CBAR 20 Level     OMAP DISPC
423:          0      CBAR   2 Edge      tps65917
425:          0   pinctrl 584 Edge      48020000.serial
426:         27      CBAR 71 Level     xhci-hcd:usb1
427:          0      CBAR 73 Level     xhci-hcd:usb3
IPI0:          0 CPU wakeup interrupts
IPI1:          0 Timer broadcast interrupts
IPI2:          0 Rescheduling interrupts
IPI3:          0 Function call interrupts
IPI4:          0 Single function call interrupts
IPI5:          0 CPU stop interrupts
IPI6:          0 IRQ work interrupts
IPI7:          0 completion interrupts
Err:          0

Michel Catudal

ACTIA Corp

over 8 years ago

0 Karthik Ramanan over 8 years ago

TI__Guru** 113810 points

Hi Michael,

Just a note, it is better to raise two tickets for these two varied issues since it is likely that the two topics will be worked by different engineers on our side.

Anyway, I will try to address the weston takes too long part here.

> Ultimately we need to run off the framebuffer without weston since weston takes too long to load. Can you help with that?
Could you please share more details about this problem and the concern that you have with running the weston as it is?
There is an application note that could help in this regard to get a faster load time (in general) and also help with weston initialization. Have you referred to the techniques in this document : www.ti.com/.../sprac82.pdf

Regards
Karthik

0 Michel Catudal over 8 years ago in reply to Karthik Ramanan

Genius 3825 points

Karthik,

I resolved the issue with weston for the QT applications.

I use soemething like this :

/usr/bin/___app_name___ -platform eglfs

As for project with Embedded Wizard they require the compositor so I have to load from weston. I am trying to convince them to switch to eglfs.

I have looked into the document that you pointed out and am planning to follow this for the boot up but that will not change anything related to weston. Once weston desktop loads it can take 5-10 seconds before the application is loaded. The work around right now is to keep the splash screen on until the app has control.

It takes about 30 seconds to get to the application to be up and running.

It takes around 14-15 seconds to get to weston. The rest is weston loading the app and Navionics taking it's time.

Not much can be done with the maps from Navionics until they fix that issue.

I should be able to reduce the first part following the advices in the document. Using eglfs will remove the weston issue for QT apps.

I think that the main issue with weston is that it is loading bunch of junk that is not used like the on screen keyboard that will never be used.

I cannot provide you the startup from Navionics being proprietary and not under our control. We do have an NDA with TI but not for code from some other companies.

From what I see they only use the compositor to get the EGL access thru wayland. It looks like they just write to the framebuffer and even take advantage of the power of the dra for drawing pictures. Their maps are slow.

How early could we get video on the screen? If I want to use the board for a cluster I need to have gauges on the display very quickly, not after 10 seconds. QT would be used in that case.

Michel Catudal

ACTIA Corp.

0 Michel Catudal over 8 years ago in reply to Michel Catudal

Genius 3825 points

Correction on this this text :
"and even take advantage of the power of the dra for drawing pictures"
don't is missing

Michel

0 Karthik Ramanan over 8 years ago in reply to Michel Catudal

TI__Guru** 113810 points

Hi MIchel,

I'm still trying to build my understanding of the problem.
You mentioned two points, could you please elaborate on these?

> I think that the main issue with weston is that it is loading bunch of junk that is not used like the on screen keyboard that will never be used.
In the past, I have profiled weston load time - that is the time measured from start of weston on command line to the point that we can launch any application and show it on the screen - this is less than 100 msec, more like 75msec but give or take a few considering system differences.

> Once weston desktop loads it can take 5-10 seconds before the application is loaded.
It sounds like this is an application issue and not really weston.

Looking at both of these it seems like the application that you are trying to launch is taking time, is my understanding correct? Please add details .

Regards
Karthik

0 Michel Catudal over 8 years ago in reply to Karthik Ramanan

Genius 3825 points

Karthik,

Our customer doesn't like that it takes too long to load the app.

First item is a problem with weston, second item is a problem with Embedded Wizard and Navionics software.

First item, Weston takes 5-6 seconds before it loads the application which is unacceptable.
I am looking at switching to eglfs to resolve that problem. As I look in the doc on multimedia it seems to imply that for most video I need weston, is that correct or not?

For the second item, those software providers draw the pictures instead of using the misc video libraries available. That is not a TI issue, I just mentioned for info. If I can reduce the first part that will be a good start, the rest will be to convince those guys to spend the time doing their proprietary software correctly.

Michel

0 Karthik Ramanan over 8 years ago in reply to Michel Catudal

TI__Guru** 113810 points

Hi Michel,

We can focus on the Weston takes too long part of the problem as a first step, and I agree with you that here is an area that we can help.

Like I mentioned earlier, our profile time for weston launch is about 100 msec. Could you please give us some details on how you measure the weston load time? 5-6 seconds is definitely very long.

In TI's profiling method, we just measure the time that it takes to launch weston to be able to launch an application (say weston-simple-egl). To be a little conservative about the timing in this post, lets say 200 msec.

weston <parameters> &
usleep 200000
weston-simple-egl

I have verified that this works on the TI EVM, please try this and let us compare the difference in terms of where the additional time is coming from.

Regards
Karthik

0 Karthik Ramanan over 8 years ago in reply to Karthik Ramanan

TI__Guru** 113810 points

Hi Michel,

Please do let me know if you have any further updates on this topic.

Regards
Karthik

0 Michel Catudal over 8 years ago in reply to Karthik Ramanan

Genius 3825 points

Karthik,

I put that aside for now as I have two more urgent tasks to work on. Our sound module seems to work but I get no output and the ST accelerometer seems to have issues. I will post on the accelerometer in another message, perhaps someone can help.

Michel

0 Karthik Ramanan over 7 years ago in reply to Michel Catudal

TI__Guru** 113810 points

Hi Michel,

I'm marking the previous post as the Suggested Answer, please reply back whenever you get back to this issue.

Regards
Karthik

Processors

Processors forum

Linux/DRA726: Display issues