U boot console Patch#

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. 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. 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. Pretty sure this is the frame buffer being overwritten with other content when the kernel loads. These artifacts are probably caused by some mode switching and the old, gargabe contents of the framebuffer memory.īefore digging a bit deeper into this, I'd like to ask if anyone else sees the same visual artifacts? The attached pictures show the screen contents right after the kernel image is started, with the very start of the artifacts in the first picture and the 'fully developed' artifacts in the second. After the U-Boot messages are displayed and right after the kernel image is loaded and started, the same screen artifacts become visible again, this time much better and lasting for a bit longer. In the first couple of seconds after powering up the PineBook Pro, before any text is displayed, there are some weird screen artifacts that last for a split second. However, this new U-Boot feature isn't issue free.

U boot console Patch#

The support for the video console is currently in form of a patch, but the patch should be merged into one of the next releases of U-Boot. That's awesome and, for someone coming from the x86 world, makes the PineBook Pro feel much more like a 'real' computer that isn't silent early in the boot process. As probably already known, support for the PineBook Pro's video console has recently been included in the U-Boot packaged by Manjaro ARM.