TPA10 (board TPA10-M3_V1.0.2): backlight dead after flashing S9E firmware — requesting a boot.img dump

[Ji983]

I bricked the display on my TPA10 and I've narrowed the cause down to a single missing signal. Hoping someone with a working unit can spare three minutes.

Hardware

• Unit: TPA10-M2E, board silkscreen TPA10-M3_V1.0.2
• SoC: RK3566, eMMC: 7634944 KB (Samsung), Flash ID 45 4d 4d 43 20
• Panel: 10.1", native portrait 1200×1920

What happened

I lost the original firmware and, before finding this project, flashed a Smatek S9/S9E RK3566 image. Android boots fine, ADB works, but the LCD is completely dark — no light at all, even in a pitch-black room, and nothing at cold boot either (U-Boot is also from the S9E image).

What I've verified — the software side is fine

Layer	State
DSI panel timing	1200×1920, htotal 1344, vtotal 1996, 150 MHz → 55.9 Hz
Android reports	Built-in Screen, 1920 x 1200, fps=56.000004 — exact match for real TPA10
vcc3v3_lcd0_n	enabled, 3300 mV (confirmed in regulator_summary)
Panel reset GPIO3_A7	released (out hi, active-low)
Backlight PWM	fe6e0010, 25000 ns period, duty 19625 ns = 78.5% — tracks brightness correctly, polarity normal
SurfaceFlinger	Boot is finished, launcher displayed

So the S9E DTB actually has the correct panel timing. What it lacks is any way to switch the backlight on:

regulator-dummy
   backlight-power        <- dummy, no real regulator
   fe060000.dsi.0-vsp     <- dummy
   fe060000.dsi.0-vsn     <- dummy

The /backlight node has only pwms, brightness-levels and default-brightness-level — no enable-gpios, no power-supply. Nothing in the GPIO dump resembles bl_en or lcd_en. My conclusion is that TPA10's LED driver has an enable pin (or boost supply) that the S9E device tree simply doesn't describe, so the PWM signal arrives at a driver that is never powered up.

Evidence the board really is TPA10, not S9E

i2cdetect across all seven buses:

• bus 0 — rk809 (PMIC) + syr827, both bound and working
• buses 1, 2, 4, 5, 6 — completely empty, yet the S9E DTB expects aw82194/aw883xx amps, a gc5035 camera, gt9xx touch, stk3a5x and cht8305 there. All of them fail to probe.
• bus 3 — three devices at 0x0e, 0x30, 0x6c that respond but appear in no device tree node

So the real peripherals live on bus 3 and the S9E DTB knows nothing about them. I dumped their registers but couldn't identify the parts with confidence; none looks like a classic backlight driver (no ID at a typical LP8556/SGM/KTD address, no register tracking the PWM duty).

Recovery sources I've already exhausted

• Full eMMC backup — only 7 MB of 7.28 GB actually read; the rest is 0xCC filler. Just the boot header and the start of the kernel survived.
• recovery partition — contains the S9E DTB, byte-identical to the live one
• backup partition — 99.97% zeroes
• stback (1.46 GB) — holds a full OTA zip, but post-build matches the running ro.build.fingerprint exactly (rockchip/rk3566_r/rk3566_r:11/RD2A.211001.002/…20250324…), so it's the S9E image, not the original
• A Tuya A4S10 RK3566 image I had on hand — its panel node is 1920×720 @ 60 Hz, a bar display. Not usable, so I never wrote it.

Nothing of the original firmware remains on the flash.

The ask

If you have a working TPA10, please dump these. It's dd over ADB, no disassembly:

adb shell "su 0 dd if=/dev/block/by-name/boot   of=/sdcard/boot.img   bs=1M"
adb shell "su 0 dd if=/dev/block/by-name/dtbo   of=/sdcard/dtbo.img   bs=1M"
adb shell "su 0 dd if=/dev/block/by-name/vbmeta of=/sdcard/vbmeta.img bs=1M"
adb pull /sdcard/boot.img
adb pull /sdcard/dtbo.img
adb pull /sdcard/vbmeta.img

boot.img is the one that matters — on these Rockchip builds the DTB sits in a separate section of the boot image (header v2, dtb_size), and that's where the panel and backlight description lives. vbmeta is needed so AVB doesn't reject a mismatched boot image.

I can flash it safely: ADB still works, so adb reboot loader gives me a verified Loader mode, and I'd write only boot/dtbo/vbmeta by name with rkdeveloptool wlx — no GPT changes, no writes to uboot, trust or security.

Happy to give back

• A verified RK356x MiniLoaderAll.bin (446 KB) extracted from an RKFW image, in case anyone needs a model-matched loader for Maskrom recovery
• Several small dependency-free Python tools I wrote while debugging: an RKFW/RKAF update.img unpacker, a DTB locator/parser that reads panel and backlight nodes straight out of a boot.img (no dtc or extract-dtb, runs on plain Windows Python), an Android boot header parser, and a dump validator that maps which regions of a raw image are real data versus 0xFF/0xCC filler — that last one would have saved me a lot of time if I'd had it earlier.

The hardware documentation in this project is what kept me from making things worse, so thanks for that regardless of how this ends.

[maxlyth]

I have a tpa10-userdebug 11 RD2A.211001.002 2.6.8-beta.33. It is pretty old firmware but that has some advantages. I am working really hard to get the 0.9.6 release out tonight or early tomorrow but can send you an image after that. If anyone else has a different version of the firmware to share then include me as I have a private archive of every version I can find to support research in the project.

I hope you fix your TPA10 because it is really awesome panel with ha-paneld other than the rear facing LED is very green biased, I'm not sure if that is something I broke or something inherent to the panel.

[maxlyth]

Sorry about the delay on the firmware. The rc4 release took a lot more work than I expected and is only just going out tonight. I will try to get the backup to you tomorrow (Friday)

[maxlyth]

You can download the 3 recovery partitions from https://we.tl/t-zmWSrBm9RuUFOCsO - Valid until Aug 2nd

[Ji983]

Thx you have save me.

[Ji983]

Quick update, one ask, and some findings that might be worth adding to the TPA10 docs.

The boot.img worked

Display, touch, backlight with proper brightness control, the RGB LED and the button backlight all came up natively. Thanks — that was the missing piece.

What I'm running now is a hybrid: your TPA10 boot on top of a Smatek/S9E super. Everything the device tree drives works; everything that lives in /vendor doesn't.

Working: display, brightness, touch, RGB LED, button backlight, sensors, Bluetooth
Not working: wifi, audio, camera

What's broken and why

Wi-Fi — the bcmdhd.ko in my super is from the Smatek build:

module: vermagic=4.19.232 SMP preempt mod_unload modversions aarch64   (gcc)
kernel: 4.19.232-ab2.6.8-beta.33 ... clang version 11.0.2 ... #53

Different suffix and a different compiler, so insmod fails with Exec format error. With modversions in play, patching the vermagic string wouldn't help — the symbol CRCs won't match either. Bluetooth works fine, so the radio hardware is healthy; it's purely the wifi kernel module.

Audio — the kernel side is fully up. The card enumerates as tuya,tpe22-snd with all PCM nodes present, and both codecs bind cleanly (rk817-hifi <-> fe410000.i2s mapping ok, es7202 pdm 0 <-> fe440000.pdm mapping ok). But tinyplay runs silently on every Playback Path setting. The mixer only exposes 4 generic rk817 controls, so the actual speaker-enable path is presumably in the vendor HAL.

Camera — the sensor is detected and bound (gc5035 2-0037: detected gc5035 sensor, csi2-dphy1 matches m00_f_gc5035, notifier completed), and Android enumerates one device. But opening it fails:

CameraProviderManager: DeviceInfo3: Converted ICameraDevice instance to nullptr
CameraService: Unknown camera ID 0
RkCamera: V4L2Subdev: VIDIOC_SUBDEV_G_SELECTION failed: Inappropriate ioctl for device

and the kernel shows the ISP not initialising properly:

rkisp_hw: can't request region for resource [mem 0xfdff0000-0xfdffffff]
rkisp: Entity type for entity rkisp-isp-subdev was not initialized!

The camera3_profiles_rk356x.xml I have is the Smatek one, describing a different sensor setup.

The ask

Is the full super.img still on the table?

I realise that's the bigger request, but all three matter for what I'm building: the panel is going to be a video doorbell / intercom endpoint in Home Assistant, so camera and two-way audio aren't optional extras — they're the point. Wifi is what's blocking ha-paneld itself, but audio and camera are what the install is actually for.

Individual files would get wifi up (/vendor/lib/modules/bcmdhd.ko plus the matching fw_bcm*.bin / nvram*.txt from /vendor/etc/firmware), but audio and camera both look like vendor-HAL problems rather than single missing files, so I don't think cherry-picking gets me there.

No rush on it, and no problem if it's not practical — I know it's 3 GB. I'm not looking to run the Tuya UI, just to have the hardware working under ha-paneld.

Findings worth documenting

Backlight pin mapping. Anyone who flashes Smatek/S9E firmware onto a TPA10 gets a completely dark screen, and the cause is that the two boards drive the backlight from different PWM controllers:

	PWM	Pin
TPA10	fe6e0000 (PWM4)	GPIO0_C3 = 19
S9E	fe6e0010 (PWM5)	GPIO0_C4 = 20

One pin over. The SoC generates a perfectly correct 40 kHz signal at the right duty cycle — on a pin that goes nowhere. The S9E device tree also has no enable-gpios at all on its panel node, while the TPA10 needs GPIO3_C2 = 114, active low.

As a stopgap before I had the correct boot.img, driving both by hand brought the display back on S9E firmware:

echo 19  > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio19/direction
echo 1   > /sys/class/gpio/gpio19/value    # PWM pin held high = full brightness
echo 114 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio114/direction
echo 0   > /sys/class/gpio/gpio114/value   # panel enable, active low

No brightness control that way, but readable — enough to make a bricked panel usable while sorting out firmware.

The DTB is stable across versions. I compared the DTB from your dump against a 2.9.604 TPA10 build I found separately: byte-identical, 123,709 bytes. So the pin numbers above should hold for any TPA10.

I2C layout confirms the board. Scanning all seven buses, the ones S9E expects its amps, camera and touch controller on are physically empty, while three devices sit on i2c-3 at 0x0e, 0x30 and 0x6c — the last matching the VI5300 in your notes.

Tools, if useful

I wrote a few small dependency-free Python utilities working through this — an RKFW/RKAF update.img unpacker, a DTB locator/parser that reads panel and backlight nodes straight out of a boot.img (no dtc or extract-dtb, runs on stock Windows Python), an Android boot-header parser, and a dump validator that maps which regions of a raw image are real data versus 0xFF/0xCC filler.

That last one is the one I'd actually recommend for anyone keeping a firmware archive. My own full-eMMC backup turned out to be 99.9% filler with only 7 MB genuinely read — and the file size was byte-exact, so nothing looked wrong until I checked the contents.

Happy to share any of them if they'd be useful.

[Ji983]

Two corrections to what I posted above.

The wifi chip is Realtek, not Broadcom. The panel reports sys.wifi.chip = RTL8723DS, so the module needed is 8723ds.ko — not bcmdhd.ko as I said earlier. Same for the firmware blobs: rtl8723ds_fw and rtl8723ds_config rather than the fw_bcm* files.

The rejection is a CRC mismatch, not just vermagic. Loading it gives:

8723ds: disagrees about version of symbol module_layout

That's modversions failing on module_layout itself, so patching the vermagic string wouldn't help — every module in the Smatek /vendor/lib/modules is affected, not just the wifi one.

Also, now that the TPA10 boot is running, two of the three devices on i2c-3 show up identified in the logs:

Address	Device
3-000e	CG5256 light sensor (light_cg5256, 196 ms poll)
3-0030	still unidentified
3-006c	VI5300 ToF — matches your notes

[davidcoulson]

Is there a reason you can't get the image from the panel manufacturer? Even with the weird off brand stuff I buy on AliExpress they're more than willing to send images, software etc.

Or buy another one and image it :)

[Ji983]

I contacted them. First they said it wasn't possible, then they said it might be possible and that they would get back to me. So far, nothing.

[maxlyth]

Thanks for the detailed follow-up. I closed this too early while the larger request was still open and then got distracted trying to get the last two releases out.

I could not verify whether the super.img might contain PID/config which would not be safe for public distribution. If you DM me on community chat (see main page README) then I will send you an image.

[Ji983]

Sent you a DM on Matrix (#ha-paneld:matrix.org)

[maxlyth]

I sent the image privately. I’m keeping super.img off the public thread because I could not confirm whether it contains device-specific data but if anyone else needs it then contact me on Matrix.