Add google kano flashing guide by cwiggs · Pull Request #223 · linuxboot/heads-wiki

cwiggs · 2026-07-22T21:22:05Z

preview: https://cwiggs.github.io/heads-wiki/

tlaurion · 2026-07-22T21:34:44Z

+TODO: Do we need to run `gsctool` from ChromeOS?  I did not have to but maybe the previous owner of my Kano
+device did it?  [source](https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#step-1-enabling-closed-case-debugging-ccd)
+
+Now we disable software write protection:


@MrChromebox this is weird and we don't understand.

Even if IFD has all regions disabled per linuxboot/heads#2133 's linuxboot/heads@aece972

Found Master Section FLMSTR1: 0xffffffff (Host CPU/BIOS) EC Region Write Access: enabled Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled EC Region Read Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled FLMSTR2: 0xffffffff (Intel ME) EC Region Write Access: enabled Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled EC Region Read Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled FLMSTR3: 0xffffffff (GbE) EC Region Write Access: enabled Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled EC Region Read Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled FLMSTR5: 0xffffffff (EC) EC Region Write Access: enabled Platform Data Region Write Access: enabled GbE Region Write Access: enabled Intel ME Region Write Access: enabled Host CPU/BIOS Region Write Access: enabled Flash Descriptor Write Access: enabled EC Region Read Access: enabled Platform Data Region Read Access: enabled GbE Region Read Access: enabled Intel ME Region Read Access: enabled Host CPU/BIOS Region Read Access: enabled Flash Descriptor Read Access: enabled

Heads flashprog -p internal still reports:

flashprog unknown on Linux 6.6.30-Heads (x86_64) flashprog is free software, get the source code at https://flashprog.org Calibrating delay loop... OK. coreboot table found at 0x76883000. Found chipset "Intel Alder Lake-P". Enabling flash write... GPR0: Warning: 0x00001000-0x001a6fff is read-only. At least some flash regions are write protected. For write operations, you should use a flash layout and include only writable regions. See manpage for more details. OK. Found Programmer flash chip "Opaque flash chip" (32768 kB, Programmer-specific) on internal. No operations were specified.

Also Heads recovery shell cbmem --console | grep '[DEBUG] ME' returns:

[DEBUG] ME: HFSTS1 : 0x90000055 [DEBUG] ME: HFSTS2 : 0x82130116 [DEBUG] ME: HFSTS3 : 0x00000050 [DEBUG] ME: HFSTS4 : 0x00004000 [DEBUG] ME: HFSTS5 : 0x00000000 [DEBUG] ME: HFSTS6 : 0x40600006 [DEBUG] ME: Manufacturing Mode : YES [DEBUG] ME: SPI Protection Mode Enabled : NO [DEBUG] ME: FW Partition Table : OK [DEBUG] ME: Bringup Loader Failure : NO [DEBUG] ME: Firmware Init Complete : NO [DEBUG] ME: Boot Options Present : NO [DEBUG] ME: Update In Progress : NO [DEBUG] ME: D0i3 Support : YES [DEBUG] ME: Low Power State Enabled : NO [DEBUG] ME: CPU Replaced : YES [DEBUG] ME: CPU Replacement Valid : YES [DEBUG] ME: Current Working State : 5 [DEBUG] ME: Current Operation State : 1 [DEBUG] ME: Current Operation Mode : 0 [DEBUG] ME: Error Code : 0 [DEBUG] ME: FPFs Committed : YES [DEBUG] ME: Enhanced Debug Mode : NO [DEBUG] ME: CPU Debug Disabled : YES [DEBUG] ME: TXT Support : NO [DEBUG] ME: Manufacturing Vars Locked : YES [DEBUG] ME: WP for RO is enabled : YES [DEBUG] ME: RO write protection scope - Start=0x1000, End=0x1A6FFF

So ME region still protected.

[DEBUG] ME: WP for RO is enabled : YES
[DEBUG] ME: RO write protection scope - Start=0x1000, End=0x1A6FFF

tlaurion

@MrChromebox we need some help figuring out what steps are needed to properly disactivate HW+SW protection so ME is not reported as locked

tlaurion · 2026-08-08T01:06:15Z

@cwiggs any updates?

cwiggs · 2026-09-01T16:00:11Z

No updates, haven't heard anything from MrChromebox. I just made this post: https://forum.chrultrabook.com/t/better-understanding-of-firmeware-write-protection/9084 hopefully it helps gain some traction?

MrChromebox · 2026-09-01T17:00:29Z

not sure the confusion here. On a factory clean device:

disable WP WP via SuzyQ
disable software WP via flashrom
unlock IFD, flash via SuzyQ

same as any other device which ships with a locked IFD - I assume. I do not have a MTL Chromebook (or any MTL device). Users wishing to run my firmware just need to disable HW WP via SuzyQ and my script does the rest. I don't touch the IFD or ME.

cwiggs · 2026-09-01T17:12:31Z

not sure the confusion here. On a factory clean device:
* disable WP WP via SuzyQ

Was this meant to say "disable HW WP via SuzyQ?

To do this would that be following the steps 1 and 2 here: https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#using-closed-case-debugging-ccd-using-a-suzyqable

* disable software WP via flashrom

2 questions:

Do you do that by following this guide: https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#disabling-software-write-protection
Can you use a SuzyQ from another computer to do this or should it be done from the device we are trying to flash (the Kano device)?

* unlock IFD, flash via SuzyQ

I don't remember doing this but I could be wrong. What is the process to unlock IFD?

same as any other device which ships with a locked IFD - I assume. I do not have a MTL Chromebook (or any MTL device). Users wishing to run my firmware just need to disable HW WP via SuzyQ and my script does the rest. I don't touch the IFD or ME.

MrChromebox · 2026-09-01T17:40:04Z

Was this meant to say "disable HW WP via SuzyQ?

yes

https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#using-closed-case-debugging-ccd-using-a-suzyqable

for a factory fresh device, yes. For the case you asked about on the chrultrabook forums where the device is already flashed, no

Do you do that by following this guide:

on a factory fresh device, yes. On a device that's already flashed, it's already been done. Doesn't hurt to verify with --wp-status

Can you use a SuzyQ from another computer to do this or should it be done from the device we are trying to flash (the Kano device)?

Yes. Connect the SuzyQ, open a terminal to ttyUSB0, verify WP off, verify factory reset, etc.

I don't remember doing this but I could be wrong. What is the process to unlock IFD?

I have no idea what has or has not been done to your device. Unlocking the IFD requires external flashing. It's not something that flashing MrChromebox firmware requires (or recommends). What exactly are you needing to do that requires the IFD/ME areas be writable from a live system?

Unlocking the IFD, at a high level, is:

reading flash with external programmer
using ifdtool to unlock the entire flash (-u) / clear the protected flags from the IFD/ME regions
flashing the IFD back to the chip with an external programmer

HEADS has documentation on doing this. it's out of scope for MrChromebox firmware.

cwiggs · 2026-09-01T18:29:20Z

Yes. Connect the SuzyQ, open a terminal to ttyUSB0, verify WP off, verify factory reset, etc.

Would that command be?:

flashrom --programmer raiden_debug_spi:target=AP,custom_rst=True \
  --chip "W25Q256JV_M" \
  --wp-status

flashrom --programmer raiden_debug_spi:target=AP,custom_rst=True \
  --chip "W25Q256JV_M" \
  --wp-enable

flashrom --programmer raiden_debug_spi:target=AP,custom_rst=True \
  --chip "W25Q256JV_M" \
  --wp-range 0,0

What exactly are you needing to do that requires the IFD/ME areas be writable from a live system?
I'll let @tlaurion respond, I'm not 100% sure on this one.

MrChromebox · 2026-09-01T19:54:50Z

@cwiggs LGTM other than --enable vs --disable

but again, I would check with --wp-status first, so you know what the current state is

tlaurion · 2026-09-02T16:11:38Z

GPR0 was active in ifd, I think i fixed it under linuxboot/heads#2133 (comment)

I'm not sure I still have a complete grasp of the steps needed.
As of today linuxboot/heads#2133, HAP is set in post processing of coreboot rom build; where GRP0 is deactivated (IFD unlocked)

MrChromebox · 2026-09-02T17:55:38Z

GPR0 was active in ifd, I think i fixed it under linuxboot/heads#2133 (comment)

I'm not sure I still have a complete grasp of the steps needed. As of today linuxboot/heads#2133, HAP is set in post processing of coreboot rom build; where GRP0 is deactivated.

why do you need to modify the ME region? isn't Kano already using CSME-lite?

tlaurion · 2026-09-02T18:22:30Z

GPR0 was active in ifd, I think i fixed it under linuxboot/heads#2133 (comment)
I'm not sure I still have a complete grasp of the steps needed. As of today linuxboot/heads#2133, HAP is set in post processing of coreboot rom build; where GRP0 is deactivated.

why do you need to modify the ME region? isn't Kano already using CSME-lite?

@MrChromebox

per https://github.com/cwiggs/heads/blob/deb24578d44b3edb724728725daaed6a9d651ed2/config/coreboot-kano.config_defconfig

CONFIG_ME_BIN_PATH="3rdparty/blobs/mainboard/google/brya/brya/kano/me.bin"

AFAIK, those blobs could be updated in coreboot blobs repo.

user@debian-13:~/heads-kano/build/x86/coreboot-mrchromebox-26.03/3rdparty/blobs/mainboard/google/brya/brya/kano$ git log me.bin
commit 3f41ecae0f63aa4058eeb20cecf21db96abc33b1
Author: Matt DeVillier <matt.devillier@gmail.com>
Date:   Tue Aug 15 17:30:17 2023 -0500

    mb/google/brya: reorganize blobs by baseboard; add nissa blobs
    
    Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>

If blob changed/updated in the future, if Heads doesn't provide RW access to it and doesn't provide a way to update it per board config (ie --ifd -i me), then end user would be left with an old version of it flashed externally.

Under Heads, we apply HAP for now to the point it will cause regression (see linuxboot/heads#1801 : Meteor Lake last platform to support S3 allegedly: still function in practice but not supported by Intel).

Same for ME+IFD writeable so we can flash whole SPI internally, and rely on PR0 to apply chipset locking before kexec call.

That's also why I ask coreboot dev to push for https://review.coreboot.org/c/coreboot/+/85278 which for now is applied per fork as patches under Heads (We had that debate personally in the past @MrChromebox : it was showed possible to apply to Skylake+ and should be merged upstream).

TLDR:

Heads apply HAP bit to ME if ME cannot be reduced (maximized in board name when reduced + space given back to IFD's BIOS region, trickling down to CBFS with current limitation to CBFS being 16m because otherwise, limited by Support >16MB SPI chips (fast_SPI support) osresearch/flashtools#10)
ME in RW mode for all boards to be able to change it if we change approach later on, if there is a way to remove parts and not only rely on HAP if cannot be neutered
PR0 is applied before kexec to apply chipset lockdown and put SPI in RO per https://review.coreboot.org/c/coreboot/+/85278
IFD is unlocked under Heads, so that if for whatever reason we need to change config of either regions defined, we can do it.
Current status quo is defined under main repo at https://github.com/linuxboot/heads/blob/master/doc/wp-notes.md

MrChromebox · 2026-09-02T20:17:55Z

PR0 is applied before kexec to apply chipset lockdown and put SPI in RO per https://review.coreboot.org/c/coreboot/+/85278

updated

Signed-off-by: Chris Wiggins <chris@cwiggs.com>

cwiggs · 2026-09-02T21:23:29Z

Updated the guide with what I think is the proper approach now that I got confirmation that we don't need to remove the battery. I think I now understand hardware vs software write protection better.

@MrChromebox Can you expand on why https://forum.chrultrabook.com/t/flashrom-error-when-trying-to-unbrick-with-suzyq/8789/2?u=stonework5729 is needed for Kano?

MrChromebox · 2026-09-02T21:47:23Z

@MrChromebox Can you expand on why https://forum.chrultrabook.com/t/flashrom-error-when-trying-to-unbrick-with-suzyq/8789/2?u=stonework5729 is needed for Kano?

not really, I don't have access to Google's documentation on why that's needed for (some? all?) Brya-based devices, I just know that it is.

Cleanup a lot of the doc and add a backup section. Signed-off-by: Chris Wiggins <chris@cwiggs.com>

cwiggs · 2026-09-03T04:54:27Z

@MrChromebox Can you expand on why https://forum.chrultrabook.com/t/flashrom-error-when-trying-to-unbrick-with-suzyq/8789/2?u=stonework5729 is needed for Kano?

not really, I don't have access to Google's documentation on why that's needed for (some? all?) Brya-based devices, I just know that it is.

Understood. Thanks for the info!

I pushed some more changes cleaning up some the doc and I added a section on how to backup the rom.

Marked the PR as ready for review.

cwiggs marked this pull request as draft July 22, 2026 21:22

tlaurion reviewed Jul 22, 2026

View reviewed changes

cwiggs mentioned this pull request Sep 1, 2026

Add Google kano (MrChromebox 26.03 coreboot fork) support - First full Chromebook port! linuxboot/heads#2133

Open

20 tasks

Add google kano flashing guide

0a1e712

Signed-off-by: Chris Wiggins <chris@cwiggs.com>

cwiggs force-pushed the device-kano branch from 03a4eb4 to 0a1e712 Compare September 2, 2026 21:22

Cleanup and backup section

0dc6d86

Cleanup a lot of the doc and add a backup section. Signed-off-by: Chris Wiggins <chris@cwiggs.com>

cwiggs marked this pull request as ready for review September 3, 2026 04:53

Uh oh!

Uh oh!

Conversation

cwiggs commented Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tlaurion Jul 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tlaurion Jul 22, 2026

Choose a reason for hiding this comment

Uh oh!

tlaurion left a comment

Choose a reason for hiding this comment

Uh oh!

tlaurion commented Aug 8, 2026

Uh oh!

cwiggs commented Sep 1, 2026

Uh oh!

MrChromebox commented Sep 1, 2026

Uh oh!

cwiggs commented Sep 1, 2026

Uh oh!

MrChromebox commented Sep 1, 2026

Uh oh!

cwiggs commented Sep 1, 2026

Uh oh!

MrChromebox commented Sep 1, 2026

Uh oh!

tlaurion commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrChromebox commented Sep 2, 2026

Uh oh!

tlaurion commented Sep 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MrChromebox commented Sep 2, 2026

Uh oh!

cwiggs commented Sep 2, 2026

Uh oh!

MrChromebox commented Sep 2, 2026

Uh oh!

cwiggs commented Sep 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

cwiggs commented Jul 22, 2026 •

edited

Loading

tlaurion Jul 22, 2026 •

edited

Loading

tlaurion commented Sep 2, 2026 •

edited

Loading

tlaurion commented Sep 2, 2026 •

edited

Loading