U-Boot, video console, and visual artifacts

[dsimic]

My apologies for the delayed response.

I did wonder if it had anything to do with the warning uboot displays about a bad CRC enviroment?

No, that message is just the result of having no U-Boot environment available, because it's never been saved.  The U-Boot environment contains some variables, e.g. they can be used to provide a "static" MAC address for the Ethernet interface.

I also thought it might be something to do with the splash screen so I disabled the boot splash screen (https://wiki.pine64.org/index.php/Pinebo...sh_picture)  so I just see the traditional text boot.  But when switching from uboot to the text, it still performs the full screen green screen effect. 

As a note, I've disabled the splash screen long time ago, and I'm also experiencing the same "plaid" visual artifacts.

Pretty sure this is the frame buffer being overwritten with other content when the kernel loads. In short, what happens is U-Boot allocates an area of RAM for it to write its pixel data into, and tells the VOP (video output processor, part of the SoC that handles display output) to read pixel data from that area and display the resulting image on screen. This is the "frame buffer".

While U-Boot is running, it knows that area is for writing data into to display on screen, and doesn't use it for anything else. But when U-Boot loads the kernel and starts it, it doesn't tell the kernel that the frame buffer memory area should be reserved or is special in any way. After control is passed to the kernel, the kernel thinks the frame buffer area is like any other free area of memory and starts using it to store data (e.g. structures related to kernel bookkeeping, or memory used by programs, etc). However the VOP was never told to stop displaying the contents of this area of memory on screen, so what you're seeing is random data structures being interpreted as pixel data and displayed on screen

I agree that the (mis)handling of the frame buffer, as you've described it, contributes to this issue.  However, there are two key points that clearly show that the framebuffer (mis)handling is not the only cause:

• These visual artifacts are also briefly visible upon powering on or rebooting the laptop, just before the U-Boot messages are displayed.  I.e., the artifacts are not visible only after the control over hardware is passed from U-Boot to the Linux kernel.
  
• The "plaid" pattern visible on the screen is simply too regular and symmetric to be caused by having essentially random data ("garbage") written to the framebuffer, "interpreted" and displayed back by the RK3399 VOP.
  

Based on my research and the way DRM driver in the Linux kernel handles the RK3399 VOP, VOP video outputs, the LCD screen and the LCD backlight, I'm pretty confident that the other causes of this issue are the following:

• Lack of synchronization between the display output and the displaying of the frames, which are handled by the VOP and the display, respectively
  
• The right order of the following operations/steps needs to be determined, in order to avoid different kinds of visual artifacts:
  • Powering up the LCD screen
    
  • Enabling the LCD screen
    
  • Powering up the LCD backlight
    
  • Configuring the LCD backlight
    
  • Configuring the VOP and the eDP video output
    
  • Enabling the eDP video output
    

Of course, the actual cause is the mix of all of the above, including the (mis)handling of the framebuffer.

I've spent more than a few days becoming familiar with the internals of U-Boot, the U-Boot driver model, etc.  As a result, I've implemented and tested out dozens of changes to the way U-Boot video console, including all of its hardware components, is initialized, turned on and off, etc.  Unfortunately, I haven't managed to isolate and eliminate the root cause of this issue (yet).