Samsung Q990D unresponsive after 1020 firmware update

- The test jig is probably pristine, so no hundreds of hours of telemetry data clogging up the internal storage.

- The test jig might be on ethernet whereas a lot of users would be using wifi.

- The test jig probably targets specific A -> B upgrades rather than testing progressive upgrade across every version that's ever existed.

- The test jig can't cover every permutation of config options.

- The test jig probably only does a bare minimal smoke test after the install, so if the problem takes a bit to kick in, it might not show up.

Not to say that it's certainly any of these, but all are possible contributors. In the coming days it'll become clearer what particular pattern the affected devices follows, and/or clever people with JTAG dongles will reverse engineer the problem and spill the beans.

I'm trying to buck the trend though and on the new embedded system I'm working on, I've specifically designed the upgrade system to be as reliable as I can make it. It goes something like this:

- The new firmware is downloaded to the secondary application slot.

- Just prior to rebooting, the entire state data of the system is serialized as a document and stored on a flash partition.

- The upgrade flag is set, the system reboots and MCUboot does its thing.

- The new firmware finds out a upgrade happened, clears out all the data partitions, restores from the document and then clears out its partition.

The system is basically sanitized and restored after each upgrade. It's also the same codepath that handles saving and restoring the system's configuration by the end-user as well as settings management. If the document schema is for an older version, run the N-to-N+1 schema upgraders on it prior to applying instead of trying to patch the system in-place. If something goes horribly wrong, flip a jumper to trigger the heavy-duty sanitization that nukes the entire external flash (internal flash only contains the bootloader, primary application slot and factory parameters so it's essentially read-only once the application boots).

It might be hubris, but I hope it's good enough that I'll never see a bricked card that can't be resurrected by a factory reset with this project (assuming no hardware damage, no internal flash corruption and no bricking firmware getting signed with production keys seeping through the cracks despite all the checks in place).

Yeah, that sounds a weird "feature" in the first place.

If I manually turn on the UHD player/Chromecast/PS5/whatever, it makes sense that the TV also turns on and switches to the respective input.

I could also sort of imagine that if I switched the TV to some input source, it might be convenient if the device connected to that input turns on. (Not by a lot, though. You need the device's remote/gamepad/whatever anyway to tell it what to do, so the one button press saved doesn't really buy you much.)

But what makes no sense for me is the TV turning on all input devices when it's being turned on itself. When would you ever want to have the PS4, the PS5 and the HD player running, let alone as the default behavior?

That sounds like a genuine bug in the TV.

(Also, you sound as if you have some sort of "2 n" setup with n input and 2 output devices. I have no idea how CEC would even be supposed to behave in such a setup. Would an input device turn on both output devices?