| Message ID | CAL_JsqKw-C6uZBU3hccGmdofXcCcUKTV6z7Af6KwYwnZiy3HoQ@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| 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?
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();