Re: Google Embedded Controller blob - how does that get to the EC?

On Mon, Dec 18, 2023 at 1:21 PM James Feeney <[email protected]> wrote:

> On Sun, 2023-12-17 at 20:36 -0600, Matt DeVillier wrote:
> >
> > On Sun, Dec 17, 2023 at 7:37 PM James Feeney <[email protected]> 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/9f780d35a7bb029a27d96e44f7fe0797eecf5143
>
> 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/platform/ec/
> 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

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]