(2017-03-18, 18:18)t2ffn Wrote: Used your script to set up a dual boot brand new Asus CN62 today. Thanks again Matt

(2017-03-20, 19:07)SandmanUT Wrote: Quick Q...can the chromebox (Asus moo4u) pass audio via the dp if using a dp to hdmi cable? The cable I have is rated for audio and a windows machine I have will pass audio over this cable, but the chromebox isn't. Is it a setting or driver that I missed or a hardware shortcoming?

It's on Peppermint 7, your script (in Legacy) and running two TVs, so both monitor ports are active.

(2017-03-20, 21:37)Matt Devo Wrote:

(2017-03-20, 19:07)SandmanUT Wrote: Quick Q...can the chromebox (Asus moo4u) pass audio via the dp if using a dp to hdmi cable? The cable I have is rated for audio and a windows machine I have will pass audio over this cable, but the chromebox isn't. Is it a setting or driver that I missed or a hardware shortcoming?

It's on Peppermint 7, your script (in Legacy) and running two TVs, so both monitor ports are active.

absolutely, but I'm unsure how Intel's driver handles things when you have two HDMI connections, or whether it's a PulseAudio config issue, or what. I assume audio is correctly output when only the DP->HDMI connection is used? This might be an issue best handled on Peppermint's or Intel's support forums

(2017-03-21, 19:42)BradD Wrote: Hi Matt, I am restoring a friends Asus Chromebox back to Chrome OS. I have done this successfully but I am still seeing the OS verification off screen on boot up. Does this mean I am still in developer mode? After the restore I reran the script and reset the GBB flags. Is there something I missed? I didn't have a back up of the original firmware so I had to download the install media.

• A lot of chromebox guides explain that in order to update the chromebox firmware you have to remove the FW write-protect screw. I assume this will only disable the flash chip write protection pin so the chip can be written to. My question is do I have to put the screw back after flashing new firmware? Any reason not to?
  
• Dear Mr. Matt Devo! I've seen that I can update my chromebox with a coreboot/SeaBIOS payload, but there is also progress on a Tianocore UEFI image (Source: https://mrchromebox.tech ). Can you perhaps explain what the advantages are for each image and suggest which one to go for?
  
• I've seen the stock coreboot firmware has enabled the verified boot for the ChromeOS. Can I achieve something similar by updating the firmware with either SeaBIOS or Tianocore coreboot image?
  
• If I want to compile the coreboot image myself, is this the correct address for the source code? What's the difference between this repository and the coreboot mainline git repository (review.coreboot.org)?
  

(2017-03-22, 15:52)Burnfire Wrote: A lot of chromebox guides explain that in order to update the chromebox firmware you have to remove the FW write-protect screw. I assume this will only disable the flash chip write protection pin so the chip can be written to. My question is do I have to put the screw back after flashing new firmware? Any reason not to?

Quote:Dear Mr. Matt Devo! I've seen that I can update my chromebox with a coreboot/SeaBIOS payload, but there is also progress on a Tianocore UEFI image (Source: https://mrchromebox.tech ). Can you perhaps explain what the advantages are for each image and suggest which one to go for?

Quote:I've seen the stock coreboot firmware has enabled the verified boot for the ChromeOS. Can I achieve something similar by updating the firmware with either SeaBIOS or Tianocore coreboot image?

Quote:If I want to compile the coreboot image myself, is this the correct address for the source code? What's the difference between this repository and the coreboot mainline git repository (review.coreboot.org)?

(2017-03-22, 22:28)Matt Devo Wrote: yes you must remove the WP screw to flash the firmware, no you don't want to put it back in, as it will just complicate things if you want to go back to stock later

(2017-03-22, 22:28)Matt Devo Wrote: The Legacy BIOS payload (SeaBIOS) is just that -- Legacy. Originally the firmware offered here used SeaBIOS, but once we had the UEFI firmware running as well/better, I switched to that. The legacy firmware is no longer updated and the UEFI firmware contains many fixes/tweaks not in the legacy firmware.

(2017-03-22, 22:28)Matt Devo Wrote: no, verified boot requires the use of the ChromeOS payload (depthcharge) and would require significant work to have it boot another OS, so I don't use it.

(2017-03-22, 22:28)Matt Devo Wrote: In terms of differences between my repos and the main/upstream ones, I have a large amount of tweaks/fixes etc on top of the upstream repos which are necessary to build or provide enhanced functionality.

(2017-03-22, 22:28)Matt Devo Wrote: All you need to do is follow the guide here, but install Mint instead of LibreELEC. Then post install, you'll likely need to "fix" the bootloader as described on the FAQ on my website. Otherwise, everything will work perfectly

(2017-03-23, 08:41)Burnfire Wrote: 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.

Quote: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.

Quote: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?

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

Quote: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.

(2017-03-23, 08:59)Matt Devo Wrote: 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.

(2017-03-23, 08:59)Matt Devo Wrote: 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.

(2017-03-23, 08:59)Matt Devo Wrote: 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.

(2017-03-23, 08:59)Matt Devo Wrote: 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.

(2017-03-23, 08:59)Matt Devo Wrote: 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.

(2017-03-23, 15:17)Burnfire Wrote: 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.

Quote: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*

Quote: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?

(2017-03-23, 22:44)Matt Devo Wrote: the flash chip is a Winbond W25Q64FV IIRC, but that datasheet won't help much, as the layout of the flash is largely dictated by the firmware itself. You never want 100% write protection with these kinds of systems as there is always some data which needs to be written. Even the stock firmware only write-protects a few small regions of the chip (teh details of which are on the firmware page of my website).

(2017-03-23, 22:44)Matt Devo Wrote: it's a perfectly viable option if building your own firmware for personal use, but less so if distributing general purpose firmware for others to use

(2017-03-23, 22:44)Matt Devo Wrote: if the OS normally installs grub (or whatever bootloader) to bootx64.efi, then it gets updated normally. If it nromally installs to (eg) /efi/ubuntu/grubx64.efi, then you would need to manually copy that, but IME that file itself isn't updated all that often since it's just a stub

(2017-03-24, 09:32)Burnfire Wrote: I'll play around a bit with those. By the way, which coreboot image of yours matches my device (Asus Chromebox CN60 - Celeron 2955U 1.4GHz)?
Is it this one: https://mrchromebox.tech/files/firmware/full_rom/coreboot_tiano-panther-mrchromebox_20170319.rom
If so, can I please have the coreboot .config (menu config) file for this image? Thanks!

Quote:Also, are you by any chance present in #coreboot on freenode IRC? Maybe we can talk live sometime. ^.^