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

cwiggs · 2026-06-24T02:59:12Z

This pull request adds support for the Acer Chromebook Spin 714 ("kano") board based on the MrChromebox coreboot fork (26.06), including CI integration, configuration files, and documentation updates. It also introduces a patch for musl compatibility in the MrChromebox fork, adds a new Linux kernel version (6.6.30), and documents TPM2 CR50 command support. The most important changes are grouped below:

Kano (Acer Chromebook Spin 714) board support:

Adds boards/kano/kano.config for Heads and Linux build configuration for the kano board.
Adds config/coreboot-kano.config_defconfig as a defconfig backup for kano, documenting non-default coreboot options.
Integrates kano into CircleCI: adds coreboot-mrchromebox as a seed, defines the kano build job, and documents its workflow. [1] [2] [3]
Documents kano's handling of the RTC century byte and why USE_PC_CMOS_ALTCENTURY must be unset for this board. [1] [2] [3]

MrChromebox coreboot fork integration:

Adds the MrChromebox coreboot fork (26.03) as a supported module in modules/coreboot, with commit hash pinning and submodule handling notes. [1] [2]
Documents and implements post-build application of the ME HAP bit for MrChromebox-based boards (e.g., kano) via ifdtool. [1] [2]

Build system and kernel updates:

Adds Linux kernel version 6.6.30 support for use by kano and other boards. [1] [2]
Adds a musl compatibility patch for MrChromebox coreboot's cbmem utility.

Documentation improvements:

Documents how to clone the repository with full history and repair shallow clones for reproducible builds.
Adds a section on CR50 TPM command limitations and Heads TPM2 command compatibility.
Expands documentation on defconfig backups for Chromebook boards and Heads-common coreboot options. [1] [2] [3]

Minor adjustments:

Updates the list of boards with specific coreboot options and clarifies configuration for Purism and QEMU boards. [1] [2]

These changes collectively enable official Heads support for the Acer Chromebook Spin 714 (kano), ensure compatibility with the MrChromebox fork, and improve build reproducibility and documentation for new contributors.

(copilot generalized pr summary, asked by @tlaurion)

TODO before merge

Additional actionable items:

Confirm/infirm initrd/bin/kexec-save-default.sh: skip symlinks when finding crypttabfiles #2155 needed to boot NixOS
Any impact from ME being HAP disabled??
doc/BOARDS_AND_TESTERS.md needs addition of the board and your name added there before merging
Create HTOP build for Kano.

tlaurion

first review as I was there and saw work on this PR :)

tlaurion · 2026-06-24T03:17:39Z

I suggest you tart a thread under Matrix Heads channel. You must rebase the old PR on linuxboot/heads master, an dthen adapt coreboot config to your board. Following https://osresearch.net/Porting/ @cwiggs otherwise your experience might be really frustrating.

cwiggs · 2026-06-24T04:01:51Z

I suggest you tart a thread under Matrix Heads channel. You must rebase the old PR on linuxboot/heads master, an dthen adapt coreboot config to your board. Following https://osresearch.net/Porting/ @cwiggs otherwise your experience might be really frustrating.

Started a thread here: https://matrix.to/#/!eMLMv62wAMCW1V-ufL_bJ_JDngDhrpSOSEQBLzX8aTg/$eepAush4kVo93Zxqtw59P6NX9g6AG7FZFplc2Fu6tyo?via=matrix.org&via=tchncs.de&via=unredacted.org

tlaurion · 2026-06-24T15:56:53Z

@cwiggs I saw you left the room?

cwiggs · 2026-06-24T16:38:26Z

@cwiggs I saw you left the room?

Looks like the Matrix homeserver decided to delete my account for some reason, I'll look into getting it reactivated.

tlaurion · 2026-06-25T19:00:06Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

cwiggs · 2026-06-26T02:37:13Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

tlaurion · 2026-06-26T17:14:31Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

Absolutely. It builds from CI. I pushed progress forward since the last base (coreboot 4.22) was old and not trivial to adapt. Let me know how the testing goes. Feel free to cherry pick all commits or if you agree i can push the changes here but that would make us both co-authors of the port.

CircleCI builds at https://app.circleci.com/pipelines/github/tlaurion/heads/4040/workflows/d7699b2f-feca-423f-b0f5-187ebf94e886

tlaurion · 2026-06-26T21:04:38Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

Absolutely. It builds from CI. I pushed progress forward since the last base (coreboot 4.22) was old and not trivial to adapt. Let me know how the testing goes. Feel free to cherry pick all commits or if you agree i can push the changes here but that would make us both co-authors of the port.

CircleCI builds at https://app.circleci.com/pipelines/github/tlaurion/heads/4040/workflows/d7699b2f-feca-423f-b0f5-187ebf94e886

https://output.circle-artifacts.com/output/job/6e1574dc-9faa-487d-8bfe-1b108383a89a/artifacts/0/build/x86/kano/heads-kano-20260626-131058-cwiggs-google_kano_-v0.2.1-3072-gb54796f.rom

cwiggs · 2026-06-27T02:35:53Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

Absolutely. It builds from CI. I pushed progress forward since the last base (coreboot 4.22) was old and not trivial to adapt. Let me know how the testing goes. Feel free to cherry pick all commits or if you agree i can push the changes here but that would make us both co-authors of the port.
CircleCI builds at https://app.circleci.com/pipelines/github/tlaurion/heads/4040/workflows/d7699b2f-feca-423f-b0f5-187ebf94e886

https://output.circle-artifacts.com/output/job/6e1574dc-9faa-487d-8bfe-1b108383a89a/artifacts/0/build/x86/kano/heads-kano-20260626-131058-cwiggs-google_kano_-v0.2.1-3072-gb54796f.rom

Thanks! I got it downloaded. The suzyq cable should arrive this weekend or Monday and I'll give it a try. I also rebased off your branch here.

tlaurion · 2026-06-27T16:57:11Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

Absolutely. It builds from CI. I pushed progress forward since the last base (coreboot 4.22) was old and not trivial to adapt. Let me know how the testing goes. Feel free to cherry pick all commits or if you agree i can push the changes here but that would make us both co-authors of the port.
CircleCI builds at https://app.circleci.com/pipelines/github/tlaurion/heads/4040/workflows/d7699b2f-feca-423f-b0f5-187ebf94e886

https://output.circle-artifacts.com/output/job/6e1574dc-9faa-487d-8bfe-1b108383a89a/artifacts/0/build/x86/kano/heads-kano-20260626-131058-cwiggs-google_kano_-v0.2.1-3072-gb54796f.rom

Thanks! I got it downloaded. The suzyq cable should arrive this weekend or Monday and I'll give it a try. I also rebased off your branch here.

@cwiggs : This branch doesn't include all the needed changes, nor CircleCI config.
I cleaned up the commit trail in my branch at https://github.com/tlaurion/heads/tree/cwiggs-google_kano
(There is 19 commits atop origin/master there; not 9 as here)

I can push here too, if needed. Let me know.

cwiggs · 2026-07-04T22:52:25Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

Absolutely. It builds from CI. I pushed progress forward since the last base (coreboot 4.22) was old and not trivial to adapt. Let me know how the testing goes. Feel free to cherry pick all commits or if you agree i can push the changes here but that would make us both co-authors of the port.
CircleCI builds at https://app.circleci.com/pipelines/github/tlaurion/heads/4040/workflows/d7699b2f-feca-423f-b0f5-187ebf94e886

https://output.circle-artifacts.com/output/job/6e1574dc-9faa-487d-8bfe-1b108383a89a/artifacts/0/build/x86/kano/heads-kano-20260626-131058-cwiggs-google_kano_-v0.2.1-3072-gb54796f.rom

Thanks! I got it downloaded. The suzyq cable should arrive this weekend or Monday and I'll give it a try. I also rebased off your branch here.

@cwiggs : This branch doesn't include all the needed changes, nor CircleCI config. I cleaned up the commit trail in my branch at https://github.com/tlaurion/heads/tree/cwiggs-google_kano (There is 19 commits atop origin/master there; not 9 as here)

I can push here too, if needed. Let me know.

I just rebased off your branch, let me know if it looks good from that point of view. Looks like I also will need to rebase off main.

As far as flashing goes: I got the Suzy-Q "cable" (It's really just a small board with a male and female usb-c, you then use your own usb-c cable). And I have some good news and some bad news (I think?). I was able to get the suzy-q cable to read the rom, but verifying the backup seems to fail.

I've been using this mrchromebox guide to get the suzy-q device working with flashrom and then this heads wiki as well. Below are some notes I put together while I was attempting the flash:

Use Suzy-Q cable for flashing

Connect the USB-C end of the Suzy-Q cable to the CCD port on your ChromeOS device
(usually left USB-C port) and the USB-A end to your Linux device
Verify the cable is properly connected:
- ls /dev/ttyUSB*
- This command should return 3 items: ttyUSB0, ttyUSB1, and ttyUSB2.
- If not, then your cable is connected to the wrong port or is upside down.
  Adjust and repeat command until output is as expected.
Set the CCD state to open:
- echo "ccd open" | sudo tee -a /dev/ttyUSB0 > /dev/null

Test Connection and detect chip. raiden_debug_spi used from mrchromebox doc

sudo flashrom -p raiden_debug_spi

╚═ $ sudo flashrom -p raiden_debug_spi
flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

FISK: (null)
Raiden target: 0,0
Raiden: Target SPI bridge is disabled (is WP enabled?)
Raiden: Error configuring protocol
    protocol       = 2
    status         = 0x00005
Error: Programmer initialization failed.

sudo flashrom -p raiden_debug_spi:target=AP casued a reboot.

 ╚═ $ sudo flashrom -p raiden_debug_spi:target=AP
flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

FISK: AP
Raiden target: 2,0
Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
No operations were specified.

Create backup, and verify.

sudo flashrom -p raiden_debug_spi:target=AP -r badflash.rom

hexdump -C badflash.rom | head -20

  00000000  11 00 00 9c 90 02 00 d6  00 00 00 05 ff ff ff ff  |................|
  00000010  5a a5 f0 0f 03 00 04 00  08 02 10 46 b0 01 14 00  |Z..........F....|
  00000020  00 00 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
  00000030  f6 30 30 09 21 42 60 ad  b7 b9 c4 c7 ff ff ff ff  |.00.!B`.........|
  00000040  00 00 00 00 00 05 ff 1f  01 00 ff 04 ff 7f 00 00  |................|
  00000050  ff 7f 00 00 ff 7f 00 00  ff 7f 00 00 ff 7f 00 00  |................|
  *
  00000080  00 07 20 00 00 05 40 00  00 00 00 00 00 00 00 00  |.. ...@.........|
  00000090  00 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff  |................|
  000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
  *
  00000100  00 00 00 00 01 00 00 00  09 00 04 00 00 ce 3d 03  |..............=.|
  00000110  7f 00 38 00 00 00 00 00  10 00 00 00 02 00 20 60  |..8........... `|
  00000120  08 30 03 48 00 00 00 00  01 00 7f 0f 82 0b c0 04  |.0.H............|
  00000130  00 00 00 00 00 00 0e 00  22 42 22 42 22 22 42 22  |........"B"B""B"|
  00000140  00 00 00 00 00 00 00 00  00 00 ff 00 60 00 80 c8  |............`...|
  00000150  45 86 00 36 01 00 a6 81  20 0e 58 00 01 00 40 00  |E..6.... .X...@.|
  00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
  00000170  00 1c 00 00 00 00 00 00  54 b3 04 a0 30 00 00 41  |........T...0..A|
  00000180  8f 03 08 c6 00 01 00 00  00 00 00 00 00 00 00 00  |................|

sudo flashrom -p raiden_debug_spi:target=AP --verify badflash.rom

  flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
  flashrom is free software, get the source code at https://flashrom.org

  FISK: AP
  Raiden target: 2,0
  Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
  Verifying flash... FAILED at 0x01bbeadb! Expected=0x94, Found=0xb4, failed byte count from 0x00000000-0x01ffffff: 0x3f

Created a backup and verify it using heads wiki guide.

sudo flashrom -p raiden_debug_spi:target=AP --read backup.bin --chip "W25Q256JV_M"

sudo flashrom -p raiden_debug_spi:target=AP --verify backup.bin --chip "W25Q256JV_M"

╚═ $ sudo flashrom -p raiden_debug_spi:target=AP --verify backup.bin --chip "W25Q256JV_M"
flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

FISK: AP
Raiden target: 2,0
Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
Verifying flash... FAILED at 0x01bc9254! Expected=0xb7, Found=0xb8, failed byte count from 0x00000000-0x01ffffff: 0x3e

Questions:

When I run sudo flashrom -p raiden_debug_spi I'm getting a "Error: Programmer initialization failed" and "Target SPI bridge is disabled (is WP enabled?)". The mrchromebox guide does talk about disabling write-protection, but it seems to only be possible to do via a tool in ChromeOS (gsctool), or by disconnecting the laptops battery. Seems very likely write-protection is still on.
Looks like I was able to create a backup, but then when I verify it I get: "Verifying flash... FAILED at 0x01bc9254! Expected=0xb7, Found=0xb8, failed byte count from 0x00000000-0x01ffffff: 0x3e" Why is it not working?

Anyway I think next steps are to disconnect the battery and try these flashrom commands again. I don't want to proceed until the verify step works without error.

cwiggs · 2026-07-04T23:17:43Z

Well I disconnected the battery and am getting the same response from flashrom. Should I just continue with flashing heads?

Here are my notes:

Disconnect Battery to disable write-protection.

Remove The 9 screws.

* Use a smudger to take the back cover off. * Disconnect battery cable.

Put laptop back together.

Disable write-protection. mrchromebox guide

Plug laptop into power.
Plug in suzy-q cable.
echo "wp false" > /dev/ttyUSB0
echo "wp false atboot" > /dev/ttyUSB0
echo "ccd reset factory" > /dev/ttyUSB0

Tried the same flashrom commands to backup and verify above and got the same result of "Error: Programmer initialization failed" and "Verifying flash... FAILED at 0x0003e1c0! Expected=0x28, Found=0x68, failed byte count from 0x00000000-0x01ffffff: 0xe99" when verifying.

tlaurion · 2026-07-05T17:21:48Z

Sorry i won't be able to help but with theory, I do not own any chromebook; you are guinea pig here :/

from https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#disabling-software-write-protection

sudo flashrom --wp-status

What is the output?

Also weird that you cannot verify a backup; that is not good. You shoud not proceed until you have a backup that can be flashed back otherwise you risk bricking. There is no A/B fallback with Heads as opposed to chromebook verified boot counterpart; firmware needs to be correct otherwise you will need to get back to prior firmware until port is complete.

Reading deeper (I guess your device is >2023), if its the case, you MUST disable CCD following those instructions https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#disable-ap-ro-firmware-verification

Let me know!
Might be useful to get direct communication, mrchromebox being online and normally really responsive; since this is first expected first port (and you have other devices) i'm willing to invest time making this work and first class citizen.
Community: https://osresearch.net/community/

tlaurion · 2026-07-05T17:25:25Z

@cwiggs check https://github.com/tlaurion/heads/tree/cwiggs-google_kano which now builds locally with blobs paths corrected and blobs submodules synced per mrchromebox gitsubmodules sync override in modules/coreboot

Okay, great, should I rebase this branch off that one then?

Absolutely. It builds from CI. I pushed progress forward since the last base (coreboot 4.22) was old and not trivial to adapt. Let me know how the testing goes. Feel free to cherry pick all commits or if you agree i can push the changes here but that would make us both co-authors of the port.
CircleCI builds at https://app.circleci.com/pipelines/github/tlaurion/heads/4040/workflows/d7699b2f-feca-423f-b0f5-187ebf94e886

https://output.circle-artifacts.com/output/job/6e1574dc-9faa-487d-8bfe-1b108383a89a/artifacts/0/build/x86/kano/heads-kano-20260626-131058-cwiggs-google_kano_-v0.2.1-3072-gb54796f.rom

Thanks! I got it downloaded. The suzyq cable should arrive this weekend or Monday and I'll give it a try. I also rebased off your branch here.

@cwiggs : This branch doesn't include all the needed changes, nor CircleCI config. I cleaned up the commit trail in my branch at https://github.com/tlaurion/heads/tree/cwiggs-google_kano (There is 19 commits atop origin/master there; not 9 as here)
I can push here too, if needed. Let me know.

I just rebased off your branch, let me know if it looks good from that point of view. Looks like I also will need to rebase off main.

As far as flashing goes: I got the Suzy-Q "cable" (It's really just a small board with a male and female usb-c, you then use your own usb-c cable). And I have some good news and some bad news (I think?). I was able to get the suzy-q cable to read the rom, but verifying the backup seems to fail.

I've been using this mrchromebox guide to get the suzy-q device working with flashrom and then this heads wiki as well. Below are some notes I put together while I was attempting the flash:

Use Suzy-Q cable for flashing

1. Connect the USB-C end of the Suzy-Q cable to the CCD port on your ChromeOS device
   (usually left USB-C port) and the USB-A end to your Linux device
   Verify the cable is properly connected:
   
   * ls /dev/ttyUSB*
   * This command should return 3 items: ttyUSB0, ttyUSB1, and ttyUSB2.
   * If not, then your cable is connected to the wrong port or is upside down.
     Adjust and repeat command until output is as expected.

2. Set the CCD state to open:
   
   * echo "ccd open" | sudo tee -a /dev/ttyUSB0 > /dev/null

3. Test Connection and detect chip. `raiden_debug_spi` used from mrchromebox [doc](https://docs.mrchromebox.tech/docs/support/unbricking/unbrick-suzyq.html#persisting-the-board-s-vital-product-data-vpd-and-hardware-id-hwid)
   
   * sudo flashrom -p raiden_debug_spi
     ```
     ╚═ $ sudo flashrom -p raiden_debug_spi
     flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
     flashrom is free software, get the source code at https://flashrom.org
     
     FISK: (null)
     Raiden target: 0,0
     Raiden: Target SPI bridge is disabled (is WP enabled?)
     Raiden: Error configuring protocol
         protocol       = 2
         status         = 0x00005
     Error: Programmer initialization failed.
     ```
   * sudo flashrom -p raiden_debug_spi:target=AP casued a reboot.
     ```
      ╚═ $ sudo flashrom -p raiden_debug_spi:target=AP
     flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
     flashrom is free software, get the source code at https://flashrom.org
     
     FISK: AP
     Raiden target: 2,0
     Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
     No operations were specified.
     ```

4. Create backup, and verify.
   
   * sudo flashrom -p raiden_debug_spi:target=AP -r badflash.rom
   * hexdump -C badflash.rom | head -20
     ```
       00000000  11 00 00 9c 90 02 00 d6  00 00 00 05 ff ff ff ff  |................|
       00000010  5a a5 f0 0f 03 00 04 00  08 02 10 46 b0 01 14 00  |Z..........F....|
       00000020  00 00 00 00 ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
       00000030  f6 30 30 09 21 42 60 ad  b7 b9 c4 c7 ff ff ff ff  |.00.!B`.........|
       00000040  00 00 00 00 00 05 ff 1f  01 00 ff 04 ff 7f 00 00  |................|
       00000050  ff 7f 00 00 ff 7f 00 00  ff 7f 00 00 ff 7f 00 00  |................|
       *
       00000080  00 07 20 00 00 05 40 00  00 00 00 00 00 00 00 00  |.. ...@.........|
       00000090  00 00 00 00 00 00 00 00  ff ff ff ff ff ff ff ff  |................|
       000000a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
       *
       00000100  00 00 00 00 01 00 00 00  09 00 04 00 00 ce 3d 03  |..............=.|
       00000110  7f 00 38 00 00 00 00 00  10 00 00 00 02 00 20 60  |..8........... `|
       00000120  08 30 03 48 00 00 00 00  01 00 7f 0f 82 0b c0 04  |.0.H............|
       00000130  00 00 00 00 00 00 0e 00  22 42 22 42 22 22 42 22  |........"B"B""B"|
       00000140  00 00 00 00 00 00 00 00  00 00 ff 00 60 00 80 c8  |............`...|
       00000150  45 86 00 36 01 00 a6 81  20 0e 58 00 01 00 40 00  |E..6.... .X...@.|
       00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
       00000170  00 1c 00 00 00 00 00 00  54 b3 04 a0 30 00 00 41  |........T...0..A|
       00000180  8f 03 08 c6 00 01 00 00  00 00 00 00 00 00 00 00  |................|
     ```
   * sudo flashrom -p raiden_debug_spi:target=AP --verify badflash.rom
     ```
       flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
       flashrom is free software, get the source code at https://flashrom.org
     
       FISK: AP
       Raiden target: 2,0
       Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
       Verifying flash... FAILED at 0x01bbeadb! Expected=0x94, Found=0xb4, failed byte count from 0x00000000-0x01ffffff: 0x3f
     ```

5. Created a backup and verify it using heads wiki guide.
   
   * sudo flashrom -p raiden_debug_spi:target=AP --read backup.bin --chip "W25Q256JV_M"
   * sudo flashrom -p raiden_debug_spi:target=AP --verify backup.bin --chip "W25Q256JV_M"
     ```
     ╚═ $ sudo flashrom -p raiden_debug_spi:target=AP --verify backup.bin --chip "W25Q256JV_M"
     flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
     flashrom is free software, get the source code at https://flashrom.org
     
     FISK: AP
     Raiden target: 2,0
     Found Winbond flash chip "W25Q256JV_M" (32768 kB, SPI) on raiden_debug_spi.
     Verifying flash... FAILED at 0x01bc9254! Expected=0xb7, Found=0xb8, failed byte count from 0x00000000-0x01ffffff: 0x3e
     ```

Questions:

1. When I run `sudo flashrom -p raiden_debug_spi ` I'm getting a "Error: Programmer initialization failed" and "Target SPI bridge is disabled (is WP enabled?)".  The mrchromebox guide does talk about disabling write-protection, but it seems to only be possible to do via a tool in ChromeOS (gsctool), or by disconnecting the laptops battery.  Seems very likely write-protection is still on.

2. Looks like I was able to create a backup, but then when I verify it I get: "Verifying flash... FAILED at 0x01bc9254! Expected=0xb7, Found=0xb8, failed byte count     from 0x00000000-0x01ffffff: 0x3e"  Why is it not working?

Anyway I think next steps are to disconnect the battery and try these flashrom commands again. I don't want to proceed until the verify step works without error.

@MrChromebox any insights on this? Kano post 2023 device? CCD required to be disabled through https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#disable-ap-ro-firmware-verification ?

Any insight really appreciated. As we discussed prior, TPM2 implementation of cr50 was complete enough; Heads was not using the proper capability, which (hopefully/should...) have been fixed under #2055

cwiggs · 2026-07-05T18:40:00Z

Sorry i won't be able to help but with theory, I do not own any chromebook; you are guinea pig here :/

No worries, I'm glad to be the guinea big here. Really excited to get heads working on chromebox/book devices.

from https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#disabling-software-write-protection

sudo flashrom --wp-status

What is the output?

 ╚═ $ sudo flashrom --wp-status
flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)             
flashrom is free software, get the source code at https://flashrom.org

Please select a programmer with the --programmer parameter.
To choose the mainboard of this computer use 'internal'. Valid choices are:
internal, dummy, nic3com, nicrealtek, gfxnvidia, raiden_debug_spi, drkaiser,
satasii, asm106x, atavia, it8212, ft2232_spi, serprog, buspirate_spi, dediprog,
developerbox, rayer_spi, pony_spi, nicintel, nicintel_spi, nicintel_eeprom,
ogp_spi, satamv, linux_mtd, linux_spi, usbblaster_spi, pickit2_spi, ch341a_spi,
ch347_spi, digilent_spi, jlink_spi, stlinkv3_spi, dirtyjtag_spi, spidriver.

 ╔ |1| 17:08:48 | framework | ~/dev/personal/heads  (google_kano)
 ╚═ $ sudo flashrom --wp-status -p raiden_debug_spi
flashrom v1.6.0 on Linux 7.0.10+deb14-amd64 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

FISK: (null)
Raiden target: 0,0
Raiden: Target SPI bridge is disabled (is WP enabled?)
Raiden: Error configuring protocol
    protocol       = 2
    status         = 0x00005
Error: Programmer initialization failed.

Also weird that you cannot verify a backup; that is not good. You shoud not proceed until you have a backup that can be flashed back otherwise you risk bricking. There is no A/B fallback with Heads as opposed to chromebook verified boot counterpart; firmware needs to be correct otherwise you will need to get back to prior firmware until port is complete.

Yeah makes sense. Another option I'll probably try it to follow the mrchromebox guide on flashing coreboot and see if I can do that normally, then at least I can always go back to Mrchromebox's coreboot if flashing heads causes issues.

Reading deeper (I guess your device is >2023), if its the case, you MUST disable CCD following those instructions https://docs.mrchromebox.tech/docs/firmware/wp/disabling.html#disable-ap-ro-firmware-verification

Yeah that is my read on it too, which is why I disconnected the battery, which should disable CCD according to that guide but doesn't seem to be working?

Let me know! Might be useful to get direct communication, mrchromebox being online and normally really responsive; since this is first expected first port (and you have other devices) i'm willing to invest time making this work and first class citizen. Community: https://osresearch.net/community/

I'll look into creating a thread on the chultrabook forum too.

Some more context that might help:

The Kano device I have should be pre 2023, the MFG Date on it is 2022.
This Kano device I have was bought used with Mrchromebox's coreboot and Linux already installed so I'm not 100% sure how the previous owner flashed the bootloader. I think this influences the "Was write-protection disabled" question.

cwiggs · 2026-07-06T02:22:46Z

While debugging these issues I did find it recommended to check here to see if the ChromeOS Device supports ccd (which is what the suzyq cable is for) and it looks like the Acer 714 does not support ccd? If that is truly the issue I'll have to order hardware to flash the chip with a normal SPI flasher.

Interestingly the chromium.org page above shows "Acer Chromebook Plus Spin 714 (CP714-1H/CP714-1HN),Acer Chromebook Plus Enterprise Spin 714 (CPE794-1N)]" which is a slightly different model than mine. My model number is CP714-1WN which according to the Mrchromebox link is board name KANO, which also doesn't match the board name on the chromium.org site. I can't find my Chromebook on the chromium.org website though.

I also have 2 other ChromeOS devices already with Mrchromebox's coreboot:

HP Chromebox G2
Acer Chromebook Spin 713 (CP713-3W)

So we could potentially try to build and flash heads on those?

cwiggs · 2026-07-06T02:50:17Z

More findings! I found a post by Mrchromebox here that mentions something is might be needed for KANO! However I tried with minicom like Mrchromebox suggested and get:

cwiggs@framework:~$ sudo minicom -b 115200 -D /dev/ttyUSB0
Failed to set baud rate

cwiggs · 2026-07-06T03:02:20Z

More findings! I found a post by Mrchromebox here that mentions something is might be needed for KANO! However I tried with minicom like Mrchromebox suggested and get:
cwiggs@framework:~$ sudo minicom -b 115200 -D /dev/ttyUSB0
Failed to set baud rate

I was able to get around this by running sudo stty -F /dev/ttyUSB2 which showed a baud rate of 9600, I then issued: sudo minicom -b 9600 -D /dev/ttyUSB2 and it seems to have worked?

Welcome to minicom 2.11.1

OPTIONS: I18n 
Port /dev/ttyUSB2, 20:55:41 [U]

Press CTRL-A Z for help on special keys

7665 C0: PE_SNK_Startup]
[818.920160 C0: PE_SNK_Discovery]
[818.921676 C0: PE_SNK_Wait_for_Capabilities]
[819.497194 C0: PE_SNK_Hard_Reset]
[819.499716 C0 Hard Reset sent]
[819.501544 C0: PE_SNK_Transition_to_default]
[820.166321 C0: PE_SNK_Startup]
[820.170223 C0: PE_SNK_Discovery]
> apshutdown
[1064.826216 chipset_force_shutdown() 32774]
> gpioset en_S5_rails 1
> [1084.253339 power state 0 = G3, in 0x0040]
i2c 7 recovery! error code is 13, current state is 0
[1084.349970 power state 0 = G3, in 0x0050]
[1084.350542 power state 0 = G3, in 0x0070]

Use upstream coreboot 26.03 (git tag 26.03, commit e5c99fe) instead of the MrChromebox fork for kano, since heads does not use EFI. The kano brya variant is present upstream at this tag. - modules/coreboot: replace coreboot-mrchromebox-26.03 fork pin with coreboot-26.03 upstream git module (repo coreboot/coreboot) and add the new coreboot-26.03 seed for the shared toolchain. - boards/kano/kano.config: CONFIG_COREBOOT_VERSION=mrchromebox-26.03 -> 26.03. The APPLY_HAP/GPR0_DISABLE ifdtool post-build handling is heads-side and unchanged (upstream has HAP Kconfigs but heads applies via ifdtool). - git mv patches/coreboot-mrchromebox-26.03 -> patches/coreboot-26.03. Both heads-maintained patches are still required on upstream 26.03 (verified unmerged upstream and cleanly applying): - 0001 util/cbmem: add endian.h include for musl compat - 0002 soc/intel/lockdown: SPI/LPC SMM lockdown for PR0. Rebased for the upstream HECI1 disable rename (soc_disable_heci1_at_pre_boot() -> CONFIG(DISABLE_HECI1_AT_PRE_BOOT)) that drifted cannonlake/tigerlake hunks vs the fork base; metadata note updated accordingly. - .circleci/config.yml + doc/circleci.md: rename kano seed/job to coreboot-26.03. Verification: upstream 26.03 clone -> both patches git-apply cleanly, and config/coreboot-kano.config olddefconfig passes (exit 0; only benign FMAP_SIZE / EC_CHROMEEC_USE_VENDOR_TABLET_CONTROLS unknown-symbol warnings, both dropped by olddefconfig). Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Regenerate coreboot-kano.config against upstream coreboot 26.03 via 'save_in_oldconfig_format_in_place' (olddefconfig) and the .config_defconfig backup via 'save_in_defconfig_format_backup', capturing what the upstream 26.03 switch rewrites. Config deltas vs the MrChromebox fork (fork-only symbols dropped upstream): - FMAP_SIZE, EDK2_BOOT_MANAGER_ESCAPE, EDK2_FOLLOW_BGRT_SPEC, EDK2_DISABLE_TPM, CSE_RESET_CLEAR_EC_AP_IDLE_FLAG, EC_CHROMEEC_USE_VENDOR_TABLET_CONTROLS, CR50_RESET_CLEAR_EC_AP_IDLE_FLAG dropped (no upstream equivalent) - CONFIG_SYSTEM_TYPE_CONVERTIBLE -> CONFIG_SYSTEM_TYPE_LAPTOP (upstream renamed the symbol; kano loses the convertible/tablet distinction) - FSP_M/FSP_S_FILE + FSP_HEADER_PATH re-homed under their sections; savedefconfig makes PCIEXP_HOTPLUG_/DRIVERS_HWID_DMI/VPD/SMBIOS_SERIAL and NO_POST/CONSOLE_SERIAL explicit CONCLUSION (build blocker): 'make BOARD=kano' fails at 'No rule to make target 3rdparty/blobs/mainboard/google/brya/brya/kano/ flashdescriptor.bin'. Upstream 26.03's 3rdparty/blobs submodule (pinned 4a8de03) contains ZERO brya blobs (only butterfly, guybrush, kahlee, link, parrot, skyrim, stout, zork). The kano IFD (flashdescriptor.bin), ME (me.bin), microcode, vbt, and ec blobs are proprietary Google/Intel blobs that exist ONLY in the MrChromebox fork's 3rdparty/blobs submodule (MrChromebox/blobs mainboard/google/brya/brya/kano). Upstream 26.03 cannot build kano unless those blobs are sourced into the heads build; this commit records the attempt and the blocker, not a working upstream build. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Abandon the upstream coreboot 26.03 attempt (see 5494064 / 4be877d which record the attempt and the blocker). Restore the build to the MrChromebox fork (coreboot 26.03 based), which is the only coreboot source that carries the kano proprietary blobs (IFD flashdescriptor.bin, me.bin, microcode, vbt, ec) in its 3rdparty/blobs submodule — upstream 26.03 lacks them entirely, so kano cannot build from upstream. Restored to pre-migration fork state (forward commit, history preserved): - modules/coreboot: coreboot-mrchromebox-26.03 module back (MrChromebox/coreboot, f8244f25) - boards/kano/kano.config: CONFIG_COREBOOT_VERSION=mrchromebox-26.03 - patches: git mv coreboot-26.03 -> coreboot-mrchromebox-26.03; 0002 restored to its original fork-flavored content (the migration had rebased it for the upstream HECI1 rename); 0001 unchanged - .circleci/config.yml + doc/circleci.md: kano seed/job back to coreboot-mrchromebox-26.03 Signed-off-by: Thierry Laurion <insurgo@riseup.net>

…ore TPM GPIO caveats Regenerate the kano coreboot config against the MrChromebox fork (coreboot 26.03 based) using the coreboot make helpers: ./docker_repro.sh make BOARD=kano coreboot.save_in_oldconfig_format_in_place ./docker_repro.sh make BOARD=kano coreboot.save_in_defconfig_format_backup These rederive config/coreboot-kano.config and config/coreboot-kano.config_defconfig from the fork, undoing the upstream-26.03 normalization from 4be877d: - SYSTEM_TYPE_LAPTOP back to SYSTEM_TYPE_CONVERTIBLE (kano is a 2-in-1) - fork-only symbols re-added: FMAP_SIZE, EDK2_BOOT_MANAGER_ESCAPE, EDK2_FOLLOW_BGRT_SPEC, EDK2_DISABLE_TPM, CSE_RESET_CLEAR_EC_AP_IDLE_FLAG, CR50_RESET_CLEAR_EC_AP_IDLE_FLAG, EC_CHROMEEC_USE_VENDOR_TABLET_CONTROLS - VPD/SMBIOS_SERIAL_FROM_VPD/DRIVERS_HWID_DMI/INTEL_GMA_HAVE_VBT/ PCIEXP_HOTPLUG_IO back in their original fork positions Result: both config files are byte-identical to the pre-attempt fork state (deb2457). Also restore the TPM GPIO NOT_VULNERABLE caveats in boards/kano/kano.config, which the switch-back (ec5fa14) had accidentally dropped by restoring the file from deb2457 (older than the TPM GPIO commit c2dd57b). Restored from c2dd57b so the board config again carries: CAVEATS: TPM_GPIO_RESET=NOT_VULNERABLE -- Google CR50 on I2C. patches/, .circleci/, and doc/circleci.md remain on the MrChromebox fork naming (coreboot-mrchromebox-26.03) as restored in ec5fa14. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

…ixups) Advance the tpm-gpio-fail pin from 8a9fc3a to 3e3a695 (tlaurion/tpm-gpio-fail), taking three upstream commits: - TPM GPIO reset PoC for Heads: extended platform support - Add Alder Lake-N, Elkhart Lake, Gemini Lake, Jasper Lake platform support - reset/inteltool.c: remove unnecessary print line at the end of execution (cleanup fixup) Delivered to boards enabling CONFIG_TPM2_TOOLS via the modules-$(CONFIG_TPM2_TOOLS) conditional (tpm-gpio-detect / tpm-gpio-assert). Signed-off-by: Thierry Laurion <insurgo@riseup.net>

The pinned revision (3e3a695) carries commits by Kondix10 / Konrad Dadasiewicz (tlaurion/tpm-gpio-fail): Alder Lake-N, Elkhart Lake, Gemini Lake, Jasper Lake platform support and the inteltool print-line cleanup fixup. Document the full attribution chain in the module header: - kukrimate/tpm-gpio-fail (Mate Kukri): original PoC - tlaurion/tpm-gpio-fail (Thierry Laurion): Heads-leaning fork + extended platform support, the repo Heads pins - Kondix10/tpm-gpio-fail (Konrad Dadasiewicz): additional platform families and build/output fixups bundled into the pinned revision Signed-off-by: Thierry Laurion <insurgo@riseup.net>

kano (MrChromebox coreboot fork, Alder Lake) meets all PR0 chipset-locking requirements: BOOTMEDIA_LOCK_CONTROLLER=y, BOOTMEDIA_LOCK_WHOLE_RO=y, INTEL_CHIPSET_LOCKDOWN disabled, SOC_INTEL_COMMON_SPI_LOCKDOWN_SMM=y, and SPI_FLASH_SMM=y (verified in config/coreboot-kano.config). Add it to the Skylake+ SMM-lockdown board list (10 -> 11, total 29 -> 30). Also document the fork's lockdown patch location for kano: patches/coreboot-mrchromebox-26.03/0002-soc-intel-lockdown-of-CB-85278 (same CB:85278 patch as coreboot-25.09/0003, rebased for the fork). Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

Add a HOTP remote-attestation variant of the Acer Chromebook Spin 714 (KANO) board, following the qemu-coreboot-fbwhiptail-tpm2[-hotp] unified pattern: boards/kano-hotp/kano-hotp.config is identical to the base boards/kano/kano.config except CONFIG_HOTPKEY=y and CONFIG_BOARD_NAME="Google Kano HOTP". Both boards share the same config/coreboot-kano.config and config/linux-kano.config pointers. CI: kano-hotp builds seeded by the kano coreboot-mrchromebox-26.03 seed. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

…king Extend .gitignore to cover editor and tooling scratch/backup files so they cannot silently get committed again (a prior commit tracked tpmr.sh.bck, tpm-patch2, tpm.md-patch and tpm2_* scratch fixtures under the repo root). Adds: *.bak, *.bck, *.orig, *.rej, *.save, *.tmp, -patch, .md-patch (build/archives already covered by *.o, *.rom, *.img, *.cpio etc.) Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion

LGTM! Last internal flash test works?

tlaurion · 2026-09-03T16:58:51Z

I confirm build is reproducible: both local build and CircleCI produced the same hash:

https://app.circleci.com/pipelines/github/linuxboot/heads/1483/details?job=11005850-befe-4671-9999-20ae778abe98&workflowId=653de792-3a20-4d2f-9edc-11a3b9c211c9&buildNumber=58316&jobType=build&invite=true&expanded=true#step-104-15491313_145

Sep 03 16:22:58 fe71a8d22816c020435f7cc58a263d5a36182e57d3cfb75ca2f97c5edf6e2ab8 build/x86/kano/heads-kano-202609031158-v0.2.1-3196-gb184149.rom

tlaurion · 2026-09-03T17:00:09Z

Two actionnable items left in OP
Additional actionable items:

Confirm/infirm

initrd/bin/kexec-save-default.sh: skip symlinks when finding crypttabfiles initrd/bin/kexec-save-default.sh: skip symlinks when finding crypttabfiles #2155 needed to boot NixOS

Any impact from ME being HAP disabled??

tlaurion · 2026-09-03T17:09:59Z

I thought that we actually decided to not fork off MrChromebox's coreboot fork and just used vanilla? I remember MrChromebox saying that if our fork doesn't relate to UEFI we don't need anything from the MrChromebox fork?

We could switch I forgot about that. Changing coreboot, board and CirclCI to reflect the change?

Oh yes, see commit trails on this. Tried to switch to coreboot 26.03 but blobs absent and gave up. In commit trails for proof and switched back to mrchromebox fork (see 98574da)

cc @MrChromebox

Bring in upstream master (PR linuxboot#2200: tpm-gpio-reset Kondix10 attribution and module pin 3e3a695). Both commits are already present in this branch by identical patch content (modules/tpm-gpio-reset matches at both tips), so they are not duplicated here. Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion · 2026-09-03T17:58:42Z

@cwiggs also, can you add your gpg public key under github so that your commits show as verified?

cwiggs · 2026-09-03T21:45:55Z

LGTM! Last internal flash test works?

Let me download the file and flash. Should I flash this internally, not externally via the SuzyQ board?

Two actionnable items left in OP Additional actionable items:

Confirm/infirm

initrd/bin/kexec-save-default.sh: skip symlinks when finding crypttabfiles initrd/bin/kexec-save-default.sh: skip symlinks when finding crypttabfiles #2155 needed to boot NixOS

Any impact from ME being HAP disabled??

I think the first one is complete? I've been able to boot into NixOS from these Heads-Kano builds for months without issue.

Any impact from ME being HAP disabled??

I think this one we solved recently but I'll check with flashprog after I flash the most recent Heads build.

@cwiggs also, can you add your gpg public key under github so that your commits show as verified?

Looks like I signed those with my old key that I'm not using anymore. My new key you can see here: linuxboot/heads-wiki@0dc6d86

Let me see about resigning the commits here.

cwiggs · 2026-09-03T23:03:54Z

Looks like I signed those with my old key that I'm not using anymore. My new key you can see here: linuxboot/heads-wiki@0dc6d86

Let me see about resigning the commits here.

Actually that it looks like they were re-signed with your key 9A53E1BB3FF00461 @tlaurion ?

cwiggs · 2026-09-03T23:12:01Z

Let me download the file and flash. Should I flash this internally, not externally via the SuzyQ board?

I ended up flashing externally via the SuzyQ board. No issues there.

I think we are good to go? Next step remove debug mode and reflash?

tlaurion · 2026-09-04T01:38:54Z

Let me download the file and flash. Should I flash this internally, not externally via the SuzyQ board?

Let's be clear :)

Initial flash: IFD, unlocking of whole flash; needs external. So on here testing went wrong, you had a IFS that was restricting ME and everythig else FD defined (regions, properties of regions) before flashing externally and confirming flashprog output with tee (which is their bad: stderr/stdout sent different paths which resolves the confusion we ha before: GPR0 was alwaus there until your test at #2133 (comment)

After IFD good: everything (everyone following your instructions under https://cwiggs.github.io/heads-wiki/ now) should be able to externally flash kano and then internally flash internal upgrades.

I ended up flashing externally via the SuzyQ board. No issues there.

I think we are good to go? Next step remove debug mode and reflash?
Exactly, redoing flashprog --programmer internal from recovery shell before/after calling lock_chip.sh to make sure https://github.com/linuxboot/heads/pull/2133/changes#diff-f1f6f628ec68a607e292baa7e86c813f2d966fc7420b31b7f24ea7f346aed525 is good and works as intended.

Next steps: checking last checkboxes of OP and merge both heads and heads-wiki pr with your consent

tlaurion · 2026-09-04T01:40:03Z

I think we are good to go? Next step remove debug mode and reflash?

When everything ticket in Op, yes, remove non-production bits and merge.

Thanks for your patience, this unlocks a whole big family of new boards here.

tlaurion · 2026-09-04T01:42:06Z

Looks like I signed those with my old key that I'm not using anymore. My new key you can see here: linuxboot/heads-wiki@0dc6d86
Let me see about resigning the commits here.

Actually that it looks like they were re-signed with your key 9A53E1BB3FF00461 @tlaurion ?

~~No.~~ -> yes?!?!?!?!

Look at https://github.com/linuxboot/heads/pull/2133/commits

That's what I see

Clicking unverified commit shows on my side

That is your's, not mine.

Mine is seen clicking on my github profile and on verified commits there:

EDIT: wait what? same key?!?!?! Damnit github... Will dig tomorrow....

cwiggs · 2026-09-04T02:32:49Z

Any impact from ME being HAP disabled??

Anything specific I should check with this? I'm able to use Heads like normal so I'm not sure if there is any impact.

tlaurion · 2026-09-04T02:35:03Z

Any impact from ME being HAP disabled??
Anything specific I should check with this? I'm able to use Heads like normal so I'm not sure if there is any impact.

@cwiggs that was empty comment

cwiggs · 2026-09-04T02:49:26Z

Any impact from ME being HAP disabled??
Anything specific I should check with this? I'm able to use Heads like normal so I'm not sure if there is any impact.

@cwiggs that was empty comment

Sorry Github has odd formatting and included my comment in the quote. I just fixed it.

tlaurion reviewed Jun 24, 2026

View reviewed changes

Comment thread modules/coreboot Outdated

tlaurion reviewed Jun 24, 2026

View reviewed changes

Comment thread modules/coreboot Outdated

tlaurion requested changes Jun 24, 2026

View reviewed changes

cwiggs mentioned this pull request Jun 24, 2026

Google omnigul retry with tpm duk supposed to work #2057

Open

cwiggs force-pushed the google_kano branch from 6c23536 to d025933 Compare June 24, 2026 04:08

tlaurion reviewed Jun 24, 2026

View reviewed changes

Comment thread boards/kano/kano.config Outdated

tlaurion reviewed Jun 24, 2026

View reviewed changes

Comment thread boards/kano/kano.config Outdated

tlaurion requested changes Jun 24, 2026

View reviewed changes

cwiggs force-pushed the google_kano branch from e2fb524 to 2f1d27c Compare June 27, 2026 02:35

cwiggs force-pushed the google_kano branch from 2f1d27c to 0b2949c Compare July 4, 2026 22:43

cwiggs force-pushed the google_kano branch 2 times, most recently from ea307b4 to 4d2c1e5 Compare July 5, 2026 00:24

tlaurion added 5 commits September 3, 2026 11:03

tlaurion force-pushed the google_kano branch from 426f650 to d242134 Compare September 3, 2026 15:06

tlaurion added 3 commits September 3, 2026 11:21

gitignore: ignore .code-graph/ workspace

1401726

Signed-off-by: Thierry Laurion <insurgo@riseup.net>

tlaurion force-pushed the google_kano branch from f9f371a to 4bf43c8 Compare September 3, 2026 15:22

tlaurion force-pushed the google_kano branch from d0ecff3 to cec089e Compare September 3, 2026 15:58

tlaurion approved these changes Sep 3, 2026

View reviewed changes

tlaurion assigned cwiggs Sep 3, 2026

This comment was marked as off-topic.

Sign in to view

Uh oh!

Uh oh!

Conversation

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

Uh oh!

TODO before merge

Uh oh!

Uh oh!

Uh oh!

tlaurion left a comment

Choose a reason for hiding this comment

Uh oh!

tlaurion commented Jun 24, 2026

Uh oh!

cwiggs commented Jun 24, 2026

Uh oh!

tlaurion commented Jun 24, 2026

Uh oh!

Uh oh!

Uh oh!

cwiggs commented Jun 24, 2026

Uh oh!

tlaurion commented Jun 25, 2026

Uh oh!

cwiggs commented Jun 26, 2026

Uh oh!

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

Uh oh!

Uh oh!

tlaurion commented Jun 26, 2026

Uh oh!

cwiggs commented Jun 27, 2026

Uh oh!

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

Uh oh!

Uh oh!

cwiggs commented Jul 4, 2026

Use Suzy-Q cable for flashing

Uh oh!

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

Uh oh!

Uh oh!

tlaurion commented Jul 5, 2026

Uh oh!

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

Uh oh!

Use Suzy-Q cable for flashing

Uh oh!

cwiggs commented Jul 5, 2026

Uh oh!

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

Uh oh!

Uh oh!

cwiggs commented Jul 6, 2026

Uh oh!

cwiggs commented Jul 6, 2026

Uh oh!

tlaurion left a comment

Choose a reason for hiding this comment

Uh oh!

This comment was marked as off-topic.

Uh oh!

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

Uh oh!

Uh oh!

tlaurion commented Sep 3, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

cwiggs commented Sep 3, 2026

Uh oh!

cwiggs commented Sep 3, 2026

Uh oh!

cwiggs commented Sep 3, 2026

Uh oh!

tlaurion commented Sep 4, 2026

cwiggs commented Jun 24, 2026 •

edited

Loading

tlaurion commented Jun 26, 2026 •

edited

Loading

tlaurion commented Jun 27, 2026 •

edited

Loading

cwiggs commented Jul 4, 2026 •

edited

Loading

tlaurion commented Jul 5, 2026 •

edited

Loading

cwiggs commented Jul 6, 2026 •

edited

Loading

tlaurion commented Sep 3, 2026 •

edited

Loading

tlaurion commented Sep 3, 2026 •

edited

Loading

tlaurion commented Sep 3, 2026 •

edited

Loading

tlaurion commented Sep 4, 2026 •

edited

Loading

cwiggs commented Sep 4, 2026 •

edited

Loading

cwiggs commented Sep 4, 2026 •

edited

Loading