|
| 1 | +# Recovery |
| 2 | + |
| 3 | +## Intro |
| 4 | + |
| 5 | +The following documentation describes the process of recovering the NovaCustom |
| 6 | +NUC BOX-155H platform from a brick state using Dasharo open-source firmware and |
| 7 | +one of two methods: |
| 8 | + |
| 9 | +- **WSON8 chip flashing using a CH341A and socket adapter** |
| 10 | +- **Remote/automated flashing via |
| 11 | + [qspimux](https://github.com/felixheld/qspimux) and |
| 12 | + [RTE](../../transparent-validation/rte/introduction.md)** |
| 13 | + |
| 14 | +The default BIOS flash chip is a **WSON8 package**, mounted in a socket — |
| 15 | +meaning **there are no exposed pins** for clip-on programmers. This makes |
| 16 | +traditional flashing using Pomona clips impossible. |
| 17 | + |
| 18 | +> ⚠️ Important: Repeated mechanical re-seating of the WSON8 chip may degrade |
| 19 | +the socket or damage the chip. This method is **not suited for remote or |
| 20 | +automated workflows**. |
| 21 | + |
| 22 | +## External flashing |
| 23 | + |
| 24 | +### CH341A with WSON8 socket adapter |
| 25 | + |
| 26 | +This method involves manually extracting the BIOS chip and flashing it outside |
| 27 | +the board using a CH341A programmer. |
| 28 | + |
| 29 | +#### Prerequisites |
| 30 | + |
| 31 | +- CH341A USB programmer |
| 32 | +- WSON8 to SOIC8 socket adapter |
| 33 | +- Known good firmware binary |
| 34 | +- [flashrom](https://flashrom.org/) installed on host PC |
| 35 | + |
| 36 | +#### Firmware flashing procedure |
| 37 | + |
| 38 | +1. Power off the NUC BOX-155H and disconnect all power. |
| 39 | +2. Carefully remove the WSON8 flash chip from the socket. |
| 40 | +3. Insert it into the WSON8-to-SOIC8 adapter, ensuring correct orientation. |
| 41 | +4. Plug the adapter into the CH341A programmer. |
| 42 | +5. Connect the programmer to your PC. |
| 43 | +6. Flash the firmware: |
| 44 | + |
| 45 | + ```bash |
| 46 | + flashrom -p ch341a_spi -w [path_to_binary] |
| 47 | + ``` |
| 48 | + |
| 49 | +7. Once completed, remove the chip from the adapter and reinsert it into the |
| 50 | + board’s socket. |
| 51 | +8. Power on the platform. |
| 52 | + |
| 53 | +> ⚠️ Note: This process is manual, not scalable, and fragile. It is **not |
| 54 | +recommended for repetitive tasks** or automated CI setups. |
| 55 | + |
| 56 | +--- |
| 57 | + |
| 58 | +### qspimux with RTE (recommended for automation) |
| 59 | + |
| 60 | +The [qspimux](https://github.com/felixheld/qspimux) setup enables **remote |
| 61 | +firmware flashing** without manually removing the flash chip. It supports SPI |
| 62 | +muxing between the host board and an external flasher like the RTE. |
| 63 | + |
| 64 | +> ⚠️ This method requires **hardware modifications**. The factory-mounted |
| 65 | +WSON8 socket must be desoldered and replaced with a 9-pin qspimux header. |
| 66 | +This involves **fine-pitch SMD soldering** and should only be done by |
| 67 | +experienced individuals. Proceed at your own risk. |
| 68 | + |
| 69 | +#### Benefits |
| 70 | + |
| 71 | +- Fully automated flashing possible via |
| 72 | + [RTE](../../transparent-validation/rte/introduction.md) |
| 73 | +- No physical chip handling after initial setup |
| 74 | +- Safer and repeatable in lab/validation environments |
| 75 | + |
| 76 | +#### Required mods |
| 77 | + |
| 78 | +- Desolder the original WSON8 socket |
| 79 | +- Solder a DIP-8 (or qspimux-compatible) header in its place |
| 80 | +- Wire the RTE and qspimux per pinouts below |
| 81 | + |
| 82 | +#### Prerequisites |
| 83 | + |
| 84 | +- [RTE](https://3mdeb.com/open-source-hardware/#rte) |
| 85 | +- qspimux board with WSON8 flash soldered onto SOIC8 adapter |
| 86 | +- Proper GPIO lines connected for mux control |
| 87 | +- `flashrom` installed on RTE |
| 88 | + |
| 89 | +#### Pin Mapping (J7 to qspimux J101) |
| 90 | + |
| 91 | +| RTE header J7 pin | qspimux J101 pin | |
| 92 | +|-------------------|------------------------| |
| 93 | +| 1 (VCC) | 2 (VCC_PROG) | |
| 94 | +| 2 (GND) | 7 (GND) | |
| 95 | +| 3 (CS) | 1 (CS_PROG#) | |
| 96 | +| 4 (SCLK) | 6 (CLK_PROG) | |
| 97 | +| 5 (MISO) | 8 (IO0_DI_PROG) | |
| 98 | +| 6 (MOSI) | 3 (IO1_DO_PROG) | |
| 99 | + |
| 100 | +#### Extra GPIOs for qspimux control |
| 101 | + |
| 102 | +| RTE header J10 pin | qspimux J101 pin | Purpose | |
| 103 | +|--------------------|-----------------------|------------------------| |
| 104 | +| 1 (GPIO400) | 9 (MUX_SEL) | Select board or programmer access | |
| 105 | +| 2 (GPIO401) | 4 (IO3_HOLD_PROG) | Deassert HOLD# | |
| 106 | +| 3 (GPIO402) | 5 (IO2_WP_PROG) | Control #WP (write protect) | |
| 107 | + |
| 108 | +#### Flashing procedure |
| 109 | + |
| 110 | +1. Wire the RTE and qspimux according to tables above. |
| 111 | +2. Tie `IO3_HOLD_PROG` high (3.3V) if not using GPIO401. |
| 112 | +3. Set mux to programmer: |
| 113 | + |
| 114 | + ```bash |
| 115 | + echo "0" > /sys/class/gpio/gpio400/value # MUX_SEL = 0 (external) |
| 116 | + echo "1" > /sys/class/gpio/gpio401/value # HOLD# = high |
| 117 | + echo "1" > /sys/class/gpio/gpio402/value # WP# = high (write enabled) |
| 118 | + ``` |
| 119 | + |
| 120 | +4. Flash the firmware: |
| 121 | + |
| 122 | + ```bash |
| 123 | + flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -w firmware.bin |
| 124 | + ``` |
| 125 | + |
| 126 | +5. Switch back to board: |
| 127 | + |
| 128 | + ```bash |
| 129 | + echo "1" > /sys/class/gpio/gpio400/value # MUX_SEL = 1 (board) |
| 130 | + ``` |
| 131 | + |
| 132 | +6. Optionally, reassert write protection: |
| 133 | + |
| 134 | + ```bash |
| 135 | + echo "0" > /sys/class/gpio/gpio402/value |
| 136 | + ``` |
| 137 | + |
| 138 | +> ⚠️ First boot after flashing may take longer. Always confirm stable power |
| 139 | +before flashing. |
| 140 | + |
| 141 | + |
| 142 | + |
| 143 | +More details and schematics: |
| 144 | +[qspimux.pdf](https://github.com/felixheld/qspimux/blob/master/qspimux/qspimux.pdf). |
0 commit comments