From mboxrd@z Thu Jan 1 00:00:00 1970 From: pavel@ucw.cz (Pavel Machek) Date: Wed, 28 Jan 2015 19:03:22 +0100 Subject: [PATCH] ARM: /proc/atags: Export also for DT In-Reply-To: References: <1403110464-29646-1-git-send-email-pali.rohar@gmail.com> <20150127174818.GM26493@n2100.arm.linux.org.uk> <20150128005032.GK28663@atomide.com> <201501281458.22088@pali> Message-ID: <20150128180322.GA16868@amd> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed 2015-01-28 09:57:18, Rob Herring wrote: > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre wrote: > > On Wed, 28 Jan 2015, Pali Roh?r wrote: > > > >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote: > >> > On omaps, the bootrom passes the bootreason in r1 to the > >> > bootloader that can do whatever it wants with it. We could > >> > maybe pass it in the kernel cmdline to the watchdog driver > >> > for user space? > >> > > >> > >> Not truth for N900. Bootreason depends on PRM_RSTST omap > >> register, state of vbat charger pins, time how long was power key > >> pressed, R&D data stored in CAL partition and other undocumented > >> registers for omap HS devices. I already tried to implement at > >> least some subset of it in userspace (or kernel), but it is > >> impossible because NOLO bootloader clear status of PRM_RSTST > >> register. > >> > >> There is also copy of PRM_RSTST register stored at address > >> 0x4020FFB8 (tracing data) but that address is rewritten (probably > >> by kernel), so we really cannot implement reading bootreason in > >> kernel. > >> > >> But in early stage in uboot it is possible to read 0x4020FFB8 > >> address and get some part of bootreason. But still PRM_RSTST is > >> not enough! > >> > >> I would be happy if DT kernel can export /proc/atags file with > >> ATAGs passed by bootloader. It would be enough for me. In > >> userspace I can parse content and do what is needed. > > > > What about defining a DT boot reason property instead? > > Maybe it already exists? If not, it's something that could certainly be > > generically used on other platforms too. > > I'm fine with that, but we just need to have a standard kernel > userspace interface in addition to something like > /proc/device-tree/bootreason. Perhaps this can be the default > implementation for the watchdog dev. Someday when we decide DT is crap > and have a new boot interface, we'll have people relying on > /proc/device-tree. I hope to be retired when that happens... Huh. Who thought putting device-tree into /proc was good idea? That should have gone to /sys, as it is not process related... Anyway, bootreason does not depend on device-tree, so it should not be in device-tree specific subdirectory. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html