• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1050 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SK-AM62: AM62x kmscube, gpu initialization

Ismail Ucar
Prodigy 40 points

Part Number: SK-AM62

Hello,

I am working on am62x dev. board. I tried kmscube on default image I got an error about the ZINK file. After I created a new image when I tried kmscube it worked after a restart it didn't work it said:

"root@am62xx-evm:~# kmscube
no connected connector!
failed to initialize legacy DRM"

kmscube worked after rebooting several times. It was not stable. I checked the system logs. I have some doubts about the startup sequence. below you can see some sample logs:

Working example:

dmesg
[    5.662034] PVR_K:  210: Device: fd00000.gpu
[    5.691954] PVR_K:  210: Read BVNC 33.15.11.3 from HW device registers
[    5.704827] PVR_K:  210: RGX Device registered with BVNC 33.15.11.3
[    5.719007] [drm] Initialized pvr 23.3.6512818 20170530 for fd00000.gpu on minor 1
[    5.719074] panel-simple display: supply power not found, using dummy regulator
[    5.746083] [drm] Initialized tidss 1.0.0 20180215 for 30200000.dss on minor 0
[    5.826129] Console: switching to colour frame buffer device 160x50
[    5.860053] tidss 30200000.dss: [drm] fb0: tidssdrmfb frame buffer device

-----------------------
journalctl
Jan 01 00:00:11 am62xx-evm kernel: PVR_K:  210: Device: fd00000.gpu
Jan 01 00:00:11 am62xx-evm kernel: PVR_K:  210: Read BVNC 33.15.11.3 from HW device registers
Jan 01 00:00:11 am62xx-evm root[254]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm kernel: PVR_K:  210: RGX Device registered with BVNC 33.15.11.3
Jan 01 00:00:11 am62xx-evm kernel: [drm] Initialized pvr 23.3.6512818 20170530 for fd00000.gpu on minor 1
Jan 01 00:00:11 am62xx-evm kernel: panel-simple display: supply power not found, using dummy regulator
Jan 01 00:00:11 am62xx-evm root[273]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm kernel: [drm] Initialized tidss 1.0.0 20180215 for 30200000.dss on minor 0
Jan 01 00:00:11 am62xx-evm root[281]: udev/mount.sh [/dev/mtdblock1] is marked to ignore
Jan 01 00:00:11 am62xx-evm root[292]: udev/mount.sh [/dev/mtdblock2] is marked to ignore
Jan 01 00:00:12 am62xx-evm root[298]: Using systemd-mount to finish mount
Jan 01 00:00:12 am62xx-evm kernel: Console: switching to colour frame buffer device 160x50
Jan 01 00:00:12 am62xx-evm root[293]: Using systemd-mount to finish mount
Jan 01 00:00:12 am62xx-evm root[303]: Using systemd-mount to finish mount
Jan 01 00:00:12 am62xx-evm root[304]: udev/mount.sh [/dev/mtdblock0] is marked to ignore
Jan 01 00:00:12 am62xx-evm kernel: tidss 30200000.dss: [drm] fb0: tidssdrmfb frame buffer device
Jan 01 00:00:12 am62xx-evm root[308]: Using systemd-mount to finish mount
,

Non-working example:

dmesg 
[    5.399467] panel-simple display: supply power not found, using dummy regulator
[    5.404500] remoteproc remoteproc1: 78000000.r5f is available
[    5.421190] remoteproc remoteproc1: attaching to 78000000.r5f
[    5.424481] [drm] Initialized tidss 1.0.0 20180215 for 30200000.dss on minor 0
[    5.428876] platform 78000000.r5f: R5F core initialized in IPC-only mode
[    5.446411] rproc-virtio rproc-virtio.2.auto: assigned reserved memory node r5f-dma-memory@9da00000
[    5.447347] virtio_rpmsg_bus virtio1: rpmsg host is online
[    5.447402] rproc-virtio rproc-virtio.2.auto: registered virtio1 (type 7)
[    5.447412] remoteproc remoteproc1: remote processor 78000000.r5f is now attached
[    5.448421] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
[    5.448721] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
[    5.505854] Console: switching to colour frame buffer device 160x50
[    5.520629] PVR_K:  208: Device: fd00000.gpu
[    5.520923] PVR_K:  208: Read BVNC 33.15.11.3 from HW device registers
[    5.533859] tidss 30200000.dss: [drm] fb0: tidssdrmfb frame buffer device
[    5.563751] PVR_K:  208: RGX Device registered with BVNC 33.15.11.3
[    5.610636] [drm] Initialized pvr 23.3.6512818 20170530 for fd00000.gpu on minor 1

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

Journalctl

Jan 01 00:00:11 am62xx-evm kernel: panel-simple display: supply power not found, using dummy regulator
Jan 01 00:00:11 am62xx-evm kernel: remoteproc remoteproc1: 78000000.r5f is available
Jan 01 00:00:11 am62xx-evm kernel: remoteproc remoteproc1: attaching to 78000000.r5f
Jan 01 00:00:11 am62xx-evm kernel: [drm] Initialized tidss 1.0.0 20180215 for 30200000.dss on minor 0
Jan 01 00:00:11 am62xx-evm kernel: platform 78000000.r5f: R5F core initialized in IPC-only mode
Jan 01 00:00:11 am62xx-evm kernel: rproc-virtio rproc-virtio.2.auto: assigned reserved memory node r5f-dma-memory@9da00000
Jan 01 00:00:11 am62xx-evm kernel: virtio_rpmsg_bus virtio1: rpmsg host is online
Jan 01 00:00:11 am62xx-evm kernel: rproc-virtio rproc-virtio.2.auto: registered virtio1 (type 7)
Jan 01 00:00:11 am62xx-evm kernel: remoteproc remoteproc1: remote processor 78000000.r5f is now attached
Jan 01 00:00:11 am62xx-evm kernel: virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
Jan 01 00:00:11 am62xx-evm kernel: virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
Jan 01 00:00:11 am62xx-evm root[251]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm root[254]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm kernel: Console: switching to colour frame buffer device 160x50
Jan 01 00:00:11 am62xx-evm root[252]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm kernel: PVR_K:  208: Device: fd00000.gpu
Jan 01 00:00:11 am62xx-evm kernel: PVR_K:  208: Read BVNC 33.15.11.3 from HW device registers
Jan 01 00:00:11 am62xx-evm kernel: tidss 30200000.dss: [drm] fb0: tidssdrmfb frame buffer device
Jan 01 00:00:11 am62xx-evm root[264]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm kernel: PVR_K:  208: RGX Device registered with BVNC 33.15.11.3
Jan 01 00:00:11 am62xx-evm kernel: [drm] Initialized pvr 23.3.6512818 20170530 for fd00000.gpu on minor 1
Jan 01 00:00:11 am62xx-evm root[289]: udev/mount.sh [/dev/mtdblock0] is marked to ignore
Jan 01 00:00:11 am62xx-evm root[293]: Using systemd-mount to finish mount
Jan 01 00:00:11 am62xx-evm root[291]: Using systemd-mount to finish mount

When "[drm] pvr " initialized before "[drm] tidss" it works. When "[drm] pvr " initialized after "[drm] tidss" it doesn't work. 

I tried to change module.order but it didn't help. 

Do you think the problem is with the startup sequence? If so, how can I change it to a correct order?

Regards,

Ismail

  • 0
    TI__Mastermind 45015 points

    Hi,

    Yes, your analysis is correct and kmscube by default expects DSS to be present on Card0. If the order changes, it will report the above error. Also, kmscube has "--device option" so you can try something like kmscube -D /dev/dri/card0. 

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Prodigy 40 points

    Hi Krunal,

    I try kmscube beacuse if it works it means my application will work onthe system. So I need to right initialization for gpu. I checked the config files, there are drm and related drivers but I couldn't see powerVR gpu initialization there.  Do you have any idea about how can I fix this gpu drivers initialization issue?

    Regards

    Ismail

  • +1 in reply to Ismail Ucar
    TI__Mastermind 45015 points

    There is no GPU initialization problem and here is  overall summary:

    Upon boot, we cannot control which device, GPU or DSS, will get probed first and who ever gets probed first will get /dev/dri/card0 assigned. In general, your userspace application needs to query the /dev/dri device, identify the GPU or DSS card and create the appropriate application APIs. kmscube does not have such logic but the developers of kmscube allow their users to pass the /dev/dri card through the --device option. On the other hand, weston will go query your display card upon boot and use the appropriate /dev/dri/card node upon booting. In summary, your custom application needs to query the display device as part of it's init logic. 

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Prodigy 40 points

    Thank you for your help.

    Regards

    Ismail