ASUS Chromebit CS10

The asus-chromebit-cs10/forky recipe builds a bootable Debian forky image for the ASUS Chromebit CS10 (google,veyron-mickey). It is an RK3288 Veyron, like the C201 and the C100P, but in an HDMI stick rather than a laptop. asus-chromebit-cs10/trixie is the same board on the stable suite.

boot2deb build asus-chromebit-cs10/forky

That produces build/asus-chromebit-cs10/forky/artifacts/asus-chromebit-cs10-forky.img.xz — a whole-disk image carrying two ChromeOS kernel slots and the ext4 rootfs, so one write lays down everything the firmware needs. The kernel is in the first slot. The second ships empty, and is what lets a later kernel upgrade roll itself back if the new kernel does not boot. See Upgrading the kernel.

What is unusual about this board

Its device tree tells you the whole story in one line. rk3288-veyron-mickey.dts includes rk3288-veyron.dtsi directly and never picks up rk3288-veyron-chromebook.dtsi. That is the file giving every other board in the family its SD slot, ChromeOS EC, keyboard, trackpad, eDP panel and max98090 codec. The Chromebit has none of those, and that single omission is what the board is:

Everything else is the family’s and is inherited unchanged: the Broadcom radio, the initramfs, the network stack, the boot method. So for all that it is the odd one out, this board costs one file. Its device file states a boot method, a board profile, a DTB and a handful of defaults, and ships no overlay at all.

Board profiles

One: mickey, which depthcharge-tools carries as a first-class board. There is no libreboot port for the Chromebit, since the family’s only libreboot profile is the C201’s. This board always runs stock ChromeOS firmware, so the crossystem step below is not optional the way it is on a libreboot C201.

You will need a USB hub

The Chromebit has one USB 2.0 port, and installing needs two things in it at once. A keyboard presses Ctrl+U, and the stick is what you are booting. So a hub is not a convenience here, it is a prerequisite.

It does work, and not by luck. The Chromebit is the one board in the Veyron family whose firmware is built with USB HID. It is the one board with no keyboard to read instead. That is CONFIG_DRIVER_INPUT_USB=y in depthcharge, and CONFIG_LP_USB_HID=y plus CONFIG_LP_USB_HUB=y in its libpayload. A keyboard behind a hub is precisely the topology this firmware was compiled for. (The inverse is also true and worth knowing: CONFIG_LP_USB_HID is not set on the C201 or the C100P, so on those boards a USB keyboard does nothing at the firmware screens.)

Use a self-powered hub, with its own wall supply. ASUS’s own documentation warns against hanging anything over 500 mA off this port directly. A keyboard plus a flash drive on a bus-powered hub is a real brown-out risk.

Flash and boot

Press the image and write it to a USB stick. A stick-shaped computer has no Ethernet, so this is the board where the Wi-Fi seed keys earn their keep. The unit joins your network on its first boot:

boot2deb press asus-chromebit-cs10/forky stick.img \
    --hostname cs10-01 --wifi-ssid "your network" --wifi-psk '...'
sudo dd if=stick.img of=/dev/sdX bs=4M status=progress conv=fsync

press verifies the file it wrote — see Producing images. Confirm the device with lsblk first, because dd overwrites it whole.

Entering developer mode. The Chromebit has no power button, since it boots the instant DC is applied. The usual “hold keys and tap power” does not exist here. The sequence is:

1. Connect HDMI, then the powered hub, then a wired USB keyboard into the hub. Leave the barrel jack unplugged.
2. Press and hold the recovery button with a paperclip. It is a pinhole on the underside, opposite the HDMI connector. Still holding it, plug in the DC barrel jack, and release when the screen changes.
3. The recovery screen appears. Press Ctrl+D on the USB keyboard. There is no on-screen prompt for it.
4. Confirm by pressing the recovery button again with the paperclip, then Ctrl+D to reboot. On a device with no keyboard the firmware treats that button as Enter.
5. It wipes and transitions to developer mode. Allow 10 to 15 minutes.

Enabling external boot. From a ChromeOS shell (Ctrl+Alt+T, then shell), once:

sudo crossystem dev_boot_usb=1 dev_boot_signed_only=0

Then reboot and press Ctrl+U at the “OS verification is OFF” screen. A 2.4 GHz keyboard with its own USB receiver works as well as a wired one. A Bluetooth keyboard does not, because the firmware has no Bluetooth stack.

If a boot fails, the board tells you by rebooting. The signed command line sets a 30-second panic timeout (sysctl.kernel.panic=30). A kernel panic, or an initramfs that gives up on root, returns to the firmware splash about 30 seconds later. A board that never reboots means the kernel never reached the initramfs at all. On a machine with no serial console that is the single most useful thing a failed boot can say. Before rebooting, an initramfs that gives up writes its dmesg and every stalled task’s stack to BOOT2DEB-PANIC.txt on each ext4 partition it reaches.

Expect several seconds of blank HDMI on a healthy boot before the console appears. The standard image leaves the DRM stack out of the initramfs to keep the signed payload under its 16 MiB ceiling. The display therefore comes up only once the real root is mounted.

Installing to the eMMC

Running from a USB 2.0 stick works but is slow, and it means the hub stays plugged in forever. The board has 16 GB of eMMC. Once the OS is on it, the Chromebit boots with no keyboard, no stick and no hub. Press Ctrl+D at the developer screen, or just wait out the 30-second timeout.

The image is a whole-disk image, so installing it is one command. Boot the USB stick, join Wi-Fi, get the same .img.xz onto the running system (scp it from the build host, or keep a copy on the stick — first boot grows the rootfs, so there is room), and write it to the internal eMMC:

lsblk                       # the eMMC is mmcblk0 — it is the one with mmcblk0boot0 beside it
xzcat asus-chromebit-cs10-forky.img.xz | sudo dd of=/dev/mmcblk0 bs=4M status=progress conv=fsync
sudo reboot                 # then Ctrl+D to boot the eMMC, or wait out the timeout

First boot on the eMMC then does what it did on the stick: it grows the rootfs to fill the device. That is all it changes — identity is stamped at build time and nothing on the device rewrites it.

Both installs therefore carry the same rootfs PARTUUID. That matters less here than it would elsewhere, because nothing on this boot path is automatic. Ctrl+D and Ctrl+U each name a medium explicitly, and the firmware verifies and loads that medium’s own signed kernel. You get the kernel you asked for.

The one thing the keypress does not cover is the root= lookup that kernel then performs, which resolves the PARTUUID by scanning attached disks. With the stick still plugged in it can land on the other medium’s rootfs. It is the same build either way, so it boots normally, but you could be writing to the disk you thought you had left behind. Pull the stick once the eMMC is written and the question does not arise.

Why this needs no kernel patch, contrary to the usual advice. The Veyron eMMC ships with its primary GPT deliberately corrupted. ChromeOS marks it IGNOREME and uses the secondary, and a stock Linux kernel cannot read a partition table like that. Every guide therefore tells you an eMMC install needs a patched kernel.

That is true only if you keep the factory GPT. Writing a whole-disk image does not keep it. It lays down a fresh, valid GPT over the top, and a stock kernel reads that one like any other. (postmarketOS does exactly this on the C201’s eMMC and boots from it.)

Keyboard

A board with no keyboard still declares a console keymap, and it is not a contradiction. The question keymap answers is “does a console layout configure anything here?”, not “does the board have keys”. The Chromebit drives an HDMI console that a USB keyboard is the only way to type at. A layout therefore means exactly what it means on a laptop, and just describes a keyboard you bring. The default is us.

There are two ways to get another layout, and neither is a build flag. An image’s keymap comes from the config its lock was resolved against:

• Change it on the running board, offline, like any Debian system:

  sudo dpkg-reconfigure keyboard-configuration && sudo setupcon
  

• Bake it into an image by writing a recipe that sets keymap. resolve shows what a choice resolves to before you commit it, and names the file to write:

  boot2deb resolve asus-chromebit-cs10/forky --keymap gb
  

  See Adapting a shipped recipe and Locale, timezone, and keyboard.

This has no bearing on the firmware screens. Depthcharge reads Ctrl+U with its own USB HID driver and its own fixed layout, long before Linux exists.

See Locale, timezone, and keyboard.

Getting online

There is no ethernet port, so Wi-Fi is the only way onto the network:

sudo nmtui        # pick "Activate a connection", choose the network, enter the key

The radio is the family’s Broadcom BCM4354, and needs two blobs Debian does not ship. They are vendored on the SoC layer and are already in the image.

Bluetooth works the same way as on the laptops. The BCM4354’s Bluetooth half is on uart0, the kernel loads the vendored patchram, and bluez is installed to use it.

Bluetooth audio takes libspa-0.2-bluetooth on top. PipeWire’s Bluetooth plugin is only a Suggests of wireplumber and pipewire-pulse. A desktop install therefore does not bring it in, and a headset pairs with no sink to play to.

Audio and display

Both come out of the HDMI connector and nothing else does.

Audio is HDMI only. The Chromebit’s sound node wires straight to the HDMI codec with no audio-codec phandle, so the machine driver builds a different card entirely. ALSA shows ROCKCHIP-HDMI, not the ROCKCHIP-MAX98090-HDMI the laptops get. There is no max98090, no headset codec, and nothing to unmute. The family’s 20-audio first-boot hook probes for the codec’s mixer controls, does not find them, and exits without touching anything. That is the correct outcome, not a failure.

Display is HDMI only, and simpler than on the laptops. The Chromebit lights one display controller (vopb), and there is no eDP, no panel and no backlight. It is therefore free of the trap the C201 has, where two controllers advertise the same maximum and DRM picks between them at runtime.

HDMI does 4K30 and cannot do 4K60. That is the silicon. The RK3288 caps TMDS at 340 MHz, its PHY has no scrambling above that, and the VOP cannot emit YUV420. There is no reduced-rate path either. Nothing in the image configures any of this.

Status

Not yet booted on hardware. The image builds, and every part it has is shared with a board that does boot. It has the same boot method, signed-payload flow, initramfs, radio and Debian kernel as the C201. That board is confirmed booting to a login prompt. What is untested is this board’s own firmware, and its DTB.

Two things to know before you try it, because they are the reported failure modes:

• USB boot on the Chromebit has been reported to fail. A 2015 review could not boot a stick at all, and there is an unanswered forum thread where Ctrl+U flashes black on a postmarketOS image. Both are most consistent with malformed boot media rather than a firmware limit. That is a kernel partition not in ChromeOS format, or one whose GPT attribute bits are unset. boot2deb’s payload is built by depthchargectl against the board’s own profile, and its attribute bits are asserted at build time. Expect it to work, but this is the board’s open question.
• No one has confirmed an eMMC install on a Chromebit. The one public attempt fails with “Primary GPT header is being ignored”. That is the factory GPT being preserved, which writing a whole-disk image does not do. The reasoning in Installing to the eMMC above is sound, and the same flow works on the C201. It has not been run on this board.

Audio, Bluetooth and HDMI ship configured and are unverified here.

The family

The Chromebit is the awkward member of the family and it still costs exactly one file. It ships no overlay and needed no change to the engine. Everything that makes a Veyron boot lives on the SoC and boot-method layers. A board that is a stick rather than a laptop inherits all of it unchanged. The same holds for the C100P, and for the seven Veyron boards not yet written.