I am in the process of getting the u-boot bootsplash working with an LCD, using the following primarily as a guide:
http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/220648.aspx
I got the LCD to show the image and it looks good all the way through boot until I load the firmware (as expected). However, right at device power-up the image scrolls both vertically and horizontally for 1-2 seconds before locking. Once the image stops scrolling, it works fine from that point forward.
I went after the usual suspects thinking this was some problem with a misconfigured hsync/vsync, some LCD initialization issue, unstable pixel clock, wrong front/backporch settings, but everything looked good on the oscilloscope.
As a test, I created the following image and loaded it up as a boot logo:
Bear in mind due to the orientation of the LCD, the image essentially has a ten pixel red line down the left hand side of the image. The line is exactly ten pixels in width, and I offset it ten pixels from the left. The idea behind creating this image was that it would allow me to put a scope on one of the red pixel traces going to the LCD, and measure the time from hsync to the red pixel.
The following image shows the timing when it's working correctly:
This shows the correct behavior in high resolution. Channel 1 (yellow) is VSYNC, channel 2 (blue) is HSYNC, channel 3 (purple) is pixel clock, and channel 4 (green) is one of the red pixel lines. You can see the ten red pixels (where the green channel is high), and it's offset from the hsync by ten pixels plus the back porch. Looks good.
Now look at the following:
This shows that the start of the pixels is 82 nanoseconds after the end of the hsync pulse, which makes sense since it's all the way to the left. If you look closely at the top view for the leftmost five hsyncs, you can see green pulses right
after each hsync pulse.
Finally, look at the following:
This capture was taken during the scrolling at power-up (note good_redline.jpg and bad_redline.jpg are at the same capture window size). You can see that the distance from the hsync pulse to the start of the ten red pixels is 13.8 us,
almost halfway into the horizontal line.
So what does this tell us? We had originally assumed we were putting out a consistent signal throughout the boot process, and that the LCD was having problems interpreting it due to some condition such as incorrect LCD initialization, unstable clocking, jitter, incorrect pulse width, wrong front/back porch settings, power ramping, etc.
However we didn't see anything wrong with the various control signals - they all look well-formed and constant.
Now that we're able to see the actual pixel *data* though, we can see that the firmware in the M3 core despite putting out properly timed control signals (pixel/hsync/vsync), it's actually putting out video with the incorrect horizontal offset. The LCD panel is correctly rendering what the device is putting out. And if you wait a second or two, the output of the M3 becomes correct (for no apparent reason).
In short, it's not that the video output was putting out slightly wrong data and the LCD eventually syncs up. The video output is actually putting out wrong data and for reasons unknown it stops doing such and starts putting out the correct data.
The LCD we're testing with is an NEC model NL4864HL11-01B, a 480x640 display with a pixel clock at 19.6MHz.
A few other interesting observations:
1. The scrolling behavior changes if I change the pixel clock rate. In all cases the actual pixel clock as measured by the scope matches the rate I specified in u-boot, so it's not clear to me what other adverse side effects the pixel clock rate may be having on the M3 core.
2. I can cause the behavior to happen more often by putting usleep() calls at various points in the u-boot initialization after the M3 firmware is loaded. This shouldn't actually have any effect given the M3 core is independent of the ARM core, yet it does.
3. I can tell the ARM CPU to sleep completely (call usleep() in a loop), and the scrolling still goes away on its own. In other words, it appears that the ARM CPU is not specifically doing anything to cause the video to stop scrolling, given the problem goes away even when the ARM CPU is spinning in a loop doing nothing.
Please advise.
Thanks,
Devin
