Hi,
I’ve been working on a custom TorizonCore Image on my Apalis iMX6, prototyping on my Ixora Board v1.2. The goal of my project is to recreate via Torizon an image created by a previous company who used a pre-built Boot2Qt Image for a Qt GUI app.
The iMX6 will end up on a custom PCBA for our device without the dev board.
The development has been going well, and when I connect my 1080p monitor to the Dev Board via HDMI, the GUI of my container displays. My application is made for 1360x768 screens, so I need to set the resolution to this fixed setting and make the image recognize my DVI monitor.
However, when I connect my device’s display monitor with a resolution of 1360x768 (720p) via DVI to HDMI, I obtain the following output on puTTY upon bootup.
The screen unfortunately does not display anything.
Looking at my application’s container logs, I see the following:
On the old Boot2Qt image, the startup script contained the command line fbset "1360x768 60.00Hz 32bit (GTF), but this command does not work on a Torizon Image, mainly because this mode is not preset.
I’m understanding I have to play around the Device Tree overlays, but I am a bit confused on how to proceed from here. Is my issue even related to Device Tree?
Thanks in advance.
Greetings @anthonyabboud,
For your DVI display I assume you are using a DVI to HDMI cable correct?
Based on the error messages it looks like the graphics sub-system has issues initializing with this display. Though it’s hard to tell what the exact problem is. Perhaps a bad cable or something?
I’m understanding I have to play around the Device Tree overlays, but I am a bit confused on how to proceed from here. Is my issue even related to Device Tree?
This shouldn’t be necessary with HDMI and DVI. Typically these types of displays communicate their resolution and other display settings via a built-in EDID. However you stated:
On the old Boot2Qt image, the startup script contained the command line fbset "1360x768 60.00Hz 32bit (GTF)
So perhaps this display does not have any built-in EDID information?
In the Weston container you can set Weston to use a specific resolution/mode: Working with Weston on TorizonCore | Toradex Developer Center
Though I’m not sure how this will work for your display but it may be worth a try.
Best Regards,
Jeremias
Hi @jeremias.tx,
For your DVI display I assume you are using a DVI to HDMI cable correct?
Yes, I am using a DVI to HDMI cable. I have tried 3 different cables so far and obtain the same result.
So perhaps this display does not have any built-in EDID information?
The monitor does display the TEZI GUI when I boot that instead of my image. Just not when its my Torizon image.
In the Weston container you can set Weston to use a specific resolution/mode: Working with Weston on TorizonCore | Toradex Developer Center
I’ll take a look at that and see if I can find anything relevant to this.
The monitor does display the TEZI GUI when I boot that instead of my image. Just not when its my Torizon image.
Well Tezi is a bit special since it forces a resolution despite whatever display may be attached. I just find it odd that on the old Boot2Qt image you had to configure the display with fbset, since if EDID was available it should have automatically configured the display.
Also you mentioned “mainly because this mode is not preset.” Could you not just copy or set the mode then manually on TorizonCore? Or was there something else that had to be done to enable/configure this specific display?
Apologies I can’t provide more specific advice since I don’t have DVI display available that exhibits this issue.
Best Regards,
Jeremias
I’ve copied the mode but still doesn’t work. Looking at the compositor logs (Weston), I compared the output between a screen where the display is working vs my screen where it doesn’t. The only difference was these 2 lines at the very end when the display does not work. Trying to see the workaround to these two:
atomic: couldn't commit new state: Device or resource busy
repaint-flush failed: Device or resource busy
I can also see the compositor detecting the correct resolution of the screen:
Output HDMI-A-1 (crtc 34) video modes:
1366x768@60.0, preferred, current, 85.8 MHz
This is really strange to see, though it’s still not obvious what the issue actually is. As a sanity check could you try a test for me. Instead of TorizonCore could you instead flash our “Reference Multimedia Image”. Then test if your display works or does not work with this image as well. This will help narrow down whether the issue is a general issue with our BSP or somehow specific to just TorizonCore.
Best Regards,
Jeremias
I’ve flashed the Reference Multimedia Image like you suggested and the display successfully works as seen below.
Also an important note I forgot to mention. On TorizonCore, even the Bootup Splash Screen does not display on that specific monitor
Ok that is interesting that it works there. Just to confirm you’re comparing between what version of TorizonCore and what version of the Reference Multimedia Image?
Best Regards,
Jeremias
Both versions I’m comparing are
TorizonCore: 5.7.0 Build 17
Reference Multimedia Image: 5.7.0 Build 20
Ok and for the Reference Multimedia Image did you install the upstream variant of it or the non-upstream variant? Or did you check both?
Just tried both and got different interesting results.
For the non-Upstream version, the display works correctly.
For the Upstream version, the bootup gets stuck at 2 seconds output:
and then unblocks and goes all the way to the login prompt with similar errors I was getting on TorizonCore:
In this case, the display does not work.
Ok that is the confirmation I was looking for. So TorizonCore uses a upstream Linux kernel as well similar to the upstream variant of the Multimedia image. With this it looks like it’s an issue only on the upstream kernel but is fine on the downstream, how strange.
I’ll need to pass this on to our team who works on the kernel and see if they have an idea of what the difference could be.
Best Regards,
Jeremias
1 Like
We’re still looking into this, though it’s quite hard for us to investigate since we don’t seem to have a display that shows a similar behavior. Though it’s unclear if this issue is display specific or some other factor.
In the meantime our team just released a new version of our reference images (5.7.2). Could you try this new version and see if it changes or fixes anything.
Also I forgot to ask before but as another check could you test any of our version 6 images to see if the issue is still there. These use a much newer version of the Linux kernel so the behavior may be different.
Finally, could you get information from modetest as shown here: Display Output, Resolution and Timings (Linux) | Toradex Developer Center
I’m curious if any information from your display is available at all to the software or if it just fails to read anything about your display.
Best Regards,
Jeremias
Hi @jeremias.tx ,
I’ve attempted to flash with the new version 5.7.2, but obtained the same result.
However, like you suggested, I also attempted to flash with Torizon 6 (as of today, the Quarterly Release 6.1.0 Build 1) which is also a Production Release, and the screen finally successfully displayed without needing to manually set anything!
I’ll continue my project with this version since it’s ok to use for Production.
Thanks alot for your help on this!
Best,
Anthony
Well glad to hear the issue does not exist in the newer upstream kernel. I suppose it would be too much trouble to isolate what exactly changed between the two kernel versions that fixes this. Anyways glad you were able to proceed!
Best Regards,
Jeremias
