Message-Id: <4CCDD671-6850-4876-A523-88F3ECA29D9A@jcrosoft.com>
Date:	Wed, 28 Jan 2015 22:46:22 +0800
From:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
To:	Pali Rohár <pali.rohar@...il.com>
Cc:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Tony Lindgren <tony@...mide.com>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	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 Jan 28, 2015, at 9:58 PM, Pali Rohár <pali.rohar@...il.com> wrote:
> 
> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@....linux.org.uk> [150127 
> 09:51]:
>>> We _could_ (and have in the past) turned round and refused
>>> to support these kinds of hacks - which IMHO is quite a
>>> reasonable stance to take: the message we should be sending
>>> is "if you wish to design new methods without discussing it
>>> with us, we reserve the right not to support them in
>>> mainline kernels; please discuss with us your
>>> requirements."
>>> 
>>> Each time that we accept one of these hacks, we're sending a
>>> message that says "it's okay to work in this crappy way".
>>> 
>>> Yes, I realise that the N900 has little in the way of
>>> support, and we can't exert that kind of back pressure
>>> (since there's no one to direct that onto to effect any
>>> change) so I guess we just have to live with it.
>> 
>> I believe after N900 Nokia dropped the custom ATAGs and used
>> the kernel cmdline instead. And most of the n900 custom ATAGs
>> are not even needed any longer.
>> 
> 
> Yes, almost all N900 ATAGs are static and are already hardcoded 
> into kernel or DT file.
> 
> Basically there are 4 non static values which are used:
> 
> 1. ATAG_REVISION
> 
> 2. ATAG_OMAP
> 2.1 OMAP_TAG_BOOT_REASON --> boot reason

you can pass it via DT I already do it on other platform such as amineoIP
which is full DT with barebox as bootloader

> 2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version

do you really need such information in the kernel as we have a standard boot API?

> 2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or “update"

this is application specific not related to the kernel just pass it via cmdline

Best Regards,
J.
> 
> ATAG_OMAP is non standard and contains sub-atags.
> 
> bootloader version is static now (as Nokia does not develop it 
> anymore), but boot reason and boot mode are set by bootloader and 
> are needed for userspace. boot mode tells init system/userspace 
> if to start normal OS or only small subset for flashing.
> 
>> The ATAG_REVISION is a standard feature that we should support
>> naturally. I don't think we should add any custom ATAGs,
>> except maybe for the bootreason.
>> 
>>>> I think this kind of information (how was board/computer
>>>> started) can be useful also for other architectures. E.g.
>>>> on laptop you would like to know if if was started by
>>>> RTC, power button, WakeOnLan, another ACPI event,
>>>> rebooted machine, watchdog, etc... And scripts can act
>>>> depending on this event (when by RTC, you need to run
>>>> some planned job, when by watchdog reset you should check
>>>> what caused that reason...).
>>> 
>>> There is a standard way to get the boot information already:
>>> look at the watchdog API:
>>> 
>>> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
>>> int)
>>> 
>>> which uses the WDIOF_* flags to indicate the last boot
>>> reason.  It probably isn't as flexible as some may desire,
>>> but it should provide at least the "watchdog rebooted us"
>>> vs "over temperature" vs some other boot reason.
>>> 
>>> The other thing to consider is whether we have a way to know
>>> what the boot reason was, and what we should do if we do
>>> not have a way of supporting some of the boot reasons.  For
>>> example, if we have support for RTC alarm based booting,
>>> but no way to actually tell if the boot was caused by the
>>> RTC alarm triggering.
>> 
>> 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.
> 
> In non DT kernel file /proc/atags is always exported.
> 
>> Of course the problem is that the signed bootloader on n900
>> cannot be modified so the pass through u-boot would have to
>> translate the custom ATAG for bootreason into a kernel
>> cmdline..
>> 
>> But it may actually make sense to add the bootreason ATAGs, it
>> seems quite generic to me.
>> 
> 
> Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
> structure? Inventing new does not solve anything because all 
> developers does not boot kernel for debugging from uboot -- but 
> directly.
> 
>> AFAIK, the other n900 ATAGs can be just ignored.
>> 
>> Regards,
>> 
>> Tony
> 
> -- 
> Pali Rohár
> pali.rohar@...il.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists