Hi Dan,
Whoops, sorry, this fell through the cracks for me since I wasn't on the to: line. Thanks for your response!
OK I can see the use of that, although I'd be a bit concerned about such a thing being available as a general service in case it gets used as an attack vector. For example, a test program could aggressively use this service to try to get the firmware to leak secure world information or something about its behaviour.
Yes, of course, we can gate this with a build option so it would only be available where desired.
However, I think there might already be support for what you need. PSCI is part of the standard service and the function SYSTEM_RESET2 allows for both architectural and vendor-specific resets. The latter allows for vendor-specific semantics, which could include crashing the firmware as you suggest.
Chrome OS could specify what such a vendor-specific reset looks like and each Chromebook's platform PSCI hooks could be implemented accordingly.
Right, but defining a separate vendor-specific reset type for each platform is roughly the same as defining a separate SiP SMC for each of them. 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.
Alternatively, this could potentially be defined as an additional architectural reset. This would enable a generic implementation but would require approval/definition by Arm's Architecture team. Like me they might have concerns about this being defined at a generic architectural level.
Yes, I think that would be the best option. Could you kick off that process with the Architecture team? Or tell me who I should talk to about this?
Thanks, Julius