| Message ID | 201501262016.52079@pali (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"): > > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c > index e7e1cc9..1975d7c 100644 > --- a/arch/arm/boot/compressed/atags_to_fdt.c > +++ b/arch/arm/boot/compressed/atags_to_fdt.c > @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) > * address and size for each bank */ > uint32_t mem_reg_property[2 * 2 * NR_BANKS]; > int memcount = 0; > - int ret, memsize; > + int ret, memsize, atag_size; > > /* make sure we've got an aligned pointer */ > if ((u32)atag_list & 0x3) > @@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) > } > } > > + /* include the terminating ATAG_NONE */ > + atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header); > + setprop(fdt, "/", "atags", atag_list, atag_size); > + > if (memcount) { > setprop(fdt, "/memory", "reg", mem_reg_property, > 4 * memcount * memsize); > > > > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file: Please properly send your patches. > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 9946c1b..0f249a3 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -29,6 +29,7 @@ > #include <asm/mach-types.h> > #include <asm/system_info.h> > > +#include "atags.h" > > #ifdef CONFIG_SMP > extern struct of_cpu_method __cpu_method_of_table[]; > @@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > if (prop) > system_rev = fdt32_to_cpu(*prop); > > + /* Save atags */ > + prop = of_get_flat_dt_prop(dt_root, "atags", NULL); > + if (prop) > + save_atags((void *)prop); > + > return mdesc; > } > > > Some userspace applications needs access to ATAG structure where can be stored some information passed > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal > mode or device update mode). This goes in the commit message. These would be non-standard fields which are not upstream. I don't know that we care in that case... Rob
On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Rohár wrote: > This patch will cause that decompressor store full ATAG structure into > DT tree ("/atags"): How about something a little more radical. Rather than trying to squeeze various ATAGs into DT, why don't we add a standard ATAG to contain the DT and pass that through into the kernel. This is IMHO how we _should_ have done the ATAG compatibility from the start. That means we could get rid of most of the libfdt in the decompressor, and instead resolve the differences in the kernel.
On Monday 26 January 2015 21:37:51 Russell King - ARM Linux wrote: > On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Rohár wrote: > > This patch will cause that decompressor store full ATAG > > structure into > > > DT tree ("/atags"): > How about something a little more radical. > > Rather than trying to squeeze various ATAGs into DT, why don't > we add a standard ATAG to contain the DT and pass that > through into the kernel. This is IMHO how we _should_ have > done the ATAG compatibility from the start. > > That means we could get rid of most of the libfdt in the > decompressor, and instead resolve the differences in the > kernel. This sounds good. Now when I patched decompressor myself with Revision property support, I wanted to ask same question: Why to convert some part from ATAGs to DT instead to pass both ATAGs and DT to kernel?
On Mon 2015-01-26 14:33:21, Rob Herring wrote: > On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"): > > > > + /* include the terminating ATAG_NONE */ > > + atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header); > > + setprop(fdt, "/", "atags", atag_list, atag_size); > > + > > if (memcount) { > > setprop(fdt, "/memory", "reg", mem_reg_property, > > 4 * memcount * memsize); > > > > > > > > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file: > > Please properly send your patches. Actually, when sending patches for discussion, this is format easier to read. > > Some userspace applications needs access to ATAG structure where can be stored some information passed > > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information > > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal > > mode or device update mode). > > This goes in the commit message. > > These would be non-standard fields which are not upstream. I don't > know that we care in that case... Other devices are going to care about boot reason, too, and we might as well be compatible... Pavel
On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote: > On Mon 2015-01-26 14:33:21, Rob Herring wrote: >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote: >> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"): >> > > >> > + /* include the terminating ATAG_NONE */ >> > + atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header); >> > + setprop(fdt, "/", "atags", atag_list, atag_size); >> > + >> > if (memcount) { >> > setprop(fdt, "/memory", "reg", mem_reg_property, >> > 4 * memcount * memsize); >> > >> > >> > >> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file: >> >> Please properly send your patches. > > Actually, when sending patches for discussion, this is format easier > to read. Some people might prefer them as attachments too... >> > Some userspace applications needs access to ATAG structure where can be stored some information passed >> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information >> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal >> > mode or device update mode). >> >> This goes in the commit message. >> >> These would be non-standard fields which are not upstream. I don't >> know that we care in that case... > > Other devices are going to care about boot reason, too, and we might > as well be compatible... What other devices? Where is bootreason in the list of ATAGS: #define ATAG_MEM 0x54410002 #define ATAG_VIDEOTEXT 0x54410003 #define ATAG_RAMDISK 0x54410004 #define ATAG_INITRD 0x54410005 #define ATAG_INITRD2 0x54420005 #define ATAG_SERIAL 0x54410006 #define ATAG_REVISION 0x54410007 #define ATAG_VIDEOLFB 0x54410008 #define ATAG_CMDLINE 0x54410009 #define ATAG_ACORN 0x41000101 #define ATAG_MEMCLK 0x41000402 Rob
On Tue 2015-01-27 08:16:45, Rob Herring wrote: > On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote: > > On Mon 2015-01-26 14:33:21, Rob Herring wrote: > >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > >> This goes in the commit message. > >> > >> These would be non-standard fields which are not upstream. I don't > >> know that we care in that case... > > > > Other devices are going to care about boot reason, too, and we might > > as well be compatible... > > What other devices? Where is bootreason in the list of ATAGS: > > #define ATAG_MEM 0x54410002 > #define ATAG_VIDEOTEXT 0x54410003 > #define ATAG_RAMDISK 0x54410004 > #define ATAG_INITRD 0x54410005 > #define ATAG_INITRD2 0x54420005 > #define ATAG_SERIAL 0x54410006 > #define ATAG_REVISION 0x54410007 > #define ATAG_VIDEOLFB 0x54410008 > #define ATAG_CMDLINE 0x54410009 > #define ATAG_ACORN 0x41000101 > #define ATAG_MEMCLK 0x41000402 Anyone, whose charging involves userspace. But the fact that it is needed on n900 should be enough. Pavel
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote: > On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote: > > On Mon 2015-01-26 14:33:21, Rob Herring wrote: > >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > >> > This patch will cause that decompressor store full ATAG > >> > structure into DT tree ("/atags"): > >> > > >> > > >> > + /* include the terminating ATAG_NONE */ > >> > + atag_size = (char *)atag - (char *)atag_list + > >> > sizeof(struct tag_header); + setprop(fdt, "/", > >> > "atags", atag_list, atag_size); + > >> > > >> > if (memcount) { > >> > > >> > setprop(fdt, "/memory", "reg", > >> > mem_reg_property, > >> > > >> > 4 * memcount * memsize); > >> > > >> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file: > >> Please properly send your patches. > > > > Actually, when sending patches for discussion, this is > > format easier to read. > > Some people might prefer them as attachments too... > > >> > Some userspace applications needs access to ATAG > >> > structure where can be stored some information passed > >> > from bootloader to kernel. Example is Nokia N900 device > >> > and NOLO bootloader which provides information about > >> > bootreason (device was started by power button or by > >> > alarm or restarted...) and bootmode (normal mode or > >> > device update mode). > >> > >> This goes in the commit message. > >> > >> These would be non-standard fields which are not upstream. > >> I don't know that we care in that case... > > > > Other devices are going to care about boot reason, too, and > > we might as well be compatible... > > What other devices? Where is bootreason in the list of ATAGS: > > #define ATAG_MEM 0x54410002 > #define ATAG_VIDEOTEXT 0x54410003 > #define ATAG_RAMDISK 0x54410004 > #define ATAG_INITRD 0x54410005 > #define ATAG_INITRD2 0x54420005 > #define ATAG_SERIAL 0x54410006 > #define ATAG_REVISION 0x54410007 > #define ATAG_VIDEOLFB 0x54410008 > #define ATAG_CMDLINE 0x54410009 > #define ATAG_ACORN 0x41000101 > #define ATAG_MEMCLK 0x41000402 > > Rob Each device is using own proprietary atag (or other information) to pass bootreason from bootloader to kernel. No standard way :-( I think Pavel mean to introduce some standard way how *new* version of bootloaders can pass boot reason to kernel and how kernel tell it to userspace... E.g. NOLO -- bootloader for Nokia N900 -- pass this information in ATAG_OMAP (0x414f4d50) and Nokia kernel exports it via procfs file /proc/bootreason. Also NOLO pass some other information via ATAGs, but those are static and now part of n900 DT file. But bootreason is not static information so cannot be hardcoded into static DT file which is part of kernel. 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...).
On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote: > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote: > > What other devices? Where is bootreason in the list of ATAGS: > > > > #define ATAG_MEM 0x54410002 > > #define ATAG_VIDEOTEXT 0x54410003 > > #define ATAG_RAMDISK 0x54410004 > > #define ATAG_INITRD 0x54410005 > > #define ATAG_INITRD2 0x54420005 > > #define ATAG_SERIAL 0x54410006 > > #define ATAG_REVISION 0x54410007 > > #define ATAG_VIDEOLFB 0x54410008 > > #define ATAG_CMDLINE 0x54410009 > > #define ATAG_ACORN 0x41000101 > > #define ATAG_MEMCLK 0x41000402 > > > > Rob > > Each device is using own proprietary atag (or other information) > to pass bootreason from bootloader to kernel. No standard way :-( The reason that happens is because people refuse to discuss their requirements here - just like people refuse to report userspace API regressions to kernel people. This rather pisses me off, because it creates all sorts of horrid per-platform yuck. 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 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 Tue, 27 Jan 2015, Pavel Machek wrote: > On Mon 2015-01-26 14:33:21, Rob Herring wrote: > > These would be non-standard fields which are not upstream. I don't > > know that we care in that case... > > Other devices are going to care about boot reason, too, and we might > as well be compatible... Care to elaborate on that statement please? What does this have to do with ATAGs? Nicolas
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote: > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote: > > > What other devices? Where is bootreason in the list of ATAGS: > > > > > > #define ATAG_MEM 0x54410002 > > > #define ATAG_VIDEOTEXT 0x54410003 > > > #define ATAG_RAMDISK 0x54410004 > > > #define ATAG_INITRD 0x54410005 > > > #define ATAG_INITRD2 0x54420005 > > > #define ATAG_SERIAL 0x54410006 > > > #define ATAG_REVISION 0x54410007 > > > #define ATAG_VIDEOLFB 0x54410008 > > > #define ATAG_CMDLINE 0x54410009 > > > #define ATAG_ACORN 0x41000101 > > > #define ATAG_MEMCLK 0x41000402 > > > > > > Rob > > > > Each device is using own proprietary atag (or other information) > > to pass bootreason from bootloader to kernel. No standard way :-( So that's what Pavel was alluding to. > The reason that happens is because people refuse to discuss their > requirements here - just like people refuse to report userspace API > regressions to kernel people. This rather pisses me off, because > it creates all sorts of horrid per-platform yuck. > > 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. If the method is: "let's pass non-standard ATAGs around and have ad-hoc user space code interpret it in some arbitrary way" then it's a complete abomination. > > 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...). Useful when properly designed and generic enough to be shared. I'd suggest a DT property be proposed for that purpose if it doesn't already exist. That at least has a chance to be generically useful. Nicolas
On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote: > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > > > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote: > > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote: > > > > What other devices? Where is bootreason in the list of ATAGS: > > > > > > > > #define ATAG_MEM 0x54410002 > > > > #define ATAG_VIDEOTEXT 0x54410003 > > > > #define ATAG_RAMDISK 0x54410004 > > > > #define ATAG_INITRD 0x54410005 > > > > #define ATAG_INITRD2 0x54420005 > > > > #define ATAG_SERIAL 0x54410006 > > > > #define ATAG_REVISION 0x54410007 > > > > #define ATAG_VIDEOLFB 0x54410008 > > > > #define ATAG_CMDLINE 0x54410009 > > > > #define ATAG_ACORN 0x41000101 > > > > #define ATAG_MEMCLK 0x41000402 > > > > > > > > Rob > > > > > > Each device is using own proprietary atag (or other information) > > > to pass bootreason from bootloader to kernel. No standard way :-( > > So that's what Pavel was alluding to. > > > The reason that happens is because people refuse to discuss their > > requirements here - just like people refuse to report userspace API > > regressions to kernel people. This rather pisses me off, because > > it creates all sorts of horrid per-platform yuck. > > > > 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. > > If the method is: "let's pass non-standard ATAGs around and have ad-hoc > user space code interpret it in some arbitrary way" then it's a complete > abomination. > > > > 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...). > > Useful when properly designed and generic enough to be shared. > > I'd suggest a DT property be proposed for that purpose if it doesn't > already exist. That at least has a chance to be generically useful. What this means is that we have to further augment the atags-to-dt code in the decompressor with the platform specific ATAGs to parse this information and merge it into the appended DT before passing the resulting DT blob to the kernel. Or we pass both the ATAGs and wrapped DT to the kernel when both exist, and let the kernel deal with it in a much saner environment than the restricted decompressor environment. Or we /could/ say that mainline never supported it, and we aren't going to add support for "new" tags to the mainline kernel. It wouldn't be a regression, because mainline hasn't ever supported them (that's been said before about such things on other platforms.) However, there's another consideration to be had here before we can say that: how many people out there want to run a mainline (or even an updated kernel derived from mainline) on this device? If there's a sizable following for the device wanting updated support, then it's something we really need to consider supporting inspite of our disappointment with Nokia inventing these "proprietary" tags.
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote: > > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > > > > > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote: > > > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote: > > > > > What other devices? Where is bootreason in the list of ATAGS: > > > > > > > > > > #define ATAG_MEM 0x54410002 > > > > > #define ATAG_VIDEOTEXT 0x54410003 > > > > > #define ATAG_RAMDISK 0x54410004 > > > > > #define ATAG_INITRD 0x54410005 > > > > > #define ATAG_INITRD2 0x54420005 > > > > > #define ATAG_SERIAL 0x54410006 > > > > > #define ATAG_REVISION 0x54410007 > > > > > #define ATAG_VIDEOLFB 0x54410008 > > > > > #define ATAG_CMDLINE 0x54410009 > > > > > #define ATAG_ACORN 0x41000101 > > > > > #define ATAG_MEMCLK 0x41000402 > > > > > > > > > > Rob > > > > > > > > Each device is using own proprietary atag (or other information) > > > > to pass bootreason from bootloader to kernel. No standard way :-( > > > > So that's what Pavel was alluding to. > > > > > The reason that happens is because people refuse to discuss their > > > requirements here - just like people refuse to report userspace API > > > regressions to kernel people. This rather pisses me off, because > > > it creates all sorts of horrid per-platform yuck. > > > > > > 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. > > > > If the method is: "let's pass non-standard ATAGs around and have ad-hoc > > user space code interpret it in some arbitrary way" then it's a complete > > abomination. > > > > > > 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...). > > > > Useful when properly designed and generic enough to be shared. > > > > I'd suggest a DT property be proposed for that purpose if it doesn't > > already exist. That at least has a chance to be generically useful. > > What this means is that we have to further augment the atags-to-dt code > in the decompressor with the platform specific ATAGs to parse this > information and merge it into the appended DT before passing the > resulting DT blob to the kernel. That would be only 2 new lines of code in the best case. Still, I opposed such platform specific hacks in the past, suggesting that a separate shim be used instead, which was done successfully. > Or we pass both the ATAGs and wrapped DT to the kernel when both exist, > and let the kernel deal with it in a much saner environment than the > restricted decompressor environment. ... which would be a step backward in the context of the transition to DT we accepted. People will have even less of an incentive to fix their stuff. > Or we /could/ say that mainline never supported it, and we aren't going > to add support for "new" tags to the mainline kernel. It wouldn't be > a regression, because mainline hasn't ever supported them (that's been > said before about such things on other platforms.) That would be my stance. > However, there's another consideration to be had here before we can say > that: how many people out there want to run a mainline (or even an > updated kernel derived from mainline) on this device? If there's a > sizable following for the device wanting updated support, then it's > something we really need to consider supporting inspite of our > disappointment with Nokia inventing these "proprietary" tags. If there is indeed a sizable following for the device then someone should figure out how to cope with upstream kernels, either through the installation of some intermediate bootloader that can talk FDT directly, or via a shim layer. None of that has to be performed by nor linked with the kernel binary, nor maintained in the kernel tree. And it's not even that hard to do: we have precedents on other platforms with crappy bootloaders where this just works. Nicolas
On Tue, 27 Jan 2015, Nicolas Pitre wrote: > If there is indeed a sizable following for the device then someone > should figure out how to cope with upstream kernels, either through the > installation of some intermediate bootloader that can talk FDT directly, > or via a shim layer. None of that has to be performed by nor linked > with the kernel binary, nor maintained in the kernel tree. And it's not > even that hard to do: we have precedents on other platforms with crappy > bootloaders where this just works. For reference I recommend the following threads: http://comments.gmane.org/gmane.linux.kbuild.devel/10722 http://www.spinics.net/lists/arm-kernel/msg249719.html Nicolas
On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote: > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > > Or we pass both the ATAGs and wrapped DT to the kernel when both exist, > > and let the kernel deal with it in a much saner environment than the > > restricted decompressor environment. > > ... which would be a step backward in the context of the transition to > DT we accepted. People will have even less of an incentive to fix their > stuff. Where's the people fixing their stuff today? I think your position is something of an idealist rather than a realist - the reality is that five years down the line of DT, the platforms which have not converted are now *never* going to convert, irrespective of how much "incentive" we may think we should apply to the situation. So, at some point we have to start thinking as a realist rather than an idealist, and realise that there are platforms out there which are /never/ going to convert. Most of my platforms here are /never/ going to convert to DT-only booting quite simply because they don't have anyone working on that stuff, and no one is willing to put the effort in. The only platforms which I have which have converted are: - OMAP SDP4430 - Versatile Express - SolidRun Hummingboard & Cubox-i Quite literally everything else is *never* going to support native DT booting - and I'd go as far as to say that if I ever wanted to put the effort in, I probably couldn't, because the boot loader sources aren't available anymore. (eg, the LDP3430 situation is such a mess that even if the boot loader source is still available, identifying the correct board version is near on impossible given the multitude of different variants of the same product.) The older Versatile and Integrator platforms, for example, are going to be booting with the appended DTB for as long as they're around. Most likely all the PXA platforms too, and, the IOP32x based N2100 boxes (which already need their kernels wrapped because the provided boot loader has had environment saving disabled.) As much as you may not like it, ATAGs are here to stay now, at least on the older platforms, and no amount of "incentives" will change that. > > However, there's another consideration to be had here before we can say > > that: how many people out there want to run a mainline (or even an > > updated kernel derived from mainline) on this device? If there's a > > sizable following for the device wanting updated support, then it's > > something we really need to consider supporting inspite of our > > disappointment with Nokia inventing these "proprietary" tags. > > If there is indeed a sizable following for the device then someone > should figure out how to cope with upstream kernels, either through the > installation of some intermediate bootloader that can talk FDT directly, > or via a shim layer. None of that has to be performed by nor linked > with the kernel binary, nor maintained in the kernel tree. And it's not > even that hard to do: we have precedents on other platforms with crappy > bootloaders where this just works. That's a rediculous position if you want something which "just works" on as much hardware as possible, which is, after all, what the single zImage project is all about. To be pro single-zImage, and anti popular hardware is quite contradictory. You only have to look at x86 for this: just because ACPI came along does not mean that the Linux kernel started demanding that ACPI is the only way to describe the world. Linux continues to directly support all the old boot protocols that it did since the days of i386, such as the e820 memory interface and doesn't convert these to an ACPI table just because it can.
Hi! > > > Useful when properly designed and generic enough to be shared. > > > > > > I'd suggest a DT property be proposed for that purpose if it doesn't > > > already exist. That at least has a chance to be generically useful. > > > > What this means is that we have to further augment the atags-to-dt code > > in the decompressor with the platform specific ATAGs to parse this > > information and merge it into the appended DT before passing the > > resulting DT blob to the kernel. > > That would be only 2 new lines of code in the best case. Yes, instead of 2 new lines of code, let people write, debug, and flash 1000 lines shim. Completely makes sense. Pavel
* 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. 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? 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. AFAIK, the other n900 ATAGs can be just ignored. Regards, Tony
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote: > > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > > > Or we pass both the ATAGs and wrapped DT to the kernel when both exist, > > > and let the kernel deal with it in a much saner environment than the > > > restricted decompressor environment. > > > > ... which would be a step backward in the context of the transition to > > DT we accepted. People will have even less of an incentive to fix their > > stuff. > > Where's the people fixing their stuff today? At least some people in this thread are, otherwise they'd still be away hacking on their own. > I think your position is something of an idealist rather than a > realist - the reality is that five years down the line of DT, the > platforms which have not converted are now *never* going to convert, > irrespective of how much "incentive" we may think we should apply to > the situation. Don't get me wrong. I'm not expecting those platforms to do native DT booting ever. However "faking" DT booting with already proven solutions that don't bastardize the kernel further should be encouraged. > > If there is indeed a sizable following for the device then someone > > should figure out how to cope with upstream kernels, either through the > > installation of some intermediate bootloader that can talk FDT directly, > > or via a shim layer. None of that has to be performed by nor linked > > with the kernel binary, nor maintained in the kernel tree. And it's not > > even that hard to do: we have precedents on other platforms with crappy > > bootloaders where this just works. > > That's a rediculous position if you want something which "just works" > on as much hardware as possible, which is, after all, what the single > zImage project is all about. Agreed. > To be pro single-zImage, and anti popular hardware is quite contradictory. Indeed. I'm not against popular hardware. > You only have to look at x86 for this: just because ACPI came along does > not mean that the Linux kernel started demanding that ACPI is the only > way to describe the world. Linux continues to directly support all the > old boot protocols that it did since the days of i386, such as the e820 > memory interface and doesn't convert these to an ACPI table just because > it can. Booting from a floppy boot sector is no longer supported though. But that's besides the point. If someone needs a 5-line addition to atags_to_fdt.c in order to boot some old stuff then let's just do it and move on. I'll happily ACK the patch. The code is there and it is not going away soon. However, if something more involved is needed, is platform specific and is likely to require about as many lines in the kernel than it would need in some externat shim then the shim solution should be encouraged instead. After all that's why LILO, Syslinux and Grub were created on X86: to Supplement the crappy PC BIOS boot interface. And if the hardware is popular, then finding a motivated hacker to do it shouldn't be too hard, right? In other words, what prevents someone from creating, say, a custom minimal Barebox version that sits on top of the existing N900 bootloader? Wouldn't that provide a much better user experience? Nicolas
> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre <nico@fluxnic.net> wrote: > > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: > >> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote: >>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote: >>>> Or we pass both the ATAGs and wrapped DT to the kernel when both exist, >>>> and let the kernel deal with it in a much saner environment than the >>>> restricted decompressor environment. >>> >>> ... which would be a step backward in the context of the transition to >>> DT we accepted. People will have even less of an incentive to fix their >>> stuff. >> >> Where's the people fixing their stuff today? > > At least some people in this thread are, otherwise they'd still be away > hacking on their own. > >> I think your position is something of an idealist rather than a >> realist - the reality is that five years down the line of DT, the >> platforms which have not converted are now *never* going to convert, >> irrespective of how much "incentive" we may think we should apply to >> the situation. > > Don't get me wrong. I'm not expecting those platforms to do native DT > booting ever. However "faking" DT booting with already proven solutions > that don't bastardize the kernel further should be encouraged. > >>> If there is indeed a sizable following for the device then someone >>> should figure out how to cope with upstream kernels, either through the >>> installation of some intermediate bootloader that can talk FDT directly, >>> or via a shim layer. None of that has to be performed by nor linked >>> with the kernel binary, nor maintained in the kernel tree. And it's not >>> even that hard to do: we have precedents on other platforms with crappy >>> bootloaders where this just works. >> >> That's a rediculous position if you want something which "just works" >> on as much hardware as possible, which is, after all, what the single >> zImage project is all about. > > Agreed. > >> To be pro single-zImage, and anti popular hardware is quite contradictory. > > Indeed. I'm not against popular hardware. > >> You only have to look at x86 for this: just because ACPI came along does >> not mean that the Linux kernel started demanding that ACPI is the only >> way to describe the world. Linux continues to directly support all the >> old boot protocols that it did since the days of i386, such as the e820 >> memory interface and doesn't convert these to an ACPI table just because >> it can. > > Booting from a floppy boot sector is no longer supported though. > > But that's besides the point. If someone needs a 5-line addition to > atags_to_fdt.c in order to boot some old stuff then let's just do it and > move on. I'll happily ACK the patch. The code is there and it is not > going away soon. > > However, if something more involved is needed, is platform specific and > is likely to require about as many lines in the kernel than it would > need in some externat shim then the shim solution should be encouraged > instead. After all that's why LILO, Syslinux and Grub were created on > X86: to Supplement the crappy PC BIOS boot interface. And if the > hardware is popular, then finding a motivated hacker to do it shouldn't > be too hard, right? > > In other words, what prevents someone from creating, say, a custom > minimal Barebox version that sits on top of the existing N900 > bootloader? Wouldn't that provide a much better user experience? I do agree with Nicolas If I can get my hand on a phone I’ll put barebox on it Best Regards, J. > > > Nicolas > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Hi! > In other words, what prevents someone from creating, say, a custom > minimal Barebox version that sits on top of the existing N900 > bootloader? Wouldn't that provide a much better user experience? Lot of useless work, that would make user experience worse? We have mostly working u-boot on N900. Its there, useful for boot menus, but makes debugging tricky, so we want to keep working with internal bootloader, too. And I have already explained this to you before. Now, would you stop assigning work to other people? Thanks, Pavel
Hi! > > In other words, what prevents someone from creating, say, a custom > > minimal Barebox version that sits on top of the existing N900 > > bootloader? Wouldn't that provide a much better user experience? > > I do agree with Nicolas > > If I can get my hand on a phone I’ll put barebox on it Grab it in the nearest "second hand cellphones" shop, and have fun! It should be less than $70. Pavel
> On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote: > > Hi! > >>> In other words, what prevents someone from creating, say, a custom >>> minimal Barebox version that sits on top of the existing N900 >>> bootloader? Wouldn't that provide a much better user experience? >> >> I do agree with Nicolas >> >> If I can get my hand on a phone I’ll put barebox on it > > Grab it in the nearest "second hand cellphones" shop, and have fun! It > should be less than $70. will see if I can found one in Shanghai at the second hand market Does it exist a qemu emulation? Best Regards, J. > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed 2015-01-28 16:06:17, Jean-Christophe PLAGNIOL-VILLARD wrote: > > > On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote: > > > > Hi! > > > >>> In other words, what prevents someone from creating, say, a custom > >>> minimal Barebox version that sits on top of the existing N900 > >>> bootloader? Wouldn't that provide a much better user experience? > >> > >> I do agree with Nicolas > >> > >> If I can get my hand on a phone I’ll put barebox on it > > > > Grab it in the nearest "second hand cellphones" shop, and have fun! It > > should be less than $70. > > will see if I can found one in Shanghai at the second hand market > > Does it exist a qemu emulation? Yes, linaro-qemu supports it. (But people are trying to break it "because it is not real hardware so it can be fixed"). Pavel
On Wednesday 28 January 2015 03:07:43 Nicolas Pitre wrote: > In other words, what prevents someone from creating, say, a > custom minimal Barebox version that sits on top of the > existing N900 bootloader? Wouldn't that provide a much > better user experience? > Strong cryptography used for signing first stage bootloader, undocumented interface and other stuff which initialize HW and small memory (about 100kB) for second stage non-signed bootloader. Next kernel image is limited to size 2MB. And currently uboot can be compiled to act as "kernel" image, so second stage bootloader can boot it. I spend some time to replace second (non signed) bootloader with something other, but really it is not possible.
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 2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version 2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or "update" 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
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. Converting the special ATAG into its standard DT equivalent would then be trivial and much cleaner overall. Nicolas
> 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
* Nicolas Pitre <nico@fluxnic.net> [150128 06:37]: > 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. > > Converting the special ATAG into its standard DT equivalent would then > be trivial and much cleaner overall. Sounds good to me as then we don't have to add any legacy custom Nokia specific atag. And it won't prevent us from adding a generic ATAG_BOOTREASON if really needed. Regards, Tony
On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote: > * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]: > > 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. > > > > Converting the special ATAG into its standard DT equivalent > > would then be trivial and much cleaner overall. > > Sounds good to me as then we don't have to add any legacy > custom Nokia specific atag. And it won't prevent us from > adding a generic ATAG_BOOTREASON if really needed. > > Regards, > > Tony And what would new atag ATAG_BOOTREASON solve for Nokia N900? Nothing.
* Pali Rohár <pali.rohar@gmail.com> [150128 07:50]: > On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote: > > * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]: > > > 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. > > > > > > Converting the special ATAG into its standard DT equivalent > > > would then be trivial and much cleaner overall. > > > > Sounds good to me as then we don't have to add any legacy > > custom Nokia specific atag. And it won't prevent us from > > adding a generic ATAG_BOOTREASON if really needed. > > And what would new atag ATAG_BOOTREASON solve for Nokia N900? > Nothing. Right, so probably no need to add it then :) But what Nico is saying we can translate the Nokia custom bootreason to a standard DT property if I'm reading right. Regards, Tony
On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.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... Rob
On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote: > 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... Anyone who thinks that DT can be replaced in the same way that we made the mistake with ATAGs would really need their head examined. As you point out, removing DT removes the /proc/device-tree/ sub-tree. Whether we like it or not, that is a userspace API, one which we have users of already. That pretty much means that we can't remove DT for existing platforms or any platform we have now converted to DT.
On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote: > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote: > > 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... > > Anyone who thinks that DT can be replaced in the same way that we made > the mistake with ATAGs would really need their head examined. > > As you point out, removing DT removes the /proc/device-tree/ sub-tree. > Whether we like it or not, that is a userspace API, one which we have > users of already. That pretty much means that we can't remove DT for > existing platforms or any platform we have now converted to DT. <ok, I'll go there!> ... and for platforms that can also be booted via ACPI? If we have to convert the ACPI tables into a device-tree purely for /proc/device-tree, then we may as well boot with the thing too :) Seriously though, I don't see how we can maintain this directory for ACPI, regardless of whether or not it's ABI. Will
On 1/28/15 10:48 AM, Tony Lindgren wrote: > * Pali Rohár <pali.rohar@gmail.com> [150128 07:50]: >> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote: >>> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]: >>>> 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. >>>> >>>> Converting the special ATAG into its standard DT equivalent >>>> would then be trivial and much cleaner overall. >>> >>> Sounds good to me as then we don't have to add any legacy >>> custom Nokia specific atag. And it won't prevent us from >>> adding a generic ATAG_BOOTREASON if really needed. >> >> And what would new atag ATAG_BOOTREASON solve for Nokia N900? >> Nothing. > > Right, so probably no need to add it then :) But what Nico is > saying we can translate the Nokia custom bootreason to a > standard DT property if I'm reading right. Well, it's mostly been forgotten now, but the pxa-impedance-matcher could do the proprietary ATAGS -> standard DT conversion before booting the kernel. https://github.com/zonque/pxa-impedance-matcher.git Don't let the 'pxa' fool you, it's grown (slightly) beyond it's original purpose. We augmented it to facilitate booting DT kernels from legacy bootloaders to prevent polluting the kernel with random vendor ATAG crap. Ping me or Daniel Mack if you have any questions. hth, Jason.
On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote: > On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote: > > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote: > > > 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... > > > > Anyone who thinks that DT can be replaced in the same way that we made > > the mistake with ATAGs would really need their head examined. > > > > As you point out, removing DT removes the /proc/device-tree/ sub-tree. > > Whether we like it or not, that is a userspace API, one which we have > > users of already. That pretty much means that we can't remove DT for > > existing platforms or any platform we have now converted to DT. > > <ok, I'll go there!> > > ... and for platforms that can also be booted via ACPI? If we have to > convert the ACPI tables into a device-tree purely for /proc/device-tree, > then we may as well boot with the thing too :) > > Seriously though, I don't see how we can maintain this directory for > ACPI, regardless of whether or not it's ABI. Welcome to the problem that exporting information to userspace creates. The same problem is also true where ACPI is exported to userspace too. As soon as ACPI is exported to userspace, it also becomes part of the userspace API that the kernel provides - even if it is merely passing through the data that it received from the firmware. (I'm not saying that the kernel is ultimately responsible for the contents of the blob.) If we took the idea that the kernel receives a blob from the firmware, and it parses it to discover whatever it needs using the appropriate parser for that blob, and then passes the blob to userspace, then it's pretty clear that where a platform switches between providing DT or ACPI tables is neither here nor there, and can't cause a kernel regression. The specification for such an API is that the kernel provides userspace with whatever data the firmware provided it. If we take the idea that the kernel receives a blob from the firmware, decodes it, and then provides the decoded form to userspace, then we're vulnerable to changes in firmware providers causing regressions for us because they've changed the way that that information is provided to us. That's the difference, and this is why I feel that a lack of thought has been put into stuff like the /sys/firmware/device-tree and similar which provides the decoded forms of the "blob". It's far too easy to export a string or number to userspace, which then becomes part of the user API, and which can then later become quite a headache later.
On Wednesday 28 January 2015 16:57:18 Rob Herring wrote: > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.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... > > Rob Then what about exporting bootreason as /proc/bootreason?
On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote: > On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote: > > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote: > > > 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... > > > > Anyone who thinks that DT can be replaced in the same way that we made > > the mistake with ATAGs would really need their head examined. > > > > As you point out, removing DT removes the /proc/device-tree/ sub-tree. > > Whether we like it or not, that is a userspace API, one which we have > > users of already. That pretty much means that we can't remove DT for > > existing platforms or any platform we have now converted to DT. > > <ok, I'll go there!> > > ... and for platforms that can also be booted via ACPI? If we have to > convert the ACPI tables into a device-tree purely for /proc/device-tree, > then we may as well boot with the thing too :) > > Seriously though, I don't see how we can maintain this directory for > ACPI, regardless of whether or not it's ABI. And if it needs stating more clearly, you have just shown why adding a boot reason to devicetree is the wrong thing to do. Let's say that we do decide to convert the boot reason atag to a device tree property. As soon as we do that, it appears in the /proc/device-tree sub-tree, whether we like it or not, because that sub-tree exports *everything* mentioned in the DT blob. So, as soon as we put anything into the DT blob, it immediately becomes part of the kernel's userspace API, whether we like it or not. That means it becomes available for userspace to start (ab)using - again, whether or not we provide a saner firmware independent interface. The more we mess around converting crap from one firmware interface to another, the more problems we're creating for ourselves. We really need to re-think our approach to this, and stop this religous "DT is everything, we must convert everything to DT."
> On Jan 28, 2015, at 11:57 PM, Rob Herring <robherring2@gmail.com> wrote: > > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.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 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed 2015-01-28 09:57:18, Rob Herring wrote: > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.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... 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
On Wednesday 28 January 2015 19:03:22 Pavel Machek wrote: > > /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... > I think /proc/device-tree predates sysfs by about six years. These days, it is a symlink to /sys/firmware/devicetree/base. Arnd
On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL- VILLARD wrote: > > On Jan 28, 2015, at 11:57 PM, Rob Herring > > <robherring2@gmail.com> wrote: > > > > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.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...
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c index e7e1cc9..1975d7c 100644 --- a/arch/arm/boot/compressed/atags_to_fdt.c +++ b/arch/arm/boot/compressed/atags_to_fdt.c @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) * address and size for each bank */ uint32_t mem_reg_property[2 * 2 * NR_BANKS]; int memcount = 0; - int ret, memsize; + int ret, memsize, atag_size; /* make sure we've got an aligned pointer */ if ((u32)atag_list & 0x3) @@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) } } + /* include the terminating ATAG_NONE */ + atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header); + setprop(fdt, "/", "atags", atag_list, atag_size); + if (memcount) { setprop(fdt, "/memory", "reg", mem_reg_property, 4 * memcount * memsize); And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file: diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c index 9946c1b..0f249a3 100644 --- a/arch/arm/kernel/devtree.c +++ b/arch/arm/kernel/devtree.c @@ -29,6 +29,7 @@ #include <asm/mach-types.h> #include <asm/system_info.h> +#include "atags.h" #ifdef CONFIG_SMP extern struct of_cpu_method __cpu_method_of_table[]; @@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) if (prop) system_rev = fdt32_to_cpu(*prop); + /* Save atags */ + prop = of_get_flat_dt_prop(dt_root, "atags", NULL); + if (prop) + save_atags((void *)prop); + return mdesc; }
This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"): Some userspace applications needs access to ATAG structure where can be stored some information passed from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal mode or device update mode).