Artist: Jeff Rumans

Some low-level details:
At first I've noticed the display uses different registers, and that resolution changed to 900x600 (from 720x480) but I've assumed the rest of the code is similar to 80D (and all other D6 cameras).
[DIGIC6] at 0x00104B68 [0xD2018228] <- 0x310000 : BMP VRAM
[DIGIC6] at 0x00104B68 [0xD2018200] <- 0x2580384 : Display resolution
[DIGIC6] at 0x00104B68 [0xD2018230] <- 0x2580384 : Display resolution
The 80D requires the display buffer address to be shifted by 8, so I've assumed the 5D4 does the same. With this assumption, everything looked fine in QEMU; I couldn't get Canon's error screens, but I assumed they were not present in the firmware update.
I've also assumed the image had 8 bits per pixel and used a color palette (just like 80D).
Now, why does the first screenshot look like a broken error message?
First hint: that error message (a hardcoded image in ROM, copied to RAM) must be nearby.
Second hint: from the number of garbage lines and the horizontal shift, we can find out the position of the error message, and cross-check it with the values written by Canon code to BMP VRAM registers.
ML was setting the buffer to 0x44000000. Shifted by 8, it ended up as 0x440000.
Canon code could set the display buffer to either 0x310000 (Loading), 0x3B0000 (Not found) or 0x450000 (Error). The error screen from the first image must be at 0x450000. The camera started to display a few lines of garbage (from 0x440000 to 0x450000), then continued with the error image.
How many lines of garbage? floor(0x10000/900) = 72. Since the division is not exact, the image was also shifted by 0x10000 - 900*72 = 736 pixels.
Counting the pixels on the first screenshot gives about 73 lines of garbage and about 500 pixels of horizontal shift. The difference is pretty large in the horizontal direction.
Looking in QEMU log, near the display resolution there is a register that looks close to horizontal resolution:
[DIGIC6] at 0x00104B68 [0xD2018228] <- 0x310000 : BMP VRAM
[DIGIC6] at 0x00104B68 [0xD201822C] <- 0x3A0 : ???
[DIGIC6] at 0x00104B68 [0xD2018230] <- 0x2580384 : Display resolution
0x3A0 = 928, so that might be the BMP pitch. That is, the image in memory is a bit larger than the one actually displayed. Let's check the math: floor(0x10000/928) = 70, 0x10000 - 928*70 = 576. A little closer, right?
Turns out, this value was right

By doing this math, I had only one failed attempt, and that attempt was actually showing exactly
what I had to change.
(I now wonder why GregoryOfManhattan said the display test did not work at all a few weeks ago - from the current results, it should have at least turned on the backlight, and maybe also displayed some garbage)
The Firmware Jump didn't appear to do anything, which I imagine is intentional.
This one is not exactly good news, but I'll keep trying.