A plain list of the claims made in my scholarship applications, each with a link to the original public record: a merged commit, a review thread, or a published DOI. Nothing here is summarised from memory; every line links to a source you can check yourself.
Full profile, all repositories: github.com/gahingwoo
Trusted Firmware-A — removed a redundant secure-boot override
Fixed a copy-paste build-configuration defect that would have silently broken secure-boot on any build without a secure OS. Reviewed by engineers at STMicroelectronics, Arm, and Rockchip. Merged into mainline.
OP-TEE — first RK3576 platform port
Ported the open-source Trusted Execution Environment to a new Rockchip chip. Passed all 57 automated checks, independently reproduced on separate hardware, and merged into mainline with a formal Reviewed-by from a Cherry Embedded Solutions maintainer. The platform code itself is in the master branch.
iommu/rockchip — two fixes applied by the IOMMU co-maintainer
Found while bringing up the RK3576 NPU. The IOMMU driver only requested a fixed {aclk,iface} clock pair, but the RK3576 NPU's IOMMU instances sit behind additional CBUF/DSU gates, so register writes were silently dropped until those clocks also ran; fixed by taking every clock the devicetree provides instead of a fixed pair. Separately, boot firmware could leave an IOMMU bank in PAGE_FAULT_ACTIVE with no handler, which made that bank ignore CMD_ENABLE_STALL and hang the stall-enable poll; fixed by acknowledging the stale fault first. Split out of the RK3576 NPU RFC below and applied directly by Will Deacon (IOMMU subsystem co-maintainer) into the IOMMU tree, with his own Signed-off-by on both commits. Live in linux-next as of next-20260727; not yet in Linus's mainline tree.
arm64: dts: rockchip — ArmSoM CM5 and CM5-IO board support, applied by the Rockchip SoC maintainer
Devicetree support for the ArmSoM CM5 compute module and CM5-IO carrier board, through five review rounds. Sashiko, an automated AI patch-review tool used on the list, flagged a real hardware-sequencing risk in the GMAC0/YT8531 clock ordering — resolved by the motorcomm PHY fix above. The dt-bindings patch also carries an Acked-by from Krzysztof Kozlowski (devicetree bindings maintainer). Applied by Heiko Stübner (Rockchip SoC maintainer) into his own tree, with his own Signed-off-by on both commits; he adjusted styling and fixed a couple of dt-checker warnings on the way in.
iommu/rockchip: implement .flush_iotlb_all
Found while bringing up the RK3576 NPU driver: Rockchip's IOMMU never implemented an optional TLB-flush op the hardware could support. Posted a standalone fix; Will Deacon and Robin Murphy (IOMMU subsystem maintainers) pushed back that a standalone flush_iotlb_all isn't the right direction without also moving invalidation into a proper iotlb_sync/gather path. I agreed and withdrew it rather than defend a fix I no longer thought was correct. Heiko Stübner (Rockchip maintainer) used the thread to suggest posting the wider RK3576 bring-up as an RFC instead, which is what became the 9-patch series below.
net: stmmac: dwmac-rk — reference-clock fix, wrong layer
Posted a fix for boards where the RGMII PHY needs a SoC-sourced 25 MHz reference with no local crystal, routing the clock enable through the MAC driver. Maxime Chevallier (Bootlin) and Andrew Lunn (net/phy subsystem maintainer) pointed out that the PHY, not the MAC, should own and request this clock. Agreed, and withdrew the series in favour of fixing it at the correct layer — the motorcomm PHY driver, below.
Linux kernel — RK3576 NPU (rocket driver) enablement, RFC series
RFC series adding RK3576 NPU support across device-tree bindings, power-domain, IOMMU, and the accel/rocket driver; now on v2 (8 patches), with the two IOMMU fixes already split out and applied — see the linux-next entry above. The remaining driver itself is still RFC: full inference is not yet correct, and a review exchange with Alexey Charkov (Flipper Devices) traced a suspicious polled-interrupt workaround back to a real hardware gating state, narrowing the search considerably. Posted to the mainline kernel list for review; not yet merged.
net: phy: motorcomm — reference-clock fix, Reviewed-by and Tested-by from independent boards
Redesigned fix for the same crystal-less RGMII PHY problem above, this time enabling the clock from the PHY driver itself. Tested on an ArmSoM CM5-IO: the YT8531 links at 1000 Mbit/s with no MAC-driver or devicetree-binding change. Carries a formal Reviewed-by from Andrew Lunn. A v2 extends the same fix to the YT8521, after Gavin Gao hit the identical problem on a different RK3576 board using that PHY — and Gavin came back with a Tested-by on his own hardware (PicoCOM RK3576 ACP, YT8521), confirming the clock stays active and Ethernet works on a board I don't own. Not yet merged into net-next.
media: rockchip — RFC V4L2 driver for the RK3576 VEPU510 H.264 encoder
RFC for a from-scratch mainline video-encoder driver. Reviewed by Heiko Stübner (Rockchip kernel maintainer) and Nicolas Dufresne (Collabora, GStreamer/V4L2 maintainer), with Paul Kocialkowski (upstream stateless-codec author) also weighing in. Based on that discussion, decided to abandon the stateful V4L2 interface and converge instead on a DRM/Vulkan-Video-style kernel/userspace split being developed for the sibling RK3588 chip — judged the better long-term direction rather than defend the original design.
RK3576 NPU bring-up: a falsification-first negative result
First byte-exact int8 convolution from the open-source driver stack on this chip, followed by a rigorous, disprove-first account of why the chained-layer failure sits below what software can reach. Archived preprint with a DOI. Independently written up by CNX Software, an embedded-systems industry news site, which quoted the work and linked both the preprint and the source repository; the write-up was subsequently picked up by Istituto Radiotecnico A. Beltrami (Milan), a technical institute, which summarised the work directly to their own audience. A separate developer (gregordinary), reverse-engineering the sibling RK3588 chip by a different method, later found that five of the same findings held on his silicon too — independent cross-validation, not a citation of authority.
rp2350-tz-tee — minimal TrustZone-M isolation example on the RP2350
The Pico SDK still can't build a Non-Secure binary that runs under a Secure one (open upstream since pico-examples#708), so there was no minimal Secure/Non-Secure starting point. Built one from scratch on a Pico 2: a Secure world guarding a secret behind NSC veneers, verified over SWD rather than trusted from source — a direct Secure-RAM read from the Non-Secure side is caught as a SecureFault with the expected fault-status bits set, not just "the demo prints the right thing." Also documents a build recipe for TF-M on rpi/rp2350 and the DMA-has-its-own-MPU pitfall (the SAU alone doesn't stop Non-Secure code from using DMA to walk around TrustZone). Extends the TF-A/OP-TEE trusted-execution work above down to the microcontroller class.
SoC-Consistency — static analysis for hardware power-tree configuration
Catches hardware misconfiguration before it reaches physical devices. Ships rule packs for five chip families, runs in CI pipelines. Published on PyPI and independently packaged into Arch Linux by an unaffiliated maintainer. A stranger ran it against their own Orange Pi 5 (RK3588) devicetree, reported two real false-positive rules in the comments; both were root-caused and shipped in a same-thread point release (v1.2.1).
RKDevelopTool-GUI — cross-platform Rockchip flashing GUI
A Qt/PySide6 graphical front-end for Rockchip firmware flashing on macOS and Linux. Independently packaged into the Arch AUR by the same community maintainer as SoC-Consistency (taotieren), and pulled in as an optional dependency of the SoC-Consistency AUR package — the two tools now have a real dependency relationship in the wild, not just two separate uploads. Radxa's own documentation now carries a dedicated page for it under CM3 low-level development, with per-platform install steps, positioned in their docs alongside their own rkdeveloptool CLI.
lore-enhancer — browser extension for reading kernel patches on lore.kernel.org
A Chrome/Edge/Firefox extension that reformats lore.kernel.org's raw single-<pre> message pages into a mail-client-style view: author card, collapsible syntax-highlighted diffs, a clickable thread sidebar in place of ASCII art, and quote folding, with an instant "Raw" toggle back to the original. No network requests, no accounts, no telemetry. Posted to r/kernel and r/embedded, where working kernel and embedded developers responded with genuine positive first impressions in the comments, not just self-reported use.
edk2-rk3576 — UEFI port pinned by a Radxa engineer
A complete EDK2/TianoCore UEFI port for the RK3576, booting a mainline Fedora 44 desktop. Builds for six boards, hardware-verified on two (Radxa ROCK 4D, ArmSoM CM5-IO). The write-up was pinned to the ROCK 4 series section of the official Radxa community forum by Zhang Yuntian, a Radxa engineer, not by me.
kiln — official Radxa tutorial for local LLM/vision on the RK3576 NPU
A deliberate stopgap, not a mainline driver: builds the vendor GPL rknpu driver out-of-tree against a mainline kernel (linux-7.1.3), drives it with the closed librkllmrt/librknnrt runtimes, and carries the RK3576 NPU clock/power-domain/IOMMU kernel patches from above so the NPU comes up at all without the vendor's 6.1 BSP. Radxa wrote and hosts a full step-by-step tutorial for it under ROCK 4D > Application Development > NPU Usage — install, health checks, local LLM chat, vision inference, and an OpenAI-compatible API server — explicitly labelled as a third-party project rather than official support, but given the same tutorial treatment as Radxa's own guides.
Flipper Devices — production validation of the OP-TEE port
Flipper Devices validated the RK3576 OP-TEE port on Flipper One hardware: 114 xtest cases, 35,681 subtests, zero failures. Credited by name in their official developer documentation.
Collabora — official post summarising the NPU bring-up
Collabora (an established Linux kernel and open-source engineering consultancy) posted their own technical summary of the RK3576 NPU work, unprompted. Heiko Stübner, the Rockchip kernel maintainer, commented on the post directly.
Rockchip upstream enablement tracker — NPU and VEPU510 reference points
A community-maintained GitLab tracker, hosted by Collabora, for Rockchip RK3576 mainline enablement status across every subsystem (GPU, ISP, media, NPU, and more). The NPU row cites the RFC series as its reference entry, and the VEPU510 H.264/AVC row was later updated by Sebastian Reichel (Collabora) to cite the video-encoder RFC thread as well — not something I added myself, but how the tracker's maintainers chose to record the state of both.
EzySpeech — real-time transcription and translation, Mt Albert Baptist Church
Built and deployed for live services; still in use. Note: the church's public website has not been updated since 2024 and still names an earlier, now-discontinued third-party service (Interado) rather than this tool — the website is stale, not a contradiction of current use. The linked service recording shows a live session.
half-baked-studios — a GitHub organisation co-run with three other students
A shared GitHub organisation I co-run with three students my own age, where I guide the group through embedded systems and firmware development while we make technical decisions together. The org's main shipped project, hbes, is a cross-platform dev-environment bootstrap tool (Debian/RHEL/Arch/macOS, a real TUI, a lockfile-tracked install/uninstall model) with CI running the actual installer on four platforms every push, and its README credits all four of us by handle.