Document USB-boot flash recovery without an SPI programmer

README.md

@@ -9,7 +9,7 @@ an affected camera:
 - if there is too little free space to install that fix, use a same-camera
   backup to build and restore a preventive image through USB;
 - a camera that no longer starts can be recovered from its own flash backup
-  with an external programmer.
+  with an external programmer, or as a fallback over USB boot without one.
 
 All routes preserve the identity of **your** camera. There is no generic
 firmware image in this repository, and you must never write another camera's
@@ -95,8 +95,13 @@ First check whether the fault is isolated to the camera:
 3. Power the printer on.
 
 If the replacement webcam produces a feed, the stock camera is likely the
-problem. Continue with the
-[hardware recovery route](#failed-camera-hardware-recovery).
+problem. If you have an external programmer, or can obtain one easily, continue
+with the [hardware recovery route](#failed-camera-hardware-recovery). If you
+want to try recovery without a programmer, use the
+[USB-boot fallback](#failed-camera-usb-boot-recovery-without-a-programmer).
+Connecting a custom camera cable directly to a laptop lacks the in-circuit
+protection that a proper SPI programmer usually provides, so treat that path
+as optional rather than recommended.
 
 If the replacement webcam also fails, this test has not isolated the problem
 to the stock camera. Stop this camera-recovery procedure.
@@ -262,7 +267,8 @@ that already contains hooks has [additional limitations](docs/STARTUP-HOOKS.md#r
 
 ## Failed camera: hardware recovery
 
-This route reads and rewrites the camera's eight-pin SPI flash with an external
+This is the recommended recovery route when the stock camera no longer starts.
+It reads and rewrites the camera's eight-pin SPI flash with an external
 programmer. The recommended setup uses the NeoProgrammer graphical
 application for every flash operation; only the recovery-image build requires
 a command line.
@@ -357,6 +363,59 @@ Only after complete verification succeeds should you unplug the programmer,
 remove the clip, reconnect the camera's normal cable, and test it in the
 printer.
 
+## Failed camera: USB-boot recovery without a programmer
+
+This is an optional fallback if you do not have an external SPI programmer.
+It forces the Ingenic bootrom into USB boot, reads the flash over USB, builds
+the same camera-specific recovery image, and writes that image back over USB.
+
+A homemade camera-to-USB cable plugged straight into a computer does not give
+you the voltage checks and isolation that a CH341-style programmer workflow
+emphasizes. Prefer the [hardware recovery route](#failed-camera-hardware-recovery)
+when you can.
+
+Full steps, pin diagram notes, stop conditions, and verification are in
+[docs/USB-BOOT-RECOVERY.md](docs/USB-BOOT-RECOVERY.md). Summary:
+
+1. Build the same [camera-to-USB cable](#build-the-camera-to-usb-cable) used by
+   the working-camera route.
+2. Power the camera over that cable while briefly shorting SPI flash pins
+   **5 and 6** (SOIC-8: SI/MOSI and SCLK, counting from the pin-1 dot/notch).
+   The host should show **Ingenic USB Boot Device** (`a108:c309`). Remove the
+   short as soon as that device appears; leave it shorted only for power-up.
+
+   ![SPI flash pins 5 and 6 to short for USB boot](docs/images/cc2-flash-short-pins-5-6.jpg)
+3. Use [thingino-dfu](https://github.com/wltechblog/thingino-dfu) to bootstrap
+   DFU and read the whole flash three times:
+
+   ```sh
+   thingino-dfu -b
+   thingino-dfu --alt flash -r cc2-camera-1.bin
+   thingino-dfu --alt flash -r cc2-camera-2.bin
+   thingino-dfu --alt flash -r cc2-camera-3.bin
+   ```
+
+   Each file must be exactly 8,388,608 bytes, and all three must match
+   byte-for-byte. Copy them somewhere safe before continuing.
+4. Build the recovery image with the same offline builder as the programmer
+   route:
+
+   ```sh
+   cc2camera build-image cc2-camera-1.bin --confirm-read cc2-camera-2.bin --confirm-read cc2-camera-3.bin
+   ```
+5. Write and verify over DFU, then confirm three readbacks match the generated
+   image:
+
+   ```sh
+   thingino-dfu --alt flash -w cc2-camera-1-cc2-recovery/cc2-camera-recovery.bin --verify
+   ```
+6. Power-cycle **without** the flash short. The camera should leave bootrom and
+   enumerate as a normal UVC device (observed: `Ingenic HD Web Camera`,
+   `a108:2240`). Only then return it to the printer.
+
+Stop if USB stays silent, the three dumps disagree, `build-image` refuses the
+dump, or DFU verify / readback mismatches. Do not write another camera's image.
+
 ## What the repair changes
 
 Affected cameras repeatedly rewrite the same configuration files during every
@@ -394,6 +453,7 @@ No full camera dump or vendor firmware image is included in this repository.
 - [Startup-fix installation and verification](docs/STARTUP-HOOKS.md)
 - [Startup-fix hardware findings](docs/STARTUP-HOOKS-VALIDATION.md)
 - [Programmer and alternative-hardware reference](hardware-recovery/PROGRAMMER_REFERENCE.md)
+- [USB-boot recovery without a programmer](docs/USB-BOOT-RECOVERY.md)
 - [Independent recovery-tool verification](hardware-recovery/CC2_RECOVERY_VERIFICATION.md)
 - [Hardware-recovery regression results](hardware-recovery/TEST_RESULTS.md)
 - [USB-maintenance reference](usb-maintenance/REFERENCE.md)

docs/USB-BOOT-RECOVERY.md

@@ -0,0 +1,198 @@
+# Failed camera: USB-boot recovery without an SPI programmer
+
+This is an **optional fallback** when you do not have an external SPI
+programmer. It recovers a camera that no longer starts by forcing the Ingenic
+bootrom into USB boot, reading the on-board SPI flash over USB, building the
+same camera-specific recovery image that the programmer path uses, and writing
+that image back over USB.
+
+The recommended route remains the
+[external-programmer workflow](../README.md#failed-camera-hardware-recovery).
+A homemade camera-to-USB cable plugged straight into a computer does not give
+you the voltage checks and isolation that a CH341-style programmer setup
+emphasizes. Use this document only if you accept that trade-off.
+
+It was validated on one supported `EF-S7-V1.0.30B` / Ingenic T23 / 8 MiB unit:
+three identical 8 MiB reads, a successful `cc2camera build-image`, a verified
+full-chip write, and re-enumeration as a normal UVC webcam.
+
+This path still uses **your** camera's dump. Never write another camera's
+image.
+
+## What you need
+
+- the failed camera removed from the printer;
+- the same [camera-to-USB pogo cable](../README.md#build-the-camera-to-usb-cable)
+  used by the working-camera USB route;
+- a computer that can talk to Ingenic USB boot / DFU devices
+  (macOS, Linux, or Windows with the drivers described by thingino-dfu);
+- [thingino-dfu](https://github.com/wltechblog/thingino-dfu) built or otherwise
+  installed;
+- [cc2camera installed](INSTALLATION.md) for offline `build-image` only
+  (ADB is not required for this route).
+
+## USB states to expect
+
+| State | What you see on USB | Meaning |
+|---|---|---|
+| Normal firmware | UVC webcam, for example `Ingenic HD Web Camera` / `a108:2240` | Flash boots |
+| USB boot | `Ingenic USB Boot Device` / `a108:c309` | Bootrom is waiting; no video |
+| Silence | No new USB device | Power, cable, connector, or SoC start problem |
+
+This recovery starts from **USB boot** (`a108:c309`). After a successful write
+and power cycle, the camera should leave bootrom and appear as a normal UVC
+device again.
+
+## 1. Enter USB boot by shorting flash pins 5 and 6
+
+On the verified 8 MiB cameras the SPI NOR is an SOIC-8 package. Pin 1 is the
+dot / notch end of the package. Count counterclockwise from there:
+
+| Flash pin | Typical SOIC-8 signal |
+|---:|---|
+| 5 | SI (MOSI) |
+| 6 | SCLK |
+
+![SPI flash pins 5 and 6 to short for USB boot](images/cc2-flash-short-pins-5-6.jpg)
+
+Shorting pins **5 and 6** during power-up prevents a clean boot from SPI, so
+the SoC falls back to the USB bootrom.
+
+Procedure:
+
+1. Keep the camera's printer cable disconnected.
+2. Open the camera housing so the SOIC-8 flash is accessible.
+3. Connect the camera-to-USB cable to the camera's four-pin socket, but do not
+   plug the USB-A end into the computer yet.
+4. Briefly short flash pins **5 and 6** with tweezers or a similar conductive
+   bridge. Confirm pin 1 first; do not short VCC to ground.
+5. While the short is held, plug USB into the computer so the camera powers on.
+6. As soon as the host shows **Ingenic USB Boot Device** (`a108:c309`),
+   **remove the short**.
+7. Leave USB power connected. Do not leave pins 5 and 6 shorted for the
+   read/write steps: the DFU payload must be able to talk to the flash.
+
+If the host stays silent, re-check the USB cable pinout, power, and that the
+short was on pins 5 and 6 of the flash — not adjacent power or ground pins.
+
+On macOS you can confirm the bootrom device with:
+
+```sh
+system_profiler SPUSBDataType
+# or
+ioreg -p IOUSB -w0
+```
+
+You want `Ingenic` / `USB Boot` / vendor `0xa108` product `0xc309`, not a UVC
+camera node.
+
+## 2. Bootstrap DFU and make three identical dumps
+
+From a built [thingino-dfu](https://github.com/wltechblog/thingino-dfu) tree:
+
+```sh
+./build/cli/thingino-dfu -l
+./build/cli/thingino-dfu -b
+```
+
+`-l` should report the device in `bootrom` stage and auto-detect a T23-family
+SoC (observed: `t23n`). `-b` USB-boots a DFU-capable U-Boot. Wait a few seconds
+for re-enumeration, then:
+
+```sh
+./build/cli/thingino-dfu -l
+```
+
+You should see DFU alt-settings including `flash`. Keep power connected and
+read the whole chip three times without moving the cable:
+
+```sh
+mkdir -p cc2-camera-dumps && cd cc2-camera-dumps
+../path/to/thingino-dfu --alt flash -r cc2-camera-1.bin
+../path/to/thingino-dfu --alt flash -r cc2-camera-2.bin
+../path/to/thingino-dfu --alt flash -r cc2-camera-3.bin
+```
+
+Each file must be exactly **8,388,608** bytes. Compare them byte-for-byte (or
+compare SHA-256 digests). All three must be identical. All-`00`, all-`FF`,
+wrong size, or mismatched reads mean the USB/DFU path is not trustworthy —
+stop and do not continue to write.
+
+Copy the three dumps to a separate safe location before building or writing.
+
+## 3. Build the recovery image with cc2camera
+
+This step is offline and is the same builder used by the programmer route:
+
+```sh
+cc2camera build-image cc2-camera-1.bin --confirm-read cc2-camera-2.bin --confirm-read cc2-camera-3.bin
+```
+
+It must finish with a pass and create:
+
+```text
+cc2-camera-1-cc2-recovery/cc2-camera-recovery.bin
+```
+
+If the builder refuses the dump, stop. Do not bypass validation. Preserve both
+the original dumps and the generated recovery image.
+
+## 4. Write and verify over DFU
+
+With the camera still in DFU mode (re-run `thingino-dfu -b` if it dropped back
+to bootrom after a disconnect):
+
+```sh
+thingino-dfu --alt flash -w cc2-camera-1-cc2-recovery/cc2-camera-recovery.bin --verify
+```
+
+Require **Verify OK** for the full 8 MiB. Then make three fresh readbacks and
+compare each to the recovery image:
+
+```sh
+thingino-dfu --alt flash -r post-write-1.bin
+thingino-dfu --alt flash -r post-write-2.bin
+thingino-dfu --alt flash -r post-write-3.bin
+cmp cc2-camera-1-cc2-recovery/cc2-camera-recovery.bin post-write-1.bin
+cmp cc2-camera-1-cc2-recovery/cc2-camera-recovery.bin post-write-2.bin
+cmp cc2-camera-1-cc2-recovery/cc2-camera-recovery.bin post-write-3.bin
+```
+
+Optional offline check:
+
+```sh
+cc2camera inspect-image post-write-1.bin
+```
+
+Stop if verify, `cmp`, or `inspect-image` fails. Do not reboot into a partial
+write and hope.
+
+## 5. Reboot and confirm UVC
+
+Power-cycle the camera over USB (unplug, wait a few seconds, plug again)
+**without** shorting the flash pins.
+
+Expected result:
+
+- USB shows a normal webcam such as **Ingenic HD Web Camera** (`a108:2240`);
+- the host camera list shows a UVC device (name may vary by OS);
+- `thingino-dfu -l` no longer reports an Ingenic bootrom/DFU gadget.
+
+If the device returns to `a108:c309`, the write did not stick or the short is
+still applied. If USB is silent, check the cable and power first.
+
+Only after UVC enumeration looks healthy should you return the camera to the
+printer and confirm the printer feed.
+
+## Limits and safety notes
+
+- This route needs a flash that the DFU U-Boot can still read and program. A
+  dead, wrong-voltage, or unreachable SPI chip still needs physical probing
+  and may require the programmer path.
+- Remove the pin 5–6 short before DFU read/write. Leaving it connected can
+  make flash access fail even though USB boot succeeded.
+- thingino-dfu is a separate project. Follow its platform notes (especially
+  Windows WinUSB / Zadig setup for both `a108:c309` and the DFU gadget).
+- The recovery image changes only the audited startup-script window and the
+  writable config area of **this** camera's dump. It is not a generic
+  firmware image.

hardware-recovery/README.md

@@ -5,6 +5,12 @@ Start with the repository's
 It determines whether this repair applies and presents the normal
 NeoProgrammer workflow with one required command-line invocation.
 
+If you do not have an external programmer and want to try recovery over USB
+boot instead, see the optional
+[USB-boot fallback](../docs/USB-BOOT-RECOVERY.md). Prefer this directory's
+programmer path when you can: a CH341-style setup includes voltage checks and
+isolation that a homemade camera-to-USB cable plugged into a laptop does not.
+
 For details beyond that normal path:
 
 - [CLI reference](../docs/CLI.md) documents inspection, alternate build
@@ -16,5 +22,3 @@ For details beyond that normal path:
   electrical mapping and the Bus Pirate alternative.
 - [Independent verification](CC2_RECOVERY_VERIFICATION.md) and
   [regression results](TEST_RESULTS.md) record the current evidence.
-
-