Hello we have implemented the Bootlogo from uboot to kernel patch for our BSP and came across an issue on the i.mx6 Solo only (no issue on imx6 quad).
We have implemented the following patches on kernel 4.9.11-1.0.0:
When we applied this the display stayed black during boot in Linux. For our 7" display, the display shows a test image (red, blue, green, some patterns..) because the display had a clock but no data.
We were able to get the logo to display during Linux boot by making some changes, discussed below.
However, an issue remains; the display is shorty black during boot of Linux, or red in the case in one of the 7" display.
The changes we made are the following:
- set the bypass_reset property to 1 in the &ipu1 group in the dts.
- set late_init option to 1 in the &mxcfb1 group in the dts.
- Turn on the
- call the mxcfb_set_par function at the end of the mxcfb_register function in the drivers/video/fbdev/mxc/mxc_ipuv3_fb.c driver. This is done like so:
fbi->var.activate = (fbi->var.activate & ~FB_ACTIVATE_MASK) | FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
Please see the attached video for an impression (issue: display turns red for a short while, even though we call mxcfb_set_par).
We made some measurements on the scope and discovered a few things.
Here we put on the scope a gpio (blue), the display clock (purple), a data signal (yellow) and the display ready (green). We used a white splash screen (only 0xFF color). These signals are not lvds but after an lvds->rgb conversion chip. However this should not matter.
The gpio goes down in uboot, and up after mxcfb_set_par is called in the driver (discussed before).
We note that the display ready signal is not there, from somewhere during the boot of Linux until the call to mxcfb_set_par (no green block signal):
When we zoom in on the part just at mxcfb_set_par (gpio up) we see that the clock is interrupted for a bit. After some testing we found that this is due to mxcfb_set_par. (if we do not add mxfb_set_par this does not happen, but display is always black or in test mode)
We already spent quite a while debugging this problem. Any possible solution or information on what it could be would be greatly appreciated.
What we expect that happens is that some driver still resets some part of the video (ipu, ldb or framebuffer). This would explain why the display clock signal (green line) is down only in Linux, while it was up in UBoot.
Why is the mxcfb_set_par function required on the imx6 solo to make this patch work, and not on the imx6 quad?
Which drivers and what code is responsible for resetting the video hardware? Where to begin to investigate this?