Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752492AbbL1Pgk (ORCPT ); Mon, 28 Dec 2015 10:36:40 -0500 Received: from mout.kundenserver.de ([212.227.126.187]:62325 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751846AbbL1Pgh (ORCPT ); Mon, 28 Dec 2015 10:36:37 -0500 From: Arnd Bergmann To: Thierry Reding Cc: linux-arm-kernel@lists.infradead.org, Andy Yan , heiko@sntech.de, linux-kernel@vger.kernel.org, mark.rutland@arm.com, devicetree@vger.kernel.org, khilman@linaro.org, linux@arm.linux.org.uk, pawel.moll@arm.com, ijc+devicetree@hellion.org.uk, benchan@google.com, sjg@chromium.org, linux-rockchip@lists.infradead.org, robh+dt@kernel.org, galak@codeaurora.org, wxt@rock-chips.com, john.stultz@linaro.org Subject: Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver Date: Mon, 28 Dec 2015 16:35:46 +0100 Message-ID: <2250962.OgUpqMgY4k@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151228092054.GA29195@ulmo.nvidia.com> References: <1447840044-19689-1-git-send-email-andy.yan@rock-chips.com> <15127971.1juVbocOjP@wuerfel> <20151228092054.GA29195@ulmo.nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:r85KnCTelH3qyXkjAyLcnN0YMYUNCc5ajrjMq5lWbiD1bhavi7w I9EfikHZIjjivGRXe+szzim4lXQF1vWbJSCoVrkgDkLfWwSxBAXLNktV9uD2u5m2qCH+c4E ReEsDXTwz51j+czT+pHQ5wbHRCDNSxU+Ex4XI/BoSWdUsBb3+hPYsIw7U/4XwHZ1c4cVGW0 A/AcZrMDt3cupYsQVRl+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:LebGE2BErWk=:ygC5gAYpKxNvXg5EJmpdYh 8cfEYrvfaC7PuNa3wdln3QHwmExRzPHk8HrG0Y+NoRphCpzbHuF/yfIFLTHxTWYMWnn7K9hUF T1nUhGven3XOgvTzO8cPKDCAkrAHXj7O5DAwLAC2Dah5u9b6jL4fzOHQDbdRX5LZPSJKO7Xyy WRpePRQ2Hyr34w0mXKCPH84gNIdzt/iC/6p+t1RHMNxBgcO3wWhOdabCHwwaLtAYFyP2KA5aR O+Cx6G6O4ZQXJV8vs2jx5lCjYw28LS3+7SU5h2ylg+XhSgmfEFvIHOwrjtqwEsZ/gM1J62HUk 39FbAfhP8ZlCoc6rUX9R5Y6K2HkdY5vEofWVlVcSP/lzEMKLHkfcHsVqIeVAzKuMH1Lm3uVNO U6CjhFya9L+1yq2qgSBlbupBru/yPf7sAqzXbxMNUKxx11X9o5qwogldbljiEJRTPydhxAAW/ CR+EH1pub6wqTbrVlw4ZlagKRNBLjPJMD0JQBcxB5k2PQcllbYvBLxIk40aVlgE9fEbpu6N53 lZDIn+25BVCJ4blxko1JkStp+VefSudvl4kTRgRzyQYkdINC95dgJxHPL1MGlH/+DOnLzowjn MsJjtCfV6+BL+VhPOBkZ1M0NDvjOU0z/oCX7eAYAXpyDfdHzjTna4toWzRRpXJqWXJmu+g+i6 2gdsaiGwf4KRo1K411KWk1xnHEaE1c0HnMGvs3N7DrDnFfK1Hk64ywma1O0V/NtUyOP3yfTHW kNxJxa6qSNDa0LLF Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2945 Lines: 56 On Monday 28 December 2015 10:20:56 Thierry Reding wrote: > > > > HTC apparently uses a separate RAM area to pass the reboot reason, > > > > and they have a driver to store that, which is separate from the > > > > driver that they use for actually rebooting the machine. > > > > > > I wasn't very clear, but the PMC_SCRATCH0 register is used to store the > > > reset reason. It supports the recovery mode, which I think is really an > > > Android thing, "bootloader" will typically cause the bootloader not to > > > boot anything, and "forced-recovery" will go into a recovery mode that > > > is used to bootstrap the device (usually by uploading a "miniloader" > > > that initializes RAM, downloads a bootloader for booting or flashing an > > > operating system, ...). > > > > > > The write that resets the SoC is to a different register. > > > > So is this scratch register interpreted by some maskrom code, or by code that > > can be provided by the OEM? > > My understanding is that its interpreted both by what's called BootROM > on Tegra (I guess that's what you call "maskrom code") and the system's > bootloader. The BootROM cannot typically be replaced by the OEM, but it > is quite typical for the bootloader to differ between devices. Ok, so not maskrom (which would not be OEM specific, but hardcoded for the chip) but rather some form of PROM. This means we can only guess that all OEMs use the same protocol but in theory someone could have implemented an incompatible BootROM, but it's also possible that HTC just ignore the register entirely and implement the same thing separately. > The BootROM will interpret a subset of the bits in that register. Most > notable the "force recovery" bit. That will cause the BootROM to go into > a mode which can be used to bootstrap the device. It implements a simple > protocol (RCM) which can be used to upload a loader (usually referred to > as mini-loader) to the device's IRAM which in turn will initialize the > memory and which can download a proper bootloader (such as U-Boot) to > memory using a slightly more complex protocol (the standard protocol is > called nv3p, but the particular choice of protocol no longer matters at > this point). > > The bootloader can also access this register and will interpret the > "bootloader" and "recovery" bits. On the, argueably small, sample of > Android devices I've worked with, the "bootloader" bit will make the > bootloader go into fastboot mode, whereas the "recovery" bit will make > it initiate the RCK mode, which is used to update through OTA. > > There are a couple of other bits in this register, but they are badly > documented and don't seem to relate to reboot. Ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/