Flashing an image to aster based colibri-imx8x module

jtrulson · November 7, 2019, 12:00am

I must be missing something obvious. I have the above mentioned hardware. I’ve built a tdx-console-image using the 3.0 repository (LinuxImage3.0). Build was successful.

Now, I want to flash that image onto my board. Previously I was using a colibri-imx6dl with LinuxImage 2.8b6.

With that, it was a simple matter to unpack the image tarball on my WS, run update to update my tftp directory, and then on the board, simply dhcp/setethupdate/update and the images would be downloaded and flashed to the board.

With the new stuff, there is this EZ Installer (ezi). The board boots into it (though nothing appears on the connected 7" LCD). I end up having to use an rdp client to connect at 640x480. (Connect at any other resolution and the connection is immediately terminated.)

Ok. But there is nothing to install - only the same EZI, and a “Toradex Embedded Console Demo” downloaded from a TDX site. For kicks I installed this, but it is severely broken on this module (many kernel errors due to “add_uevent_var: too many keys”, failed device probing) and a blank LCD. So clearly that image is no good.

So I want to install my own image I built yesterday, in the hopes it works better - just a standard “bitbake console-tdx-image”, but I just can’t seem to figure out how to get it on the board.

I followed the directions on preparing an SDcard with the latest EZI for this board downloaded off of the tdx website, and ran 'run distro_bootcmd".

This seemed to work better in that I could actually see the ezi screen on the LCD now (it’s a newer version than what shipped on the board).

However, it still only gives me the same two choices - the old ezi that does not work with the LCD and the same tdx console image I’ve already tried with many problems that seem related to it’s DT configuration.

I tried placing the generated tarball (Colibri-iMX8X_Console-Image-Tezi_3.0b2-20191105.tar) on a USB stick ( a couple of them in fact) but they never seem to be ‘seen’ by the ez installer. I tried placing the tarball on the sdcard along with the newer ezi in the hopes it would look there, and booted again via distro_bootcmd. But no, it is not listed. Again, it seems no ability to convince ‘ezi’ to look at or flash this image.

All I want to be able to do is easily flash my images on this board during development like I could with the imx6. Can someone please tell me what I need to do to accomplish this?

jtrulson · November 6, 2019, 11:43pm

Ok, so by unpacking the tezi tarball onto a freshly formatted FAT USB stick (I guess vfat has issues?) and inserting it, the ‘new’ EZI saw the image and let me install it.

However, it too seems to be quite broken - just like the demo image I initially installed with dozens of kernel errors like:

[   11.296311] add_uevent_var: too many keys
[   11.302269] ------------[ cut here ]------------
[   11.308811] WARNING: CPU: 1 PID: 1 at /yoctos/toradex-training-2019-imx8x/tmp/
work-shared/colibri-imx8x/kernel-source/lib/kobject_uevent.c:568 add_uevent_var+0
xc8/0xf0
[   11.328004] Modules linked in:
[   11.333170] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G        W       4.14.117-3
.0.2+ge43e3a26e1b7 #1
[   11.346554] Hardware name: Toradex Colibri iMX8QXP/DX on Colibri Evaluation Bo
ard V3 (DT)
[   11.357111] task: ffff8000281c8000 task.stack: ffff000008040000
[   11.365428] PC is at add_uevent_var+0xc8/0xf0
[   11.372207] LR is at add_uevent_var+0xc8/0xf0
[   11.378932] pc : [<ffff000008d5dcf0>] lr : [<ffff000008d5dcf0>] pstate: 400001
45
[   11.388832] sp : ffff000008043ac0
[   11.394598] x29: ffff000008043ac0 x28: 0000000000000000 
[   11.402403] x27: ffff000008ee1558 x26: ffff8000282c1180 
[   11.410198] x25: ffff000008fca970 x24: 0000000000000006 
[   11.417983] x23: ffff0000091cc3a0 x22: ffff00000927e0f0 
[   11.425750] x21: ffff800028f79980 x20: ffff8000286a4410 
[   11.433484] x19: ffff800028f92000 x18: 0000000000000000 
[   11.441179] x17: 0000000000000001 x16: 0000000000000000 
[   11.448855] x15: 0000000000aaaaaa x14: 0720072007200720 
[   11.456511] x13: 0000000000000001 x12: 00000000ffffffff 
[   11.464158] x11: ffff000008e4f850 x10: 0000000000000001 
[   11.471793] x9 : 0000000000000001 x8 : 0000000000000020 
[   11.479383] x7 : 0000000000000000 x6 : 000000000000053c 
[   11.486926] x5 : 0000000000000000 x4 : 0000000000000000 
[   11.494408] x3 : ffffffffffffffff x2 : ffff000009503268 
[   11.501795] x1 : ffff8000281c8000 x0 : 000000000000001d 
[   11.509069] Call trace:
[   11.513357] Exception stack(0xffff000008043980 to 0xffff000008043ac0)
[   11.521709] 3980: 000000000000001d ffff8000281c8000 ffff000009503268 fffffffff
fffffff
[   11.531466] 39a0: 0000000000000000 0000000000000000 000000000000053c 000000000
0000000
[   11.541144] 39c0: 0000000000000020 0000000000000001 0000000000000001 ffff00000
8e4f850
[   11.550720] 39e0: 00000000ffffffff 0000000000000001 0720072007200720 000000000
0aaaaaa
[   11.560270] 3a00: 0000000000000000 0000000000000001 0000000000000000 ffff80002
8f92000
[   11.569874] 3a20: ffff8000286a4410 ffff800028f79980 ffff00000927e0f0 ffff00000
91cc3a0
[   11.579447] 3a40: 0000000000000006 ffff000008fca970 ffff8000282c1180 ffff00000
8ee1558
[   11.588978] 3a60: 0000000000000000 ffff000008043ac0 ffff000008d5dcf0 ffff00000
8043ac0
[   11.598514] 3a80: ffff000008d5dcf0 0000000040000145 ffff80002bfec990 ffff80002
81c8000
[   11.608078] 3aa0: ffffffffffffffff 0000000000000000 ffff000008043ac0 ffff00000
8d5dcf0
[   11.617667] [<ffff000008d5dcf0>] add_uevent_var+0xc8/0xf0
[   11.624866] [<ffff000008abcb6c>] of_device_uevent_modalias+0x34/0xa0
[   11.633073] [<ffff0000086ba548>] platform_uevent+0x18/0x70
[   11.640427] [<ffff0000086b5ba8>] dev_uevent+0x88/0x1b0
[   11.647458] [<ffff000008d5df20>] kobject_uevent_env+0x208/0x568
[   11.655310] [<ffff000008d5e290>] kobject_uevent+0x10/0x18
[   11.662623] [<ffff0000086b7e20>] driver_bound+0xa8/0xb8
[   11.669775] [<ffff0000086b82a8>] driver_probe_device+0x238/0x2c0
[   11.677738] [<ffff0000086b83e8>] __driver_attach+0xb8/0xc0
[   11.685219] [<ffff0000086b64b4>] bus_for_each_dev+0x6c/0xa8
[   11.692834] [<ffff0000086b7a68>] driver_attach+0x20/0x28
[   11.700177] [<ffff0000086b776c>] bus_add_driver+0x1dc/0x208
[   11.707791] [<ffff0000086b8d78>] driver_register+0x60/0xf8
[   11.715297] [<ffff0000086b9d9c>] __platform_driver_register+0x44/0x50
[   11.723747] [<ffff0000093f782c>] vpu_driver_init+0x1c/0x24
[   11.731179] [<ffff000008083c08>] do_one_initcall+0x38/0x11c
[   11.738677] [<ffff0000093a0ccc>] kernel_init_freeable+0x17c/0x210
[   11.746732] [<ffff000008d6a1cc>] kernel_init+0x10/0xfc
[   11.753797] [<ffff000008084e98>] ret_from_fork+0x10/0x18
[   11.761023] ---[ end trace 606b5b6910ef37c8 ]---

The LCD is still in text mode, and a process is trying to start weston. Just like the ‘demo’ image. No touch events either (tested via evtest).

Should I just abandon the LinuxImage3.0 repo and try LinuxImage2.8b6?

Also, regardless, I’d still like to simpler quicker mechanism to flash the module than preparing sdcards and a usbstick.

jaski.tx · November 7, 2019, 11:58am

Hi @jtrulson

As you found out, you need to extract the .tar file a USB key or SD Card to get them recognized by Toradex Easy Installer.

I have installed the Colibri-iMX8X_Console-Image_3.0b3.54-nightly-20191107 and it works fine. You need to activate the CI Feeds in the Toradex Easy Installer.

No touch events either (tested via evtest).

This should also work with the given image.

Should I just abandon the LinuxImage3.0 repo and try LinuxImage2.8b6?

No, colibri-imx8x is only supported starting from Bsp 3.0.

Also, regardless, I’d still like to simpler quicker mechanism to flash the module than preparing sdcards and a usbstick.

You can use the Stable/CI Feeds Sever from Toradex or create your custom Feeds Server as explained here.

Best regards,
Jaski

jtrulson · November 7, 2019, 6:55pm

Hello @jaski.tx

I have installed the
Colibri-iMX8X_Console-Image_3.0b3.54-nightly-20191107
and it works fine. You need to
activate the CI Feeds in the Toradex
Easy Installer.

I tried the same, plus a few other images there like the Qt5 demo. The preempt-rt version of Console Image does show all of those kernel errors (19 of them):

    [    2.825126] add_uevent_var: too many keys

...

The Non preempt-rt version does not.

These were all b3-54 nightly versions.

I also tried the Qt5 demo image (also preempt). This kernel also shows the kernel errors and tries to start Xorg which crashes due to “no screens found”.

This should also work with the given
image.

In none of the 4 images I tried, + the one I built (3.0b2) does the touch work - I have reseated the flex cable twice. I am using the 7" capacitive touchscreen for Aster.

evtest (and dmesg) show the device:

[    2.398805] input: AD7879 Touchscreen as /devices/platform/5a800000.i2c/i2c-16/16-002c/input/input1

root@colibri-imx8x:~# evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:      sc-powerkey
/dev/input/event1:      AD7879 Touchscreen
Select the device event number [0-1]: 1
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x0 product 0x79 version 0x3
Input device name: "AD7879 Touchscreen"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value      0
      Min        0
      Max     4095
    Event code 1 (ABS_Y)
      Value      0
      Min        0
      Max     4095
    Event code 24 (ABS_PRESSURE)
      Value      0
      Min        0
      Max     4096
Properties:
Testing ... (interrupt to exit)

But I never see any events.

/proc/interrupts never shows any interrupts for this device either, if I am reading this right:

root@colibri-imx8x:~# cat /proc/interrupts 
           CPU0       CPU1       
...
204:          0          0  gpio-mxc   5 Edge      16-002c
...

WRT flashing the device, I can deal with that later - these other issues are the real concern. I cannot build the b3 images as you haven’t released them yet, and they (at least the preempt-rt ones) seem to have serious problems.

My goal is to be able to build an image supporting Qt 5, preferably with EGLFS. I understand that FSL is not supporting that any more, so barring that, I need to support Qt5 on weston/wayland with touch and full 2D/3D HW acceleration.

So, I guess I am stuck for the time being on this.

jtrulson · November 7, 2019, 8:03pm

Ok, so I’ve learned the AD7879 is for a 4-wire resistive. No wonder it does not emit events.

Apparently I am supposed to be using atmel_mxt_ts which is built into the kernel. For some reason or another it just does not see the touch controller. I’ve reseated yet again, and verified that pin1->pin1, etc.

jaski.tx · November 8, 2019, 11:13am

Sorry I also tested on Resistive touch. I was not aware that you were using Capacitive touch. I can do the test again with capacitive touch and report my results to you next week.

My goal is to be able to build an image supporting Qt 5, preferably with EGLFS. I understand that FSL is not supporting that any more, so barring that, I need to support Qt5 on weston/wayland with touch and full 2D/3D HW acceleration.

Hardware Acceleration with Wayland is working. Why you need EGLFS?

jtrulson · November 9, 2019, 9:13am

Sorry I also tested on Resistive
touch. I was not aware that you were
using Capacitive touch. I can do the
test again with capacitive touch and
report my results to you next week.

Thanks.

Hardware Acceleration with Wayland is
working. Why you need EGLFS?

Is it? Can you tell me how? With EGLFS I wouldn’t need wayland… But I am fine with using wayland and getting Qt running on it using it’s wayland plugin.

But - I have yet to actually see any graphics running at all on all the images I’ve tried/built. As I mentioned, the nightly qt5 image failed (trying to run Xorg).

I just built the lxqt-image. This, in theory should run Weston with Xwayland. But it fails also. In addition to all of the kernel errors I’ve reported earlier (these are serious and should be investigated), wayland fails to start:

root@colibri-imx8x:~# weston-start
root@colibri-imx8x:~# cat /var/log/weston.log
Date: 2019-11-08 UTC
[16:47:41.865] weston 5.0.0
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 5.0.0-33-gfb563901-dirty MGS-4627 [#ccc] weston will turn off when panel-psotion=none and use gplay (2019-03-14 11:30:30 +0800)
[16:47:41.865] Command line: weston --modules=xwayland.so --log=/var/log/weston.log
[16:47:41.865] OS: Linux, 4.14.117-3.0.2+ge43e3a26e1b7, #1 SMP PREEMPT Tue Nov 5 01:45:58 UTC 2019, aarch64
[16:47:41.865] Using config file '/etc/xdg/weston/weston.ini'
[16:47:41.865] Output repaint window is 16 ms maximum.
[16:47:41.865] Loading module '/usr/lib/libweston-5/x11-backend.so'
[16:47:41.900] fatal: failed to create compositor backend

Of course it seems to have tried to start on boot too and failed:

[15:58:40.453] weston 5.0.0
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 5.0.0-33-gfb563901-dirty MGS-4627 [#ccc] weston will turn off when panel-psotion=none and use gplay (2019-03-14 11:30:30 +0800)
[15:58:40.453] Command line: /usr/bin/weston --log=/var/log/weston.log --xwayland
[15:58:40.453] OS: Linux, 4.14.117-3.0.2+ge43e3a26e1b7, #1 SMP PREEMPT Tue Nov 5 01:45:58 UTC 2019, aarch64
[15:58:40.454] Using config file '/etc/xdg/weston/weston.ini'
[15:58:40.457] Output repaint window is 16 ms maximum.
[15:58:40.458] Loading module '/usr/lib/libweston-5/drm-backend.so'
[15:58:40.473] initializing drm backend
[15:58:40.488] logind: session control granted
[15:58:40.494] using /dev/dri/card0
[15:58:40.494] DRM: supports universal planes
[15:58:40.494] DRM: supports atomic modesetting
[15:58:40.494] DRM: does not support picture aspect ratio
[15:58:40.495] Loading module '/usr/lib/libweston-5/gl-renderer.so'
[15:58:40.515] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_KHR_platform_wayland
               EGL_EXT_platform_wayland EGL_KHR_platform_gbm

And that’s it.

None of the images I’ve tried (latest) in nightly seems to have working graphics. The only graphics I’ve seen so far is the recent ez installer I downloaded for tdx. The one built into the board when I received it didn’t even show any graphics on the LCD.

So - if you know a way I can build an image with working wayland, I am all “ears”.

marcel.tx · November 8, 2019, 5:10pm

Yes, like you already found out, the preempt-rt stuff is not yet functional on the i.MX 8/8X. After all, those are just nightly builds.

Capacitive touch should work but you would need to use the Aster specific device tree (fsl-imx8qxp-colibri-aster.dts) for that (e.g. just set fdt_file resp. fdtfile).

jtrulson · November 9, 2019, 9:14am

Yes, like you already found out, the
preempt-rt stuff is not yet functional
on the i.MX 8/8X. After all, those are
just nightly builds.

Yes - though that is also the default behavior in the currently released 3.0b2, and therefore also affected my builds. Just wanted to make that clear.

Capacitive touch should work but you
would need to use the Aster specific
device tree
(fsl-imx8qxp-colibri-aster.dts) for
that (e.g. just set fdt_file resp.
fdtfile).

Ah… This dtb does not exist in my 3.0b2 builds. So I downloaded/installed the non PREEMPT-RT version of LXQT - 3.0b3.55-nightly (2019-11-08) via the EZ installer.

With that loaded, I could use that DTB. On boot, the touchscreen was detected and I could get proper events from evtest. Nice.

Graphics was/is still broken though. It seems to have tried to start weston, which failed:

Date: 2019-11-08 UTC
[18:19:30.810] weston 5.0.0
               https://wayland.freedesktop.org
               Bug reports to: https://gitlab.freedesktop.org/wayland/weston/issues/
               Build: 5.0.0-33-gfb563901-dirty MGS-4627 [#ccc] weston will turn off when panel-psotion=none and use gplay (2019-03-14 11:30:30 +0800)
[18:19:30.810] Command line: /usr/bin/weston --log=/var/log/weston.log --xwayland
[18:19:30.810] OS: Linux, 4.14.126-3.0.3+g6f7808220263, #1 SMP PREEMPT Thu Nov 7 03:55:56 UTC 2019, aarch64
[18:19:30.814] Using config file '/etc/xdg/weston/weston.ini'
[18:19:30.817] Output repaint window is 16 ms maximum.
[18:19:30.818] Loading module '/usr/lib/libweston-5/drm-backend.so'
[18:19:30.827] initializing drm backend
[18:19:30.839] logind: session control granted
[18:19:30.845] using /dev/dri/card0
[18:19:30.845] DRM: supports universal planes
[18:19:30.845] DRM: supports atomic modesetting
[18:19:30.845] DRM: does not support picture aspect ratio
[18:19:30.847] Loading module '/usr/lib/libweston-5/gl-renderer.so'
[18:19:30.882] EGL client extensions: EGL_EXT_client_extensions
               EGL_EXT_platform_base EGL_KHR_platform_wayland
               EGL_EXT_platform_wayland EGL_KHR_platform_gbm

No other diagnostics. No kernel messages (dmesg).

So… Do I just need to wait for a new release (3.0b3?) in order to be able to build a workable image?

Should I start a separate thread?

jaski.tx · November 9, 2019, 11:11am

Hi @jtrulson

Good that you made some progress.

Graphics was/is still broken though. It seems to have tried to start weston, which failed:

This is a side effect on an other issue in Toradex Easy Installer. Could you go to U-Boot and reset to the default Environment after Image Installation by following these instructions:

env default -a
saveenv

Best regards,
Jaski

jtrulson · November 11, 2019, 9:57pm

Hi @jaski.tx ,

That worked on the lxqt image I had installed. Weston came up.

The issue then is that it comes up in the wrong resolution (640x480, rather than the correct 800x480).

I tired the instructions here but had no success.

modetest -M imx-drm

fails with:

"failed to open device 'imx-drm': No such file or directory"

Just running modetest shows:

trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...failed
trying to open device 'tilcdc'...failed
trying to open device 'msm'...failed
trying to open device 'sti'...failed
trying to open device 'tegra'...failed
trying to open device 'imx-drm'...failed
trying to open device 'rockchip'...failed
trying to open device 'atmel-hlcdc'...failed
trying to open device 'fsl-dcu-drm'...failed
trying to open device 'vc4'...failed
trying to open device 'virtio_gpu'...failed
trying to open device 'mediatek'...failed
trying to open device 'meson'...failed
trying to open device 'pl111'...failed

Any attempt to use fbset to set resolution results in:

ioctl FBIOPUT_VSCREENINFO: Invalid argument

I’m not sure if it possible to set the resolution on the kernel command line like previous modules - I didn’t see anything obvious.

So to recap:

With the newer b3 lxqt image, and the correct DTB selected (aster), and clearing the environment (env default -a), I do get weston graphics (at the wrong resolution), and the touchscreen does work.

I also did not see all of the kernel errors on boot after clearing the environment. So that’s good

So - I guess I still need to wait for updated software (b3+) to be released before I can build my own custom image?

Thanks for the help!

jaski.tx · November 13, 2019, 8:00am

Hi

Could you use the QT5 image instead of LXQT image and post the errors you get.

With the newer b3 lxqt image, and the correct DTB selected (aster), and clearing the environment (env default -a), I do get weston graphics (at the wrong resolution), and the touchscreen does work.

Just to be sure. First you will clear the Environment, then setup the aster carrier board.

Thanks.

marcel.tx · November 13, 2019, 12:38pm

I’m not sure if it possible to set the resolution on the kernel command line like previous modules - I didn’t see anything obvious.

No, not really, unless you inject a custom EDID.

With the newer b3 lxqt image, and the correct DTB selected (aster), and clearing the environment (env default -a), I do get weston graphics (at the wrong resolution), and the touchscreen does work.

The resolution being wrong is quite subjective. It’s just using default VESA VGA.

I also did not see all of the kernel errors on boot after clearing the environment. So that’s good

So - I guess I still need to wait for updated software (b3+) to be released before I can build my own custom image?

No, not at all, as it really is more or less feature complete already.

Actually, parallel RGB aka eLCDIF currently does not use DRM but rather a plain framebuffer. The place to change the display resolution/timing is therefore in the device tree (e.g. more in-line with how it is done for the i.MX 7 as well):

http://git.toradex.com/cgit/linux-toradex.git/tree/arch/arm64/boot/dts/freescale/fsl-imx8qxp-colibri.dtsi?h=toradex_4.14-2.0.x-imx#n46

jtrulson · November 14, 2019, 7:52pm

Hi @jaski.tx,

Could you use the QT5 image instead of
LXQT image and post the errors you
get.

I used EZI to install:

Qt5 Demo (non preempt-rt)
3.0b3.61-nightly 2019-11-14

I see no kernel errors. The screen still comes up in 640x480 instead of 800x480.

Weston comes up. Touch appears to work (I ran weston-terminal, and I can drag it around).

There is a defunct process, Xorg (ps -ef):

root      3912  3891  1 19:09 ?        00:00:00 [Xorg] <defunct>

and later, xinit goes defunct:

root      3993  3969  0 19:10 ?        00:00:00 [xinit] <defunct>

It looks like both Xorg and weston are started on boot and Xorg fails. I don’t think Xorg (the server binary) should be present nor should there be any attempt to start it on boot. Xwayland is present and started by weston itself.

I also looked at the Qt platform plugins that were present - it seems only xcb (X11) is supported.

My understanding is that with IMX8, only wayland/weston supports full 2d/3d acceleration, so for Qt to also be accelerated, it would need to use the Qt wayland plugin, which is missing on this image.

I could not test performance since I can’t build an SDK for this build as it is not released. The image itself does include qmake, but does not include the compiler, includes, etc, needed to try to compile a test program.

I could not find any Qt examples or such to run either, though I did not spend a lot of time trying.

I did not try the preempt-rt version of the Qt5 image.

Just to be sure. First you will clear
the Environment, then setup the aster
carrier board.

Yes - the steps I followed were:

install the image via EZI,
on first boot, interrupt and go to the u-boot prompt. Then:

env default -a
setenv fdtfile fsl-imx8qxp-colibri-aster.dtb
setenv fdt_file fsl-imx8qxp-colibri-aster.dtb
saveenv

Then booted.

Thanks!

jtrulson · November 14, 2019, 8:09pm

Hi @marcel.tx

No, not really, unless you inject a
custom EDID.

The ability to set the video config in u-boot was quite handy for me. Oh well.

The resolution being wrong is quite
subjective. It’s just using default
VESA VGA.

Perhaps my choice of words was incorrect then? For LCD’s, the correct resolution is pretty much always the panel’s native resolution. So, at least for the panel I’m using, 640x480 is wrong, as it leaves garbage on the right 160 pixels of the screen.

The reason I brought it up in the first place was that my first build (3.0b2, currently available from your repos) did set the correct resolution and configuration on boot, maybe accidentally? Of course graphics and touch didn’t work, but…

No, not at all, as it really is more
or less feature complete already.

Except for the fsl-imx8qxp-colibri-aster.dts file I need, and do not have…

Actually, parallel RGB aka eLCDIF
currently does not use DRM but rather
a plain framebuffer. The place to
change the display resolution/timing
is therefore in the device tree (e.g.
more in-line with how it is done for
the i.MX 7 as well):

Perhaps I am missing something here then. I assumed that the LCD (parallel) was simply another output for the GPU. I could understand if KMS/DRM does not currently support changing it’s configuration other than via the DT.

The GPU is supported in DRM or there would be no way to get HW accelerated 2D/3D, as a plain dumb FB cannot support that without a GPU backing it up using egl/es2/es3.

Are you saying that by using this panel, I am not using the acceleration capabilities of the GPU, and am in fact rendering completely in software?

If that is the case, we cannot use this panel. We need accelerated rendering via whatever means currently supported with imx8, which I understand to be wayland/weston.

marcel.tx · November 15, 2019, 6:43am

The ability to set the video config in u-boot was quite handy for me. Oh well.

Yes, in the future e.g. with Torizon this may be achieved by device tree overlays.

The reason I brought it up in the first place was that my first build (3.0b2, currently available from your repos) did set the correct resolution and configuration on boot, maybe accidentally? Of course graphics and touch didn’t work, but…

Yes, BSP 3.0b2 was using a stupid default which by accident happened to match your desired one.

Except for the fsl-imx8qxp-colibri-aster.dts file I need, and do not have…

Sorry, my feature complete comment was meant to current nightly builds.

And your last section of comments are very valid and probably the one single place which still needs some more work. However, please understand that we are still on NXP pre-release silicon and not even they have parallel RGB working at all! The final solution is still targeted for regular DRM integration. Unfortunately, any of NXP’s schedule is still confidential.

jtrulson · November 15, 2019, 7:43pm

@marcel.tx, @jaski.tx

Thank you both for attempting to help me here. Now I have a better understanding of the issues.

I have informed my management that this solution is not quite ready for us yet, but is likely to be in the future.

I appreciate the information provided and will be keeping an eye on this hardware and software as it becomes available.

marcel.tx · November 18, 2019, 5:40pm

I’m not quite sure what exactly you expected of a sample product based on a pre-release system on chip. Anyway, concerning the hardware accelerated display we found out that despite us thinking otherwise it is actually fully DRM enabled and hardware accelerated already. It’s just that instead of imx-drm it uses mxsfb-drm which is handling the eLCDIF giving you parallel RGB. And if e.g. using modetest one has to explicitly specify this using -M mxsfb-drm.

jtrulson · November 18, 2019, 6:28pm

I’m not quite sure what exactly you
expected of a sample product based on
a pre-release system on chip.

I think that is the crux of the issue - we did not expect this to be the case. I’ll follow up in another comment flagged for tdx/moderators only explaining what we are/were doing.

Anyway, concerning the hardware
accelerated display we found out that
despite us thinking otherwise it is
actually fully DRM enabled and
hardware accelerated already.

I suspected so after looking though the module datasheet - there it explicitly said that the parallel RGB was essentially “just another output”.

-M mxsfb-drm does run, though as you mentioned, only 640x480 is defined. It does draw a pattern at 640x480, so that seems to work well!

I am looking forward to using this combo in time.