From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> To: "Pali Rohár" <pali.rohar@gmail.com> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>, Tony Lindgren <tony@atomide.com>, Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>, Russell King - ARM Linux <linux@arm.linux.org.uk>, Sebastian Reichel <sre@debian.org>, Will Deacon <will.deacon@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH] ARM: /proc/atags: Export also for DT Date: Wed, 28 Jan 2015 22:46:22 +0800 [thread overview] Message-ID: <4CCDD671-6850-4876-A523-88F3ECA29D9A@jcrosoft.com> (raw) In-Reply-To: <201501281458.22088@pali> > On Jan 28, 2015, at 9:58 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote: >> * Russell King - ARM Linux <linux@arm.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@gmail.com > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: /proc/atags: Export also for DT Date: Wed, 28 Jan 2015 22:46:22 +0800 [thread overview] Message-ID: <4CCDD671-6850-4876-A523-88F3ECA29D9A@jcrosoft.com> (raw) In-Reply-To: <201501281458.22088@pali> > On Jan 28, 2015, at 9:58 PM, Pali Roh?r <pali.rohar@gmail.com> wrote: > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote: >> * Russell King - ARM Linux <linux@arm.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 at gmail.com > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2015-01-29 1:22 UTC|newest] Thread overview: 197+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-18 16:54 [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible Pali Rohár 2014-06-18 16:54 ` Pali Rohár 2014-06-18 19:01 ` Russell King - ARM Linux 2014-06-18 19:01 ` Russell King - ARM Linux 2014-06-18 19:09 ` Pali Rohár 2014-06-18 19:09 ` Pali Rohár 2014-06-18 19:59 ` Russell King - ARM Linux 2014-06-18 19:59 ` Russell King - ARM Linux 2014-06-19 8:21 ` Pavel Machek 2014-06-19 8:21 ` Pavel Machek 2014-07-11 19:31 ` Pavel Machek 2014-07-11 19:31 ` Pavel Machek 2014-06-18 19:07 ` Rob Herring 2014-06-18 19:07 ` Rob Herring 2014-06-18 19:22 ` Pali Rohár 2014-06-18 19:22 ` Pali Rohár 2014-06-18 20:00 ` Russell King - ARM Linux 2014-06-18 20:00 ` Russell King - ARM Linux 2014-06-18 20:20 ` Pali Rohár 2014-06-18 20:20 ` Pali Rohár 2014-06-18 21:53 ` Fabio Estevam 2014-06-18 21:53 ` Fabio Estevam 2014-11-24 22:16 ` Pali Rohár 2014-11-24 22:16 ` Pali Rohár 2014-06-18 20:46 ` Rob Herring 2014-06-18 20:46 ` Rob Herring 2014-06-18 21:47 ` Russell King - ARM Linux 2014-06-18 21:47 ` Russell King - ARM Linux 2014-06-18 22:27 ` Rob Herring 2014-06-18 22:27 ` Rob Herring 2014-06-18 23:07 ` Russell King - ARM Linux 2014-06-18 23:07 ` Russell King - ARM Linux 2014-11-24 22:19 ` Pali Rohár 2014-11-24 22:19 ` Pali Rohár 2014-12-04 0:33 ` Rob Herring 2014-12-04 0:33 ` Rob Herring 2014-12-04 0:48 ` Pali Rohár 2014-12-04 0:48 ` Pali Rohár 2014-12-04 16:49 ` Rob Herring 2014-12-04 16:49 ` Rob Herring 2014-12-04 17:57 ` Pali Rohár 2014-12-04 17:57 ` Pali Rohár 2014-12-04 18:10 ` Rob Herring 2014-12-04 18:10 ` Rob Herring 2015-01-26 19:09 ` [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision Pali Rohár 2015-01-26 19:09 ` Pali Rohár 2015-01-26 20:22 ` Rob Herring 2015-01-26 20:22 ` Rob Herring 2015-01-30 14:14 ` Pali Rohár 2015-01-30 14:14 ` Pali Rohár 2015-01-30 21:03 ` Rob Herring 2015-01-30 21:03 ` Rob Herring 2015-02-27 15:45 ` Pali Rohár 2015-02-27 15:45 ` Pali Rohár 2015-02-27 15:55 ` [PATCH v2 0/2] " Pali Rohár 2015-02-27 15:55 ` Pali Rohár 2015-02-27 15:55 ` [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision Pali Rohár 2015-02-27 15:55 ` Pali Rohár 2015-02-27 15:55 ` [PATCH v2 2/2] arm: boot: convert ATAG_REVISION to DT revision field Pali Rohár 2015-02-27 15:55 ` Pali Rohár 2015-03-02 11:28 ` [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision Pavel Machek 2015-03-02 11:28 ` Pavel Machek 2015-03-16 15:44 ` Tony Lindgren 2015-03-16 15:44 ` Tony Lindgren 2015-03-16 16:14 ` Russell King - ARM Linux 2015-03-16 16:14 ` Russell King - ARM Linux 2015-03-16 16:43 ` Nicolas Pitre 2015-03-16 16:43 ` Nicolas Pitre 2015-03-16 19:21 ` Russell King - ARM Linux 2015-03-16 19:21 ` Russell King - ARM Linux 2015-03-16 18:10 ` Tony Lindgren 2015-03-16 18:10 ` Tony Lindgren 2015-03-16 19:59 ` Russell King - ARM Linux 2015-03-16 19:59 ` Russell King - ARM Linux 2015-03-16 20:54 ` Pali Rohár 2015-03-16 20:54 ` Pali Rohár 2015-03-16 20:59 ` Tony Lindgren 2015-03-16 20:59 ` Tony Lindgren 2015-01-26 22:34 ` [PATCH] " Andreas Färber 2015-01-26 22:34 ` Andreas Färber 2015-02-27 15:56 ` Pali Rohár 2015-02-27 15:56 ` Pali Rohár 2015-01-26 19:16 ` [PATCH] ARM: /proc/atags: Export also for DT Pali Rohár 2015-01-26 19:16 ` Pali Rohár 2015-01-26 20:33 ` Rob Herring 2015-01-26 20:33 ` Rob Herring 2015-01-27 13:21 ` Pavel Machek 2015-01-27 13:21 ` Pavel Machek 2015-01-27 14:16 ` Rob Herring 2015-01-27 14:16 ` Rob Herring 2015-01-27 14:24 ` Pavel Machek 2015-01-27 14:24 ` Pavel Machek 2015-01-27 14:32 ` Pali Rohár 2015-01-27 14:32 ` Pali Rohár 2015-01-27 17:48 ` Russell King - ARM Linux 2015-01-27 17:48 ` Russell King - ARM Linux 2015-01-27 20:03 ` Nicolas Pitre 2015-01-27 20:03 ` Nicolas Pitre 2015-01-27 21:09 ` Russell King - ARM Linux 2015-01-27 21:09 ` Russell King - ARM Linux 2015-01-27 21:34 ` Nicolas Pitre 2015-01-27 21:34 ` Nicolas Pitre 2015-01-27 21:58 ` Nicolas Pitre 2015-01-27 21:58 ` Nicolas Pitre 2015-01-27 22:33 ` Russell King - ARM Linux 2015-01-27 22:33 ` Russell King - ARM Linux 2015-01-28 2:07 ` Nicolas Pitre 2015-01-28 2:07 ` Nicolas Pitre 2015-01-28 6:21 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-28 6:21 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-28 7:19 ` Pavel Machek 2015-01-28 7:19 ` Pavel Machek 2015-01-28 8:06 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-28 8:06 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-28 8:25 ` Pavel Machek 2015-01-28 8:25 ` Pavel Machek 2015-01-28 7:18 ` Pavel Machek 2015-01-28 7:18 ` Pavel Machek 2015-01-28 13:38 ` Pali Rohár 2015-01-28 13:38 ` Pali Rohár 2015-01-27 23:10 ` Pavel Machek 2015-01-27 23:10 ` Pavel Machek 2015-01-28 0:50 ` Tony Lindgren 2015-01-28 0:50 ` Tony Lindgren 2015-01-28 13:58 ` Pali Rohár 2015-01-28 13:58 ` Pali Rohár 2015-01-28 14:33 ` Nicolas Pitre 2015-01-28 15:39 ` Tony Lindgren 2015-01-28 15:39 ` Tony Lindgren 2015-01-28 15:47 ` Pali Rohár 2015-01-28 15:47 ` Pali Rohár 2015-01-28 15:48 ` Tony Lindgren 2015-01-28 15:48 ` Tony Lindgren 2015-01-28 16:31 ` Jason Cooper 2015-01-28 16:31 ` Jason Cooper 2015-01-28 15:57 ` Rob Herring 2015-01-28 15:57 ` Rob Herring 2015-01-28 16:13 ` Russell King - ARM Linux 2015-01-28 16:13 ` Russell King - ARM Linux 2015-01-28 16:19 ` Will Deacon 2015-01-28 16:19 ` Will Deacon 2015-01-28 17:01 ` Russell King - ARM Linux 2015-01-28 17:01 ` Russell King - ARM Linux 2015-01-28 17:29 ` Russell King - ARM Linux 2015-01-28 17:29 ` Russell King - ARM Linux 2015-01-28 17:18 ` Pali Rohár 2015-01-28 17:18 ` Pali Rohár 2015-01-28 18:00 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-28 18:00 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-28 19:33 ` Pali Rohár 2015-01-28 19:33 ` Pali Rohár 2015-01-28 18:03 ` Pavel Machek 2015-01-28 18:03 ` Pavel Machek 2015-01-28 19:27 ` Arnd Bergmann 2015-01-28 19:27 ` Arnd Bergmann 2015-01-28 14:46 ` Jean-Christophe PLAGNIOL-VILLARD [this message] 2015-01-28 14:46 ` Jean-Christophe PLAGNIOL-VILLARD 2015-01-27 19:40 ` Nicolas Pitre 2015-01-27 19:40 ` Nicolas Pitre 2015-01-26 20:37 ` Russell King - ARM Linux 2015-01-26 20:37 ` Russell King - ARM Linux 2015-01-26 20:44 ` Pali Rohár 2015-01-26 20:44 ` Pali Rohár 2014-12-04 19:00 ` [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible Pali Rohár 2014-12-04 19:00 ` Pali Rohár 2014-12-04 10:59 ` Russell King - ARM Linux 2014-12-04 10:59 ` Russell King - ARM Linux 2014-06-18 21:10 ` Aaro Koskinen 2014-06-18 21:10 ` Aaro Koskinen 2014-07-11 19:28 ` Pavel Machek 2014-07-11 19:28 ` Pavel Machek 2014-11-24 22:21 ` Pali Rohár 2014-11-24 22:21 ` Pali Rohár 2014-09-05 11:38 ` Pali Rohár 2014-09-05 11:38 ` Pali Rohár 2014-09-05 12:13 ` Russell King - ARM Linux 2014-09-05 12:13 ` Russell King - ARM Linux 2014-09-10 12:46 ` Pavel Machek 2014-09-10 12:46 ` Pavel Machek 2014-11-24 22:23 ` Pali Rohár 2014-11-24 22:23 ` Pali Rohár 2014-09-05 13:45 ` Mark Rutland 2014-09-05 13:45 ` Mark Rutland 2014-09-05 13:52 ` Pali Rohár 2014-09-05 13:52 ` Pali Rohár 2014-09-05 13:58 ` Mark Rutland 2014-09-05 13:58 ` Mark Rutland 2014-11-24 22:25 ` Pali Rohár 2014-11-24 22:25 ` Pali Rohár 2014-09-05 13:58 ` Fabio Estevam 2014-09-05 13:58 ` Fabio Estevam 2014-11-24 22:27 ` Pali Rohár 2014-11-24 22:27 ` Pali Rohár 2014-09-06 15:34 ` Andreas Färber 2014-09-06 15:34 ` Andreas Färber 2014-11-24 22:29 ` Pali Rohár 2014-11-24 22:29 ` Pali Rohár
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4CCDD671-6850-4876-A523-88F3ECA29D9A@jcrosoft.com \ --to=plagnioj@jcrosoft.com \ --cc=ivo.g.dimitrov.75@gmail.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=pali.rohar@gmail.com \ --cc=pavel@ucw.cz \ --cc=sre@debian.org \ --cc=tony@atomide.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.