I had also never used ChromeOS, and was really curious. At the time I was developing Android apps, and being able to code natively and run the app on-device sounded exciting. It turned out to be disappointing because the performance in ChromeOS was not really there, and I had to run everything Linux through a container, which felt awkward. I quietly stopped using the device.

A while later, I realized that postmarketOS supported it. That meant a real Linux distribution, based on Alpine Linux, with any DE (GNOME, KDE, etc.) and proper Linux tooling and performance. I had to try.

Installing postmarketOS was really easy, thanks to the effort they put into the wiki and the installation guide. Basically: put the device in 'developer mode', download an image, write it to a USB stick and boot from it using the 'developer mode' menu. You then land in a live postmarketOS image you can use to install to the eMMC.

The ChromeOS firmware 'developer mode' menu, which allows you to select boot media, USB or internal storage. Mine is in French. 'Start legacy BIOS' does nothing here; I suspect this only works on x86 Chromebooks, and they just reused the same firmware.

So far, so good: they even have images with preinstalled DEs like GNOME. I'm a heavy GNOME user on my main computer, so I went with that one. Unfortunately, it turned out to be a mistake. GNOME can be quite resource-hungry, which didn't suit the device's weak CPU and 4 GiB of RAM. It was a bit slow, and there was too much friction for it to be really usable. I also find GNOME ill-suited to a "minimalist" workflow - it tends to go all out. Thinking about it now, a tiling window manager with a terminal-centric workflow would have surely been better for the device.

I kept using it from time to time anyway. Eventually I updated to postmarketOS 26.06, and then the device refused to reboot.

I managed to boot the old 25.12 version, but even writing 26.06 to a USB stick and booting it does not seem to work. Something must have changed between the two versions that silently breaks boot on the Duet. While investigating, I realized that all the necessary drivers were now in the mainline kernel. I also now work at Canonical on Ubuntu development, doing bring-up of RISC-V devices. Given the state of the Duet, an Ubuntu bring-up seemed genuinely feasible. So... I have a weekend. Let's do it!

Installing Ubuntu?

At this point, I have almost no idea how postmarketOS boots on the device, what the boot flow looks like, and whether anything will work with Ubuntu. One of the easiest ways to get 'something that looks like Ubuntu' is to replace the postmarketOS 26.06 rootfs with an Ubuntu rootfs. So that's what I did.

I booted into my postmarketOS 25.12 USB stick. First, I inspected the state of the internal eMMC storage:

Running fdisk on /dev/mmcblk0, printing the partition table

Ok. So there's a mysterious "ChromeOS Kernel" partition, a /boot EFI partition, and then the rootfs partition. An easy way to then install the Ubuntu rootfs is to just replace that one. Which is exactly what I did, in the dumbest possible way:

# mount /dev/mmcblk0p3 /mnt
# ls /mnt/boot
   Nothing, so /dev/mmcblk0p2 was mounted on /boot
# rm -rf /mnt/*
   Removing all files on the old postmarketOS rootfs
# curl -L -O https://cdimage.ubuntu.com/.../ubuntu-base-26.04-base-arm64.tar.gz
   Downloading the Ubuntu 'base' image, a minimal Ubuntu rootfs
# tar -C /mnt -xzf ubuntu-base-26.04-base-arm64.tar.gz
   Extracting that base Ubuntu rootfs at /dev/mmcblk0p3

With that, I was ready to chroot into /mnt to enjoy my new Ubuntu system.

Chrooted from the postmarketOS 25.12 USB stick into /dev/mmcblk0p3 with the new Ubuntu rootfs. I even installed some packages, like fastfetch! Notice the 6.12.87-mt81 kernel: that's the postmarketOS kernel from the USB stick.

Ok, this is all very nice, but living inside a chroot forever and having to boot from USB just to mount the internal storage doesn't feel great at all. Time to see if we can boot into this new rootfs! I expected this to fail, since I assumed something was wrong with the new postmarketOS 26.06 kernel, but to my surprise it worked flawlessly. Which means the 26.06 issue must have been in the rootfs startup programs, silently crashing something.

Booted from internal storage into the Ubuntu rootfs on /dev/mmcblk0p3. Notice the new 6.18.44-mt81 kernel: that's the postmarketOS kernel from the 26.06 installation, on the /dev/mmcblk0p1 or p2 boot partitions.

As you can see, the device now calls itself localhost, so I'd have to do some setup to finish configuration; but I had already created my user account in the chroot before. Another issue: the new rootfs lacks the firmware for the postmarketOS kernel, so Wi-Fi no longer works. A simple fix is to take the 26.06 image, extract the /lib/firmware/6.18.../* tree and copy it into the rootfs, which would restore Wi-Fi.

But that means staying with the postmarketOS kernel, unable to update. I did not want that, I want full Ubuntu running, including the kernel.

So I did the simplest thing: I installed the linux-generic package from the archive. It copied vmlinuz and initrd into /dev/mmcblk0p2, the /boot partition. I also copied the upstream DTB for the device into the /boot partition, so I could hardcode it on the kernel command line if needed. I expected everything to crash, nothing to work, since I didn't know the bootloader and assumed the kernel wouldn't get the right DTB. I rebooted.

To my surprise, the machine booted normally. Better yet: I ran fastfetch again and everything was identical, including the kernel version.

Wait, what? I had just overwritten that kernel in the /boot partition. Is that partition not used at all?

Using the Ubuntu kernel

Understanding the boot flow

Clearly, I needed to take a step back and actually understand how the machine boots, as trying random stuff was not going to work anymore. So I read some resources and talked with Claude, giving him (it?) the URLs and asking for a boot flow explanation.

Turns out the boot flow is a bit complicated on Chromebooks. Here are the schematics that Claude generated when explaining the chain to me. I find them quite clear.

Firmware boot chain for Chromebooks. The boot ROM contains the FSBL, which loads Coreboot, which has upstream support for the Duet. Then, Coreboot loads the ARM Trusted Firmware (not relevant to this analysis), which then loads Depthcharge, the bootloader for ChromeOS devices.

So Depthcharge, the ChromeOS bootloader, is also what shows the 'Developer Mode' menu that lets me pick between USB and internal storage at boot. This is really interesting. Now, what is the next step? What does Depthcharge actually load?

Depthcharge booting internal storage. It only cares about the first, mysterious "ChromeOS kernel" partition. That actually contains a FIT image, which here is basically a bundle of kernel, initrd and device tree.

That clears up the mystery! The /boot partition was never actually used at boot, only by postmarketOS to prepare the Depthcharge FIT image (using the mkdepthcharge tool). So installing my new kernel there was not enough. I would also have to re-generate the Depthcharge image.

EFI environment needed

Although this would be very easy, it would unfortunately not work. See, in this boot flow, there was never EFI-capable firmware involved. Neither EDK2 nor U-Boot is used: Depthcharge loads and boots the kernel directly from the FIT image. That works fine for the postmarketOS kernel, but not for the Ubuntu kernel, which is an EFI executable and expects an EFI environment. Ubuntu only boots via UEFI.

So, we need a UEFI-capable firmware. The easiest to get working would be U-Boot: EDK2 can be harder to work with, and U-Boot already has support for the mt8183 SoC. That support is only present as a config for the 'Pumpkin' reference development board of the SoC, so we will need to do some work into U-Boot to be able to boot it. Our goal is to chainload U-Boot via Depthcharge, in order to get a UEFI environment, that will be able to boot Grub which will then boot our Ubuntu kernel:

Target boot flow after Depthcharge.

Let's get started hacking U-Boot! Wait, but do we even know how to print something to the screen? How are we going to debug this? We can't expect U-Boot with no drivers at all for the board to work right away printing debug logs... and bringing up a screen is not easy. Let's think this through.

U-Boot

Our target

Our goal is to have U-Boot chainloaded as a Depthcharge payload, for it to then be able to access the eMMC and load Grub that is there. Grub will then use the UEFI storage drivers, i.e. U-Boot drivers exposed over the EFI API, to load the kernel and initrd.

U-Boot already has support for the mt8183, so we won't need to write the drivers, which makes this work possible. Unfortunately, we will still need board-specific adaptations for the Lenovo IdeaPad Duet. I'll also refer to it by its codename kukui-krane (kukui being the codename for the mt8183-based chromebooks, krane for the specific Lenovo IdeaPad Duet).

Realistically, we will need some form of logging to debug our U-Boot build. Two options:

• Using a serial output on the board. This is actually possible, with what is called a SuzyQable which enables 'CCD', Closed-Case Debug, and gives you a UART interface on Chromebooks. Unfortunately, I don't have such a cable (I've ordered one).
• Using the screen directly. Harder, because we would need to write a driver for that specific panel, or the specific framebuffer as initialized by Coreboot. It is also something that we ultimately want: proper U-Boot support for the device. So let's go!

The Coreboot source tree has a krane_panel.c file with some of the panel initialization code. I was not so sure what to do with that, but I figured that either we could use Coreboot/Depthcharge code to rewrite a panel driver, or directly use the framebuffer that Coreboot had already set up. So I gave Claude that suggestion.

Immediately, it started with a wonderful idea: instead of trying to make that work inside U-Boot directly, just write an assembly stub that shows colors on the screen. It also figured out how to read Coreboot's "LBIO" table to get the framebuffer details. I asked it for a detailed prompt for an agent to implement that, and it wrote one.

krane-fb-stub

I rebooted the Duet, installed OhMyPi and connected it to GLM-5.3-Flash. I then gave it the prompt Claude had prepared, and it started implementing the stub and investigating all available kernel/firmware logs on-device.

Task: Build and test a minimal ARM64 "hello framebuffer" stub for a Lenovo

IdeaPad Duet (MT8183 / Krane)

Goal

Produce the smallest possible standalone ARM64 binary that depthcharge (the ChromeOS firmware bootloader) can load as if it were a Linux kernel, which does nothing but locate the already-initialized boot-splash framebuffer and fill it with solid colors at distinct checkpoints. This validates the whole depthcharge → custom-payload pipeline before any real U-Boot bring-up work begins. No U-Boot involved yet — this is a from-scratch freestanding binary, as small and dependency-free as possible.

Extract of the prompt fed to my local OhMyPi + GLM-5.3-Flash agent

The agent happily started writing ARM assembly as the entry point, then C code for the actual "color display" thing, i.e. parsing Coreboot tables and device tree, finding the framebuffer, and utility code for showing colors.

The flow went like this: the agent would make a build, then bundle it into a Depthcharge image and flash it to internal storage. Then I would reboot into it, see what happened, and report back to the agent. It took a total of 10 tries for us to get a fully working stub.

OhMyPi testing the framebuffer stub in QEMU, mid-implementation (not part of the prompt, by the way)

There were small issues, like wrong register layouts, which required going back and comparing the Coreboot and Depthcharge trees. Debugging was hard at first, because "black screen, no backlight" could mean anything, from no payload at all, to any part of the display driver being wrong.

Eventually, it figured out the real issue. Depthcharge was actually blanking the screen, killing the backlight, and disabling the display. That is a real problem, that the agent chose to circumvent by adding a revival step: exactly undoing what Depthcharge did, right after handoff.

Afterwards, debugging got easier: I started seeing backlight patterns (blinks) that I could describe to the agent as feedback. Soon enough, there were colors on the screen.

Finally, the stub was complete, and showed the color sequence imagined by Claude: red (early init), yellow (DTB parsed), green (LBIO parsed), blue (all good). This was actually completely faked by the agent, as early init, DTB and LBIO are all required to find the framebuffer, so it just parsed all and showed all colors in a sequence. In any case, drawing to the framebuffer now works!

The final stub booted on the Duet

U-Boot using the framebuffer

So, this framebuffer revival hack is a bit ugly; but I still do not have a serial cable and I would really like to be able to see U-Boot logs on the screen, and now we have a way to print to the screen, so let's go with that.

With the stub done, I asked the agent to prepare a prompt for a new session to get U-Boot working on the board, including graphical output reusing our work from the stub.

Task: bring up mainline U-Boot on the Lenovo IdeaPad Duet (google,krane sku176, MT8183)

You are taking over a bring-up that just passed its first milestone: a minimal bare-metal payload ("krane-fb-stub") boots via depthcharge and draws to the panel. Your job is to replace it with mainline U-Boot as the payload, with a working framebuffer console, in a form that is upstreamable to mainline U-Boot later.

Current state

U-Boot shallow clone: /home/vhaudiquet/u-boot (mainline main, ~2026-08). SoC support exists: arch/arm/mach-mediatek/mt8183/. Reference target: configs/mt8183_pumpkin_defconfig (CONFIG_POSITION_INDEPENDENT=y, MTK serial, mtk-sd MMC, WDT, USB). dts/upstream/src/arm64/mediatek/mt8183-kukui-krane-sku176.dts exists; there is NO krane/kukui defconfig or board dir yet — that is your starting point.

Extract of the agent prompt for the new session, for U-Boot bring-up

This was unexpectedly a lot harder than the framebuffer stub. It took 27 tries before U-Boot ran properly on the device.

The first flash went in the worst possible way, i.e. the screen was pitch black again. This is really bad, as I cannot know anything about what is wrong from the observation.

I suggested that the agent use the same kind of debugging we did before: show colored bands on the screen for every step. One in the stub (which was kept at first for the revival step), one as first step in U-Boot, etc. This helped a lot to pinpoint the issues to the specific lines of code involved.

It turned out that the issue was very early in U-Boot (the agent added something like 13 checkpoints, and I only saw the second one). Actually, the steps were a bit more embarrassing, with errors made by the agent thinking something was already in U-Boot when it was in the stub, and other issues, but we ended up finding the big one: an alignment problem.

There are two separate alignment requirements in play here, and they can't both be satisfied at the same address:

• depthcharge's boot protocol hands control to a fixed offset: 0x40 bytes into the payload. No matter what. On this device that offset is not a multiple of 4096.
• U-Boot, built as position-independent code, requires its entry point to be on a 4096-byte boundary. Its startup code literally checks this and spins forever if it doesn't hold, because the relocation math it does immediately afterward assumes it.

The only way to fix that seems to be keeping a shim loader, that can have its entry point at the address that Depthcharge wants, and that will jump to U-Boot afterwards, which can be anywhere in the payload. So this is what we did.

Everything after that was faster, and the issues that were left were all small (missing environment variable in defconfig for the board, reset that turned out to be a panic and a crash in the video driver's memory mapping, as U-Boot was running out of page-table space). Eventually, we got rid of all those issues, and U-Boot finally showed up on the display.

U-Boot finally appearing on the Duet. It shows up in portrait instead of landscape, with all the diagnostic color bands from earlier.

Console and USB keyboard

Nice! We have U-Boot running. We can remove all of those silly diagnostic bands.

The console appears in portrait, and given that the device has an attached keyboard, it makes more sense to display it in landscape. So we need to add a rot=3 parameter for the screen orientation by default.

Once we have this, we also need to rebuild U-Boot enabling all UEFI-support related configurations. Then, time to try and boot! Wait, I can't type anything?

Right, so we first need to make the keyboard work in the U-Boot console, which will help with debugging. All we need is to enable a pre-init sequence that will run the USB set-up (even though the keyboard attaches via pogo pins, those pogo pins actually carry USB data lines).

Then we can start typing. Let me type 'help' to look at the commands and... weird, the console does not scroll. The text overwrites itself in a weird way? That was really puzzling. I reopened the agent and explained the problem, since it didn't look like a straightforward issue.

It turns out that it was not a straightforward issue at all, as it was actually an upstream bug. I prepared an upstream patch that fixes scrolling on a weirdly rotated screen (i.e. screens where rot=1 or rot=3). This is literally a one-character fix, that the agent pointed out. Nice to run into that and fix it!

Now we can finally try booting.

Booting the eMMC

Let's go! bootefi bootmgr is the magic command that starts the EFI boot manager and tries to boot the EFI entries. Typing that, and... nothing. Right, we don't have any EFI bootable executable yet on the EFI partition... the Ubuntu chroot does not contain grub and it was never installed properly. So let's reboot into the chroot from the postmarketOS USB stick and install Grub:

$ sudo apt install grub-efi-arm64
... installing grub package ...
$ sudo grub-install --target=arm64-efi --efi-directory=/boot/efi \
                    --boot-directory=/boot
... installing grub to /boot and /boot/efi ...

Now let's try booting again. This time, bootefi bootmgr takes us to Grub!

The Grub prompt appearing for the first time on the Duet. Sadly, that's not a Grub menu... something went wrong when Grub tried to load its configuration.

After investigating in Grub console, I can manually make it load grub.cfg; something seems wrong at handoff time, and Grub cannot access the eMMC. Maybe it is because U-Boot is still using it, so Grub cannot directly access it, and then Grub fully loads without its config, U-Boot lets go of the eMMC, and Grub can now access it, but too late. In any case, we can manually progress to a menu.

The only issue is that the menu was in portrait. After changing Grub config, we can finally get to a clean landscape Grub menu!

The Grub menu, finally working for the first time on the Duet.

Finally, let's boot into Ubuntu! I see some kernel logs, in portrait of course, and... what's happening? Why is the display suddenly corrupting itself? Oh. Right. Our display framebuffer is a hack.

Remember the "revival" hack to reuse the framebuffer from Coreboot for U-Boot and Grub? Well, it seems that the kernel did not like it. After the end of the earlycon which uses that same EFI-provided framebuffer, the kernel tries to set up the display for itself, finding it in this weird hacked state. At least that's my theory. In any case, the display shows weird things: blinking bands, logs disappearing, lines appearing here and there. Something is wrong.

Given the display hack and the fact that there was no way I was going to see kernel logs on there, it felt only natural to try and implement a real panel driver for U-Boot and drop the hack once and for all. So that is what I (or rather, the agent) did.

Panel driver

So.... we have to write a real panel driver. How do we do that? This was also the end of the weekend, and I was starting to feel tired. But I was set on starting the real panel driver work when convenient for me.

I had some time on weekday evenings and the next weekend, but not enough of course to try and write a driver myself. So I started another agent with that mission:

Task: proper MT8183 display pipeline bring-up (MIPI DSI host + PHY + BOE TV101WUM-NL6 panel driver) for U-Boot on the Lenovo IdeaPad Duet (google,krane sku176)

You are taking over an in-progress U-Boot port on this machine. U-Boot already boots on the device with a working rotated vidconsole. Today's display path is a "scanout" driver that revives the display pipeline left running by the boot firmware (coreboot + depthcharge) instead of bringing it up itself. Your job is to add a real display pipeline: a MediaTek MT8183 MIPI DSI host driver, the MIPI TX PHY, and a proper driver for the panel (BOE TV101WUM-NL6), so U-Boot brings the panel up from scratch and no longer depends on firmware handoff.

This also meant going back into the dark: no screen output at all if something failed. Back to blinking screens and dark panels. After 3 flashes like that, it was clear this wasn't going to work. Debugging a real display driver with blinking lights alone is just not realistic.

Remember the SuzyQable I ordered? Well, it fortunately arrived around that time. It's not a cable per se, but rather a small SuzyQ adapter that you plug any regular USB-C cable into for the host connection.

The SuzyQ adapter. It plugs into the device's USB-C port and connects to a host computer with a USB-C cable, giving serial access.

This required a small amount of work to bring up serial support in U-Boot: just changing the baudrate in the defconfig to 115200. Not obvious at first, but pumpkin, the reference mt8183 board in the U-Boot tree, sets the baudrate to 921600, and that setting had been carried over to kukui_krane.

After that, serial helped spot the issue with the panel driver: the agent had forgotten to set a property that gets read during initialization, leading to a NULL pointer dereference. An easy fix. Once that was done, the panel driver worked. I would have expected this to be much harder, but with serial the issues were easy to spot, and the agent mostly adapted work from the existing Coreboot panel driver (and the kernel one), which made the task easy for it (him?).

Technical details on the panel driver and the whole U-Boot saga are available in the "Cleaning up the U-Boot tree" section below. Before that, let's boot the kernel.

First kernel boot

A missing module

Finally, we can try booting our Ubuntu 7.0 kernel! Booting it with Grub went fine but then the kernel got stuck in initrd. Dracut dropped me into an emergency console, and it couldn't see any of the devices: screen, eMMC, nothing. It seems that we are lacking a module...

Indeed, after investigating, we had to modify the initrd to include: mtk_pmic_wrap, mt6397, mt6358_regulator modules. This allowed the other modules to work properly and detect all the devices.

This is an intricate problem of module dependencies, and it is unfortunately not solvable as-is by just adding rules in the kernel. The cleanest fix in the kernel is to set MTK_PMIC_WRAP, MFD_MT6397, REGULATOR_MT6358 to y and not m when configuring the kernel. The less clean fix is to add hooks to dracut or initramfs-tools to force load them in the initrd, which is what I did here.

The hang: fixing with an agent

Once the module issue was fixed, booting got to the initrd again, but the kernel output on screen got stuck once the boot console went down. It seems that the U-Boot display driver keeps control of the screen, so when the kernel wants to take over and bring the display up itself, it can't. That is ok, it is also something we can fix directly. We still have the rest of the logs over serial now (with the SuzyQ), so let's follow... wait... why did it stop there?

So it turns out that the kernel 'hangs' in the middle of initrd, sometimes before, sometimes after pivoting root and showing the login prompt. I've had a true nightmare debugging this. I was pretty sure it was a U-Boot issue (something going wrong in the handoff), but the agents were convinced that there were upstream kernel bugs everywhere. We tried many things in random order, including a lot of changes that weren't necessary.

This ate a lot of my evenings and got nowhere.

In the end I had the new OpenAI model, GPT-6 Astra, take a look, and maybe because it was new (so its knowledge cutoff was later), it found a real issue: an upstream kernel patch not present in the 7.0 kernel, "pmdomain: mediatek: Fix mt8183 hang on boot". At that moment I thought Astra was magic and everything was solved. I was about to find out that I was wrong.

To try it, I tasked an agent with rebuilding the 7.0 kernel for me with that patch on top and the Ubuntu default configs. Somehow, that didn't work at all: the kernel didn't boot to initrd properly. Kernel builds were also very slow on the device, and I had to rebuild all the modules, which was even slower. That was not fun at all.

I decided to switch to the development release, Ubuntu 26.10 Stonking Stingray. It has a 7.2 kernel packaged, which is more recent, contains that patch, and maybe other fixes introduced along the way. Upgraded the kernel package, rebooted... and... it's just like the 7.0 kernel. Same hang. Astra was wrong.

So, this patch might be useful, but the hang that it fixes seems very specific and might not be the one I was experiencing. It still allowed me to switch to a more recent kernel, and to consider the fact that there might be multiple bugs involved causing multiple different kinds of hang. That might be a reason why the agent went in all kinds of random directions and each fix did not seem to change anything.

Getting (a bit more) involved

I decided to change my approach and get a bit more involved in the fixing process. I started reading a full boot log from a hang, looking for every error or weird stuff in chronological order.

The first weird thing was in the U-Boot startup log over serial:

U-Boot 2026.10-rc2-00071-g7670f264dc3a (Sep 10 2026 - 21:09:40 +0200)

CPU:   MediaTek MT8183
DRAM:  2 GiB
Core:  47 devices, 14 uclasses, devicetree: separate
MMC:   mmc@11230000: 0, mmc@11240000: 1
Loading Environment from nowhere...
Loading Environment from nowhere... OK
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Net:   No ethernet found.

U-Boot banner and initial logs. Do you see something weird?

U-Boot only reports 2 GiB of DRAM! We had some issues around memory reservation tables and the EFI memory map before, so this might be real. Could be harmless, but might be a problem, so let's fix it. That one was easy to hand to an agent. In parallel I had other agents working on fixing the slow display bring-up, and the slow serial console.

The agent fixed this the right way (reading Coreboot tables to find the actual amount of memory on the board), and also the wrong way (adding a config override to 4 GiB in defconfig for kukui-krane). Given that kukui-krane only exists in 4 GiB variants (to my knowledge), I decided to still keep the defconfig entry, but verified (with logs) that the Coreboot read worked:

DRAM:  DRAM: coreboot tables at 0xffed9000 report 4096 MiB of usable RAM
4 GiB

U-Boot reporting 4 GiB RAM after reading the Coreboot tables

I spotted other small issues in the logs and tasked the agent with fixing them one by one, each in a new session. That took a bit more time and involvement, since I was analyzing everything and verifying the work each time.

Ubuntu works (?)

Afterwards, I rebooted, wanting to retry a full chain, capture a new log, and address the remaining errors. To my surprise, after rebooting once, twice, and multiple times: boot worked flawlessly every time, and I could actually use the system. Finally.

Ubuntu 26.10 development release, with the Ubuntu 7.2 generic kernel, actually running on the Duet. Finally. All of this for a single 'Kernel' line change... :)

I started using the system, connected to Wi-Fi (which worked fine!), cleaned up patches, ran an update and... oh. Stuck again. During apt upgrade. I rebooted, ran the dpkg command to fix up the upgrade, and... stuck again. Always while dracut was generating the initramfs. That's a problem.

I tried multiple things, but it turns out that the machine still seemingly hangs in some CPU-heavy tasks, or long-running tasks. At this point, it's a bit hard to reproduce: you have to use the machine for 20+ minutes before it shows up. Specific operations like apt upgrade seem to trigger it every time, though. I tried looking online, and it seems that the LKML has recent patches for that SoC.

For now, I don't want to try rebuilding another kernel. I want to try and clean up everything in the U-Boot code, which I first did with agents again. Adversarial reviewers found style issues, stale comments, etc. They also addressed some display performance issues. I made sure to clean up stale configs and build caches, then to rebuild with the kukui-krane defconfig. Below is a video of the final boot flow for Ubuntu on the device.

Full boot chain on the display. Depthcharge kills the display, U-Boot brings it back up, Grub is loaded, EFI exitBootServices kills the display again, to allow the kernel to bring it back up again. Could be optimized, but working.

Cleaning up the U-Boot tree

After all of those debugging steps, the U-Boot tree was a bit of a mess: 43 commits on top of main. 43.

That is a lot, so I started refactoring, squashing, dropping, and cleaning up all of this. After a heavy pass, that also caught issues (performance-wise, potential bugs in the driver, or stylistic errors, all through this 'static analysis'), I ended up with 20 commits. Still a lot, but more manageable. Here they are:#Commit1arm: mediatek: add MT8183 kukui krane board support2scripts: Makefile.lib: prefer upstream DT includes with OF_UPSTREAM3serial: mtk: leave the sample count alone in low-speed mode4video: console: fix scrolling and cursor position on rotated consoles5video: console: report damage when showing the cursor6efi: console: re-sync the vidconsole cursor and accept stdout lists7boot: image-fdt: treat duplicate region reservation as a no-op8clk: mediatek: mt8183: add MMSYS display clock gates9gpio: add MediaTek MT8183 GPIO driver10phy: add MediaTek MT8183 MIPI TX D-PHY driver11video: add MediaTek MT8183 MIPI DSI host driver12video: add MT8183 cold display bring-up for krane with BOE panel13video: mt8183: quiesce the display pipeline at ExitBootServices14arm: mediatek: mt8183: enlarge the page-table budget for dynamic display mappings15arm: mediatek: mt8183: determine the real DRAM size from the previous bootloader16mmc: mtk-sd: bounce DMA above 4 GiB and keep U-Boot inside the 32-bit window17usb: xhci: bound the interrupt-in event wait to unblock the console18usb: xhci-mtk: shut the T-PHY down on remove19arm64: dts: mt8183: krane: describe the SSUSB block for U-Boot's xhci driver20board: mediatek: mt8183: finish the krane configuration for EFI boot

Full commit series added to U-Boot at the end of the experimentation, after a cleanup phase.

This is all the changes that the agents added, grouped together when that made sense (for example, there were 8 commits for the DSI driver, with fix-up stuff and performance improvements, so they all got squashed together to make a final commit for the DSI driver). As you can see, there are also changes that aren't for the board itself, but to fix a more generic bug, like "video: console: fix scrolling and cursor position on rotated consoles", sent upstream already. Some of those changes might not be useful at all though, or even break other boards, so this will need a manual review. Let's do that.

First, we need to walk through the generic upstream bug candidates, that have virtually nothing to do with MT8183:

• #2: a real bug in the U-Boot machinery for OF_UPSTREAM devicetree usage (which is used to sync the DTS of the board with the one in the upstream kernel). This is a specific case of the SoC having both a legacy and an upstream dt-bindings header. Really looks like a genuine bug, will be sent as PATCH RFC upstream after verifications.
• #4: already sent upstream to fix scrolling on weirdly rotated screens
• #5: reporting video "damage" when the cursor is set visible. Damage was missing for this specific function, so when having the video console in "only refresh damaged parts" mode, showing the cursor would not work until the next update. Will be sent upstream as PATCH after verification.
• #6: another simple bug fix, related to EFI console output string. This is just a re-sync of the cursor in the EFI console with the one in the U-Boot video console. This will also need evaluation to see if it is really needed, but another candidate for a standalone upstream patch.
• #7: seems like a wrong patch. It is a change to treat a second reservation of the same region for the same purpose as a no-op. That seems like shadowing a real issue that the reservation function was called twice, and will need further investigation why (and maybe a patch). Moving on, dropping it.
• #17: also seems a bit weird. This was added by the agent when investigating serial typing slowness when video was on, and it somehow seems to address a USB keyboard typing slowness which never existed, by creating a new, smaller USB driver timeout kind for waiting over an interrupt. Dropping it seems fine.

Then, we can tackle the MediaTek fixes (not specific to MT8183 SoC):

• #3: this one was hard to understand for me at first. It only adds a

  if(samplecount <= 1) return; line in the MediaTek serial driver function that sets the baud rate. The agent added a five-line comment referencing our Coreboot firmware in this generic MediaTek driver, so something was wrong. But the commit itself was in fact right, it seems: the function is writing uninitialized data into serial controller registers without this. I'm not sure why this was never seen before, but it might be because on most boards, those registers have null initial value, and it happens that in this particular case it would write a zero. But with my board that has serial controller already initialized from Coreboot, something went wrong with that and it caused an issue. That seems like a nice catch, that will need further testing before being forwarded upstream.

• #16: the SoC has a weird quirk: the MMC controller's DMA engine has 32-bit address registers. Given that we have 4 GiB of usable RAM on krane (and could have this much or more on other boards), with a non-zero memory-map base, addresses can go over the 32-bit unsigned integer maximum. So we need to split the memory at that point. What this patch does is that it only allows U-Boot allocations on the 0x0-0x1_0000_0000 memory range, but shows the whole memory map to the EFI consumers. This feels like a hack, technically I guess only the DMA engine should be restricted, but U-Boot has no mechanism to do that as far as I know, so I will keep it this way.
• #18: a simple one-line change to call xhci_mtk_phy_shutdown() on driver removal, so that the kernel can bring up the driver on its own later. Simple fix to verify and send upstream.

Now, we are left with the board enablement patches, that we want to send as one or multiple patch series upstream:

• #1: defining the defconfig for our board and renaming mt8183_pumpkin.c to mt8183.c, as it becomes generic
• #8: there were missing clocks in the SoC's clock driver, notably the specific clock that the display DSI driver will use. This adds support for those.
• #9: this adds the missing GPIO driver for the SoC, which is needed to then be able to reset/power enable the display. Adapted from Depthcharge.
• #10: this adds the "MIPI TX D-PHY driver" for the SoC. That gets a bit technical. "MIPI", "Mobile Industry Processor Interface", is an alliance (ARM, Intel, Nokia, TI, ST) that standardizes interfaces in mobile SoCs. So this driver is for a specific MIPI standard, for a Transmitter (TX), that does something on the physical layer (PHY). This driver was ported from the Linux kernel by the agent. This is the physical layer for the transmitter that will be used by the next driver.
• #11: this adds the "MIPI DSI host driver" for the SoC. DSI being Display Serial Interface, the protocol standard, defined by MIPI again, to drive displays. This specifies how pixels, commands (e.g. brightness), and video timing signals are sent to the screen.
• #12: finally, this commit unites them all to add the display driver. It uses #9 to power on the display, then the DSI interface from #11 (that uses the #10 PHY driver and #8 clocks) to drive that specific "boe_tv101wum" panel present on the Duet. Adapted from Coreboot and verified against Linux kernel.
• #13: this shuts down the display when EFI ExitBootServices() is called, i.e. right before the kernel starts, to allow it to take over from an uninitialized display, the same kind of state that Depthcharge would have left the display in. This might need a change, as there might be a way to tell the kernel in what state we left the display, for it to use it for earlycon, and take over after. This will need more investigation.
• #14: this one is another that left me a bit puzzled. It defines a get_page_table_size() function, that returns SZ_256K, inside the mt8183.c file. That is it. This is actually a function that is called during the generic initialization path, and the issue is that the default page table budget is not enough to map the Coreboot table and the framebuffer for the display. That seems to be the standard pattern to account for that, present in Apple platform files as well, so I left it as-is, but will need to check a bit more before trying to send it upstream.
• #15: this one allows detecting the real memory present on the board from the Coreboot tables, instead of relying on the static "2 GiB" from the devicetree. The code is in the generic init path for the MT8183, which seems wrong to me, as this has a lot of Coreboot-specific paths. So I think this should be abstracted away in a Coreboot table driver that can extract information, and multiple different paths to check whether this driver should be used. It will need a bit more work.
• #19: this commit adds a U-Boot-specific overlay for the krane devicetree, describing the SuperSpeed USB node of the device. Linux uses the more generic "MTU3" MediaTek driver for the USB node, which has multiple capabilities (Dual-Role OTG). U-Boot lacks this driver, so we manually add only the SuperSpeed USB part that is nested under the mtu3 node in the upstream devicetree and thus invisible to U-Boot.
• #20: this is a weird commit that enables everything that was added before (video, USB, PHY and DSI drivers, etc.) in the board defconfig. This will go or stay like this depending on how the series is split for upstream.

I guess this will need to be split between basic board support and video drivers. I don't want to waste the time of the maintainers with "AI slop" and code that does not follow the right conventions, so I will take extra care to read the U-Boot contributing documentation, and make sure all the patches are in a good shape before sending them. I also don't think they have an AI policy at the moment, but I plan anyway to rewrite all the patches myself with the AI output as input, and will of course disclose that all of this was AI-assisted.

Fixing the kernel

Getting rid of the hang

Now that we have a cleaner U-Boot tree, and have a global understanding of all the modifications, it is time to go back to that kernel hang debugging. And the issue might already be clearer now.

See, I was convinced from the beginning that this was a U-Boot issue, something going wrong in the handoff, particularly regarding memory, hence why we added commit #15 to U-Boot. But as we have seen right before, that commit is still doing weird things and would need more work. Let's try to analyze memory issues now.

I was able to reproduce the hang deterministically when running a stress benchmark program, that would try to use a large amount of memory. So this made me even more convinced that there was a memory map issue. The solution: compare memory maps on the postmarketOS kernel booted from Depthcharge, and the one from the Ubuntu kernel booted from U-Boot.

To look at kernel memory maps, I just used sudo cat /proc/iomem. I fed both outputs to the agent, and it immediately found the difference: a memory area, marked as reserved for the ARM Trusted Firmware from the postmarketOS side, but as regular usable memory from the Ubuntu side. Because of this, when programs are requiring more and more memory, the kernel will end up mapping that region and giving it to programs that will try writing on it, which will trigger some kind of security exception, that could very well end up freezing the OS. That really sounds like the bug. Finally.

The agent started implementing the fix for it directly, which was extracting the full memory map from Coreboot tables and trusting that. Given that this specific firmware memory region can depend on the firmware, it is not part of the upstream devicetree (that only describes the hardware). Because of this, it was missing in our EFI memory map, and needed this new Coreboot tables parsing.

After three unsuccessful attempts, the fourth flash was the win. I re-ran the stress program, and it completed without issues. Victory! Changes squashed with commit #15 (I knew it needed more work). A clean experience on the Duet. Almost.

Bluetooth

Unfortunately, Bluetooth does not work on the upstream kernel. The postmarketOS kernel uses a specific patch to restore functionality, but that is a revert of another upstream patch, so this likely won't be mainlined soon.

This can be seen in my boot video, as the kernel will spam

Bluetooth: hci0: Frame reassembly failed (-84)

on each boot. Personally, I will experiment with adding that patch on top of the kernel, but I don't want to have to maintain a custom kernel build every time, so I'll mostly keep using the generic one for now.

I hope that someday, someone will do the work to have a patch that works upstream, and after a simple apt upgrade, I'll end up with working Bluetooth again.

A bootable Ubuntu image

Now we can crystallize all the work into a bootable Ubuntu image, embedding this modified U-Boot in a first Depthcharge partition. The goal of this is that anyone can download the image, put it on a USB stick, and boot it using Depthcharge "USB boot" option, to get into a real Ubuntu on the Duet.

This might seem a bit hard, but it is actually very easy for me as I did this a couple times already for RISC-V boards for my job at Canonical, so I know exactly which tools to use to produce such an image. We need ubuntu-image and a gadget file that describes the partition of the image we want to build, as well as an image definition file that describes the version, packages and stuff we want in the image. See this tutorial for more details.

I created a Git repo with everything needed to build such an image: uboot/ with all the patches, krane-shim-loader/ with the shim loader and the script to create the Depthcharge payload from it and U-Boot, image/ with the files described above as well as custom script to make the Depthcharge partition work well and test the image. This was also easily done, assisted by an agent.

###

GitHub - vhaudiquet/krane: Lenovo IdeaPad Duet (kukui-krane) experimentationsLenovo IdeaPad Duet (kukui-krane) experimentations - vhaudiquet/kranehttps://github.com/vhaudiquet/krane

If you own a Lenovo IdeaPad Duet, go to the repo, download the image in Releases, burn it to a USB stick and try it! You don't need anything more, only put it in 'Developer Mode' (this will factory reset the device) and select 'USB boot' from the menu. Default password is ubuntu. Disclaimer: this is not an official Ubuntu image in any way, all of this was done in my free time and unaffiliated with official Ubuntu or Canonical.

Full Ubuntu Desktop finally running on the Duet. Unfortunately, GNOME is even slower from the live USB image than it was with postmarketOS. I guess that comes from my slow USB stick and the lack of RAM...

Conclusion

Using AI for hardware bring-up/debugging

I saw many posts on X (Twitter) and other social networks of people having "Claude vibe-code them support for hardware x or y" everywhere. I was a bit skeptical of some of those posts. Most of them are about kernel drivers for a specific piece of hardware, and I can believe that, as the agent can automatically load/unload to test on-device, without human intervention required. When a datasheet and an out-of-tree driver exist, an agent can indeed fully adapt a driver for the running kernel, as we have seen with the work on the U-Boot panel driver (which still needed manual testing).

For some of the posts that blew up on my timeline, though, it seemed like OpenAI GPT-6 Astra or Claude Fable was able to one-shot (so, just a prompt, it worked alone, and then the user tested) full Linux support for devices that had none. I don't buy those. It took 10 flashes to get a stub that only draws solid colors on a screen, and 27 to get U-Boot to run at all. Models are also confidently wrong in ways only hardware reveals: Astra had me convinced I'd found the fix for the hang, and it wasn't, and one of the U-Boot patches made a symptom disappear by hiding a double call instead of fixing it. And that's before we get to reverse-engineering hardware support from scratch, which still takes a huge amount of human work.

The most interesting thing, though, is whether those AI-generated or AI-helped drivers and patches are maintainable and upstreamable. That is the core of the debate. If an unmaintained vendor kernel already exists, using AI to make it work on your kernel gains you nothing: you now own a second unmaintained kernel, and this one is your problem. This is why I will try to upstream all my patches to U-Boot, but that needs real software engineering skills, or a large amount of disrespect for the maintainers if you expect to send unreviewed AI-generated patches.

As we have seen with the previous U-Boot patches, it seems that some of them will need more work, and it isn't perfect. However, with multiple rounds of adversarial reviews from AI models, I believe the patches are better than what I would have produced alone. That is one of the strengths of the AI agents: even if you write all code by hand, they can find mistakes pretty well.

Furthermore, I would never have been able to write the U-Boot drivers here myself without help. First, I would never have the time to do that. Second, I would have had to read the Linux and Coreboot drivers multiple times, and would have probably missed a lot of data and introduced bugs. The quality of the agent's code seems really great, and it doesn't differ much from the other upstream drivers.

However, I can say all of that because I'm a software engineer. I have written patches for similar firmware projects. I know what makes good code, and I understand the underlying boot flow and necessities of what I want to accomplish, including what the right ways to do things are, and what the wrong ones are. That judgment is the part I don't think an agent replaces, and it's the part someone without the background would have to acquire first. With it, this is a formidable tool. Without it, you can generate a lot of plausible hardware code and have no way to tell which parts are wrong.

AI can be used to fill in the missing knowledge (e.g. boot flow on Chromebooks) and generate the code of precise things (i.e. a framebuffer driver stub that prints colors, integrating such driver in U-Boot, adapting a panel driver from Linux and Coreboot). The barrier to entry is lower than ever, but you have to put in the work, be determined to learn and try hard to understand what is going on, and still have prior coding experience to be able to review and maintain the output. I don't think someone prompting "I want to run Ubuntu on my Duet tablet" without any software engineering background or the will to learn and really spend time on it would have been able to make this work.

Another important thing is that I'm talking about models from September 2026, and I have used mostly GLM-5.3-Flash here, a 'flash' model. Those experiments ended up costing approximately $15 to $20, I think. Of course, if I had spent $500 and ran Astra all the time (the Astra session alone cost $4, for only one output which was a link to the patch it found), the code quality might have been better, but it does not change some structural problems for a model to do things alone.

Next steps

Obviously, the immediate next step is to try and upstream all this U-Boot work, so that the bug fixes help everyone and support for the device is added upstream, which should both let anyone play with it and keep it maintained.

Afterwards, I want to try, some day, to get rid of the annoying Depthcharge menu. This would mean flashing a whole new Coreboot + Depthcharge firmware image, and I think it is possible using the SuzyQ. This is a significant next step, and if I have the time to do it one day, it will deserve its own blog post.

Until then, see you later! :)

• Lenovo IdeaPad Duet
• Installing Ubuntu?
• Using the Ubuntu kernel
• Understanding the boot flow
• EFI environment needed
• U-Boot
• Our target
• krane-fb-stub
• U-Boot using the framebuffer
• Console and USB keyboard
• Booting the eMMC
• Panel driver
• First kernel boot
• A missing module
• The hang: fixing with an agent
• Getting (a bit more) involved
• Ubuntu works (?)
• Cleaning up the U-Boot tree
• Fixing the kernel
• Getting rid of the hang
• Bluetooth
• A bootable Ubuntu image
• Conclusion
• Using AI for hardware bring-up/debugging
• Next steps