[Matt Devo]

I don't want to go back to stock, but even if I did I would simply remove the screw again before flashing. But no, I was asking whether the new custom coreboot image actually needs write access to the flash during normal boot/runtime (excluding manually changing boot settings and configuration), and whether denying this privilege would cause problems. I would prefer to have the firmware read-only for security reasons.

the long answer is that the firmware needs write access to the coreboot filesystem (CBFS) on the first boot at least, in order to write the RAM training data (MRC cache). If our firmware supported saving settings on NVRAM it would need access to that as well, but it doesn't. Additionally, the write-protect screw only tells the SPI flash chip to enforce the software-defined address range. When flashing the Full ROM firmware that range is cleared, so for the WP screw to have any effect, you would need to re-define the range to protect (manually calculating the address for the MRC cache to exclude it) before reinstalling the screw. Without doing so, the WP screw is essentially useless.

Wait, so the E-Z setup script will now install the UEFI firmware by default? If so, I can easily use the script to update the firmware to UEFI without meddling with experimental images. I had the sensation that the script still used SeaBIOS, and the UEFI image was only in experimental stage.

yes and yes. UEFI has been the default for a few months now. The Legacy/SeaBIOS firmware ceased development back in Nov 2016 and I don't intend to resume it.

Forgive me, but I'm being a bit lax about the terms. I have no idea what ChromeOS does during its "verified boot" stage, but I was wondering whether I can achieve boot verification using a custom/updated firmware image, not the stock coreboot. Since Tianocore is UEFI, does that mean that the image supports Secure Boot or some other type of boot verification?

you can, but not with the firmware I provide. The UEFI firmware doesn't yet support secure boot, though you might be able to do something using grub.

Do you have any plans to push these changes to mainline?

I've pushed a large portion of them upstream already - in fact, the reason all (most) these devices are supported is because I ported them. The remaining patches that haven't yet been upstreamed are due to either being Windows/UEFI specific, a bit hacky, or due to lack of time.

Thanks, I'll have to play a bit with the settings to get my setup right. I recon I can even use a custom bootloader i.e. rEFInd instead of grub.

you could, but it's not necessary. All you need to do is copy the grub EFI stub to the location the firmware is expecting (/EFI/BOOT/BOOTX64.efi) as per the wiki note. rEFInd works well for multi-OS configs but adds an unnecessary delay for single-OS setups IMO.