[Burnfire]

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.

Okay, this information is new to me. I was under the impression that by activating the screw and therefore the SPI flash chip write-protect pin you would get a full 100% hardware write protection. Do you perhaps know which flash chip is in use by an Asus Chromebox CN60 so I can check the datasheet? Thanks.

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.

Thanks, then I'll just use the E-Z script to do the firmware update and install linux manually.

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.

I'll stick with Tianocore image for now, but I've heard people in #coreboot on Freenode mention that there were some patches available for GRUB2 to implement boot verification, however you'd need to use GRUB2 as the coreboot payload to do so. I don't know how well this is supported on a chromebox, but I will try to experiment once I get more into coreboot. *bbl*

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.

Great, and thank you very much for your work!

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.

I'll try it out. By the way, do you know what happens when grub receives an update via the sysupgrade option i.e. by running "apt-get dist-upgrade"? Is there a mechanism that automatically updates the BOOTX64.efi file or do I have to copy and overwrite the file manually each time?


Thanks for the info!