Disable backlight until kernel splash screen

I’ve followed the various blogs and videos, and have built a custom OE layer for my carrier board, including various kernel patches and device tree changes. My board uses PWM2 (pin 4 GPIO01) as the backlight enable signal instead of the standard pin (286), which I’ve successfully addressed in patching the device tree. I’ve also applied a patch for my kernel splash screen, which also works nicely :slight_smile:

I’ve disabled all console output in u-boot which also works, so the first content displayed on the display is the kernel splash screen. However, the display back light toggles on/off briefly during u-boot before turning on during kernel initialisation. I’d like to be able to keep the back light completely disabled until the kernel splash image is ready. I also notice that when the back light does turn on for the kernel, there appears to be, for a fraction of a second, the remnants of a cursor in the top right of the display as the splash screen is initially displayed. As mentioned above, I’ve disabled console output as well as cursor output (vt.global_cursor_default=0) for u-boot, so I’m not sure what this artefact could be.

My questions:

  1. Which is the recommended approach for setting the back light enable signal low until it’s under the kernel’s control? I’ve tried the setenv approach listed here without success. Would patching the apalis_imx6.c file, changing the definition of RGB_BACKLIGHT_GP and then gpio_direction_output to RGB_BACKLIGHT_GP, 0 be suitable?
  2. Can you think of any reason why I’d have a momentary artefact when the kernel splash screen initialises? Are there any additional console/framebuffer parameters I need to disable to ensure when the display does first turn on, the kernel splash screen is displayed cleanly?

Hi jars121

Good to hear that you managed to set up your own OE layer and it works. A good place where I always look if I don’t know how to do stuff in Linux is the wiki from ArchLinux. There is an article about Plymouth where they mention to have the following kernel command line for clean boot:

quiet splash loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0

1: I think that is suitable. You can just put the gpio to 0 on this line


or on this line:


whatever you have plugged in for a display

2: I do not fully understand what artefact you mean. Do mean just the blinking underscore?
You mentioned you did that for u-boot. Make sure that vt.global_cursor_default=0 is passed in the kernel command line like:

setenv tdxargs "quiet splash loglevel=3 rd.udev.log_priority=3 vt.global_cursor_default=0"

I think that should work. Try my suggested command line and let me know if that worked for you.

Best Regards

Thanks @philippe.tx much appreciated, I’ll give that a go and report back :slight_smile:

Hi @philippe.tx

I’ve had some success on point 1. I’ve amended the apalis_imx6.c file with a patch, where I’ve changed the RGB_BACKLIGHT_GP GPIO from the default (3, 13) to my actual BLEN pin (1, 1), and then changed the direction to 0 as mentioned above. This has partially addressed the problem, as the backlight stays off during U-Boot now as desired. However, as I’ve set my BLEN pin (GPIO1 1) as ACTIVE_HIGH in the device tree, the backlight turns on momentarily when the board is first powered, and then turns off once U-Boot starts, then turns on again when the kernel starts.

As such, it would seem I need to configure my BLEN pin with a pull down so it remains off in the reset/uncontrolled state, but then have the kernel pull it high. I.e. the following process:

  1. Device powered up, BLEN pulled low (as per GPIO_ACTIVE_LOW definition in .dts patch)
  2. U-Boot
  3. Kernel begins
  4. Kernel splash displayed on framebuffer
  5. BLEN toggled HIGH
  6. Hand over to operating system

How would I go about toggling the BLEN pin, ensuring it’s toggled immediately after the splash routine has been run in the kernel?

Hello Jars

The PWM2 on the Apalis is hooked directly to iMX6’s pad GPIO09. Then you can see in the reference manual how the SoC is behaving in reset. The pad mux register is called IOMUXC_SW_MUX_CTL_PAD_GPIO09 and in reset muxed to function ALT5, meaning GPIO1_IO09. And normally GPIOs are put to input mode out of reset.
I guess that is your problem right there. If your display backlight-enable-input has a high-Z input then that signal is floating around, causing that flicker. I guess you should pull that line to “off” with a weak pull-resistor. U-Boot is then shutting the signal off in any way. Check that signal with an oscilloscope if you still have problems.

If you added the gpio correctly to your backlight node in the devicetree (&gpio1 9 GPIO_ACTIVE_HIGH) and also muxed it properly (should be already done by the bsp) then you only have to link that backlight to the display and display driver will turn the backlight on once it’s set-up.

Check out our examples we put in the devicetrees:

We specify the panel and link it to the backlight node. The enable gpio is in this case specified in SoM-level devicetree provided by our bsp. But no worries, just override that gpio in your devicetree by specifying a new one like: enable-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;

Best Regards

Hi @philippe.tx

Thanks for that. Just to confirm, my BLEN is connected to MXM pin 4, which is Apalis PWM2, which is connected to iMX6 pad GPIO1_IO01, not iMX6 pad GPIO09 as stated above. The iMX6 datasheet states that GPIO1_IO01 is reset as an input with a 100K pull-up resistor, which is the same as EIM_AD13 which is the default Apalis BLEN pin (MXM pin 286). Given it’s a relatively weak pull-up, I’m thinking that a 10K pull-down on this pin should keep it low on reset, and still allow for the kernel to drive it high (as you outlined above). Does that sound reasonable?

Hi @jars121

You’re right! I jumped a row up when I read the table. And I also checked with the iMX6 datasheet. That pin is indeed 100k pull-up. So yes, If you need a pull-down a 10k will work for you.

Best Regards,
Philippe Schenker