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 <[email protected]>
---
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;
--
1.7.9.5
On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r 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.
http://archive.arm.linux.org.uk/lurker/message/20130726.132850.53d47576.en.html
"If userspace wants to get at the DT information about a platform, we already
have ways that can happen already - we export the DT stuff so that kexec's
tools can get at it."
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár <[email protected]> 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 <[email protected]>
> ---
> 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-November/208878.html
On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux
wrote:
> On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Rohár 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.
>
> http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> .53d47576.en.html
>
> "If userspace wants to get at the DT information about a
> platform, we already have ways that can happen already - we
> export the DT stuff so that kexec's tools can get at it."
Userspace application does not know that kernel using DT. And
also it does not want to get DT information. Only board/machine
name. So existing applications stop working after migration to
DT. And because legacy board boot code (without DT) is going to
be removed for ARM in near future this will permanently break
existing applications.
And sometimes it is even not possible to fix userspace
application if is closed source - binary only.
--
Pali Rohár
[email protected]
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
<[email protected]> 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 <[email protected]>
> > ---
> >
> > 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?
--
Pali Rohár
[email protected]
On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Roh?r wrote:
> On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux
> wrote:
> > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r 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.
> >
> > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > .53d47576.en.html
> >
> > "If userspace wants to get at the DT information about a
> > platform, we already have ways that can happen already - we
> > export the DT stuff so that kexec's tools can get at it."
>
> Userspace application does not know that kernel using DT. And
> also it does not want to get DT information. Only board/machine
> name. So existing applications stop working after migration to
> DT. And because legacy board boot code (without DT) is going to
> be removed for ARM in near future this will permanently break
> existing applications.
We're already breaking the userspace API through moving to DT, because
all the device names in /sys/devices are changing. Userspace is going
to have to cope with change as we move towards DT. This is just
another aspect of moving towards DT, and one which userspace is going
to have to deal with.
> And sometimes it is even not possible to fix userspace
> application if is closed source - binary only.
And why do we care about closed source?
If we listened to this argument, then we wouldn't ever be able to
change anything in procfs or sysfs.
Change is inevitable.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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.)
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
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?
--
Pali Rohár
[email protected]
On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <[email protected]> wrote:
> On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> <[email protected]> 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 <[email protected]>
>> > ---
>> >
>> > 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 <[email protected]> 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...
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <[email protected]> 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
<[email protected]> 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 <[email protected]> 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
> <[email protected]> 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 <[email protected]> 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.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
On Wed 2014-06-18 20:59:08, Russell King - ARM Linux wrote:
> On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux
> > wrote:
> > > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r 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.
> > >
> > > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > > .53d47576.en.html
> > >
> > > "If userspace wants to get at the DT information about a
> > > platform, we already have ways that can happen already - we
> > > export the DT stuff so that kexec's tools can get at it."
> >
> > Userspace application does not know that kernel using DT. And
> > also it does not want to get DT information. Only board/machine
> > name. So existing applications stop working after migration to
> > DT. And because legacy board boot code (without DT) is going to
> > be removed for ARM in near future this will permanently break
> > existing applications.
>
> We're already breaking the userspace API through moving to DT, because
> all the device names in /sys/devices are changing. Userspace is going
> to have to cope with change as we move towards DT. This is just
> another aspect of moving towards DT, and one which userspace is going
> to have to deal with.
>
> > And sometimes it is even not possible to fix userspace
> > application if is closed source - binary only.
>
> And why do we care about closed source?
"No regressions". Recent DT changes broke userspace we care about. Now you can either
revert DT changes, or fix the code to be compatible-enough. Second option is better, I guess.
> If we listened to this argument, then we wouldn't ever be able to
> change anything in procfs or sysfs.
If we find procfs/sysfs changes that break userspace, we revert them. Its
that simple.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed 2014-06-18 20:59:08, Russell King - ARM Linux wrote:
> On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux
> > wrote:
> > > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r 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.
> > >
> > > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > > .53d47576.en.html
> > >
> > > "If userspace wants to get at the DT information about a
> > > platform, we already have ways that can happen already - we
> > > export the DT stuff so that kexec's tools can get at it."
> >
> > Userspace application does not know that kernel using DT. And
> > also it does not want to get DT information. Only board/machine
> > name. So existing applications stop working after migration to
> > DT. And because legacy board boot code (without DT) is going to
> > be removed for ARM in near future this will permanently break
> > existing applications.
>
> We're already breaking the userspace API through moving to DT, because
> all the device names in /sys/devices are changing. Userspace is going
> to have to cope with change as we move towards DT. This is just
> another aspect of moving towards DT, and one which userspace is going
> to have to deal with.
You don't _have_ to break /proc/cpuinfo. No, "DT breaks stuff" should
not be reason to "break more stuff". (Actually, I'm not aware of
anything DT would have to break.)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wednesday 18 June 2014 23:53:00 Fabio Estevam wrote:
> On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <[email protected]> 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.
--
Pali Rohár
[email protected]
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
<[email protected]> wrote:
> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >
> > <[email protected]> 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 <[email protected]>
> >> > ---
> >> >
> >> > 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
--
Pali Rohár
[email protected]
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.
--
Pali Rohár
[email protected]
On Wednesday 10 September 2014 14:46:15 Pavel Machek wrote:
> On Fri 2014-09-05 13:13:16, Russell King - ARM Linux wrote:
> > On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Rohár wrote:
> > > On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > > > - 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;
> > >
> > > So, do you really want to break userspace which reading
> > > file /proc/cpuinfo (after migration from boardcode -->
> > > DT)?
> > >
> > > I still do not see reason for that. And only this one file
> > > is problematic...
> >
> > Sorry, I just don't give a damn about your whinging about
> > this. I've made the situation perfectly clear. Your patch
> > will not be accepted.
>
> Linus made it pretty clear that regressions are not accepted.
>
> You are an arm maintainer and there is regression in n900 that
> broke userspace.
>
> How do you solve it?
> Pavel
I must agree, it is breaking userspace. Even worse DT booting
does not provide those old information about board which
bootloader set in ATAG info (and which is needed for some
applications).
--
Pali Rohár
[email protected]
On Friday 05 September 2014 15:58:16 Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 02:52:05PM +0100, Pali Rohár wrote:
> > On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> > > On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> > > > On Wednesday 18 June 2014 18:54:24 Pali Rohár 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 <[email protected]>
> > > > > ---
> > > > >
> > > > > 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;
> > > >
> > > > So, do you really want to break userspace which reading
> > > > file /proc/cpuinfo (after migration from boardcode -->
> > > > DT)?
> > >
> > > You have no guarantee model name in the DT == the name in
> > > a board file anyhow, and trying to force that is wrong.
> > > So further to Russell's reply, I must NAK this from a DT
> > > perspective.
> > >
> > > Realistically your userspace is already broken if relying
> > > on such things. You built something that only ever worked
> > > for a particular arbitrary string. So it was already
> > > broken for every other board, and there was never any
> > > guarantee that new boards where your userspace could have
> > > worked would share the same name.
> > >
> > > You're trying to fix the wrong side of the equation.
> > >
> > > Mark.
> >
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
>
> Without knowing your use case I have no idea if that's even a
> sane thing to do.
>
> Mark.
Read information which was previously (non DT boot) in file:
/proc/cpuinfo
Hardware : Nokia RX-51 board
Revision : 0012
Serial : 0000000000000000
Userspace applications using them for identifying on which device
and hw revisions are running.
--
Pali Rohár
[email protected]
On Friday 05 September 2014 15:58:34 Fabio Estevam wrote:
> On Fri, Sep 5, 2014 at 10:52 AM, Pali Rohár
<[email protected]> wrote:
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
>
> $ cat /sys/bus/soc/devices/soc0/machine
> Freescale i.MX6 Quad SABRE Smart Device Board
This output is on Nokia N900 useless:
$ cat /sys/bus/soc/devices/soc0/machine
OMAP3430/3530
It does not specify that this is Nokia N900 (RX-51) device but
only some generic omap board.
--
Pali Rohár
[email protected]
On Saturday 06 September 2014 17:34:47 Andreas Färber wrote:
> Am 05.09.2014 15:52, schrieb Pali Rohár:
> > On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> >> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> >>> On Wednesday 18 June 2014 18:54:24 Pali Rohár 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 <[email protected]>
> >>>> ---
> >>>>
> >>>> 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;
> >>>
> >>> So, do you really want to break userspace which reading
> >>> file /proc/cpuinfo (after migration from boardcode -->
> >>> DT)?
> >>
> >> You have no guarantee model name in the DT == the name in a
> >> board file anyhow, and trying to force that is wrong. So
> >> further to Russell's reply, I must NAK this from a DT
> >> perspective.
> >>
> >> Realistically your userspace is already broken if relying
> >> on such things. You built something that only ever worked
> >> for a particular arbitrary string. So it was already
> >> broken for every other board, and there was never any
> >> guarantee that new boards where your userspace could have
> >> worked would share the same name.
> >>
> >> You're trying to fix the wrong side of the equation.
> >
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
>
> /proc/device-tree/compatible should give you a nul-separated
> list of compatible strings for the machine. Ideally they're
> even documented under Documentation/devicetree/bindings/arm/.
>
> But as Mark said, depending on what you are actually trying to
> distinguish in userspace, there may be better ways.
>
> Regards,
> Andreas
Ok, this is better. It at least output that device is Nokia N900
and not some generic omap device...
$ cat /proc/device-tree/compatible
nokia,omap3-n900ti,omap3430ti,omap3
But I need also serial number and hw revisions which are reported
by bootloader in ATAGs.
--
Pali Rohár
[email protected]
On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <[email protected]> wrote:
> On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> <[email protected]> wrote:
>> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >
>> > <[email protected]> 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
<[email protected]> wrote:
> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >
> > <[email protected]> wrote:
> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >
> >> > <[email protected]> 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).
--
Pali Rohár
[email protected]
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 <[email protected]> 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.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár <[email protected]> wrote:
> On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> <[email protected]> wrote:
>> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
>> >
>> > <[email protected]> wrote:
>> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >> >
>> >> > <[email protected]> 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
<[email protected]> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> >
> > <[email protected]> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >> >
> >> > <[email protected]> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >> >
> >> >> > <[email protected]> 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)?
--
Pali Rohár
[email protected]
On Thu, Dec 4, 2014 at 11:57 AM, Pali Rohár <[email protected]> wrote:
> On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
>> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár
> <[email protected]> wrote:
>> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
>> >
>> > <[email protected]> wrote:
>> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
>> >> >
>> >> > <[email protected]> wrote:
>> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >> >> >
>> >> >> > <[email protected]> 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
<[email protected]> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> >
> > <[email protected]> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >> >
> >> > <[email protected]> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >> >
> >> >> > <[email protected]> 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?
--
Pali Rohár
[email protected]