https://bugzilla.kernel.org/show_bug.cgi?id=215001
--- Comment #2 from Artem S. Tashkinov (aros@gmx.com) --- CC'ing the relevant mailing list.
A regression in kernel 5.15 causes FB_VGA16 (vga16fb) to fail to detect that it has been passed a firmware-initialized graphics bitmap instead of a character-mapped 80x25 display. It takes ownership of the console, instead of passing control to FB_EFI, FB_VESA, FB_SIMPLE and so on. This results in writing ASCII bytes into the RGB bitmap, with random bits appearing in the first few scanlines of the screen. (The remainder of the screen is untouched, e.g. Grub's window saying it is loading the Linux kernel.)
Once udevd loads the appropriate modesetting driver (in my case, amdgpu), the graphics screen is (re)initialized properly and becomes usable.
Kernel config options CONFIG_SYSFB_SIMPLEFB, CONFIG_FB_SIMPLE, CONFIG_FB_EFI, and CONFIG_FB_VESA had no effect when toggled on and off.
Workaround: Disabling CONFIG_FB_VGA16 blocks vga16fb from grabbing the console, allowing the EFI framebuffer to properly take ownership of the console.
This bug is a duplicate of #214603. Credit goes to that reporter for disabling FB_VGA16 as a workaround. I would have updated that report rather than file a duplicate, except that #214603 does not have its metadata (product, component, version, regression, or even its summary fields) set correctly. Hopefully this new report will be seen by the correct maintainers.