Date:	Wed, 28 Jan 2015 20:33:53 +0100
From:	Pali Rohár <pali.rohar@...il.com>
To:	"Jean-Christophe PLAGNIOL-VILLARD" <plagnioj@...osoft.com>
Cc:	Rob Herring <robherring2@...il.com>,
	Nicolas Pitre <nico@...xnic.net>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	"Russell King - ARM Linux" <linux@....linux.org.uk>,
	Tony Lindgren <tony@...mide.com>,
	Sebastian Reichel <sre@...ian.org>,
	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: /proc/atags: Export also for DT

On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL-
VILLARD wrote:
> > On Jan 28, 2015, at 11:57 PM, Rob Herring
> > <robherring2@...il.com> wrote:
> > 
> > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@...xnic.net> 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…
> 
> but if we try to do this generic, where will you store the
> boot mode
> 
> I mean where the SoC boot from
> 
> useful to for the Userspace to known where is the bootloader
> in case of multi boot mode
> 
> Best Regards,
> J.
> 
> > Rob
> > 

I think in this discussion we are mixing two parts which should 
be designed & solved separately.

1) How should bootloader tell to kernel what is bootreason

2) How should kernel export bootreason to userspace

In modern x86 laptop world bootreason can be requested from 
BIOS/WMI/firmware by special proprietary vendor specific command.

So we should not lock bootreason to DT or ATAG only. Or only 
bootloader --> kernel transition. For other platforms, board or 
even architectures (x86) there can runtime way (for kernel) how 
to read bootreason...

-- 
Pali Rohár
pali.rohar@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists