Since my MrChromebox firmware does not use vboot, I have ported the EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection.
Well, there are over 100 files named "ramstage.c" in the github repository.
Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that?
It's not necessary to build your own EC-RW firmware or even update it unless there's a specific issue you're trying to resolve.
But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image?
And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?
On Sun, Dec 17, 2023 at 7:37 PM James Feeney james@nurealm.net wrote:
Since my MrChromebox firmware does not use vboot, I have ported the
EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection.
Well, there are over 100 files named "ramstage.c" in the github repository.
it's not in a file named ramstage; I was simply mentioning where it occurred in the boot process, which is different than in Google-built images
https://github.com/MrChromebox/coreboot/commit/9f780d35a7bb029a27d96e44f7fe0...
Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that?
completely. My tree has over 100 commits in addition to the upstream tag on which it is based. The addition of the EC firmware update is just one of many.
coreboot does not update the EC firmware, because it's a function of vboot and Google's payload (depthcharge).
It's not necessary to build your own EC-RW firmware or even update it
unless there's a specific issue you're trying to resolve.
But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image?
absolutely. If you're building from upstream coreboot, the RO EC firmware will be used. if building from my tree, then the RW firmware will be used (regardless if it is updated or not)
And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?
not necessarily. You'd need a version of flashrom which supports EC firmware updates (it's actually being removed / may have been removed), kernel permissions which allow it, an EC that's actually on the LPC bus (vs eSPI). And you wouldn't want to write the entire EC firmware as in the command above, you'd only want to update the RW portion. And you'd want to have a mechanism to not boot the RW firmware automatically in case your update failed, or in case it succeeded and the firmware was bad.
On Sun, 2023-12-17 at 20:36 -0600, Matt DeVillier wrote:
On Sun, Dec 17, 2023 at 7:37 PM James Feeney james@nurealm.net wrote:
Since my MrChromebox firmware does not use vboot, I have ported the EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection.
Well, there are over 100 files named "ramstage.c" in the github repository.
it's not in a file named ramstage; I was simply mentioning where it occurred in the boot process, which is different than in Google-built images
https://github.com/MrChromebox/coreboot/commit/9f780d35a7bb029a27d96e44f7fe0...
Thanks for that. This is such a "rabbit hole"!
Do I understand correctly that the MrChromebox firmware generated will have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that?
completely. My tree has over 100 commits in addition to the upstream tag on which it is based. The addition of the EC firmware update is just one of many.
coreboot does not update the EC firmware, because it's a function of vboot and Google's payload (depthcharge).
Then, I'm curious, why have all the chromebook changes not been merged to coreboot main?
Let's see if I understand:
To get the "latest and greatest" chromebook firmware, I should just use the MrChromebox repository, and not bother at all extracting blobs from the Google firmware images?
And, if I want to play with different payloads, I could still just change the payload, and leave everything else exactly the same?
It's not necessary to build your own EC-RW firmware or even update it unless there's a specific issue you're trying to resolve.
But still, to play-around with different payloads, using mostly stock coreboot, the EC firmware could just be completely left out of the coreboot ROM image?
absolutely. If you're building from upstream coreboot, the RO EC firmware will be used. if building from my tree, then the RW firmware will be used (regardless if it is updated or not)
What's the difference between the RO EC firmware and the RW EC firmware?
Hmm - Where the "implement EC software sync" patch, above, begins with "*If* an updated EC firmware image is present in CBFS," does that mean that the EC firmware image could be left-out and missing, and the EC software sync code would still behave and just skip the sync?
And, if I still needed to update the EC firmware, I could use the Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?
not necessarily. You'd need a version of flashrom which supports EC firmware updates (it's actually being removed / may have been removed), kernel permissions which allow it, an EC that's actually on the LPC bus (vs eSPI). And you wouldn't want to write the entire EC firmware as in the command above, you'd only want to update the RW portion. And you'd want to have a mechanism to not boot the RW firmware automatically in case your update failed, or in case it succeeded and the firmware was bad.
Uhm - I was referring to Google's fork of flashrom, https://chromium.googlesource.com/chromiumos/third_party/flashrom/ . Is that version being removed, or maybe disabled? I suppose that it is just as easy to re-flash the MrChromebook firmware if there were EC updates.
The "Flashrom @ Chromium.org" document seemed to suggest that the x86 chromebooks use the LPC bus for the EC, saying: "For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC." Is that not always true? I suppose that I could double check by trying a "read". The Google ChromeOS update still includes /usr/sbin/flashrom.
Hmm - I'm curious - only the RW section of the EC ever gets updated? Everything else is a backup? The chromeOS firmware update includes both a RO and a RW:
$ ./cbfstool ../../2023Dec01/images/ec-casta.ro-2-0-773.rw-2-0-890.bin layout -v -w This image contains the following sections that can be accessed with this tool:
'EC_RO' (read-only, size 196672, offset 0) 'FR_MAIN' (read-only, size 196608, offset 64) 'RO_FRID' (size 32, offset 388) 'FMAP' (read-only, size 350, offset 133824) 'WP_RO' (read-only, size 262144, offset 0) 'EC_RW' (read-only, size 196608, offset 262144) 'RW_FWID' (size 32, offset 262468)
https://chromeos.dev/en/posts/embedded-controller has:
Google recently decided to move the EC application over to a new RTOS provided by the Zephyr Project. ... With the switch to a Zephyr based EC, the public interfaces to the EC are unchanged.
But then, https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/plat... has:
The legacy EC implementation is used by all Chromebook reference designs prior to July 2021.
On Mon, Dec 18, 2023 at 1:21 PM James Feeney james@nurealm.net wrote:
On Sun, 2023-12-17 at 20:36 -0600, Matt DeVillier wrote:
On Sun, Dec 17, 2023 at 7:37 PM James Feeney james@nurealm.net wrote:
Since my MrChromebox firmware does not use vboot, I have ported the
EC-RW firmware update code from vboot to coreboot, and check if an EC-RW update is needed on each boot as part of EC init in ramstage. This code is in my tree on github for inspection.
Well, there are over 100 files named "ramstage.c" in the github
repository.
it's not in a file named ramstage; I was simply mentioning where it
occurred in the boot process, which is different than in Google-built images
https://github.com/MrChromebox/coreboot/commit/9f780d35a7bb029a27d96e44f7fe0...
Thanks for that. This is such a "rabbit hole"!
Do I understand correctly that the MrChromebox firmware generated will
have a custom ramstage, different from the stock coreboot ramstage, just to check if an EC-RW update is needed? Coreboot would not typically try to do that?
completely. My tree has over 100 commits in addition to the upstream tag
on which it is based. The addition of the EC firmware update is just one of many.
coreboot does not update the EC firmware, because it's a function of
vboot and Google's payload (depthcharge).
Then, I'm curious, why have all the chromebook changes not been merged to coreboot main?
because the code isn't quite robust enough, doesn't work well for some newer boards, some people feel it's the payload's job vs coreboot's -- a host of reasons
Let's see if I understand:
To get the "latest and greatest" chromebook firmware, I should just use the MrChromebox repository, and not bother at all extracting blobs from the Google firmware images?
IMO, yes
And, if I want to play with different payloads, I could still just change the payload, and leave everything else exactly the same?
yes.
It's not necessary to build your own EC-RW firmware or even update
it unless there's a specific issue you're trying to resolve.
But still, to play-around with different payloads, using mostly stock
coreboot, the EC firmware could just be completely left out of the coreboot ROM image?
absolutely. If you're building from upstream coreboot, the RO EC
firmware will be used. if building from my tree, then the RW firmware will be used (regardless if it is updated or not)
What's the difference between the RO EC firmware and the RW EC firmware?
read-only vs read-write. The latter is designed to be updated and the former is not.
Hmm - Where the "implement EC software sync" patch, above, begins with "*If* an updated EC firmware image is present in CBFS," does that mean that the EC firmware image could be left-out and missing, and the EC software sync code would still behave and just skip the sync?
yes, it's designed to only compare and update the ECRW firmware if there is an ECRW file and hash in cbfs.
And, if I still needed to update the EC firmware, I could use the
Google flashrom fork, as in the Google example, just: flashrom -p internal:bus=lpc -w ec.bin ?
not necessarily. You'd need a version of flashrom which supports EC
firmware updates (it's actually being removed / may have been removed), kernel permissions which allow it, an EC that's actually on the LPC bus (vs eSPI). And you wouldn't want to write the entire EC firmware as in the command above, you'd only want to update the RW portion. And you'd want to have a mechanism to not boot the RW firmware automatically in case your update failed, or in case it succeeded and the firmware was bad.
Uhm - I was referring to Google's fork of flashrom, https://chromium.googlesource.com/chromiumos/third_party/flashrom/ . Is that version being removed, or maybe disabled? I suppose that it is just as easy to re-flash the MrChromebook firmware if there were EC updates.
sorry, it's just certain EC-connected subtypes (like touchpad and fingerprint reader) that are being removed
The "Flashrom @ Chromium.org" document seemed to suggest that the x86 chromebooks use the LPC bus for the EC, saying: "For these examples, we assume the x86 firmware ROM is connected directly to the host via SPI and the EC ROM is connected via the EC to LPC." Is that not always true? I suppose that I could double check by trying a "read". The Google ChromeOS update still includes /usr/sbin/flashrom.
like I said, most newer EC's are connected via eSPI, not LPC
Hmm - I'm curious - only the RW section of the EC ever gets updated? Everything else is a backup? The chromeOS firmware update includes both a RO and a RW:
because the RO part is designed to be a read-only failsafe. if you update RO and it goes bad, you're fucked.
$ ./cbfstool ../../2023Dec01/images/ec-casta.ro-2-0-773.rw-2-0-890.bin layout -v -w This image contains the following sections that can be accessed with this tool:
'EC_RO' (read-only, size 196672, offset 0) 'FR_MAIN' (read-only, size 196608, offset 64) 'RO_FRID' (size 32, offset 388) 'FMAP' (read-only, size 350, offset 133824) 'WP_RO' (read-only, size 262144, offset 0) 'EC_RW' (read-only, size 196608, offset 262144) 'RW_FWID' (size 32, offset 262468)
https://chromeos.dev/en/posts/embedded-controller has:
Google recently decided to move the EC application over to a new RTOS provided by the Zephyr Project. ... With the switch to a Zephyr based EC, the public interfaces to the EC are unchanged.
But then, https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/plat... has:
The legacy EC implementation is used by all Chromebook reference designs prior to July 2021.
Zephyr is a codebase change, it doesn't change the flash layout or update mechanism
-
James Feeney -
Matt DeVillier