NOTE: Fully ai generated response:

We actually pulled BL1 off the running SoC over SWD and disassembled its header check, so those two fields aren't guesses any more. The important part first: you don't need a donor sector 0. A byte-for-byte copy of your own FW2 header (eMMC 0x500000) written to LBA 0 is a valid FW1 header, because BL1 checks nothing slot-specific.

Your AI's parse of the trailer is off. The 8 bytes at 0x1F8 are four separate fields, not a type dword + a checksum dword:

+0x1F8 0x42 type byte BL1 checks == 0x42
+0x1F9 0x00 0x00 padding...

Quick update from today, made quite a bit of progress.

I first tried the suspected mainboard RX path on CN804_DB pin 3 while keeping the known-good TX connected. I can still read the normal mainboard UART spam, but I couldn’t get any response from the hidden debug shell. So either pin 3 isn’t RX, the console needs some extra enable condition, or the magic-key input is gated somehow. I’ve parked that for now before I turn this into another rabbit hole 😅

The more useful part is that I got SWD working on the slave T-CON SoC with a Raspberry Pi Debug Probe.
...

Quick follow up. I've downloaded the firmware again and let claude and fable run it. The debug shell is protected by a password.



The thing is claude is claiming that it's very easy to brute force this key since the board has a count of the correct characters typed in. so basically i let it write a script that just does this one by one ill test it out tonight and if it works send you the key or the script in case keys are not the same per monitor...

That’s massively helpful, thanks. I’ve now got one Raspberry Pi Debug Probe in hand and I’ve already confirmed its UART side works with the T-CON logs, so I’m moving onto SWD next.

I’ve also ordered a second Debug Probe now after looking at your patch2.py and seeing that it expects two OpenOCD instances at the same time for Master and Slave. Bit annoying to need another one, but at least the setup is very clear now.

My UART output matches your board exactly on both SoCs, including:

FW#1_CORE0 magickey error(0x0)
BL1 EMMC FW#2 core0,1
...

That’s perfect, thank! Really useful to know the exact SWD pads and that you didn’t need VTref.

I’ve got a Raspberry Pi Debug Probe on order now, so I’m basically waiting for that to arrive before I can continue on the SWD side. I’ve already got the soldering gear and thin wire sorted, and I’ll definitely take your advice on securing/insulating the leads properly after seeing what happened to your first board.

I’m also interested to see whether you manage to get into the mainboard shell and whether any of those T-CON dump/data commands expose calibration-related...

I’ve now confirmed both MDBG_TX and SDBG_TX show the exact same FW1 magickey → FW2 → Boot GPIO CNT Over → reset loop as yours. Do you still have a photo/pinout of the SWD pads you used for the Master/Slave SoCs, and which Pico Debug Probe pins you connected to SWDIO/SWCLK/VTref/GND?

Quick update: I actually got UART working in the meantime.

The mainboard log is constantly spamming:

SecDrvTcon_ReadPowerOnStatus: 00 00 00 00

over and over, exactly like in your case.

So between that and the motherboard swap test I did earlier, it’s looking more and more like the same T-CON-side failure.

I also managed to get hold of the official Samsung firmware packages and did some AI-assisted analysis on them.

The current public mainboard firmware (M-C9349GGAA-1011.0) contains a hidden UART debug console with...

Very impressive indeed, im actually in a situation with the exact same. coil whine, no led, no display.
In my case i had a second monitor what i just tried is switching the motherboards, display still wont turn on.
The display on the working monitor turns on fine and works properly. I'll install a firmware update on it and place it back but don't have a lot of trust that that will change anything.

anyone got tips / an idea i could try next? don't feel like switching the t-con board since i dont want to risk to much on the working display.