On Wed 31 May 12:31 PDT 2017, Rob Herring wrote: > On Fri, May 26, 2017 at 11:33:07PM -0700, Bjorn Andersson wrote: > > In order to aid post-mortem debugging the Qualcomm platforms provides a > > "memory download mode", where the boot loader will provide an interface > > for custom tools to "download" the content of RAM to a host machine. > > > > The mode is triggered by writing a magic value somehwere in RAM, that is > > read in the boot code path after a warm-restart. Two mechanism for > > setting this magic value are supported in modern platforms; a direct SCM > > call to enable the mode or through a secure io write of a magic value. > > > > In order for a normal reboot not to trigger "download mode" the magic > > must be cleared during a clean reboot. > > This must be happening somewhere before the kernel is entered? Or > warm-restarts are not the norm? > Not sure I'm getting what you're asking here. We set the flag on boot and clear it on shutdown, that way the early boot stages will be able to detect if the board restarted uncleanly - e.g. from accessing a protected register. > > Download mode has to be enabled by including qcom_scm.download_mode=1 on > > the command line. > > This looks similar to reboot reason functionality (i.e. boot into mode > X). I'd expect this to use that at least for the kernel. Not sure about > bindings though. > It's very much like reboot reason except the small detail that we want to enter this state when the board reboots without the kernels knowledge. Thinking about it, it may make sense to not clear the flag if we exit through the panic handler. But if that's wanted it could be done in a follow up patch, I only added this to catch an error where the RPM hit its error handler and reboots the board. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
