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:

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.

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

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.

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) experimentations

Lenovo IdeaPad Duet (kukui-krane) experimentations - vhaudiquet/krane

https://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.

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! :)