I just wanted to inform you (because Purism didn’t publicly stated it until now) that you should update coreboot to the newest revision to get rid of another blob.
See: https://source.puri.sm/coreboot/releases/blob/master/changelog.md
“All devices now using coreboot native graphics init (libgfxinit) for display init, eliminating the use of the VGA BIOS blob”
that update was pushed literally less than 24h ago. I just haven’t finished the blog post yet detailing our recent updates for both coreboot and PureBoot 
Credit to Burt Bacharach:
Beware of The Blob, it creeps
And leaps and glides and slides
Across the floor
Right through the door
And all around the wall
A splotch, a blotch
Be careful of The Blob
NO TRANSPARENCY, YOU’RE TOO SLOW!
PURISM IS LYING!
/r/purism
(just kidding )
That’s more for r/purismRelatedDrama than r/purism (yeah, it exists!)…
Should be two letter o’s in your “to”.
(I see it was edited to fix, this may be ignored.)
Hopefully your post will be reflected in the freedom roadmap as well
It just seems to get better every day, absolutely loving it!
And here is the blogpost 
I installed that update on my Librem 13v3 and now the GRUB2 resolution became really super small (like 640x400).
I went into command line mode on GRUB and ran videomode command which confirmed that no other mode could be set (nothing higher than some 844x400).
Could it be that I missed something ? I run Debian Buster and used the usual coreboot script shipped by purism.
I am slightly out of my waters on this one, but I suspect that GRUB needs to be reinstalled due to some assumptions made regarding the BIOS at the time of the initial installation no longer holding for the new coreboot graphics drivers. My Librem 13 v4 running NixOS could not get past GRUB with the latest coreboot and I had to downgrade to 4.9-Purism-2 for now, but I will look into this further once I find the time as I doubt it will be that difficult of a fix.
@ninjin Actually I already run grub-coreboot, should I still reinstall it?
Output is as follow:
ii grub-common 2.02+dfsg1-20 amd64 GRand Unified Bootloader (common files)
ii grub-coreboot 2.02+dfsg1-20 amd64 GRand Unified Bootloader, version 2 (Coreboot version)
ii grub-coreboot-bin 2.02+dfsg1-20 amd64 GRand Unified Bootloader, version 2 (Coreboot modules)
ii grub2-common 2.02+dfsg1-20 amd64 GRand Unified Bootloader (common files for version 2)
ii grub2-splashimages 1.0.1+nmu1 all a collection of great GRUB2 splashimages
Flash it a couple of days ago, screen is not blinking anymore everything is working perfect.
Thank you!
you’re not missing anything, this is working as intended.
With the new (blob-free) native video init, coreboot sets the framebuffer resolution when initializing the panel, and that resolution is used (by SeaBIOS, by grub, etc) until the kernel i915 driver is loaded and re-inits the screen.
Previously, with the VBIOS blob, it would remain resident in memory, and SeaBIOS/grub etc could call to it and set the video mode (within the range of supported options). SeaBIOS would init the screen in VGA text mode (640x400), then switch to a VESA mode to show the bootsplash (1280x1024, highest available), then back to text mode to show the boot menu. Likewise, grub could change/set the video mode depending on its configuration.
Now, since we’re stuck with a single resolution, I chose to use 848x480 – which maintains the panel’s 16x9 aspect ratio, and keeps the SeaBIOS/grub text at a readable size. This has the effect of lowering the quality of the splash screen, and if grub assumes VGA text mode, results in the grub menu being in the upper left 640x400 portion of the 848x480 display.
Does it help to set a value for GRUB_GFXMODE in /etc/default/grub
just for giggles: kernel-boot-parameter console=null is supposed to work with systemd , but actually does not one some machines: either hangs or does not fully shut down. so that is a test case for the VGA BIOS blob removal. Even Mr Pöttering was puzzled initially… Wanna try it and report? I’m collecting it for the github issue.
Have you tried settng GRUB_GFXMODE ? Anyone ?
No success I am afraid, both 4.9-Purism-2 and 4.11-Purism-1 failed at the GRUB to OS hand over. I really want to steal some cycles to explore this further to see if it will resolve some issues I am having with an external monitor.
that’s completely unrelated to firmware I suspect, and to the display init since those versions use two different methods
Just tried upgrading to the newest version and had to revert back to 4.9-Purism-2 as it failed at the grub screen for me as well 
I’m running debian testing. Also, would it make any difference if grub-pc was installed or not ?