[t2ffn]

Used your script to set up a dual boot brand new Asus CN62 today. Thanks again Matt

[Matt Devo]

Used your script to set up a dual boot brand new Asus CN62 today. Thanks again Matt

[emoji106]

[SandmanUT]

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.

[Matt Devo]

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

[SandmanUT]

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

Cool. Just wanted to start on the bottom rung and work my way out. If it works in ANY configuration on this machine, then it's fixable, so I will pursue.

[BradD]

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.

[Matt Devo]

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.

yes, you're still in Developer Mode, simply press the spacebar on that screen and confirm when prompted. that's the last step to return to stock

[Burnfire]

Greetings, I'll drop in here.

I have a brand new Asus Chromebox I'd like to use for Kodi and some other things. I originally wanted to use LibreELEC, but instead I decided to go for a full linux distro since I'll be using the device for some other things that LibreELEC doesn't support. Anyway, I plan to remove the existing ChromeOS and use Linux Mint as the only OS (single-boot). There are a number of guides online that suggest to use this E-Z setup script, but the thing doesn't quite do what I want so I'll have to perform some steps manually. Anyway, I have a bunch of related questions since some of the steps are similar to those in the E-Z setup script.

• 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)?
  

Thanks in advance!

[Matt Devo]

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?

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

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?

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.

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?

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.

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)?

that's the correct address for coreboot, but you also need the payload to go with it (SeaBIOS or Tianocore) but my repos for those are also located on my github. Building your own firmware isn't easy/straightforward but if you're going to do so, then using my scripts/repos is the way to go. 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. When looking at the commit history for my repos, my commits are always on top so it's easy to see what I've added

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

[Burnfire]

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

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

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.

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.

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?

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.

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

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

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.

Cheers!

[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.

[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!

[Matt Devo]

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.

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).

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*

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

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?

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

[Burnfire]

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).

Nice to know. I always believed the WP pin would block 100% of writes, but apparently I was wrong.

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

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/...170319.rom
If so, can I please have the coreboot .config (menu config) file for this image? Thanks!

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

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

Interesting, I'll definitely check this out next time I setup an UEFI system. Thanks for the info though.

Sincerely.

[Matt Devo]

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/...170319.rom
If so, can I please have the coreboot .config (menu config) file for this image? Thanks!

the Asus CN60's board/device name is indeed 'panther,' and that is the current UEFI firmware link as of this post (but subject to change at any time)
the config used to build is always embedded in the firmware image and can be extracted using cbfstool (in coreboot repo utils). It's also in my github repo:
https://github.com/MattDevo/coreboot/blo...nther.uefi

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

I'm MrChromebox on #coreboot, just ping me and I should get notice.