AW99703 INDSEL: the 2026-08-26 schematic doubles boost inductor L102 to 10 uH, and the driver never writes register 0x05

[Nicola-Ceornea]

The ODM's 2026-08-26 schematic revision changes the AW99703 boost inductor L102
from 4.7 µH to 10 µH. The AW99703 has a register bit that must track that
value, and our driver does not write it.

Found while diffing the newly-tracked revision against the superseded 2026-07-14
sheet (51848729). It was missed by an earlier visual read of the backlight
block, which looked at the output capacitors and not the inductor.

The datasheet requirement

AW99703 V1.6, "Inductor Select" (local copy ~/Documents/PQ1/vendor-docs/):

The AW99703 can use inductors in the range of 4.7μH to 10μH. In order to
optimize the converter loop response, the minimum inductor select bit Boost
Control Register 0x05 Bit[6] should be set depending on which value of
inductance is chosen. For 10μH inductors, this bit should be set to 1. For
less than 10μH, this bit should be set to 0.

Register table: 0x05 BSTCTR2, bit 6 INDSEL, 0: 4.7μH (default) / 1: 10μH,
register reset 0x00.

What our firmware does

secure/src/hw/aw99703.rs writes 0x02 MODE, 0x03 LEDCUR, 0x04 BSTCTR1,
0x06 LEDLSB, 0x07 LEDMSB, and reads 0x00 CHIP_ID, 0x0E/0x0F FLAGS.

0x05 appears nowhere in the file — not written, not read. So the boost runs
with INDSEL = 0 (4.7 µH) regardless of what is fitted.

Naming trap for whoever fixes this: our constant REG_BSTCTR1 is 0x04.
INDSEL is in 0x05, which is BSTCTR2 — a different register.

Scope — what this is and is not

It is loop-response tuning, not a protection threshold. It does not move OVP
or OCP, and it cannot explain a protection trip. The #733 fault readout cannot
see it either: that reads 0x00/0x02/0x04/0x0E/0x0F, never 0x05.

Speculative and flagged as such: a boost whose compensation is tuned for half the
fitted inductance could plausibly respond poorly to a load step, and #705 records
a one-frame brightness transient at the first content draw with no fault flag
set (F2=00 F1=00), which is consistent with a loop-response artefact rather
than a protection event. That is a hypothesis, not a finding — nobody has
measured the boost's transient response, and the transient was never
characterised at other brightnesses either.

The blocker before any code change

Nobody knows which inductor is fitted on which units. The schematic changed
on 2026-08-26; the sealed EVT unit 003B0022 and the pq1 bench board were built
at unknown dates against unknown BOM revisions. Writing INDSEL = 1 to a board
carrying the old 4.7 µH part would be exactly as wrong as the current state is
for a board carrying the new one.

So the order is:

1. Ask the ODM which inductor is fitted on which builds, and whether existing
   EVT units were reworked. This is a real question for them, unlike the
   over-voltage one that was withdrawn in pq1: FSBL cannot light the panel (no I2C stage for the AW99703) — invariant #10's boot fingerprint is invisible on a sealed unit #705.
2. Only then decide whether the driver writes 0x05, and whether it must be
   conditional — which would be unpleasant, since the FSBL copy of this driver
   (pq1: FSBL cannot light the panel (no I2C stage for the AW99703) — invariant #10's boot fingerprint is invisible on a sealed unit #705) is frozen by the RDP-2 self-lock and cannot be made conditional later.

That last point makes this worth settling before the FSBL I2C stage is
written, not after.

Also found in the same dump, closing an open item

LEDLSB 0x06 reset value is 0x07 and LEDMSB 0x07 reset is 0xFF.
#705 recorded these as "could not extract cleanly from the datasheet and am not
guessing", and the FSBL design pass declined to read them back for that reason.
They are in the V1.6 register table. LEDMSB defaulting to 0xFF also confirms
why the retired full-brightness experiment could not distinguish "survived" from
"reset" on that byte.