| Message ID | CAL_JsqKw-C6uZBU3hccGmdofXcCcUKTV6z7Af6KwYwnZiy3HoQ@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár <pali.rohar@gmail.com> wrote: > > Machine name from board description is some generic name on > > DT kernel. DT provides machine name property which is > > specific for board, so use it instead generic one when > > possible. > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > > --- > > > > arch/arm/kernel/setup.c | 7 +++++-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/kernel/setup.c > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644 > > --- a/arch/arm/kernel/setup.c > > +++ b/arch/arm/kernel/setup.c > > @@ -875,10 +875,13 @@ void __init setup_arch(char > > **cmdline_p) > > > > setup_processor(); > > mdesc = setup_machine_fdt(__atags_pointer); > > > > - if (!mdesc) > > + if (mdesc) > > + machine_name = > > of_flat_dt_get_machine_name(); + else > > > > mdesc = setup_machine_tags(__atags_pointer, > > __machine_arch_type); > > > > machine_desc = mdesc; > > > > - machine_name = mdesc->name; > > + if (!machine_name) > > + machine_name = mdesc->name; > > > > if (mdesc->reboot_mode != REBOOT_HARD) > > > > reboot_mode = mdesc->reboot_mode; > > I did a similar patch previously[1]. Like my original patch, > your patch unconditionally changes the name which could be > considered part of the userspace ABI. It's arguably not good > practice for userspace to depend on the name, but there are > likely cases that do. So I think this needs to be optional > and only use the DT name if the machine desc name is NULL. > > So something like the below and then change the machine > descriptors you care about. The default generic DT machine > desc should definitely be changed. > > I had a follow-up discussion with Grant about his concerns in > the thread about knowing which machine desc used to boot. He > said he was okay if just the machine desc address is printed > out. > > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c > index 50e198c..1479250 100644 > --- a/arch/arm/kernel/setup.c > +++ b/arch/arm/kernel/setup.c > @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p) > if (!mdesc) > mdesc = setup_machine_tags(__atags_pointer, > __machine_arch_type); > machine_desc = mdesc; > - machine_name = mdesc->name; > + machine_name = mdesc->name ? mdesc->name : > of_flat_dt_get_machine_name(); > > if (mdesc->reboot_mode != REBOOT_HARD) > reboot_mode = mdesc->reboot_mode; > > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No > vember/208878.html Hi, now legacy board code for Nokia N900 (RX-51) is migrating to DT kernel and there is problem with info which /proc/cpuinfo reports New DT kernel (3.16-rc1) reports: # busybox cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc08 CPU revision : 3 Hardware : Generic OMAP3 (Flattened Device Tree) Revision : 0000 Serial : 0000000000000000 But legacy board code kernel reports: # busybox cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc08 CPU revision : 3 Hardware : Nokia RX-51 board Revision : 0012 Serial : 0000000000000000 Basically in DT kernel is missing Hardware, Revision and probably also Serial key. (Now I used only qemu for testing which set serial key to 0). All these informations is used by userspace applications which determinate how to behave. So without this patch DT migration for Nokia N900 cannot be done without breaking userspace - which is not acceptable... Also I still did not know why DT kernel does not report Revision number which is passed by bootloader via atags. Any idea?
On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote: > So without this patch DT migration for Nokia N900 cannot be done > without breaking userspace - which is not acceptable... > > Also I still did not know why DT kernel does not report Revision > number which is passed by bootloader via atags. Any idea? It was a concious decision by the DT people to exclude most of the ATAGs which provide that information. Only memory information and command line ATAGs are merged into DT. Every other tag is ignored (as there's no place for it in DT.)
On Wednesday 18 June 2014 22:00:54 Russell King - ARM Linux wrote: > On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote: > > So without this patch DT migration for Nokia N900 cannot be > > done without breaking userspace - which is not > > acceptable... > > > > Also I still did not know why DT kernel does not report > > Revision number which is passed by bootloader via atags. > > Any idea? > > It was a concious decision by the DT people to exclude most of > the ATAGs which provide that information. Only memory > information and command line ATAGs are merged into DT. Every > other tag is ignored (as there's no place for it in DT.) So how to read Revision and Serial number in DT based kernel?
On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár > <pali.rohar@gmail.com> wrote: >> > Machine name from board description is some generic name on >> > DT kernel. DT provides machine name property which is >> > specific for board, so use it instead generic one when >> > possible. >> > >> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> >> > --- >> > >> > arch/arm/kernel/setup.c | 7 +++++-- >> > 1 file changed, 5 insertions(+), 2 deletions(-) >> > >> > diff --git a/arch/arm/kernel/setup.c >> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644 >> > --- a/arch/arm/kernel/setup.c >> > +++ b/arch/arm/kernel/setup.c >> > @@ -875,10 +875,13 @@ void __init setup_arch(char >> > **cmdline_p) >> > >> > setup_processor(); >> > mdesc = setup_machine_fdt(__atags_pointer); >> > >> > - if (!mdesc) >> > + if (mdesc) >> > + machine_name = >> > of_flat_dt_get_machine_name(); + else >> > >> > mdesc = setup_machine_tags(__atags_pointer, >> > __machine_arch_type); >> > >> > machine_desc = mdesc; >> > >> > - machine_name = mdesc->name; >> > + if (!machine_name) >> > + machine_name = mdesc->name; >> > >> > if (mdesc->reboot_mode != REBOOT_HARD) >> > >> > reboot_mode = mdesc->reboot_mode; >> >> I did a similar patch previously[1]. Like my original patch, >> your patch unconditionally changes the name which could be >> considered part of the userspace ABI. It's arguably not good >> practice for userspace to depend on the name, but there are >> likely cases that do. So I think this needs to be optional >> and only use the DT name if the machine desc name is NULL. >> >> So something like the below and then change the machine >> descriptors you care about. The default generic DT machine >> desc should definitely be changed. >> >> I had a follow-up discussion with Grant about his concerns in >> the thread about knowing which machine desc used to boot. He >> said he was okay if just the machine desc address is printed >> out. >> >> >> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c >> index 50e198c..1479250 100644 >> --- a/arch/arm/kernel/setup.c >> +++ b/arch/arm/kernel/setup.c >> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p) >> if (!mdesc) >> mdesc = setup_machine_tags(__atags_pointer, >> __machine_arch_type); >> machine_desc = mdesc; >> - machine_name = mdesc->name; >> + machine_name = mdesc->name ? mdesc->name : >> of_flat_dt_get_machine_name(); >> >> if (mdesc->reboot_mode != REBOOT_HARD) >> reboot_mode = mdesc->reboot_mode; >> >> >> [1] >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No >> vember/208878.html > > Hi, > > now legacy board code for Nokia N900 (RX-51) is migrating to DT > kernel and there is problem with info which /proc/cpuinfo reports Thanks for providing your motivation which was missing from the commit message. > > New DT kernel (3.16-rc1) reports: > > # busybox cat /proc/cpuinfo > processor : 0 > model name : ARMv7 Processor rev 3 (v7l) > Features : swp half thumb fastmult vfp edsp thumbee neon > vfpv3 tls vfpd32 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x2 > CPU part : 0xc08 > CPU revision : 3 > > Hardware : Generic OMAP3 (Flattened Device Tree) > Revision : 0000 > Serial : 0000000000000000 > > But legacy board code kernel reports: > > # busybox cat /proc/cpuinfo > processor : 0 > model name : ARMv7 Processor rev 3 (v7l) > Features : swp half thumb fastmult vfp edsp thumbee neon > vfpv3 tls vfpd32 > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant : 0x2 > CPU part : 0xc08 > CPU revision : 3 > > Hardware : Nokia RX-51 board > Revision : 0012 > Serial : 0000000000000000 > > Basically in DT kernel is missing Hardware, Revision and probably > also Serial key. (Now I used only qemu for testing which set > serial key to 0). All these informations is used by userspace > applications which determinate how to behave. It is somewhat fragile to expect the name in the DT to match the old name from the kernel. As your patch to n900 dts shows, we'd probably have to update every dts file to make them match. While I think we should work to remove this string from the kernel, userspace depending on the DT model string is a bad idea. For example, if you had some platform with multiple OEMs just rebranding the same base design, they may all want to put their own model string into each product. The true h/w id is the compatible string. Serial number is easy. There is already a standard although not widely used property for it with "/serial-number". You just need to wire it up to cpuinfo. > So without this patch DT migration for Nokia N900 cannot be done > without breaking userspace - which is not acceptable... I agree, but I would like to come up with something that prevents future dependence on this string. > Also I still did not know why DT kernel does not report Revision > number which is passed by bootloader via atags. Any idea? Probably because no one cared until now and revision info for every SOC is different. I would like to see revision info set in the DT in a standard way and remove the various SOC specific kernel implementations. Rob
Hi, On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote: > So without this patch DT migration for Nokia N900 cannot be done > without breaking userspace - which is not acceptable... I guess the fact is that the Nokia N900 proprietary userspace has never worked properly with the mainline kernel without severe patching, so you cannot really talk about any regression. If you cannot fix those programs, you could still probably emulate the old Nokia kernel's /proc/cpuinfo by providing some text file and bind mounting it, no? A.
On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote: > On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > Also I still did not know why DT kernel does not report Revision > > number which is passed by bootloader via atags. Any idea? > > Probably because no one cared until now and revision info for every > SOC is different. I would like to see revision info set in the DT in a > standard way and remove the various SOC specific kernel > implementations. Except... that's not what it is. What that revision field was originally invented for was the Netwinder to indicate the _platform_ revision. >From what I've seen, almost everyone else sets this to zero in their boot loaders - it is /very/ rarely used. However, I think OMAP (ab)uses it by putting the SoC revision into it at kernel boot time. That's not what it is supposed to be used for. Others have already solved the problem of exporting SoC specific information, such as SoC name, SoC revision, etc, if only people would use it - drivers/base/soc.c. This gives machine, family, soc_id and SoC revision information in a standard place - it /might/ have been a good idea if the creation of that also contained documentation for what was expected in each of the fields, rather than leaving it open...
On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > So how to read Revision and Serial number in DT based kernel? $ cat /sys/bus/soc/devices/soc0/soc_id i.MX6SX $ cat /sys/bus/soc/devices/soc0/revision 1.0 $ cat /sys/bus/soc/devices/soc0/machine Freescale i.MX6 SoloX SDB Board
On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote: >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote: >> > Also I still did not know why DT kernel does not report Revision >> > number which is passed by bootloader via atags. Any idea? >> >> Probably because no one cared until now and revision info for every >> SOC is different. I would like to see revision info set in the DT in a >> standard way and remove the various SOC specific kernel >> implementations. > > Except... that's not what it is. What that revision field was originally > invented for was the Netwinder to indicate the _platform_ revision. Okay. DT describes the platform, so having a top-level revision in the DT could be similar, but... > > From what I've seen, almost everyone else sets this to zero in their > boot loaders - it is /very/ rarely used. However, I think OMAP (ab)uses > it by putting the SoC revision into it at kernel boot time. That's > not what it is supposed to be used for. it could suffer the same abuse as the ATAG. Perhaps if Revision in cpuinfo is never going to be set for DT based platforms, then we should remove it from cpuinfo in that case. > Others have already solved the problem of exporting SoC specific > information, such as SoC name, SoC revision, etc, if only people would > use it - drivers/base/soc.c. This gives machine, family, soc_id and > SoC revision information in a standard place - it /might/ have been > a good idea if the creation of that also contained documentation for > what was expected in each of the fields, rather than leaving it > open... The problem with soc-device is it is optional and at the whim of the platform to add. Adding it also causes the the platform devices to change paths because people make the soc device the bus parent. Sysfs paths to devices are not considered part of the ABI, but still this is a silly reason to change the path. If we want soc-device to be used, then it should always exist and have a default version. Rob
On Wed, Jun 18, 2014 at 05:27:16PM -0500, Rob Herring wrote: > On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote: > >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > >> > Also I still did not know why DT kernel does not report Revision > >> > number which is passed by bootloader via atags. Any idea? > >> > >> Probably because no one cared until now and revision info for every > >> SOC is different. I would like to see revision info set in the DT in a > >> standard way and remove the various SOC specific kernel > >> implementations. > > > > Except... that's not what it is. What that revision field was originally > > invented for was the Netwinder to indicate the _platform_ revision. > > Okay. DT describes the platform, so having a top-level revision in the > DT could be similar, but... > > > > > From what I've seen, almost everyone else sets this to zero in their > > boot loaders - it is /very/ rarely used. However, I think OMAP (ab)uses > > it by putting the SoC revision into it at kernel boot time. That's > > not what it is supposed to be used for. > > it could suffer the same abuse as the ATAG. I think the (ab)use I mentioned above has been eliminated (it was being used for the SoC revision). It's worth grepping for system_rev to find where it's used now, and it's looks like it's all platform level. > The problem with soc-device is it is optional and at the whim of the > platform to add. Adding it also causes the the platform devices to > change paths because people make the soc device the bus parent. It's got to be optional, but anyone with a SoC should be strongly encouraged to use it, especially when converting to DT - again, this is probably one of those numerous "missed opportunities" since the DT conversion fundamentally changes the names of all platform devices in that heirarchy. I'm tempted to say that we went through that device name change, and as far as I saw, there was not one complaint about those devices changing names. So, I suspect it isn't that big a deal to encourage SoCs to make use of this. > Sysfs > paths to devices are not considered part of the ABI, but still this is > a silly reason to change the path. If we want soc-device to be used, > then it should always exist and have a default version. So what do we do on systems which aren't a SoC? Make up some random information for the SoC stuff? That's just wrong.
On Thu 2014-06-19 00:10:39, Aaro Koskinen wrote: > Hi, > > On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote: > > So without this patch DT migration for Nokia N900 cannot be done > > without breaking userspace - which is not acceptable... > > I guess the fact is that the Nokia N900 proprietary userspace has > never worked properly with the mainline kernel without severe patching, > so you cannot really talk about any regression. If you cannot fix > those programs, you could still probably emulate the old Nokia kernel's > /proc/cpuinfo by providing some text file and bind mounting it, no? Actually, yes, it worked pretty well with some close-to-mainline kernels. And bind-mount on /proc/cpuinfo is beyond ugly, don't you think? Pavel
On Wednesday 18 June 2014 23:53:00 Fabio Estevam wrote: > On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > So how to read Revision and Serial number in DT based > > kernel? > > $ cat /sys/bus/soc/devices/soc0/soc_id > i.MX6SX > > $ cat /sys/bus/soc/devices/soc0/revision > 1.0 > > $ cat /sys/bus/soc/devices/soc0/machine > Freescale i.MX6 SoloX SDB Board This does *not* working with DT based boot! $ cat /sys/bus/soc/devices/soc0/soc_id cat: can't open '/sys/bus/soc/devices/soc0/soc_id': No such file or directory $ cat /sys/bus/soc/devices/soc0/revision ES3.1 $ cat /sys/bus/soc/devices/soc0/machine OMAP3430/3530 Here is output from *non* DT based boot: # busybox cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x2 CPU part : 0xc08 CPU revision : 3 Hardware : Nokia RX-51 board Revision : 0012 Serial : 0000000000000000 As you can see in those files are totally *different* values.
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: > On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár > > > > <pali.rohar@gmail.com> wrote: > >> > Machine name from board description is some generic name > >> > on DT kernel. DT provides machine name property which is > >> > specific for board, so use it instead generic one when > >> > possible. > >> > > >> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com> > >> > --- > >> > > >> > arch/arm/kernel/setup.c | 7 +++++-- > >> > 1 file changed, 5 insertions(+), 2 deletions(-) > >> > > >> > diff --git a/arch/arm/kernel/setup.c > >> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644 > >> > --- a/arch/arm/kernel/setup.c > >> > +++ b/arch/arm/kernel/setup.c > >> > @@ -875,10 +875,13 @@ void __init setup_arch(char > >> > **cmdline_p) > >> > > >> > setup_processor(); > >> > mdesc = setup_machine_fdt(__atags_pointer); > >> > > >> > - if (!mdesc) > >> > + if (mdesc) > >> > + machine_name = > >> > of_flat_dt_get_machine_name(); + else > >> > > >> > mdesc = > >> > setup_machine_tags(__atags_pointer, > >> > __machine_arch_type); > >> > > >> > machine_desc = mdesc; > >> > > >> > - machine_name = mdesc->name; > >> > + if (!machine_name) > >> > + machine_name = mdesc->name; > >> > > >> > if (mdesc->reboot_mode != REBOOT_HARD) > >> > > >> > reboot_mode = mdesc->reboot_mode; > >> > >> I did a similar patch previously[1]. Like my original > >> patch, your patch unconditionally changes the name which > >> could be considered part of the userspace ABI. It's > >> arguably not good practice for userspace to depend on the > >> name, but there are likely cases that do. So I think this > >> needs to be optional and only use the DT name if the > >> machine desc name is NULL. > >> > >> So something like the below and then change the machine > >> descriptors you care about. The default generic DT machine > >> desc should definitely be changed. > >> > >> I had a follow-up discussion with Grant about his concerns > >> in the thread about knowing which machine desc used to > >> boot. He said he was okay if just the machine desc address > >> is printed out. > >> > >> > >> diff --git a/arch/arm/kernel/setup.c > >> b/arch/arm/kernel/setup.c index 50e198c..1479250 100644 > >> --- a/arch/arm/kernel/setup.c > >> +++ b/arch/arm/kernel/setup.c > >> @@ -887,7 +887,7 @@ void __init setup_arch(char > >> **cmdline_p) > >> > >> if (!mdesc) > >> > >> mdesc = setup_machine_tags(__atags_pointer, > >> > >> __machine_arch_type); > >> > >> machine_desc = mdesc; > >> > >> - machine_name = mdesc->name; > >> + machine_name = mdesc->name ? mdesc->name : > >> of_flat_dt_get_machine_name(); > >> > >> if (mdesc->reboot_mode != REBOOT_HARD) > >> > >> reboot_mode = mdesc->reboot_mode; > >> > >> [1] > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-> >> No vember/208878.html > > > > Hi, > > > > now legacy board code for Nokia N900 (RX-51) is migrating to > > DT kernel and there is problem with info which > > /proc/cpuinfo reports > > Thanks for providing your motivation which was missing from > the commit message. > > > New DT kernel (3.16-rc1) reports: > > > > # busybox cat /proc/cpuinfo > > processor : 0 > > model name : ARMv7 Processor rev 3 (v7l) > > Features : swp half thumb fastmult vfp edsp thumbee > > neon vfpv3 tls vfpd32 > > CPU implementer : 0x41 > > CPU architecture: 7 > > CPU variant : 0x2 > > CPU part : 0xc08 > > CPU revision : 3 > > > > Hardware : Generic OMAP3 (Flattened Device Tree) > > Revision : 0000 > > Serial : 0000000000000000 > > > > But legacy board code kernel reports: > > > > # busybox cat /proc/cpuinfo > > processor : 0 > > model name : ARMv7 Processor rev 3 (v7l) > > Features : swp half thumb fastmult vfp edsp thumbee > > neon vfpv3 tls vfpd32 > > CPU implementer : 0x41 > > CPU architecture: 7 > > CPU variant : 0x2 > > CPU part : 0xc08 > > CPU revision : 3 > > > > Hardware : Nokia RX-51 board > > Revision : 0012 > > Serial : 0000000000000000 > > > > Basically in DT kernel is missing Hardware, Revision and > > probably also Serial key. (Now I used only qemu for testing > > which set serial key to 0). All these informations is used > > by userspace applications which determinate how to behave. > > It is somewhat fragile to expect the name in the DT to match > the old name from the kernel. As your patch to n900 dts > shows, we'd probably have to update every dts file to make > them match. While I think we should work to remove this > string from the kernel, userspace depending on the DT model > string is a bad idea. For example, if you had some platform > with multiple OEMs just rebranding the same base design, they > may all want to put their own model string into each product. > The true h/w id is the compatible string. > > Serial number is easy. There is already a standard although > not widely used property for it with "/serial-number". You > just need to wire it up to cpuinfo. > There is no "/serial-number" property in kernel: $ ls -l -a /sys/bus/soc/devices/soc0/ drwxr-xr-x 3 0 0 0 Jan 1 00:00 . drwxr-xr-x 18 0 0 0 Jan 1 00:00 .. -r--r--r-- 1 0 0 4096 Jan 1 00:00 family -r--r--r-- 1 0 0 4096 Jan 1 00:00 machine drwxr-xr-x 2 0 0 0 Jan 1 00:00 power -r--r--r-- 1 0 0 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 0 Jan 1 00:00 subsystem -> ../../bus/soc -r--r--r-- 1 0 0 4096 Jan 1 00:00 type -rw-r--r-- 1 0 0 4096 Jan 1 00:00 uevent > > So without this patch DT migration for Nokia N900 cannot be > > done without breaking userspace - which is not > > acceptable... > > I agree, but I would like to come up with something that > prevents future dependence on this string. > > > Also I still did not know why DT kernel does not report > > Revision number which is passed by bootloader via atags. > > Any idea? > > Probably because no one cared until now and revision info for > every SOC is different. I would like to see revision info set > in the DT in a standard way and remove the various SOC > specific kernel implementations. > > Rob
On Wednesday 18 June 2014 23:10:39 Aaro Koskinen wrote: > Hi, > > On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote: > > So without this patch DT migration for Nokia N900 cannot be > > done without breaking userspace - which is not > > acceptable... > > I guess the fact is that the Nokia N900 proprietary userspace > has never worked properly with the mainline kernel without > severe patching, so you cannot really talk about any > regression. If you cannot fix those programs, you could still > probably emulate the old Nokia kernel's /proc/cpuinfo by > providing some text file and bind mounting it, no? > > A. Mainline kernel (with patches for missing driver) working with Maemo CSSU-Devel userspace. So there are regressions. Emulation of /proc/cpuinfo is possible if somebody provides needed info. But I still do not know from *where* to read machine, serial number and hw revision.
On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár > <pali.rohar@gmail.com> wrote: >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár >> > >> > <pali.rohar@gmail.com> wrote: >> >> > Machine name from board description is some generic name >> >> > on DT kernel. DT provides machine name property which is >> >> > specific for board, so use it instead generic one when >> >> > possible. >> >> > [...] >> > Basically in DT kernel is missing Hardware, Revision and >> > probably also Serial key. (Now I used only qemu for testing >> > which set serial key to 0). All these informations is used >> > by userspace applications which determinate how to behave. >> >> It is somewhat fragile to expect the name in the DT to match >> the old name from the kernel. As your patch to n900 dts >> shows, we'd probably have to update every dts file to make >> them match. While I think we should work to remove this >> string from the kernel, userspace depending on the DT model >> string is a bad idea. For example, if you had some platform >> with multiple OEMs just rebranding the same base design, they >> may all want to put their own model string into each product. >> The true h/w id is the compatible string. >> >> Serial number is easy. There is already a standard although >> not widely used property for it with "/serial-number". You >> just need to wire it up to cpuinfo. >> > > There is no "/serial-number" property in kernel: > > $ ls -l -a /sys/bus/soc/devices/soc0/ > drwxr-xr-x 3 0 0 0 Jan 1 00:00 . > drwxr-xr-x 18 0 0 0 Jan 1 00:00 .. > -r--r--r-- 1 0 0 4096 Jan 1 00:00 family > -r--r--r-- 1 0 0 4096 Jan 1 00:00 machine > drwxr-xr-x 2 0 0 0 Jan 1 00:00 power > -r--r--r-- 1 0 0 4096 Jan 1 00:00 revision > lrwxrwxrwx 1 0 0 0 Jan 1 00:00 > subsystem -> ../../bus/soc > -r--r--r-- 1 0 0 4096 Jan 1 00:00 type > -rw-r--r-- 1 0 0 4096 Jan 1 00:00 uevent Wrong place. If you put /serial-number in your DT, then it will be in /proc/device-tree/serial-number. If you want to wire that up to /proc/cpuinfo, I would be fine with that. Rob
On Thursday 04 December 2014 01:33:08 Rob Herring wrote: > On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: > >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár > > > > <pali.rohar@gmail.com> wrote: > >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár > >> > > >> > <pali.rohar@gmail.com> wrote: > >> >> > Machine name from board description is some generic > >> >> > name on DT kernel. DT provides machine name property > >> >> > which is specific for board, so use it instead > >> >> > generic one when possible. > > [...] > > >> > Basically in DT kernel is missing Hardware, Revision and > >> > probably also Serial key. (Now I used only qemu for > >> > testing which set serial key to 0). All these > >> > informations is used by userspace applications which > >> > determinate how to behave. > >> > >> It is somewhat fragile to expect the name in the DT to > >> match the old name from the kernel. As your patch to n900 > >> dts shows, we'd probably have to update every dts file to > >> make them match. While I think we should work to remove > >> this string from the kernel, userspace depending on the DT > >> model string is a bad idea. For example, if you had some > >> platform with multiple OEMs just rebranding the same base > >> design, they may all want to put their own model string > >> into each product. The true h/w id is the compatible > >> string. > >> > >> Serial number is easy. There is already a standard although > >> not widely used property for it with "/serial-number". You > >> just need to wire it up to cpuinfo. > > > > There is no "/serial-number" property in kernel: > > > > $ ls -l -a /sys/bus/soc/devices/soc0/ > > drwxr-xr-x 3 0 0 0 Jan 1 00:00 . > > drwxr-xr-x 18 0 0 0 Jan 1 00:00 .. > > -r--r--r-- 1 0 0 4096 Jan 1 00:00 > > family -r--r--r-- 1 0 0 4096 Jan 1 > > 00:00 machine drwxr-xr-x 2 0 0 0 > > Jan 1 00:00 power -r--r--r-- 1 0 0 > > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 > > 0 Jan 1 00:00 subsystem -> ../../bus/soc > > -r--r--r-- 1 0 0 4096 Jan 1 00:00 > > type -rw-r--r-- 1 0 0 4096 Jan 1 > > 00:00 uevent > > Wrong place. If you put /serial-number in your DT, then it > will be in /proc/device-tree/serial-number. > > If you want to wire that up to /proc/cpuinfo, I would be fine > with that. > > Rob I cannot hardcode it into DT, because it is set by bootloader. And bootloader tell it to kernel via ATAGs structure. Bootloader is closed and proprietary and cannot be replaced (there is no documentation for hw init).
On Wed, Dec 03, 2014 at 06:33:08PM -0600, Rob Herring wrote: > On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > There is no "/serial-number" property in kernel: > > > > $ ls -l -a /sys/bus/soc/devices/soc0/ > > drwxr-xr-x 3 0 0 0 Jan 1 00:00 . > > drwxr-xr-x 18 0 0 0 Jan 1 00:00 .. > > -r--r--r-- 1 0 0 4096 Jan 1 00:00 family > > -r--r--r-- 1 0 0 4096 Jan 1 00:00 machine > > drwxr-xr-x 2 0 0 0 Jan 1 00:00 power > > -r--r--r-- 1 0 0 4096 Jan 1 00:00 revision > > lrwxrwxrwx 1 0 0 0 Jan 1 00:00 > > subsystem -> ../../bus/soc > > -r--r--r-- 1 0 0 4096 Jan 1 00:00 type > > -rw-r--r-- 1 0 0 4096 Jan 1 00:00 uevent > > Wrong place. If you put /serial-number in your DT, then it will be in > /proc/device-tree/serial-number. > > If you want to wire that up to /proc/cpuinfo, I would be fine with that. That would be fine for me too. Then it's just a matter of how to copy the contents of the ATAG into the DT (I assume it's possible in a similar way to the memory and command line information.) That's something I know nothing about though.
On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Thursday 04 December 2014 01:33:08 Rob Herring wrote: >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár > <pali.rohar@gmail.com> wrote: >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár >> > >> > <pali.rohar@gmail.com> wrote: >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár >> >> > >> >> > <pali.rohar@gmail.com> wrote: >> >> >> > Machine name from board description is some generic >> >> >> > name on DT kernel. DT provides machine name property >> >> >> > which is specific for board, so use it instead >> >> >> > generic one when possible. >> >> [...] >> >> >> > Basically in DT kernel is missing Hardware, Revision and >> >> > probably also Serial key. (Now I used only qemu for >> >> > testing which set serial key to 0). All these >> >> > informations is used by userspace applications which >> >> > determinate how to behave. >> >> >> >> It is somewhat fragile to expect the name in the DT to >> >> match the old name from the kernel. As your patch to n900 >> >> dts shows, we'd probably have to update every dts file to >> >> make them match. While I think we should work to remove >> >> this string from the kernel, userspace depending on the DT >> >> model string is a bad idea. For example, if you had some >> >> platform with multiple OEMs just rebranding the same base >> >> design, they may all want to put their own model string >> >> into each product. The true h/w id is the compatible >> >> string. >> >> >> >> Serial number is easy. There is already a standard although >> >> not widely used property for it with "/serial-number". You >> >> just need to wire it up to cpuinfo. >> > >> > There is no "/serial-number" property in kernel: >> > >> > $ ls -l -a /sys/bus/soc/devices/soc0/ >> > drwxr-xr-x 3 0 0 0 Jan 1 00:00 . >> > drwxr-xr-x 18 0 0 0 Jan 1 00:00 .. >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 >> > family -r--r--r-- 1 0 0 4096 Jan 1 >> > 00:00 machine drwxr-xr-x 2 0 0 0 >> > Jan 1 00:00 power -r--r--r-- 1 0 0 >> > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 >> > 0 Jan 1 00:00 subsystem -> ../../bus/soc >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 >> > type -rw-r--r-- 1 0 0 4096 Jan 1 >> > 00:00 uevent >> >> Wrong place. If you put /serial-number in your DT, then it >> will be in /proc/device-tree/serial-number. >> >> If you want to wire that up to /proc/cpuinfo, I would be fine >> with that. >> >> Rob > > I cannot hardcode it into DT, because it is set by bootloader. > And bootloader tell it to kernel via ATAGs structure. Bootloader > is closed and proprietary and cannot be replaced (there is no > documentation for hw init). Either the bootloader can put the serial number into the DTB instead of ATAGs or the kernel decompressor can copy it from ATAGs to DTB like is done already for other ATAGs. I presume you cannot update the bootloader and will need the latter. Rob
On Thursday 04 December 2014 17:49:40 Rob Herring wrote: > On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Thursday 04 December 2014 01:33:08 Rob Herring wrote: > >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár > > > > <pali.rohar@gmail.com> wrote: > >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: > >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár > >> > > >> > <pali.rohar@gmail.com> wrote: > >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár > >> >> > > >> >> > <pali.rohar@gmail.com> wrote: > >> >> >> > Machine name from board description is some generic > >> >> >> > name on DT kernel. DT provides machine name > >> >> >> > property which is specific for board, so use it > >> >> >> > instead generic one when possible. > >> > >> [...] > >> > >> >> > Basically in DT kernel is missing Hardware, Revision > >> >> > and probably also Serial key. (Now I used only qemu > >> >> > for testing which set serial key to 0). All these > >> >> > informations is used by userspace applications which > >> >> > determinate how to behave. > >> >> > >> >> It is somewhat fragile to expect the name in the DT to > >> >> match the old name from the kernel. As your patch to > >> >> n900 dts shows, we'd probably have to update every dts > >> >> file to make them match. While I think we should work > >> >> to remove this string from the kernel, userspace > >> >> depending on the DT model string is a bad idea. For > >> >> example, if you had some platform with multiple OEMs > >> >> just rebranding the same base design, they may all want > >> >> to put their own model string into each product. The > >> >> true h/w id is the compatible string. > >> >> > >> >> Serial number is easy. There is already a standard > >> >> although not widely used property for it with > >> >> "/serial-number". You just need to wire it up to > >> >> cpuinfo. > >> > > >> > There is no "/serial-number" property in kernel: > >> > > >> > $ ls -l -a /sys/bus/soc/devices/soc0/ > >> > drwxr-xr-x 3 0 0 0 Jan 1 00:00 > >> > . drwxr-xr-x 18 0 0 0 Jan 1 > >> > 00:00 .. -r--r--r-- 1 0 0 4096 Jan > >> > 1 00:00 family -r--r--r-- 1 0 0 > >> > 4096 Jan 1 00:00 machine drwxr-xr-x 2 0 0 > >> > 0 Jan 1 00:00 power -r--r--r-- 1 0 > >> > 0 > >> > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 > >> > > >> > 0 Jan 1 00:00 subsystem -> ../../bus/soc > >> > > >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 > >> > type -rw-r--r-- 1 0 0 4096 Jan 1 > >> > 00:00 uevent > >> > >> Wrong place. If you put /serial-number in your DT, then it > >> will be in /proc/device-tree/serial-number. > >> > >> If you want to wire that up to /proc/cpuinfo, I would be > >> fine with that. > >> > >> Rob > > > > I cannot hardcode it into DT, because it is set by > > bootloader. And bootloader tell it to kernel via ATAGs > > structure. Bootloader is closed and proprietary and cannot > > be replaced (there is no documentation for hw init). > > Either the bootloader can put the serial number into the DTB > instead of ATAGs or the kernel decompressor can copy it from > ATAGs to DTB like is done already for other ATAGs. I presume > you cannot update the bootloader and will need the latter. > > Rob Rob, thanks for info! Btw, theoretically I can update bootloader if someone write it. So in practise I need to use second option. Can you tell me which CONFIG_ needs to be enabled for kernel decompressor (so it copy some ATAGs) and where to start looking at code (for adding new code for copying other ATAGs)?
On Thu, Dec 4, 2014 at 11:57 AM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Thursday 04 December 2014 17:49:40 Rob Herring wrote: >> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár > <pali.rohar@gmail.com> wrote: >> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote: >> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár >> > >> > <pali.rohar@gmail.com> wrote: >> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: >> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár >> >> > >> >> > <pali.rohar@gmail.com> wrote: >> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: >> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár >> >> >> > >> >> >> > <pali.rohar@gmail.com> wrote: >> >> >> >> > Machine name from board description is some generic >> >> >> >> > name on DT kernel. DT provides machine name >> >> >> >> > property which is specific for board, so use it >> >> >> >> > instead generic one when possible. >> >> >> >> [...] >> >> >> >> >> > Basically in DT kernel is missing Hardware, Revision >> >> >> > and probably also Serial key. (Now I used only qemu >> >> >> > for testing which set serial key to 0). All these >> >> >> > informations is used by userspace applications which >> >> >> > determinate how to behave. >> >> >> >> >> >> It is somewhat fragile to expect the name in the DT to >> >> >> match the old name from the kernel. As your patch to >> >> >> n900 dts shows, we'd probably have to update every dts >> >> >> file to make them match. While I think we should work >> >> >> to remove this string from the kernel, userspace >> >> >> depending on the DT model string is a bad idea. For >> >> >> example, if you had some platform with multiple OEMs >> >> >> just rebranding the same base design, they may all want >> >> >> to put their own model string into each product. The >> >> >> true h/w id is the compatible string. >> >> >> >> >> >> Serial number is easy. There is already a standard >> >> >> although not widely used property for it with >> >> >> "/serial-number". You just need to wire it up to >> >> >> cpuinfo. >> >> > >> >> > There is no "/serial-number" property in kernel: >> >> > >> >> > $ ls -l -a /sys/bus/soc/devices/soc0/ >> >> > drwxr-xr-x 3 0 0 0 Jan 1 00:00 >> >> > . drwxr-xr-x 18 0 0 0 Jan 1 >> >> > 00:00 .. -r--r--r-- 1 0 0 4096 Jan >> >> > 1 00:00 family -r--r--r-- 1 0 0 >> >> > 4096 Jan 1 00:00 machine drwxr-xr-x 2 0 0 >> >> > 0 Jan 1 00:00 power -r--r--r-- 1 0 >> >> > 0 >> >> > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 >> >> > >> >> > 0 Jan 1 00:00 subsystem -> ../../bus/soc >> >> > >> >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 >> >> > type -rw-r--r-- 1 0 0 4096 Jan 1 >> >> > 00:00 uevent >> >> >> >> Wrong place. If you put /serial-number in your DT, then it >> >> will be in /proc/device-tree/serial-number. >> >> >> >> If you want to wire that up to /proc/cpuinfo, I would be >> >> fine with that. >> >> >> >> Rob >> > >> > I cannot hardcode it into DT, because it is set by >> > bootloader. And bootloader tell it to kernel via ATAGs >> > structure. Bootloader is closed and proprietary and cannot >> > be replaced (there is no documentation for hw init). >> >> Either the bootloader can put the serial number into the DTB >> instead of ATAGs or the kernel decompressor can copy it from >> ATAGs to DTB like is done already for other ATAGs. I presume >> you cannot update the bootloader and will need the latter. >> >> Rob > > Rob, thanks for info! Btw, theoretically I can update bootloader > if someone write it. So in practise I need to use second option. > > Can you tell me which CONFIG_ needs to be enabled for kernel > decompressor (so it copy some ATAGs) and where to start looking > at code (for adding new code for copying other ATAGs)? See CONFIG_ARM_ATAG_DTB_COMPAT and arch/arm/boot/compressed/atags_to_fdt.c. Rob
On Thursday 04 December 2014 17:49:40 Rob Herring wrote: > On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Thursday 04 December 2014 01:33:08 Rob Herring wrote: > >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár > > > > <pali.rohar@gmail.com> wrote: > >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: > >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár > >> > > >> > <pali.rohar@gmail.com> wrote: > >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár > >> >> > > >> >> > <pali.rohar@gmail.com> wrote: > >> >> >> > Machine name from board description is some generic > >> >> >> > name on DT kernel. DT provides machine name > >> >> >> > property which is specific for board, so use it > >> >> >> > instead generic one when possible. > >> > >> [...] > >> > >> >> > Basically in DT kernel is missing Hardware, Revision > >> >> > and probably also Serial key. (Now I used only qemu > >> >> > for testing which set serial key to 0). All these > >> >> > informations is used by userspace applications which > >> >> > determinate how to behave. > >> >> > >> >> It is somewhat fragile to expect the name in the DT to > >> >> match the old name from the kernel. As your patch to > >> >> n900 dts shows, we'd probably have to update every dts > >> >> file to make them match. While I think we should work > >> >> to remove this string from the kernel, userspace > >> >> depending on the DT model string is a bad idea. For > >> >> example, if you had some platform with multiple OEMs > >> >> just rebranding the same base design, they may all want > >> >> to put their own model string into each product. The > >> >> true h/w id is the compatible string. > >> >> > >> >> Serial number is easy. There is already a standard > >> >> although not widely used property for it with > >> >> "/serial-number". You just need to wire it up to > >> >> cpuinfo. > >> > > >> > There is no "/serial-number" property in kernel: > >> > > >> > $ ls -l -a /sys/bus/soc/devices/soc0/ > >> > drwxr-xr-x 3 0 0 0 Jan 1 00:00 > >> > . drwxr-xr-x 18 0 0 0 Jan 1 > >> > 00:00 .. -r--r--r-- 1 0 0 4096 Jan > >> > 1 00:00 family -r--r--r-- 1 0 0 > >> > 4096 Jan 1 00:00 machine drwxr-xr-x 2 0 0 > >> > 0 Jan 1 00:00 power -r--r--r-- 1 0 > >> > 0 > >> > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 > >> > > >> > 0 Jan 1 00:00 subsystem -> ../../bus/soc > >> > > >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 > >> > type -rw-r--r-- 1 0 0 4096 Jan 1 > >> > 00:00 uevent > >> > >> Wrong place. If you put /serial-number in your DT, then it > >> will be in /proc/device-tree/serial-number. > >> > >> If you want to wire that up to /proc/cpuinfo, I would be > >> fine with that. > >> > >> Rob > > > > I cannot hardcode it into DT, because it is set by > > bootloader. And bootloader tell it to kernel via ATAGs > > structure. Bootloader is closed and proprietary and cannot > > be replaced (there is no documentation for hw init). > > Either the bootloader can put the serial number into the DTB > instead of ATAGs or the kernel decompressor can copy it from > ATAGs to DTB like is done already for other ATAGs. I presume > you cannot update the bootloader and will need the latter. > > Rob And what about copying also Revision ATAG (passed by bootloader) to DTB (in compressed code) and then show DTB revision in /proc/cpuinfo file? Would be something like this for Revision acceptable for upstream? Rob, and what about exporting /proc/atags file (to userspace) also in DT boot if bootloader provides ATAG structure? It is possible? Would be something like that accepted to upstream?
On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT > revision property: > > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 11c54de..9946c1b 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c > @@ -19,6 +19,7 @@ > #include <linux/of_irq.h> > #include <linux/of_platform.h> > #include <linux/smp.h> > +#include <linux/libfdt_env.h> > > #include <asm/cputype.h> > #include <asm/setup.h> > @@ -26,6 +27,7 @@ > #include <asm/smp_plat.h> > #include <asm/mach/arch.h> > #include <asm/mach-types.h> > +#include <asm/system_info.h> > > > #ifdef CONFIG_SMP > @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match) > const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > { > const struct machine_desc *mdesc, *mdesc_best = NULL; > + unsigned long dt_root; > + const u32 *prop; > > #ifdef CONFIG_ARCH_MULTIPLATFORM > DT_MACHINE_START(GENERIC_DT, "Generic DT based system") > @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys))) > return NULL; > > + dt_root = of_get_flat_dt_root(); > mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach); > > if (!mdesc) { > const char *prop; > int size; > - unsigned long dt_root; > > early_print("\nError: unrecognized/unsupported " > "device tree compatible list:\n[ "); > > - dt_root = of_get_flat_dt_root(); > prop = of_get_flat_dt_prop(dt_root, "compatible", &size); > while (size > 0) { > early_print("'%s' ", prop); > @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > /* Change machine number to match the mdesc we're using */ > __machine_arch_type = mdesc->nr; > > + /* Set system revision from DT */ > + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); > + if (prop) > + system_rev = fdt32_to_cpu(*prop); > + > return mdesc; > } > > > And here is patch which convert ATAG revision into DT revision property and append it into DT in > decompress code: > > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c > index 9448aa0..e7e1cc9 100644 > --- a/arch/arm/boot/compressed/atags_to_fdt.c > +++ b/arch/arm/boot/compressed/atags_to_fdt.c > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) > cpu_to_fdt32(atag->u.mem.size); > } > > + } else if (atag->hdr.tag == ATAG_REVISION) { > + setprop_cell(fdt, "/", "revision", atag->u.revision.rev); > } else if (atag->hdr.tag == ATAG_INITRD2) { > uint32_t initrd_start, initrd_size; > initrd_start = atag->u.initrd.start; > > > I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG. > > I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one, > let me know what to use instead. Also you can add my Signed-off-by for both patches. It is the correct property, but /revision in DT is a string. You need to add your own sign-off. Rob
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?
Am 26.01.2015 um 20:09 schrieb Pali Rohár: > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c > index 11c54de..9946c1b 100644 > --- a/arch/arm/kernel/devtree.c > +++ b/arch/arm/kernel/devtree.c [...] > @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match) > const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > { > const struct machine_desc *mdesc, *mdesc_best = NULL; > + unsigned long dt_root; > + const u32 *prop; > > #ifdef CONFIG_ARCH_MULTIPLATFORM > DT_MACHINE_START(GENERIC_DT, "Generic DT based system") > @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys))) > return NULL; > > + dt_root = of_get_flat_dt_root(); > mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach); > > if (!mdesc) { > const char *prop; Probably the use of two differently typed variables of name "prop" in this function is not intentional? Regards, Andreas > int size; > - unsigned long dt_root; > > early_print("\nError: unrecognized/unsupported " > "device tree compatible list:\n[ "); > > - dt_root = of_get_flat_dt_root(); > prop = of_get_flat_dt_prop(dt_root, "compatible", &size); > while (size > 0) { > early_print("'%s' ", prop); > @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) > /* Change machine number to match the mdesc we're using */ > __machine_arch_type = mdesc->nr; > > + /* Set system revision from DT */ > + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); > + if (prop) > + system_rev = fdt32_to_cpu(*prop); > + > return mdesc; > } [snip]
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...
On Monday 26 January 2015 21:22:27 Rob Herring wrote: > On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote: > > Ok, here is patch which set Revision field (global variable > > system_rev) in /proc/cpuinfo from DT revision property: > > > > diff --git a/arch/arm/kernel/devtree.c > > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644 > > --- a/arch/arm/kernel/devtree.c > > +++ b/arch/arm/kernel/devtree.c > > @@ -19,6 +19,7 @@ > > > > #include <linux/of_irq.h> > > #include <linux/of_platform.h> > > #include <linux/smp.h> > > > > +#include <linux/libfdt_env.h> > > > > #include <asm/cputype.h> > > #include <asm/setup.h> > > > > @@ -26,6 +27,7 @@ > > > > #include <asm/smp_plat.h> > > #include <asm/mach/arch.h> > > #include <asm/mach-types.h> > > > > +#include <asm/system_info.h> > > > > #ifdef CONFIG_SMP > > > > @@ -204,6 +206,8 @@ static const void * __init > > arch_get_next_mach(const char *const **match) > > > > const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) { > > > > const struct machine_desc *mdesc, *mdesc_best = > > NULL; > > > > + unsigned long dt_root; > > + const u32 *prop; > > > > #ifdef CONFIG_ARCH_MULTIPLATFORM > > > > DT_MACHINE_START(GENERIC_DT, "Generic DT based > > system") > > > > @@ -215,17 +219,16 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > if (!dt_phys || > > !early_init_dt_verify(phys_to_virt(dt_phys))) > > > > return NULL; > > > > + dt_root = of_get_flat_dt_root(); > > > > mdesc = of_flat_dt_match_machine(mdesc_best, > > arch_get_next_mach); > > > > if (!mdesc) { > > > > const char *prop; > > int size; > > > > - unsigned long dt_root; > > > > early_print("\nError: > > unrecognized/unsupported " > > > > "device tree compatible list:\n[ > > "); > > > > - dt_root = of_get_flat_dt_root(); > > > > prop = of_get_flat_dt_prop(dt_root, > > "compatible", &size); while (size > 0) { > > > > early_print("'%s' ", prop); > > > > @@ -246,5 +249,10 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > /* Change machine number to match the mdesc we're > > using */ __machine_arch_type = mdesc->nr; > > > > + /* Set system revision from DT */ > > + prop = of_get_flat_dt_prop(dt_root, "revision", > > NULL); + if (prop) > > + system_rev = fdt32_to_cpu(*prop); > > + > > > > return mdesc; > > > > } > > > > And here is patch which convert ATAG revision into DT > > revision property and append it into DT in decompress code: > > > > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c > > b/arch/arm/boot/compressed/atags_to_fdt.c index > > 9448aa0..e7e1cc9 100644 > > --- a/arch/arm/boot/compressed/atags_to_fdt.c > > +++ b/arch/arm/boot/compressed/atags_to_fdt.c > > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void > > *fdt, int total_space) > > > > cpu_to_fdt32(atag->u > > .mem.size); > > > > } > > > > + } else if (atag->hdr.tag == ATAG_REVISION) { > > + setprop_cell(fdt, "/", "revision", > > atag->u.revision.rev); > > > > } else if (atag->hdr.tag == ATAG_INITRD2) { > > > > uint32_t initrd_start, initrd_size; > > initrd_start = atag->u.initrd.start; > > > > I tested it on DT booted Nokia N900 and it is working, in > > /proc/cpuinfo is revision from ATAG. > > > > I do not know which DT property to use for storing HW > > Revision, so if "/revision" is not correct one, let me know > > what to use instead. Also you can add my Signed-off-by for > > both patches. > > It is the correct property, but /revision in DT is a string. > > You need to add your own sign-off. > > Rob Any documentation which says that /revision is string? If it is really string, how to store ATAG_REVISON (number) to string? dec or hex?
lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár <pali.rohar@gmail.com> wrote: > On Monday 26 January 2015 21:22:27 Rob Herring wrote: >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár > <pali.rohar@gmail.com> wrote: >> > Ok, here is patch which set Revision field (global variable >> > system_rev) in /proc/cpuinfo from DT revision property: [...] >> > I do not know which DT property to use for storing HW >> > Revision, so if "/revision" is not correct one, let me know >> > what to use instead. Also you can add my Signed-off-by for >> > both patches. >> >> It is the correct property, but /revision in DT is a string. >> >> You need to add your own sign-off. >> >> Rob > > Any documentation which says that /revision is string? Sorry, I was confusing this with serial-number, so I guess a number is fine here. > If it is really string, how to store ATAG_REVISON (number) to > string? dec or hex? However /proc/cpuinfo displays it would be fine if you stay with a string. Rob
On Friday 30 January 2015 22:03:36 Rob Herring wrote: > lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár <pali.rohar@gmail.com> wrote: > > On Monday 26 January 2015 21:22:27 Rob Herring wrote: > >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár > > > > <pali.rohar@gmail.com> wrote: > >> > Ok, here is patch which set Revision field (global > >> > variable > > >> > system_rev) in /proc/cpuinfo from DT revision property: > [...] > > >> > I do not know which DT property to use for storing HW > >> > Revision, so if "/revision" is not correct one, let me > >> > know what to use instead. Also you can add my > >> > Signed-off-by for both patches. > >> > >> It is the correct property, but /revision in DT is a > >> string. > >> > >> You need to add your own sign-off. > >> > >> Rob > > > > Any documentation which says that /revision is string? > > Sorry, I was confusing this with serial-number, so I guess a > number is fine here. > > > If it is really string, how to store ATAG_REVISON (number) > > to string? dec or hex? > > However /proc/cpuinfo displays it would be fine if you stay > with a string. > > Rob I will send new patch which will store number value as string. So same output will be in /proc/cpuinfo and in DT /revision.
This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. Pali Rohár (2): arm: devtree: Set system_rev from DT revision arm: boot: convert ATAG_REVISION to DT revision field arch/arm/boot/compressed/atags_to_fdt.c | 37 +++++++++++++++++++++++++++++++ arch/arm/kernel/devtree.c | 20 ++++++++++++----- 2 files changed, 52 insertions(+), 5 deletions(-)
On Monday 26 January 2015 23:34:34 Andreas Färber wrote: > Am 26.01.2015 um 20:09 schrieb Pali Rohár: > > diff --git a/arch/arm/kernel/devtree.c > > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644 > > --- a/arch/arm/kernel/devtree.c > > +++ b/arch/arm/kernel/devtree.c > > [...] > > > @@ -204,6 +206,8 @@ static const void * __init > > arch_get_next_mach(const char *const **match) > > > > const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) { > > > > const struct machine_desc *mdesc, *mdesc_best = NULL; > > > > + unsigned long dt_root; > > + const u32 *prop; > > > > #ifdef CONFIG_ARCH_MULTIPLATFORM > > > > DT_MACHINE_START(GENERIC_DT, "Generic DT based system") > > > > @@ -215,17 +219,16 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > if (!dt_phys || > > !early_init_dt_verify(phys_to_virt(dt_phys))) > > > > return NULL; > > > > + dt_root = of_get_flat_dt_root(); > > > > mdesc = of_flat_dt_match_machine(mdesc_best, > > arch_get_next_mach); > > > > if (!mdesc) { > > > > const char *prop; > > Probably the use of two differently typed variables of name > "prop" in this function is not intentional? > Fixed in PATCH v2. > Regards, > Andreas > > > int size; > > > > - unsigned long dt_root; > > > > early_print("\nError: unrecognized/unsupported " > > > > "device tree compatible list:\n[ "); > > > > - dt_root = of_get_flat_dt_root(); > > > > prop = of_get_flat_dt_prop(dt_root, "compatible", &size); > > while (size > 0) { > > > > early_print("'%s' ", prop); > > > > @@ -246,5 +249,10 @@ const struct machine_desc * __init > > setup_machine_fdt(unsigned int dt_phys) > > > > /* Change machine number to match the mdesc we're using */ > > __machine_arch_type = mdesc->nr; > > > > + /* Set system revision from DT */ > > + prop = of_get_flat_dt_prop(dt_root, "revision", NULL); > > + if (prop) > > + system_rev = fdt32_to_cpu(*prop); > > + > > > > return mdesc; > > > > } > > [snip]
On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > Pali Rohár (2): > arm: devtree: Set system_rev from DT revision > arm: boot: convert ATAG_REVISION to DT revision field Acked-by: Pavel Machek <pavel@ucw.cz>
* Pavel Machek <pavel@ucw.cz> [150302 03:32]: > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > Pali Rohár (2): > > arm: devtree: Set system_rev from DT revision > > arm: boot: convert ATAG_REVISION to DT revision field > > Acked-by: Pavel Machek <pavel@ucw.cz> Are these queued somewhere now? Sounds like this is the last pending issue for n900 to use legacy user space with current mainline kernels, so I'd like to get these in so we can get closer to making omap3 boot in device tree only mode. Regards, Tony
On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > Pali Rohár (2): > > > arm: devtree: Set system_rev from DT revision > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > Are these queued somewhere now? Sounds like this is the last pending > issue for n900 to use legacy user space with current mainline kernels, > so I'd like to get these in so we can get closer to making omap3 boot > in device tree only mode. Not that I know of. As everyone is aware, patches need to be in my patch system if they want me to apply them - which would've been especially important as I was away from kernel stuff for a week at the start of March (for medical reasons) and I can't be expected to track the status of stuff which is buried behind 1000+ extra mails. In any case, I'm currently not accepting /any/ patches into my tree at present; I'm chasing a horrid instability on one of my test platforms which is making it impossible to tell whether any particular change or changes in my tree is responsible or not for it. It doesn't seem to be a hardware failure (if it was, I'd simply take the board out of the nightly test system.) It's quite literally taking hours to figure out what's going on - I've been on this for about 12 hours now and still not much closer to knowing what's causing it (other than I know that -rc1 plus my queue seems to be fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So something I'm already carrying seems to be responsible, but each time I identify a particular patch and drop _just_ that change, I find that the problem is back when I try my queue minus the bad changes. With a test cycle time of 20+ minutes (due to the number of boots required to make certain of a dependable result), this is /really/ slow progress. Right now, I can't be positively sure that /anything/ I have already merged isn't a factor in causing this problem, so I don't want to augment my tree with any additional patches which would upset my ability to move about in the tree, and get reproducable results from repeated testing. To merge something else will probably mean I'll have to start again from the beginning and the last 12 hours spent testing will have been wasted. Sorry.
On Mon, 16 Mar 2015, Russell King - ARM Linux wrote: > In any case, I'm currently not accepting /any/ patches into my tree at > present; I'm chasing a horrid instability on one of my test platforms > which is making it impossible to tell whether any particular change or > changes in my tree is responsible or not for it. It doesn't seem to be > a hardware failure (if it was, I'd simply take the board out of the > nightly test system.) > > It's quite literally taking hours to figure out what's going on - I've > been on this for about 12 hours now and still not much closer to knowing > what's causing it (other than I know that -rc1 plus my queue seems to be > fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So > something I'm already carrying seems to be responsible, but each time I > identify a particular patch and drop _just_ that change, I find that the > problem is back when I try my queue minus the bad changes. With a test > cycle time of 20+ minutes (due to the number of boots required to make > certain of a dependable result), this is /really/ slow progress. > > Right now, I can't be positively sure that /anything/ I have already > merged isn't a factor in causing this problem, so I don't want to > augment my tree with any additional patches which would upset my > ability to move about in the tree, and get reproducable results from > repeated testing. To merge something else will probably mean I'll > have to start again from the beginning and the last 12 hours spent > testing will have been wasted. Your publicly visible tree contains only a few mundane patches. Is that the tree you're testing with? If no then could you publish it for others to have a look and test? Nicolas
* Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]: > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > > > Pali Rohár (2): > > > > arm: devtree: Set system_rev from DT revision > > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > Are these queued somewhere now? Sounds like this is the last pending > > issue for n900 to use legacy user space with current mainline kernels, > > so I'd like to get these in so we can get closer to making omap3 boot > > in device tree only mode. > > Not that I know of. As everyone is aware, patches need to be in my > patch system if they want me to apply them - which would've been > especially important as I was away from kernel stuff for a week at > the start of March (for medical reasons) and I can't be expected to > track the status of stuff which is buried behind 1000+ extra mails. Pali, care to upload these two patches to Russell's patch tracking system if no other comments? > In any case, I'm currently not accepting /any/ patches into my tree at > present; I'm chasing a horrid instability on one of my test platforms > which is making it impossible to tell whether any particular change or > changes in my tree is responsible or not for it. It doesn't seem to be > a hardware failure (if it was, I'd simply take the board out of the > nightly test system.) > > It's quite literally taking hours to figure out what's going on - I've > been on this for about 12 hours now and still not much closer to knowing > what's causing it (other than I know that -rc1 plus my queue seems to be > fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine. So > something I'm already carrying seems to be responsible, but each time I > identify a particular patch and drop _just_ that change, I find that the > problem is back when I try my queue minus the bad changes. With a test > cycle time of 20+ minutes (due to the number of boots required to make > certain of a dependable result), this is /really/ slow progress. > > Right now, I can't be positively sure that /anything/ I have already > merged isn't a factor in causing this problem, so I don't want to > augment my tree with any additional patches which would upset my > ability to move about in the tree, and get reproducable results from > repeated testing. To merge something else will probably mean I'll > have to start again from the beginning and the last 12 hours spent > testing will have been wasted. Oh debugging those things sucks. Maybe try with CONFIG_DEBUG_SLAB to see if you trigger any poison. Regards, Tony
On Mon, Mar 16, 2015 at 12:43:47PM -0400, Nicolas Pitre wrote: > Your publicly visible tree contains only a few mundane patches. > Is that the tree you're testing with? If no then could you publish it > for others to have a look and test? Okay, having investigated three cases of this, ended up mostly at dead-ends, and having talked to Will, I think the conclusion is that no one really understands what's going on here. :p A number of people (including people within ARM) have seen the problem that I've seen with a variety of kernel versions, including versions which I haven't seen a problem with. My own investigations turn up patches which don't have that much to do with the SMP booting itself: yes, one was a L2C patch, but I've had that for a very long time. The FIQ changes for the GIC which shouldn't have affected it. Olof's MMC patches to support resets and regulators which we don't even get to, so couldn't affect it /code-wise/. What all these have in common is an influence on the layout of the kernel image. Exactly what that is, I don't know yet - I've not had the time to be able to investigate that deeply as I've been trying to characterise the failure and track it down to an easy "this works, this doesn't" test case. I now have that with a kernel without MMC changes vs a kernel with MMC changes - where I know that the actual changes have nothing to do with the problem itself. There's only one person (not me) who has been able to get a reasonable amount of debug so far - Sudeep (@arm) has found that both CPU0 and CPU1 are stuck in the radix code, but merely using the debugger "frees" them from there. Now that I'm aware that _others_ are or have seen the same issue I am, I can worry slightly less about the issue... and what it confirms to me is that it's less about what the kernel code is, more about the placement of kernel code. The unfortunate side effect is that it cuts down on the amount of useful testing I can do prior to sending stuff to Linus... but C'est la vie.
On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]: > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote: > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT. > > > > > > > > > > Pali Rohár (2): > > > > > arm: devtree: Set system_rev from DT revision > > > > > arm: boot: convert ATAG_REVISION to DT revision field > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > > > Are these queued somewhere now? Sounds like this is the last pending > > > issue for n900 to use legacy user space with current mainline kernels, > > > so I'd like to get these in so we can get closer to making omap3 boot > > > in device tree only mode. > > > > Not that I know of. As everyone is aware, patches need to be in my > > patch system if they want me to apply them - which would've been > > especially important as I was away from kernel stuff for a week at > > the start of March (for medical reasons) and I can't be expected to > > track the status of stuff which is buried behind 1000+ extra mails. > > Pali, care to upload these two patches to Russell's patch tracking > system if no other comments? If it's done soon, I should be able to send them to Linus fairly quickly, since this problem I'm grappling with is being seen by others who have better tools to be able to investigate the problem (and hence they're in a better position to investigate what's going on.)
On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote: > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 > > 09:15]: > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren > > > wrote: > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > > > This patch adds support for DT "/revision" and > > > > > > convert ATAG_REVISION to DT. > > > > > > > > > > > > Pali Rohár (2): > > > > > > arm: devtree: Set system_rev from DT revision > > > > > > arm: boot: convert ATAG_REVISION to DT revision > > > > > > field > > > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > Are these queued somewhere now? Sounds like this is the > > > > last pending issue for n900 to use legacy user space > > > > with current mainline kernels, so I'd like to get these > > > > in so we can get closer to making omap3 boot in device > > > > tree only mode. > > > > > > Not that I know of. As everyone is aware, patches need to > > > be in my patch system if they want me to apply them - > > > which would've been especially important as I was away > > > from kernel stuff for a week at the start of March (for > > > medical reasons) and I can't be expected to track the > > > status of stuff which is buried behind 1000+ extra mails. > > > > Pali, care to upload these two patches to Russell's patch > > tracking system if no other comments? > > If it's done soon, I should be able to send them to Linus > fairly quickly, since this problem I'm grappling with is > being seen by others who have better tools to be able to > investigate the problem (and hence they're in a better > position to investigate what's going on.) I have no idea how to upload those patches into tracking system. Right now I do not have enough time for testing any patches... Tony, or somebody else, if you have free time, can you upload (my) patches to that needed tracking system?
* Pali Rohár <pali.rohar@gmail.com> [150316 13:54]: > On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote: > > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote: > > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 > > > 09:15]: > > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren > > > > wrote: > > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]: > > > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote: > > > > > > > This patch adds support for DT "/revision" and > > > > > > > convert ATAG_REVISION to DT. > > > > > > > > > > > > > > Pali Rohár (2): > > > > > > > arm: devtree: Set system_rev from DT revision > > > > > > > arm: boot: convert ATAG_REVISION to DT revision > > > > > > > field > > > > > > > > > > > > Acked-by: Pavel Machek <pavel@ucw.cz> > > > > > > > > > > Are these queued somewhere now? Sounds like this is the > > > > > last pending issue for n900 to use legacy user space > > > > > with current mainline kernels, so I'd like to get these > > > > > in so we can get closer to making omap3 boot in device > > > > > tree only mode. > > > > > > > > Not that I know of. As everyone is aware, patches need to > > > > be in my patch system if they want me to apply them - > > > > which would've been especially important as I was away > > > > from kernel stuff for a week at the start of March (for > > > > medical reasons) and I can't be expected to track the > > > > status of stuff which is buried behind 1000+ extra mails. > > > > > > Pali, care to upload these two patches to Russell's patch > > > tracking system if no other comments? > > > > If it's done soon, I should be able to send them to Linus > > fairly quickly, since this problem I'm grappling with is > > being seen by others who have better tools to be able to > > investigate the problem (and hence they're in a better > > position to investigate what's going on.) > > I have no idea how to upload those patches into tracking system. > Right now I do not have enough time for testing any patches... Well it's pretty easy, all you have to do is upload them to: http://www.arm.linux.org.uk/developer/patches/ There's an email interface it too. > Tony, or somebody else, if you have free time, can you upload > (my) patches to that needed tracking system? Eeek, I'm swamped too, probably best that you do it yourself since they're your patches. Regards, Tony
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 50e198c..1479250 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p) if (!mdesc) mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type); machine_desc = mdesc; - machine_name = mdesc->name; + machine_name = mdesc->name ? mdesc->name : of_flat_dt_get_machine_name();