Add Google kano (Mr Chromebox) support - First full Chromebook port!

[cwiggs]

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

• Create Chromebook section with notes of this PR
• Go through/modify porting guide checklist
  • Go through/modify testing checklist
    • Successful external flash link to circleci: https://X.Y.Z. from commit X.Y.Z. using external programmer model X.Y.Z. on X.Y.Z. Voltage mode
    • Boots successfully after the flashing:
    • Setting clock prompt on first reboot: ok if triggered correctly after initial flashing and CMOS battery disconnected
    • Clean boot detected (no keyring, nothing installed on disk): usb boot proposed and followed
    • Boots on usb
    • OS X.Y.Z. install and reboot
    • Heads functionality- no pubkey detected, but OS detected -> OEM-Factory-reset proposed. Done with X.Y.Z. hardwarekey e.g. nk3
    • On reboot after re-ownership: generate new HOTP/TOTP
    • wifi works based on OS X.Y.Z.
    • PR0
      • flashprog -p internal (not locked)
      • lock_chip (locks the platform with PR0, if PR0 patch applied in fork or under patches/coreboot-X.Y.Z. and coreboot config contain proper preparation of the platform)
      • flashprog -p internal (reports locked)

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

[tlaurion]

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

[tlaurion]

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]

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]

@cwiggs I saw you left the room?

[cwiggs]

@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]

@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]

@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]

@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]

@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]

@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]

@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]

@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

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

[cwiggs]

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

Here are my notes:

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

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

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

[Copilot]

Pull request overview

Copilot reviewed 15 out of 18 changed files in this pull request and generated 4 comments.

[tlaurion]

Flashed the most recent build (https://output.circle-artifacts.com/output/job/5f5b720f-8d71-4878-91df-a20af7beac2f/artifacts/0/build/x86/kano/heads-kano-202607092012-v0.2.1-3123-g852dc8e.zip)

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... OK.
Found Programmer flash chip "Opaque flash chip" (32768 kB, Programmer-specific) on internal.
No operations were specified.

Looks good!

@cwiggs Now will be time to checklist things, i will update OP with checklist (to improve docs as well. Todo still is open a pr against heads-wiki with what is absolutely necessary to flash chromebooks. Will also rename PR to make it clear that this is first chromebook port :)

Once CircleCI builds the Kano zip I'll flash the image and fill out the checklist.

I also have a working branch for the wiki for heads. I'll get it up as a draft/WIP and then add to it.

Curious since you are a daily NixOS user, and that installation docs under https://osresearch.net are.... hmm. less then optimal to guide users into what is different requirements then UEFI, even though latest #2130 helped a lot fb+iso support, unless bugs found, most if not all linux distributions.

You didn't need #2155 ?

I was able to get my NixOS install working in Heads with a very simple change you can see here: https://gitlab.com/cwiggs/nix/-/commit/a7419c5511b45e0fa04590788bcb8309e12825e9

I didn't need #2155 and DUK still works without issues. I can also post a tree or files in /boot if that helps.

Interesting. My issue was not about installing grub, that did work. My issue pointing to #2155 being required was that when setting up a TPM DUK for a selected boot entry to become default, initramfs unpacking failed finding a valid crypttab in initramfs pointed by boot entry in grub (it was a symlink pointing to rootfs path which is not available from initramfs itself.

If you could describe your custom partitioning scheme, I would definitely be interested in it, mine was roughly described into #2155 linked issue #2154. NixOS installer (GUI) complies with basic custom partitioning even though it warns that /boot mount point is reserved. But yeah, From my understanding, NixOS expects /boot to be subdir of / from an installation standpoint.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 18 changed files in this pull request and generated 3 comments.

[cwiggs]

CircleCI

Here is my drive and partitions for my NixOS system:

[cwiggs@nixos:~]$ sudo fdisk -l /dev/nvme0n1
Please enter the PIN: 
Please touch the FIDO authenticator.
Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: WDC PC SN530 SDBPNPZ-256G-1114          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CC2714F1-6089-4161-8899-DE78A35C6E1E

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      4096   2101247   2097152     1G EFI System
/dev/nvme0n1p2   2101248 481663187 479561940 228.7G Linux filesystem
/dev/nvme0n1p3 481663188 500118125  18454938   8.8G Linux filesystem

[cwiggs@nixos:~]$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                       259:0    0 238.5G  0 disk  
├─nvme0n1p1                                   259:1    0     1G  0 part  /boot
├─nvme0n1p2                                   259:2    0 228.7G  0 part  
│ └─luks-d85bd48a-c082-4814-8d41-1504334b6045 254:0    0 228.7G  0 crypt /nix/store
│                                                                        /
└─nvme0n1p3                                   259:3    0   8.8G  0 part  

I installed this system before Heads on on this device. After I installed Heads I wasn't able to boot (makes sense). I then updated my Nix config to create the Grub files but not actually install Grub (boot.loader.grub.device="nodev").

Perhaps this section in my hardware-configuration.nix helped with Heads being able to work with DUK without your PR?

  boot.initrd.luks.devices."luks-d85bd48a-c082-4814-8d41-1504334b6045".device = "/dev/disk/by-uuid/d85bd48a-c082-4814-8d41-1504334b6045";

Btw what is the status of the Kano port. Should I try and flash the most recent CircleCI build: https://output.circle-artifacts.com/output/job/b467f40a-e1a8-4a12-bef1-d14b1fe2f7c1/artifacts/0/build/x86/kano/heads-kano-202607102221-v0.2.1-3126-g2aaa5ee.zip ?

[cwiggs]

I'm not sure if Heads 100% caused it but it seems like my usb-c ports on the Kano device no longer work in Heads, or GDM, they only work after logging into Gnome.

[tlaurion]

Here is my drive and partitions for my NixOS system:

[cwiggs@nixos:~]$ sudo fdisk -l /dev/nvme0n1
Please enter the PIN: 
Please touch the FIDO authenticator.
Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: WDC PC SN530 SDBPNPZ-256G-1114          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CC2714F1-6089-4161-8899-DE78A35C6E1E

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      4096   2101247   2097152     1G EFI System
/dev/nvme0n1p2   2101248 481663187 479561940 228.7G Linux filesystem
/dev/nvme0n1p3 481663188 500118125  18454938   8.8G Linux filesystem

[cwiggs@nixos:~]$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                       259:0    0 238.5G  0 disk  
├─nvme0n1p1                                   259:1    0     1G  0 part  /boot
├─nvme0n1p2                                   259:2    0 228.7G  0 part  
│ └─luks-d85bd48a-c082-4814-8d41-1504334b6045 254:0    0 228.7G  0 crypt /nix/store
│                                                                        /
└─nvme0n1p3                                   259:3    0   8.8G  0 part  

I installed this system before Heads on on this device. After I installed Heads I wasn't able to boot (makes sense). I then updated my Nix config to create the Grub files but not actually install Grub (boot.loader.grub.device="nodev").

Perhaps this section in my hardware-configuration.nix helped with Heads being able to work with DUK without your PR?

This doesn't make sense to me.

• nvme0n1p1 -> /boot (fat32), UEFI
• nvme0n1p2 -> / (ext4 under LUKS container)
• nvme0n1p3 -> swap (not under LUKS container)

But yeah, Heads can read fat32 and doesn't really care.

Unpacking initramfs from /boot to setup a TPM DUK under master (without #2155) would sill have a crypttab as a symlink to real /root/nixstore......./..../crypttab, so I don't understand why ypu don't need it. But that is another issue unrelated to the port. Will document in issue #2154

  boot.initrd.luks.devices."luks-d85bd48a-c082-4814-8d41-1504334b6045".device = "/dev/disk/by-uuid/d85bd48a-c082-4814-8d41-1504334b6045";

That's good and can relate, UUID are passed down to kexec call. Anyway this is #2154

Btw what is the status of the Kano port. Should I try and flash the most recent CircleCI build: https://output.circle-artifacts.com/output/job/b467f40a-e1a8-4a12-bef1-d14b1fe2f7c1/artifacts/0/build/x86/kano/heads-kano-202607102221-v0.2.1-3126-g2aaa5ee.zip ?

You tell me :) I'm doing cleanup for pesterity but that shoul'd impact functionality, unless bumping to recent coreboot 26.06 mrchromebook fork created issues with USB per your next comment?

[tlaurion]

I'm not sure if Heads 100% caused it but it seems like my usb-c ports on the Kano device no longer work in Heads, or GDM, they only work after logging into Gnome.

Is that regression of mrchromebook coreboot fork 26.03 vs 26.06?
What exactly happens there? you try to usb boot or plug dongle in usb ports and nothing happens?

Can you go to recovery shell and give debug output?
cbmem -1? dmesg?

[tlaurion]

Here is my drive and partitions for my NixOS system:

[cwiggs@nixos:~]$ sudo fdisk -l /dev/nvme0n1
Please enter the PIN: 
Please touch the FIDO authenticator.
Disk /dev/nvme0n1: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: WDC PC SN530 SDBPNPZ-256G-1114          
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: CC2714F1-6089-4161-8899-DE78A35C6E1E

Device             Start       End   Sectors   Size Type
/dev/nvme0n1p1      4096   2101247   2097152     1G EFI System
/dev/nvme0n1p2   2101248 481663187 479561940 228.7G Linux filesystem
/dev/nvme0n1p3 481663188 500118125  18454938   8.8G Linux filesystem

[cwiggs@nixos:~]$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1                                       259:0    0 238.5G  0 disk  
├─nvme0n1p1                                   259:1    0     1G  0 part  /boot
├─nvme0n1p2                                   259:2    0 228.7G  0 part  
│ └─luks-d85bd48a-c082-4814-8d41-1504334b6045 254:0    0 228.7G  0 crypt /nix/store
│                                                                        /
└─nvme0n1p3                                   259:3    0   8.8G  0 part  

I installed this system before Heads on on this device. After I installed Heads I wasn't able to boot (makes sense). I then updated my Nix config to create the Grub files but not actually install Grub (boot.loader.grub.device="nodev").
Perhaps this section in my hardware-configuration.nix helped with Heads being able to work with DUK without your PR?

This doesn't make sense to me.

* nvme0n1p1 -> /boot (fat32), UEFI

* nvme0n1p2 -> / (ext4 under LUKS container)

* nvme0n1p3 -> swap (not under LUKS container)

But yeah, Heads can read fat32 and doesn't really care.

Unpacking initramfs from /boot to setup a TPM DUK under master (without #2155) would sill have a crypttab as a symlink to real /root/nixstore......./..../crypttab, so I don't understand why ypu don't need it. But that is another issue unrelated to the port. Will document in issue #2154

  boot.initrd.luks.devices."luks-d85bd48a-c082-4814-8d41-1504334b6045".device = "/dev/disk/by-uuid/d85bd48a-c082-4814-8d41-1504334b6045";

That's good and can relate, UUID are passed down to kexec call. Anyway this is #2154

Btw what is the status of the Kano port. Should I try and flash the most recent CircleCI build: https://output.circle-artifacts.com/output/job/b467f40a-e1a8-4a12-bef1-d14b1fe2f7c1/artifacts/0/build/x86/kano/heads-kano-202607102221-v0.2.1-3126-g2aaa5ee.zip ?

You tell me :) I'm doing cleanup for pesterity but that shoul'd impact functionality, unless bumping to recent coreboot 26.06 mrchromebook fork created issues with USB per your next comment?

I found the proper requirement for nixos installer, which is basically ticking grub-bios on /boot unencrypted partition and setting /boot as mountpoint at #2154, and confirmed, with debug trace and where crypttab fails without #2155 and works with it.

[cwiggs]

You tell me :) I'm doing cleanup for pesterity but that shoul'd impact functionality, unless bumping to recent coreboot 26.06 mrchromebook fork created issues with USB per your next comment?

I'll flash the newest .zip and start testing things next.

Is that regression of mrchromebook coreboot fork 26.03 vs 26.06?
What exactly happens there? you try to usb boot or plug dongle in usb ports and nothing happens?

I was trying to use my hardware security device (Yubikey)

Can you go to recovery shell and give debug output?
cbmem -1? dmesg?

I'll get this over to you shortly.

I'll be unavailable for the next few weeks (and 2 weeks in August), I'll be slower to respond but I'm committed to getting this over the finish line when possible.

[cwiggs]

Just checked again and it looks like my hardware security device (yubikey) isn't working on usb-c or via a usb-c to usb-a convertor on the kano device anymore. I dropped into a recovery shell and gpg --card-status shows nothing on all ports.

I'm on FW_VER Heads-v0.2.1-3123-g852dc8e

Right as I was about to post this I went to boot into NixOS and because I updated recently I had to set a new default. While going through that flow I was able to use my hardware security device to do a gpg operation so I assume something wasn't loaded to allow the yubikey to work when I just dropped into the recovery console?

Attached are the cbmem -1 and dmesg outputs.
cbmem.txt
dmesg.txt

[cwiggs]

Is https://app.circleci.com/pipelines/github/linuxboot/heads/1367/workflows/b13145ac-3a8a-482a-b99c-6124ab69ac71/jobs/50653 the most recent kano build that I should test? Looks like we might want to rebase off main/master to get the nixos changes you pushed in the other PRs?

[cwiggs]

Just checked again and it looks like my hardware security device (yubikey) isn't working on usb-c or via a usb-c to usb-a convertor on the kano device anymore. I dropped into a recovery shell and gpg --card-status shows nothing on all ports.

I'm on FW_VER Heads-v0.2.1-3123-g852dc8e

Right as I was about to post this I went to boot into NixOS and because I updated recently I had to set a new default. While going through that flow I was able to use my hardware security device to do a gpg operation so I assume something wasn't loaded to allow the yubikey to work when I just dropped into the recovery console?

Attached are the cbmem -1 and dmesg outputs. cbmem.txt dmesg.txt

I reset the tpm and I ran into the issue of the security key not being detected in either usb-c port, but it does work in the usb-a port via an adapter. Seems like this bug is intermittent.

Perhaps I can just flash the most recent image to the rom and then retry?

[tlaurion]

Just checked again and it looks like my hardware security device (yubikey) isn't working on usb-c or via a usb-c to usb-a convertor on the kano device anymore. I dropped into a recovery shell and gpg --card-status shows nothing on all ports.

I'm on FW_VER Heads-v0.2.1-3123-g852dc8e

Right as I was about to post this I went to boot into NixOS and because I updated recently I had to set a new default. While going through that flow I was able to use my hardware security device to do a gpg operation so I assume something wasn't loaded to allow the yubikey to work when I just dropped into the recovery console?

Attached are the cbmem -1 and dmesg outputs.
cbmem.txt
dmesg.txt

Looking at the logs, usb controllers drivers are loaded and everything usb is ready, your dmesg logs show detection of controllers, and then listing of ventoy prepared thumb drive with available isos listed from Heads when asking for usb boot not a default boot?

Going to recovery shell early ('r' key hammered while heads is early booting after splash screen) would bypass a lot of, going into recovery shell early from inited/init without hitting the boot script (gui-init.sh).

Frim what I can see here, nothing Heads related. The pci controllers, usb controllers are listed under dmesg. Are there some missing?

Is this usbc problem recent or was problematic before?

You should be able to see Linux kernel listing connection and removal of devices if you plug and remove them.

On usb security dongles: there is logic in code to kill gpg-agent and scdaemon, responsible to keep exclusive access on the usb dongle but none of the debug taxe shown in dmesg shows discovery/removal of the Yubikey. If you remove and add it, does the Linux kernel see it?

Tldr: heads loads Linux kernel modules once and then skip loading if already present. Hypothesis is either usbc Linux kernel drivers missing (not aware something changed there but maybe with Linux kernel version used in the port) or Yubikey having a problem?

To test: go in recovery shell, and remove plug Yubikey and see if you see trace in dmesg.

Question stays: was this working under 26.03 and regressed under 26.06 coreboot bump?

[tlaurion]

Is https://app.circleci.com/pipelines/github/linuxboot/heads/1367/workflows/b13145ac-3a8a-482a-b99c-6124ab69ac71/jobs/50653 the most recent kano build that I should test? Looks like we might want to rebase off main/master to get the nixos changes you pushed in the other PRs?

Each pushed commit builds all boards under Circleci and rom filename includes that commit id at the end of filename "*-gCOMMIT.rom/zip)

So 2aaa5ee -> https://output.circle-artifacts.com/output/job/b467f40a-e1a8-4a12-bef1-d14b1fe2f7c1/artifacts/0/build/x86/kano/heads-kano-202607102221-v0.2.1-3126-g2aaa5ee.zip

So yes: that's the latest commit from this branch, without (unneeded from you) tpm duk fixes for crypptab override creation you didn't needed. Will rebase/merge master in current branch Monday if you don't beat me to it, but nothing changed/fixed on usb side of things.

cwiggs/heads@google_kano...linuxboot:heads:master

[tlaurion]

You can check differences between commits with something like

852dc8e...cwiggs:heads:google_kano

Where 852dc8e was effectively mrchromebox based on upstream 26.03 (March 2026) not 26.06 (June) release. Maybe something off in usb init from coreboot side if you spotted a regression? But yet again, if unplugging replugging, seems to point to dongle having issues, unless working perfectly fine on another machine?

[tlaurion]

@cwiggs merged master into this branch at 5cbf889 from which commit you should be able to get kano artifacts for internal upgrade from GUI.

Still pending: usbc regression or not, usb dongle causing issue or not and OP checklist + pr against heads-wiki for board addition. Let me know if you want to co-work on what is missing in the next days in a specific timeframe or tell me a timeframe that works for you specifying timezone,