added mainline working files

research/kindle-pw3-mainline-notes.md

@@ -0,0 +1,333 @@
+# Kindle Paperwhite 3 (KPW3) Mainline Linux Port — Project Notes
+
+**Goal:** Get mainline Linux 6.15 booting on a Kindle Paperwhite 3, an
+i.MX6SoloLite ("Wario") board, replacing/supplementing the stock Amazon
+2009.08-lab126 U-Boot and 3.0.35 kernel.
+
+---
+
+## Hardware Summary
+
+- **SoC:** i.MX6SoloLite, 512MB LPDDR2 (Nanya)
+- **Compatible string:** `fsl,imx6sl-wario`, `fsl,imx6sl`
+- **UART1:** `0x02020000`, console = `ttymxc0,115200`
+- **eMMC:** SEM04G, 3.68GiB
+  - Kernel device: `mmc0` / `/dev/mmcblk0`
+  - BIST device: `dev 1`
+  - Boot partitions: `mmcblk0boot0` / `boot1` (2MB each)
+- **I2C0 (kernel `i2c1`):**
+  - max77696 PMIC @ `0x3c`
+  - max17135 EPD PMIC @ `0x34` / `0x35`
+  - Possible RTC @ `0x68`
+- **I2C1 (kernel `i2c2`):** Cypress CYTTSP4 touchscreen @ `0x24`
+- **WiFi:** Atheros ath6kl over SDIO (`mmc1`)
+- **GPIOs:**
+  - `gpio-82` — watchdog (`wario_wdog`, **active!** — must be serviced or
+    disabled or the board reboots)
+  - `gpio-93` — wifi power
+  - `gpio-113` / `gpio-119` — eMMC 3.3V / 1.8V enables
+  - `gpio-116` — max77696 IRQ
+
+### eMMC Partition Table (`/dev/mmcblk0`)
+
+| Partition | Size   | FS    | Notes                          |
+|-----------|--------|-------|--------------------------------|
+| p1        | 450MB  | ext3  | root — **do not touch**        |
+| p2        | 64MB   | ?     | `/usr/share/nh`                |
+| p3        | 64MB   | ?     | `/var/local`                   |
+| p4        | 3.1GB  | FAT32 | books — expendable, usable space |
+
+### Stock Kernel Cmdline (original Amazon 3.0.35 kernel)
+
+```
+rootwait log_pos_goal=0x8fff0000 console=ttymxc0,115200 root=/dev/mmcblk0p1 ro ip=off quiet video=mxcepdcfb:E60,bpp=8,x_mem=3M
+```
+
+---
+
+## Stock Bootloader (U-Boot 2009.08-lab126)
+
+This is a **very old, heavily customized** U-Boot. Key facts:
+
+- `bootcmd=bootm 0x41000` — **this is a raw byte offset into `/dev/mmcblk0`**,
+  not an LBA / sector number. The stock `bootm` implementation has been
+  patched to read directly from this byte offset.
+- `bootcmd_diags=bootm 0xE41000` — diagnostic/recovery kernel slot, also a
+  raw byte offset. **This is the recovery path that saved the device** when
+  the main kernel slot got corrupted during testing.
+- Gap between main kernel slot (`0x41000`) and diags slot (`0xE41000`) is
+  `0xE00000` = **14MB** — this is our usable space for a custom kernel image
+  at the main slot.
+
+### Confirmed via hexdump of `/dev/mmcblk0`
+
+- At byte offset `0x41000`: real Amazon uImage header
+  - magic: `27 05 19 56`
+  - data size: `0x3a6cf4` (3,829,492 bytes)
+  - load/entry: `0x80008000`
+  - name: `"Linux-3.0.35-lab126"`
+  - uncompressed
+- At byte offset `0xE41000`: diags kernel, same uImage format.
+
+### Compression / Multi-file image support — **the blocker**
+
+Stock 2009.08-lab126 U-Boot's `bootm` **only supports**:
+- `Image Type: ARM Linux Kernel Image (uncompressed)`
+
+Tried and **all rejected**:
+- gzip (compression type 1) → `"Unimplemented compression type 1"`
+- lzo (compression type 4) → rejected
+- lzma (compression type 3) → rejected
+- Multi-file uImage (kernel + DTB) → old `bootm` doesn't parse the
+  multi-image DTB component correctly. Got "Bad Data CRC" on one attempt
+  (likely transfer corruption of that particular copy), and even with a
+  valid CRC the old `bootm` likely can't pass the DTB to the kernel anyway.
+  This concern is **moot now** since we're moving to a new U-Boot.
+
+### BIST (factory diagnostic) commands — confirmed working
+
+- `mmc read <ram_addr> <byte_offset> <count>` — **uses byte offsets**, not
+  sectors, for the offset parameter (empirically confirmed: offset `266240`
+  decimal = `0x41000` byte offset works).
+- `mmc write <ram_addr> <byte_offset> <count>` — same byte-offset semantics.
+- `loady`, `loadb` — load binary into RAM over serial (Y-modem / raw binary).
+- `source` — run a U-Boot script from RAM.
+- `go <addr>` — jump to and execute code at a RAM address. **This is our
+  planned non-destructive test mechanism for the new U-Boot.**
+- `iminfo` — inspect a uImage header in RAM.
+
+---
+
+## Mainline Kernel Build
+
+- Source tree: mainline Linux **6.15.0**, built on
+  `/media/atticpi/.../build_drive/linux`
+- Config: stripped-down `imx_v6_v7_defconfig`
+  - Removed: non-i.MX6SL SoCs, sound, DRM, media, USB gadget, and other
+    unused subsystems.
+- Build artifact sizes:
+  - `arch/arm/boot/Image` (uncompressed): **13MB** (down from 23MB
+    unstripped)
+  - `arch/arm/boot/zImage` (self-decompressing): confirmed buildable,
+    ~9.3MB compressed (uImage-wrapped zImage was 9,757,400 bytes /
+    ~9.31MB per a successful build log)
+  - `arch/arm/boot/uImage` — successfully built, e.g.:
+    ```
+    Image Name:   Linux-6.15.0
+    Image Type:   ARM Linux Kernel Image (uncompressed)
+    Data Size:    9757400 Bytes = 9528.71 KiB = 9.31 MiB
+    Load Address: 80008000
+    Entry Point:  80008000
+    ```
+- **Conclusion:** even the stripped uncompressed `Image` (13MB) plus a
+  ~21KB DTB doesn't comfortably fit alongside the compression
+  incompatibility of the stock U-Boot. The zImage at ~9.3MB *would* fit in
+  the 14MB window, but the stock `bootm` can't run a zImage via `bootz`
+  (that command doesn't exist in 2009.08-lab126) — hence the need for a
+  new U-Boot.
+
+---
+
+## Device Tree Sources
+
+Two candidate Wario DTS sources identified:
+
+1. **u-boot-wario's built-in "wario" DTS** at `boot/dts/` in the
+   `u-boot-wario` repo — likely the most relevant since it's paired with
+   the U-Boot fork we're using. (Not yet fully inspected.)
+
+2. **Gist by Reagan Bohan** —
+   `https://gist.github.com/gdamjan/13fc8c75a2f8bb34541da0948739baed`
+   - Working `imx6sl-wario.dts` skeleton
+   - `compatible = "fsl,imx6sl-wario", "fsl,imx6sl"`
+   - Includes `imx6sl.dtsi`
+   - Has `uart1` with `pinctrl_uart1`, `usdhc1` pinctrl
+   - `chosen { stdout-path = &uart1; }`
+   - `memory@80000000` node: `reg = <0x80000000 0x10000000>` (256MB —
+     note actual board has 512MB, may need adjusting)
+
+3. **In-progress mainline kernel-side DTS** (may be superseded by #1):
+   `arch/arm/boot/dts/imx6sl-kindle-pw3.dts`
+   - includes `imx6sl.dtsi`
+   - `pinctrl_uart1`
+   - `usdhc2` for eMMC
+   - `i2c1`: max77696, max17135
+   - `i2c2`: cyttsp4 touchscreen
+   - `wdog1`
+
+---
+
+## Decision Log
+
+1. **QEMU testing abandoned** — `mcimx6ul-evk` / `qemu_arm_defconfig` had
+   incomplete peripheral emulation for this board. Pivoted to real hardware
+   testing via serial/BIST since we have physical access to a KPW3.
+
+2. **New U-Boot fork chosen:** `bdm310/u-boot-wario`, branch
+   `amazon-wario-max77696`
+   - Repo: `https://github.com/bdm310/u-boot-wario` (public, C, by user
+     `bdm310`, confirmed to exist via search; direct fetch blocked by
+     GitHub robots.txt but repo was successfully **cloned locally**)
+   - Has a `wario_defconfig` board config (confirmed)
+   - Key config options present:
+     ```
+     CONFIG_CMD_BOOTZ=y
+     CONFIG_CMD_BOOTMENU=y
+     CONFIG_CMD_DM=y
+     CONFIG_CMD_MMC=y
+     CONFIG_CMD_USB=y
+     CONFIG_CMD_EXT2=y
+     CONFIG_CMD_EXT4=y
+     CONFIG_CMD_EXT4_WRITE=y
+     CONFIG_CMD_FAT=y
+     CONFIG_CMD_FS_GENERIC=y
+     CONFIG_CMD_USB_MASS_STORAGE=y
+
+     CONFIG_OF_CONTROL=y
+     CONFIG_OF_LIBFDT=y
+     CONFIG_DEFAULT_DEVICE_TREE="wario"
+
+     CONFIG_DM=y
+     CONFIG_DM_GPIO=y
+     CONFIG_DM_MMC=y
+     CONFIG_DM_REGULATOR=y
+     CONFIG_DM_REGULATOR_FIXED=y
+     CONFIG_DM_SERIAL=y
+     CONFIG_DM_THERMAL=y
+     CONFIG_DM_USB=y
+
+     CONFIG_FSL_USDHC=y
+     CONFIG_PINCTRL=y
+     CONFIG_PINCTRL_IMX6=y
+     CONFIG_IMX_THERMAL=y
+     CONFIG_MXC_UART=y
+
+     CONFIG_USB=y
+     CONFIG_USB_HOST=y
+     CONFIG_USB_GADGET=y
+     CONFIG_USB_GADGET_MANUFACTURER="FSL"
+     CONFIG_USB_GADGET_VENDOR_NUM=0x0525
+     CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
+     CONFIG_USB_GADGET_DOWNLOAD=y
+
+     CONFIG_CI_UDC=y
+     CONFIG_MMC=y
+
+     CONFIG_SPL_WATCHDOG_SUPPORT=y
+     CONFIG_SPL_MMC_SUPPORT=y
+     CONFIG_SPL_MMC_TINY=y
+     CONFIG_SPL_SEPARATE_BSS=y
+     CONFIG_SPL_EARLY_BSS=y
+     ```
+   - This solves both blockers from the stock U-Boot: `bootz` gives us
+     zImage (compressed) support, and `CONFIG_OF_CONTROL` gives us proper
+     DTB passing to the kernel.
+
+3. **DDR init concern (unresolved):** the Amazon boot ROM already
+   initializes DDR before handing off to stock U-Boot. The new U-Boot's
+   SPL would normally re-init DDR itself. If we chainload the new U-Boot
+   via `go` from the stock U-Boot/BIST (DRAM already up), running SPL's DDR
+   init again could be risky or redundant.
+   - **Open question:** can we jump directly into the post-SPL
+     `u-boot.bin` / `u-boot.img` (skipping SPL) and have it work given DRAM
+     is already initialized? Need to check `CONFIG_SYS_TEXT_BASE` for
+     `wario_defconfig` and test via `loady` + `go` before any flashing.
+
+---
+
+## Current Status / Risk State
+
+- **Main kernel slot (`0x41000`) was written with a multi-file uImage**
+  (kernel + DTB) and **did boot** to the point of:
+  ```
+  Image Type: ARM Linux Multi-File Image
+  Verifying Checksum...OK
+  Loading Multi-File Image...OK
+  Starting kernel...
+  ```
+  ...but produced **no further serial output** — likely missing
+  earlycon / DTB-passing issue in how the old `bootm` hands off to the
+  kernel.
+
+- **Diags kernel slot (`0xE41000`) is intact** and is the fallback recovery
+  path via `bootcmd_diags` / `bootm 0xE41000`. This gives a limited busybox
+  shell.
+  - `/dev` is not populated by default in this diags environment — need
+    `mount -t devtmpfs devtmpfs /dev` or `mdev -s` to get block device
+    nodes before you can access `/dev/mmcblk0*`.
+
+- **Main Kindle shell** (the original Android-like Kindle OS root shell)
+  is currently reported as broken/inaccessible. A `kernel.bak` restoration
+  was attempted but reportedly corrupted earlier in the session.
+
+- **Available recovery/access paths:**
+  - Serial console + BIST (always available, lowest-level)
+  - Stock U-Boot prompt
+  - Diags kernel (limited busybox shell via `bootm 0xE41000`)
+  - WiFi-enabled root shell (when the device is in a state where it comes
+    up far enough for networking)
+  - A second/spare KPW3 unit was on order as a hardware fallback.
+
+---
+
+## Build Environment
+
+- Build machine path root:
+  `/media/atticpi/69626740-3694-4e07-956f-49cc8e0219a4/build_drive/`
+- Relevant directories:
+  - `linux/` — mainline kernel source, currently configured and building
+    successfully (6.15.0, `Image`/`zImage`/`uImage` all built)
+  - `linux-imx/` — (NXP's downstream i.MX kernel tree, presumably for
+    reference)
+  - `u-boot/` — original/stock-related U-Boot tree
+  - `u-boot-wario/` — **target U-Boot fork**, cloned, `wario_defconfig`
+    confirmed present, currently being explored at `boot/dts/`
+  - `kindle-linux-3.0.35-lab126/` — stock Amazon kernel source (reference)
+
+---
+
+## Next Steps (as of last session)
+
+1. Inspect `u-boot-wario/boot/dts/` for the `wario` DTS and compare against
+   the Reagan Bohan gist DTS and the in-progress mainline
+   `imx6sl-kindle-pw3.dts`.
+2. Build u-boot-wario:
+   ```sh
+   cd u-boot-wario
+   make mrproper
+   export ARCH=arm
+   export CROSS_COMPILE=arm-linux-gnueabihf-
+   make wario_defconfig
+   make -j$(nproc)
+   ```
+   Confirm it produces `SPL` and `u-boot.img` (or `u-boot-dtb.img`).
+3. Check `CONFIG_SYS_TEXT_BASE` for `wario_defconfig` (`grep TEXT_BASE
+   .config`, or `include/configs/wario.h` if present) to determine the load
+   address for testing.
+4. **Test without flashing**: via BIST, `loady <addr>` the new U-Boot
+   binary into RAM, then `go <addr>` to execute it — non-destructive since
+   nothing is written to eMMC.
+   - Resolve the open DDR-init/SPL question above before/while doing this.
+5. If the new U-Boot runs successfully with `bootz` + OF support:
+   - Build the mainline kernel as a **zImage** (~9.3MB, fits the 14MB
+     window easily since compression is now supported) plus a separate
+     `wario.dtb`.
+   - Boot with `bootz <kernel_addr> - <fdt_addr>`.
+6. Eventually, flash the new U-Boot to replace/supplement the stock
+   2009.08 bootloader at the appropriate eMMC offset — exact location and
+   method **TBD**, but expected to be in the boot0/early region of the
+   eMMC, separate from the `0x41000` kernel slot.
+
+---
+
+## Useful External References
+
+- u-boot-wario repo: `https://github.com/bdm310/u-boot-wario`
+  (branch `amazon-wario-max77696`) — direct GitHub fetch blocked by
+  robots.txt, but repo confirmed public and already cloned locally.
+- Wario DTS gist (Reagan Bohan):
+  `https://gist.github.com/gdamjan/13fc8c75a2f8bb34541da0948739baed`
+- General KPW3 mainline porting thread: MobileRead Forums — "PW3 Kindle
+  Paperwhite 3 Schematics and Mainline u-boot/Linux", Kindle Developer's
+  Corner (`mobileread.com/forums/showthread.php?t=332253` — returned 404
+  on last check, may have moved/been removed).

research/kpw3-session-summary.md

@@ -0,0 +1,185 @@
+# Kindle Paperwhite 3 (KPW3) Mainline Linux Port — Session Summary
+
+**Session date:** 13 June 2026
+**Outcome:** 🎉 **Mainline Linux 6.15 successfully booted to a root shell on real KPW3 hardware**, using both a borrowed reference DTB and (eventually) the project's own custom DTS.
+
+---
+
+## Starting Point
+
+At the start of this session, the project had:
+- Confirmed hardware details (SoC, eMMC layout, peripherals — see project notes)
+- A non-destructive test method via BIST `go` to chainload a new U-Boot
+- `u-boot-wario` (2021.04-rc3, `bdm310/u-boot-wario`, `wario_defconfig`) built but not yet tested
+- A mainline 6.15 kernel built with a stripped-down `imx_v6_v7_defconfig`
+- An in-progress custom DTS (`imx6sl-kindle-pw3.dts`) for the board
+- One eMMC kernel slot (`0x41000`) already overwritten with a prior lzma test image (non-stock, considered disposable)
+- Diags kernel slot (`0xE41000`) intact as a recovery fallback
+
+---
+
+## 1. u-boot-wario Brought Up Successfully
+
+- Used BIST: `loady` to transfer `u-boot.bin` (353KB) to `0x87800000` (`CONFIG_SYS_TEXT_BASE`), then `go 0x87800000`
+- **Worked first try** — DDR was already initialized by the boot ROM, so jumping directly into the post-SPL binary (skipping SPL's DDR init) was the correct, low-risk approach
+- Result: full u-boot-wario 2021.04-rc3 banner, correct SoC identification (i.MX6SL rev1.3 @ 996MHz), **512MiB DRAM correctly detected** (vs the 256MB placeholder in the Reagan Bohan gist DTS)
+- Both `FSL_SDHC: 1` (eMMC) and `FSL_SDHC: 2` controllers detected
+
+### eMMC confirmed via `mmc info`
+- `mmc dev 1` (note: index **1**, not 0)
+- Manufacturer: SEM04G, 3.7GiB, 8-bit bus, MMC 4.5, High Speed (52MHz)
+- Boot areas (2MB each), RPMB present — matches hardware notes
+
+### Block-offset math confirmed
+- Byte offset `0x41000` = block `0x208` (= 1032 decimal) for `mmc read`/`mmc write` under u-boot-wario
+- `mmc read 0x87800000 0x208 <count>` + `iminfo` successfully read back the existing lzma test image header — confirms mainline U-Boot's block-based addressing lines up correctly with the byte-offset semantics used by BIST/stock U-Boot
+
+---
+
+## 2. Compression Support — Resolved
+
+- The old `0x41000` slot contained an **lzma-compressed** uImage from earlier testing
+- `bootm` on that image failed: **"Unimplemented compression type 3"** — lzma not compiled into this u-boot-wario build
+- **Resolution:** moved to **gzip**-compressed uImages (default for mainline kernel `uImage` target), which u-boot-wario supports out of the box
+- Also clarified: `bootz` requires a raw zImage-type image; **legacy uImage-wrapped images (any compression) must use `bootm`**, not `bootz`
+
+---
+
+## 3. Chainload-via-stock-bootcmd — Abandoned
+
+**Goal:** make stock 2009.08-lab126 U-Boot automatically chainload into u-boot-wario via `bootcmd=bootm 0x41000`, to avoid needing BIST+`loady` every session.
+
+**Findings:**
+- Stock U-Boot's command set (confirmed via `help`) lacks `mmc`, `source`, `loady` — these are BIST-only commands, not available at the interactive stock U-Boot prompt
+- Wrote `u-boot.bin` as a `mkimage -T standalone` legacy uImage to `0x41000`
+- `bootcmd=bootm 0x41000` **loaded it successfully** ("Loading Standalone Program ... OK") but **returned "OK" without jumping** — the standalone-type auto-jump either didn't occur or jumped into u-boot-wario in a state where it executed briefly then returned/reset, never printing its banner
+- **Critically, this left the console unresponsive** — even chaining `bootm 0x41000; go 0x87800000` on one line did not recover an interactive prompt afterward
+- **Conclusion:** this chainload approach is a dead end with this stock U-Boot. The BIST `loady` + `go` path remains the only reliable way to start u-boot-wario each session (note: u-boot.bin is only 353KB, so this transfer is fast — the real time cost was always the multi-MB kernel, addressed separately below)
+
+---
+
+## 4. Fast Iteration Loop Established
+
+To avoid re-transferring the multi-MB kernel over serial every test cycle:
+
+1. `dd` the current kernel uImage to the eMMC at byte offset `0x41000` (the disposable slot) from the development machine / diags shell
+2. Each test cycle, from a freshly-started u-boot-wario prompt:
+   ```
+   mmc dev 1
+   mmc read 0x87800000 0x208 0x5000    # ~10MB, covers a 9.3MB uImage + header
+   loady 0x83000000                     # transfer only the small .dtb (~20KB)
+   setenv bootargs 'console=ttymxc0,115200 root=/dev/mmcblk1p1 rootwait ro'
+   bootm 0x87800000 - 0x83000000
+   ```
+3. Diags slot (`0xE41000`) kept untouched throughout as the recovery fallback
+
+This reduced each iteration to a small DTB transfer only.
+
+---
+
+## 5. Kernel Rebuilt on `imx_v6_v7_defconfig`
+
+- Switched from the heavily stripped defconfig to full `imx_v6_v7_defconfig` (size is no longer a constraint now that gzip uImages work and fit the 14MB window)
+- Confirmed `CONFIG_MMC_SDHCI_ESDHC_IMX=y` present (this was a suspected gap in the old stripped config, but turned out not to be the actual blocker — see below)
+- New uImage: gzip-compressed, ~9.3MB
+
+---
+
+## 6. The Long Hang-After-`etnaviv` Debugging Saga
+
+Across multiple kernel boots (both stripped and full defconfig), the kernel consistently hung immediately after:
+```
+etnaviv etnaviv: bound 2200000.gpu (ops ...)
+etnaviv etnaviv: bound 2204000.gpu (ops ...)
+```
+with **zero further output**, even after 5+ minutes — a true hang, not a silent/deferred probe.
+
+### Ruled out one at a time (each via `status = "disabled"` + rebuild):
+- `usdhc2` (eMMC) — not the cause
+- `i2c1` (max77696 PMIC, max17135 EPD PMIC) — not the cause
+- `i2c2` (cyttsp4 touchscreen) — not the cause
+- `usdhc3` (WiFi/ath6kl) — not the cause
+
+### Breakthrough via reference DTB
+A second DTS source was found: **`bdm310/wario-hardware`'s `wario.dtb`** (binary only). Decompiled with `dtc -I dtb -O dts` and **booted successfully past the hang point**, all the way to a root shell on the original Amazon ext3 rootfs (`mmcblk1p1`).
+
+### Diffing the two flattened device trees revealed the actual cause
+Your DTS's `gpc@20dc000` (GPC power-controller) node included nested `pgc`/`power-domain@0/1/2` subnodes, with the **GPU nodes** (`gpu@2200000`, `gpu@2204000`) declaring `power-domains = <&pgc_power_domain_1>`. `wario.dtb` has **no GPU nodes and no nested power-domain subnodes at all**.
+
+**Root cause:** the GPU's power-domain dependency, combined with anatop regulator settings that differ from wario.dtb's (missing `regulator-always-on` on the relevant rail), caused etnaviv's post-bind power-on call to **block indefinitely** waiting on a power domain that never becomes ready.
+
+**Fix:** disabled `gpu_2d` and `gpu_3d` nodes (`status = "disabled"`) in the custom DTS. Boot proceeded immediately past the former hang point.
+
+---
+
+## 7. eMMC Power Sequencing — Second Blocker, Now Resolved
+
+With GPU disabled, boot proceeded to `Waiting for root device /dev/mmcblk1p1...` but then failed in progressively more informative ways:
+
+1. **First attempt** (usdhc2 still disabled from earlier isolation testing — forgot to re-enable): no `mmcblk1` device at all. *(Fixed by re-enabling `usdhc2`.)*
+
+2. **Second attempt** (`usdhc2` enabled, both `vmmc-supply`/`vqmmc-supply` present, neither `boot-on`/`always-on`):
+   - Card misidentified as `SDM032 30.6 MiB` (wrong — real eMMC is `SEM04G 3.69 GiB`)
+   - `Power: 0x00000000` in SDHCI register dump — **no power being supplied to the card**
+   - Timeout waiting for hardware interrupt, eventual kernel panic (unable to mount root)
+
+3. **Third attempt** (dropped `vmmc-supply`, kept only `vqmmc-supply` with `regulator-boot-on; regulator-always-on;`, matching wario.dtb's single-supply approach):
+   - New failure: `mmc1: Card stuck being busy! __mmc_poll_for_busy` (repeated, then "Failed to initialize a non-removable card")
+   - Different failure mode = real progress (card now powered, but stuck in a busy/voltage-switch state)
+
+4. **Fourth attempt — SUCCESS:** re-added **both** `vmmc-supply` (`emmc_3v3`, gpio-113) and `vqmmc-supply` (`emmc_1v8`, gpio-119), with **`regulator-boot-on; regulator-always-on;` added to BOTH regulators** (not just one).
+
+**Result: full boot to root shell**, using the project's own `imx6sl-kindle-pw3.dts`:
+```
+mmc1: new high speed DDR MMC card at address 0001
+mmcblk1: mmc1:0001 SEM04G 3.69 GiB
+ mmcblk1: p1 p2 p3 p4
+mmcblk1boot0/boot1/rpmb: ... 2.00 MiB
+EXT4-fs (mmcblk1p1): mounted filesystem ... ro
+Run /bin/sh as init process
+/ #
+```
+
+---
+
+## Current Known-Working DTS Configuration
+
+`imx6sl-kindle-pw3.dts`, working state at end of session:
+
+| Node | Status | Notes |
+|---|---|---|
+| `uart1` | ✅ enabled | console working throughout |
+| `usdhc2` (eMMC) | ✅ enabled | requires `pinctrl_usdhc2`, **both** `vmmc-supply`/`vqmmc-supply` with `regulator-boot-on; regulator-always-on;` on both `emmc_3v3` and `emmc_1v8` |
+| `gpu_2d` / `gpu_3d` | ❌ disabled | causes hang via GPC power-domain dependency; needs anatop regulator fix (`regulator-always-on` on relevant rail) before re-enabling |
+| `i2c1` (max77696 PMIC, max17135 EPD PMIC) | ❌ disabled | disabled during isolation testing, not yet re-tested in working config; also has a dtc warning: `max17135@48` node name doesn't match `reg = <0x34>` |
+| `i2c2` (cyttsp4 touchscreen) | ❌ disabled | disabled during isolation testing, not yet re-tested |
+| `usdhc3` (WiFi/ath6kl) | ❌ disabled | disabled during isolation testing, not yet re-tested |
+| `wdog1` | ✅ enabled | present in working boot, not yet stress-tested for long-running stability |
+
+`root=/dev/mmcblk1p1` (note: **mmcblk1**, not mmcblk0 — eMMC is the second MMC device under mainline's probe order with this DTS)
+
+---
+
+## Next Steps
+
+1. **Re-enable incrementally, one at a time**, using the now-fast iteration loop (BIST `go` → `mmc read` kernel from `0x41000` → `loady` dtb → `bootm`):
+   - `i2c1` (PMIC/EPD) — fix `max17135@48` reg/name mismatch (`reg = <0x34>` per hardware notes, not `0x48`) while re-enabling
+   - `i2c2` (touchscreen)
+   - `usdhc3` (WiFi)
+2. **GPU**: compare anatop regulator `regulator-min/max-microvolt` and `anatop-enable-bit`/`regulator-always-on` settings between your DTS and wario.dtb to find the specific fix needed to re-enable `gpu_2d`/`gpu_3d` without reintroducing the power-domain hang
+3. **Watchdog**: verify `wdog1` is actively serviced by mainline's `imx2-wdt` during longer-running sessions (hardware notes flag this as active/must-be-serviced)
+4. **Persistence**: now that a known-working kernel+DTS combination exists, consider:
+   - Writing the working DTB to a fixed eMMC offset (avoiding `loady` entirely)
+   - Revisiting U-Boot persistence options (the standalone-chainload approach was abandoned, but other options — e.g. flashing u-boot-wario to the boot ROM's primary search location — remain on the table, with appropriate backups)
+5. **Full backup**: before any further eMMC writes beyond the disposable `0x41000` slot, take a full or partial `dd` backup of `/dev/mmcblk0` from the diags shell
+
+---
+
+## Key Technical Lessons
+
+- **BIST and stock U-Boot are different command environments** — BIST has `mmc`, `loady`, `source`, `go`; stock U-Boot's interactive prompt has none of these except `go`
+- **`mmc read`/`write` use block (512-byte) offsets** in mainline U-Boot, vs **byte offsets** in BIST/stock U-Boot's patched `bootm` — always convert (`byte_offset / 512`)
+- **`bootz` requires raw zImage type; `bootm` handles legacy uImage-wrapped images** regardless of inner compression (provided the compression algorithm is supported by that U-Boot build)
+- **A clean "hang with zero output" after a specific driver bind is often a *later* driver blocking on a dependency** (e.g. GPU blocking on a GPC power domain) — isolate by disabling nodes one at a time, but also consider what comes *after* the last successful message, not just the message itself
+- **eMMC power sequencing matters**: both `vmmc` (card power) and `vqmmc` (I/O voltage) supplies often need `regulator-boot-on` + `regulator-always-on` for non-removable eMMC, especially when using GPIO-controlled fixed regulators rather than always-on board rails
+- **A working reference DTB (even without source) is extremely valuable** — `dtc -I dtb -O dts` to decompile, then diff specific nodes against your own tree to find configuration deltas