06-27-2021, 06:36 AM
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.
When the display driver in the kernel (called "rockchipdrm") loads, it resets the VOP and allocates a new area of RAM for it to use/display as a frame buffer while Linux is running, hence the weird green screen goes away and you start seeing the expected Linux console text and then graphical desktop.
It's probably harmless that the VOP isn't stopped by U-Boot when it hands control to the kernel and is still reading out from random kernel memory, though real problems can happen if the firmware leaves hardware *writing* into a memory area and doesn't tell the kernel about it, as that can corrupt kernel memory structures - for an example of this happening: https://mjg59.dreamwidth.org/11235.html
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.
When the display driver in the kernel (called "rockchipdrm") loads, it resets the VOP and allocates a new area of RAM for it to use/display as a frame buffer while Linux is running, hence the weird green screen goes away and you start seeing the expected Linux console text and then graphical desktop.
It's probably harmless that the VOP isn't stopped by U-Boot when it hands control to the kernel and is still reading out from random kernel memory, though real problems can happen if the firmware leaves hardware *writing* into a memory area and doesn't tell the kernel about it, as that can corrupt kernel memory structures - for an example of this happening: https://mjg59.dreamwidth.org/11235.html
