Hi Julius,

OK, in that case I can see that a solution based on TF-A's DebugFS interface might not be desirable. Indeed, our original intention was to make the whole DebugFS system a debug-only feature (hence its name!). As such, I agree that it is likely not to get the same level of scrutiny and testing as other features intended for production systems.

One of the main use cases we have in mind for DebugFS is, being able to peek and poke into the firmware for testing purposes. Today, when doing functional testing from the normal world (for example, using TF-A Tests), we are limited to what's exposed through the SMC interface. And even then, we have limited visibility on what really happened in the firmware, as we can only deduce so much from the SMC return value(s). DebugFS could be used to bridge this gap, by providing a side channel for getting internal firmware state information.

Going back to the SMC-based solution then, I am not quite convinced SYSTEM_RESET2 is the right interface for intentionally triggering a panic in TF-A. I think the semantics do not quite match. If anything, a firmware crash seems more like a shutdown operation to me rather than a reset (we don't recover from a firmware crash). I am not even sure we should look into the PSCI SMC range, as it's not a power-management operation.

Julius, you wrote:

It's the same problem that the SMC/PSCI spec and the TF repository layout is only designed to deal with generic vs. SoC-vendor-specific differentiation. If the normal world OS needs a feature, we can only make it generic or duplicate it across all vendors running that OS.

So it sounds like it's not the first time that you hit this issue, is it? Do you have any other example of Normal World OS feature you would have liked to expose through a generic SMC interface? I am wondering whether this could help choosing the right SMC range, if we can identify some common criteria among a set of such features.

Regards, Sandrine