How to consider non-default branches for TorizonCore Builder Tool

Technical Support
, ,
1

Dear Torizon experts.

Aiming for using two lvds displays, in recent questions you have recommended to prepare overlays with your TorizonCore Builder Tool (Community Question).
This has worked for using the two displays, but only one at a time. The image does not start the second lvds display since framebuffers are not enabled or rather specified in your overlay repository of branch (“toradex_5.4.y”).

At least, this is the case for your most recent images, which are e.g…

  1. torizon-core-docker-apalis-imx6-Tezi_5.1.0-devel-202011+build.4.tar
  2. torizon-core-docker-apalis-imx6-Tezi_5.1.0-devel-20201112+build.120.tar

…from my perspective. These have been built with the meta-toradex-bsp-common repository (more precisely the root/recipes-kernel/linux/linux-toradex-mainline_5.4.bb).
However, using the command of you TorizonCore Bulder Tool

torizoncore-builder dt checkout

this “toradex_5.4.y” branch will be used since this is the default and here, mxcfb1, mxcfb2, mxcfb3 and mxcfb4 are not specified.

Having a look on the branch “toradex_5.4-2.1.x-imx” of that repository, I have figured out that the framebuffers (mxcfb1, mxcfb2, mxcfb3 and mxcfb4) are specified, here.
You can see this at link (e.g. at line 94).

Selecting this specific branch with the command of your TorizonCore Bulder Tool

torizoncore-builder dt checkout --branch toradex_5.4-2.1.x-imx

regrettably, it is not possible to apply the dt command successfully. Of course, this is because of the different kernel versions…

  1. Do you provide a Torizon Image in your artifactory, that is buit on the toradex_5.4-2.1.x-imx branch?
  2. Alternatively, how can the framebuffers be enabled in the toradex_5.4.y branch?
  3. Are you going to update you linux-toradex-mainline_5.4.bb, so that the “KBRANCH=toradex_5.4-2.1.x-imx”?

I am looking forward to hear from you.

Many thanky for your help.

2

Greetings @Marcus,

To answer your questions one by one:

Do you provide a Torizon Image in your artifactory, that is buit on the toradex_5.4-2.1.x-imx branch?

In short no. In detail the older/mature i.MX modules like i.MX6 use the mainline 5.4 kernel. For newer modules like the i.MX8 we still have to use the downstream 5.4_2.1.x kernel from NXP. On our non-Torizon BSP I believe we do have images that provide both 5.4_2.1.x and 5.4 kernels for i.MX6. But for Torizon we only build the mainline kernel variant for the i.MX6.

Alternatively, how can the framebuffers be enabled in the toradex_5.4.y branch?

Currently I believe we use a different mechanism here than traditional framebuffers like in the NXP kernel. But I’ll need to do some research and checking on my side first.

Are you going to update you
linux-toradex-mainline_5.4.bb, so that
the “KBRANCH=toradex_5.4-2.1.x-imx”?

As I said previously no, since these are two fundamentally different Linux Kernels. For the NXP basped 5.4-2.1.x-imx we use this recipe: https://git.toradex.com/cgit/meta-toradex-nxp.git/tree/recipes-kernel/linux/linux-toradex_5.4-2.1.x.bb

This honestly was less confusing when the NXP kernel was 4.14 and not 5.4 like our mainline kernel so the confusion is understandable.

Anyways I’ll do some research and check with the team since I believe we’ve done multiple display tests in the pasts. I’ll get back to you when I get something promising.

Best Regards,
Jeremias

3

Dear Jeremias.

Thank you very much for your answer as well as for checking with your team.
Is there anything I can to help to progress, here?

I am looking forward to hearing from you,

best,

Marcus

4

I’ve done some digging and I think I generally know what needs to be done for dual LVDS. I’m unable to do any testing however as I don’t have the display setup necessary. But I wanted to share my thoughts with you anyways.

So as you can see here in the SoC level device tree: imx6qdl.dtsi « dts « boot « arm « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

The ldb/lvds node is initialized with the 2 possible LVDS channels. In the Toradex level device tree here: imx6q-apalis-eval.dts « dts « boot « arm « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

We modify the first LVDS channel to use the configuration of the lvds_panel node. But we never do any further configuration with the 2nd LVDS channel.

Therefore in theory if you setup the 2nd channel in a similar way to the first channel then you’d have your 2 LVDS displays.

Best Regards,
Jeremias

5

Dear Jeremias.

Thank you very much for your thoughts on it. There has been a lot of testing on the basis of your last reply. Hence, the late reply.
We have decided to create an individual device-tree in order to test your thoughts.
This device-tree is based on imx6q-apalis-ixora-v1.1.dts.
You can find the custom file attached called “imx6q-test-sensgit-next2.dts”.
You will see that we tried to start to different kinds of displays: one long display (primary) and one short display.

For a very, very, very short moment (about a half second), the long display shows the torizon logo successfully. The logo then disappears and reappears on the short display. From hereon, the short display seems to be interpreted as primary display because the boot process ends at displaying the console on the short display while the long display is black.

Our interpretation is the following: Timings for both displays are correct because the work nicely in a solo mode. Trying to activate both, which is based on your thoughts, we belief that the hardware correctly activates the displays because both displays have shown the logo correctly. Then, the linux kernel only deals with one display. It only creates one frame buffer as you can see in the file called “console.txt”. For more debug information, you can further find the dmsg output (“dmseg.txt”) and the journalctl output (“journalctl.txt”). As not any output shows error messages on the display creation and the frame buffer creation, the failure is hard to detect… Do you have any idea about it? How can we debug it further? Is it a torizon software issue?

Hopefully, you can help.
Please let us know if you need further input.

Best regards,

Marcus

6

Unfortunately, I don’t have a 2 LVDS displays nor do I have a carrier board with 2 LVDS connectors. Therefore I can’t test your changes here directly. But I was able to do a somewhat similar test.

So I took an Apalis i.MX6 on an Ixora carrier board. I connected two displays 1 LVDS and 1 Parallel RGB. While it isn’t 2 LVDS displays, it’s a similar dual display setup. Interestingly once I made the device tree changes for timings and enabling both interfaces they both turn on at boot time and stay on. Once the system settles on the login prompt both displays are showing the login prompt. Furthermore I checked for framebuffer devices in /dev. Like you I only have the 1 fb0 device. Therefore I don’t think it’s a case of not having 2 fb* devices.

I then launched a graphical container. The output was present on both screen though it seems like the display is extended across both connected displays rather than being cloned.

So given my test I don’t think it’s an issue of frame-buffers or the software not being able to handle multiple displays. I’m inclined to believe it’s perhaps a configuration issue with the two LVDS displays though I may still be mistaken since I can’t confirm it directly.

Let’s try and narrow down what the issue may be then. First some questions.

  • When the system settles after boot you say the long display is “black”. Is this black as in completely blank with no backlight? Or black with a backlight?
  • What happens when you run a graphical container? Like the Weston container in this article: Debian Containers for Torizon | Toradex Developer Center

Now as for some observations with your device tree.

That’s all that jumps out to me right now looking at your device tree. Apologies I can’t give more detailed answers, as I can only speculate without having the hardware myself.

Best Regards,
Jeremias

7

Dear @jeremias.tx.

You have presented great ideas - thank you very much for this.
Please allow to present some results on it.

  • Regarding your idea of needing a backlight node: Since the displays are hard wired, the backlight is switched on all the time. So this is not the problem from my perspective. Hence, your description “black with a backlight” describes it best.
  • Regarding the idea of needing a data-mapping and width field: This indeed has improved the picture quality. The values of “spwg” and “24” are the right ones in our case. Thanks you very much for your reminder.
  • Regarding your idea of starting a graphical container: Starting the weston container leads to the displaying of the gray weston surface on the non-primary display. The primary display remains black with a backlight. Surprisingly, the weston logs mention both displays, as you can see here: westonLogs.txt.

Beside of these thoughts, we came up with a further idea: Maybe we have to select the corresponding registry and port selection right? In regard with the files “imx6qdl.dtsi”, “imx6q.dtsi” and “imx6qdl-apalis.dtsi” that show increasing port numbers for ldb, we tried using the ports 5 and 6, which has no different effect (black with a backlight). The following shows one example of trying different kinds of ports and registries:

&ldb {
	status = "okay";
	#address-cells = <1>;
	#size-cells = <0>;
	lvds-channel@0 {
		status = "okay";
		primary;
		port@3 {
			reg = <3>;
			lvds_out_1: endpoint {
				remote-endpoint = <&lvds_panel_in_1>;
			};
		};
	};
	lvds-channel@1 {
		status = "okay";
		port@4 {
			reg = <4>;

			lvds_out_2: endpoint {
				remote-endpoint = <&lvds_panel_in_2>;
			};
		};
	};
};

Regrettably, this has no effect (black with a backlight), too. Is it correct to use port 4 and reg=4? How do you know, which port and reg to use?

Best,

Marcus

8

Hmm well the Weston output was useful in showing that both LVDS displays are being recognized by the kernel. Just to confirm this can you run ls /sys/class/drm on the base Torizon OS. I want to see if there are 2 LVDS interfaces listed like Weston says there are.

If this is true then there can’t be any serious errors with your device tree implementation, otherwise I wouldn’t expect the kernel to recognize both LVDS interfaces. Also as you said earlier for a brief moment the boot logo is displayed on the long display before switching. Though I can’t think of an explanation right now for this switching during boot.

In regards to the ports both channels should be port 4 as far as I know. Each lvds-channel should have it’s own set of ports, meaning there should be no conflict as they each use their own port 4, if that makes sense.

Let me do some research and see if there’s maybe some configuration we’re missing.

Best Regards,
Jeremias

9

Dear @jeremias.tx.

Great news: Your command

ls /sys/class/drm

has brought up the following console output:

card0  card1  card1-LVDS-1  card1-LVDS-2  renderD128  version

Obviously, the SoM correctly recognizes both displays.
We even were able to specifically switch displays on and of with the following commands:

sudo sh -c "echo off > /sys/class/drm/card1-LVDS-2/status"
sudo sh -c "echo off > /sys/class/drm/card1-LVDS-1/status"
sudo sh -c "echo on > /sys/class/drm/card1-LVDS-2/status"
sudo sh -c "echo on > /sys/class/drm/card1-LVDS-1/status"

Hence, we have tested a lot of procedures in switching displays on and off manually and starting applications. Here, we were able to show an application nicely on each display specifically, while the other display was switched off. Hence, both displays are connected correctly and work well individually, which is a great news from our perspective.

We were even able to start an application, which is shown at both displays simultaneously. This is the case when we first start the (originally) secondary display and then switch on the primary display. Regrettably, right at that moment, the primary display was switch on, the image quality of the secondary display worsens immensely. Here, the primary display works nicely.

By the way, if we switch the primary display on first and then switch the secondary display on, the primary display returns to a “black with a backlight” and the secondary display works nicely. In all the cases, the displays remain “connected” when switched on and “disconnected” when switched off.

This leads us to the assumption the the last display turned on is responsible for the corresponding clocks. Since the secondary display still shows content when the primary display is switch on, obviously, the secondary display seems to be a bit more robust in regard with clock times and of course, the display quality of the second display is bad when it runs with clocks of the primary display…

However, the prove for the use of the same clocks although they have been specified individually becomes visible by the following command:

sudo cat /sys/kernel/debug/clk/clk_summary | grep ldb

When having switched on the secondary display last (primary=black, secondary=nice), the following clocks can be found: SecondaryDisplaySwitchedOnLast.txt.
When having switched on the primary display last (primary=nice, secondary=bad quality), the following clocks can be found: PrimaryDisplaySwitchedOnLast.txt.

We assume that the reason refers to conflicting clock times and the most recent display start leads to the system’s clock values. This explains, why the primary display presents the Torizon logo at the boot procedure for a very short moment and the secondary display then overrules the primary display clocks. Hence, the logo disappears at the primary display and reappears at the secondary display.

Even tweaking with clocks around and changing the display order does not change the described effects…

Long things short: Do you know advice in the following things:

  1. How can we can deal with these conflicting clocks best?
  2. Is it possible to specify the clock values via the terminal?
  3. Is it possible to specify clock values by the config.ini of the weston container, so that the displays can be started by the weston container nicely? (FYI: see page WestonIniPage at section “mode=mode” at the text “173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync” at which 173.00 could represent clock timings)
10

I did have a thought that perhaps there was a clock conflict between the two differing required pixel-clocks. I’m glad you somewhat confirmed this with your findings.

I’m unsure whether you can force the right clock via software or whether the device tree setting will try and take priority. I suppose it’s worth a try and see what happens, I’m curious as well as what might occur.

Baseline on Torizon I think the only utility we have for interacting with the display stack is fbset so this may also be worth a try in addition to the Weston config file.

I believe the LVDS clock for both channels gets derived from the same parent/base clock. Therefore it may be the case that the two clocks frequencies either need to be the same or can be derived from one another via a clock divider.

For context the clocks for the ldb node are set here: imx6q.dtsi « dts « boot « arm « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

The clock software driver for the i.MX6 goes a bit more into how the clocks for LDB are derived from the parent clocks: clk-imx6q.c « imx « clk « drivers - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

So this seems like a hardware limitation that despite there being 2 LVDS clock signals generated, it all comes from the same source. It seems it all gets derived from this PLL5 clock. I wonder if it would be useful at all to try a different base/parent clock. Though it’s probably safer/quicker to at least try the software changes first before we resort to reassigning clocks.

Best Regards,
Jeremias

11

Dear @jeremias.tx .

That’s it. Because of assigning individual parent clocks, by

&clks {
         assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
                           <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
         assigned-clock-parents = <&clks IMX6QDL_CLK_PLL2_PFD0_352M>, 
                                  <&clks IMX6QDL_CLK_PLL5_VIDEO_DIV>; 
};

has solved the issue. Maybe, it’s an option to overtake this to the torizon images…?

However, thank you very much for your guidance through the last two months!

Best,

Marcus

12

Glad you were able to resolve the timing issue. Please let me know if you notice any side effects that you believe to be due to the clock changes.

Best Regards,
Jeremias