Random nitpick from the middle of a good writeup of tracking down a hardware bug, but 'SMC' in this context doesn't stand for 'Secure Memory Controller'. It's the Arm instruction that lets normal-world (kernel) code call into secure world code (firmware). Just like the SVC insn lets userspace call the kernel, SMC lets the kernel call the trusted firmware. PSCI is a standardized API that the firmware implements with functions like 'power CPU on/off' and 'reset system'. The PSCI spec is public so you can get the function ID values and argument values from there rather than guessing them from source code. PSCI is the preferred mechanism for reset, cpu hotplug, etc on 64-bit Arm (it abstracts the details of prodding reset controller hardware and so on away and lets the firmware deal with it.)
Wow, that was really involved. The breakthrough seemed to be him seeing the through-hole via with the microscope where no branch in the circuit was supposed to exist. That is, after a whole bunch of dead-end exploratory exercises. Feels like the Pine folks should ship him a thank you package of goodies.
>There was an OD4 diode, but it is deleted from the schematics.
this is why providing schematics alone is not sufficient. PinePhone only provides schematics and not board layout and it is entirely possible that they are only loosely related. an imperfect analogy would be providing source but only running a binary compiled by someone else. you can see what they intended to do, but not necessarily what they did.
I'd considered getting a Clusterboard previously, but the reset-not-actually-working problem was a showstopper.
If this "fix" makes it into the next hardware revision of the Clusterboard, that should mean it's a feasible learning/experimentation platform after all. :)
How typical is this kind of troubleshooting on a scale from 1 (meaning every embedded dev can do this) to 10 (meaning there are 5 embedded devs in existence that can do this)?
