On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL-
VILLARD wrote:

quoted

On Jan 28, 2015, at 11:57 PM, Rob Herring
[off-list ref] wrote:

On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 

[off-list ref] wrote:

quoted

quoted

On Wed, 28 Jan 2015, Pali Roh?r wrote:

quoted

On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:

quoted

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.

quoted

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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/cc59673e/attachment-0001.sig>