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 <redacted>
---
arch/arm/kernel/setup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
From: Russell King - ARM Linux <hidden> Date: 2014-06-18 19:01:25
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.
From: Rob Herring <hidden> Date: 2014-06-18 19:07:57
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r [off-list ref] wrote:
quoted hunk
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 <redacted>
---
arch/arm/kernel/setup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
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.
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:
quoted
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/5d34ccda/attachment.sig>
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted hunk
quoted
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 <redacted>
---
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
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.
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/5a518bfe/attachment.sig>
From: Russell King - ARM Linux <hidden> Date: 2014-06-18 19:59:21
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:
quoted
On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
quoted
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.
From: Russell King - ARM Linux <hidden> Date: 2014-06-18 20:01:06
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:
quoted
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/b648a269/attachment.sig>
From: Rob Herring <hidden> Date: 2014-06-18 20:46:42
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r [off-list ref] wrote:
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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 <redacted>
---
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
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.
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
From: Aaro Koskinen <aaro.koskinen@iki.fi> Date: 2014-06-18 21:10:48
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.
From: Russell King - ARM Linux <hidden> Date: 2014-06-18 21:48:06
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 [off-list ref] wrote:
quoted
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.
From: Rob Herring <hidden> Date: 2014-06-18 22:27:38
On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
[off-list ref] wrote:
On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r [off-list ref] wrote:
quoted
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
From: Russell King - ARM Linux <hidden> Date: 2014-06-18 23:07:36
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
[off-list ref] wrote:
quoted
On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r [off-list ref] wrote:
quoted
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...
quoted
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.
From: Pavel Machek <hidden> Date: 2014-06-19 08:21:52
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:
quoted
On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux
wrote:
quoted
On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
quoted
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.
quoted
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.
From: Pavel Machek <hidden> Date: 2014-07-11 19:28:49
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:
quoted
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?
From: Pavel Machek <hidden> Date: 2014-07-11 19:31:47
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:
quoted
On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux
wrote:
quoted
On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
quoted
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.
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted hunk
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 <redacted>
---
arch/arm/kernel/setup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
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...
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140905/db8b702e/attachment.sig>
From: Russell King - ARM Linux <hidden> Date: 2014-09-05 12:13:52
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:
quoted
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 <redacted>
---
arch/arm/kernel/setup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
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.
Thanks.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
From: Mark Rutland <mark.rutland@arm.com> Date: 2014-09-05 13:46:41
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:
quoted
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 <redacted>
---
arch/arm/kernel/setup.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
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.
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:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
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 <redacted>
---
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
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)?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140905/6e3c7aea/attachment.sig>
From: Mark Rutland <mark.rutland@arm.com> Date: 2014-09-05 13:59:11
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:
quoted
On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
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 <redacted>
---
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
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.
From: Andreas Färber <afaerber@suse.de> Date: 2014-09-06 15:35:01
Am 05.09.2014 15:52, schrieb Pali Roh?r:
On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
quoted
On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
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 <redacted>
---
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
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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140906/61e3eb45/attachment-0001.sig>
From: Pavel Machek <hidden> Date: 2014-09-10 12:46:24
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:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
- 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.
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/835bc0cb/attachment.sig>
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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 <redacted>
---
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
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
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.
quoted
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
quoted
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.
quoted
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:
quoted
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/aa667d0d/attachment.sig>
On Wednesday 10 September 2014 14:46:15 Pavel Machek wrote:
On Fri 2014-09-05 13:13:16, Russell King - ARM Linux wrote:
quoted
On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Roh?r wrote:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
- 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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/32a8d5c9/attachment.sig>
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:
quoted
On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
quoted
On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
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 <redacted>
---
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
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/cf51288a/attachment.sig>
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/823526be/attachment.sig>
On Saturday 06 September 2014 17:34:47 Andreas F?rber wrote:
Am 05.09.2014 15:52, schrieb Pali Roh?r:
quoted
On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
quoted
On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
quoted
On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
quoted
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 <redacted>
---
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
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/a2955bc8/attachment-0001.sig>
From: Rob Herring <hidden> Date: 2014-12-04 00:33:31
On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r [off-list ref] wrote:
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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.
[...]
quoted
quoted
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
[off-list ref] wrote:
quoted
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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.
[...]
quoted
quoted
quoted
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/c9644671/attachment.sig>
From: Russell King - ARM Linux <hidden> Date: 2014-12-04 10:59:26
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 [off-list ref] wrote:
quoted
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.
From: Rob Herring <hidden> Date: 2014-12-04 16:50:04
On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r [off-list ref] wrote:
On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
quoted
On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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.
[...]
quoted
quoted
quoted
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
[off-list ref] wrote:
quoted
On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
quoted
On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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.
[...]
quoted
quoted
quoted
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/fa7d9132/attachment-0001.sig>
From: Rob Herring <hidden> Date: 2014-12-04 18:10:55
On Thu, Dec 4, 2014 at 11:57 AM, Pali Roh?r [off-list ref] wrote:
On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
quoted
On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
quoted
On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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.
[...]
quoted
quoted
quoted
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
[off-list ref] wrote:
quoted
On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
quoted
On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
quoted
On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
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.
[...]
quoted
quoted
quoted
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
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/93a4559f/attachment-0001.sig>
@@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)if(!dt_phys||!early_init_dt_verify(phys_to_virt(dt_phys)))returnNULL;+dt_root=of_get_flat_dt_root();mdesc=of_flat_dt_match_machine(mdesc_best,arch_get_next_mach);if(!mdesc){constchar*prop;intsize;-unsignedlongdt_root;early_print("\nError: unrecognized/unsupported ""device tree compatible list:\n[ ");-dt_root=of_get_flat_dt_root();prop=of_get_flat_dt_prop(dt_root,"compatible",&size);while(size>0){early_print("'%s' ",prop);
@@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)/* Change machine number to match the mdesc we're using */__machine_arch_type=mdesc->nr;+/* Set system revision from DT */+prop=of_get_flat_dt_prop(dt_root,"revision",NULL);+if(prop)+system_rev=fdt32_to_cpu(*prop);+returnmdesc;}
And here is patch which convert ATAG revision into DT revision property and append it into DT in
decompress code:
@@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)cpu_to_fdt32(atag->u.mem.size);}+}elseif(atag->hdr.tag==ATAG_REVISION){+setprop_cell(fdt,"/","revision",atag->u.revision.rev);}elseif(atag->hdr.tag==ATAG_INITRD2){uint32_tinitrd_start,initrd_size;initrd_start=atag->u.initrd.start;
I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.
I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one,
let me know what to use instead. Also you can add my Signed-off-by for both patches.
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/e883d073/attachment.sig>
@@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)*addressandsizeforeachbank*/uint32_tmem_reg_property[2*2*NR_BANKS];intmemcount=0;-intret,memsize;+intret,memsize,atag_size;/* make sure we've got an aligned pointer */if((u32)atag_list&0x3)
@@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)}}+/* include the terminating ATAG_NONE */+atag_size=(char*)atag-(char*)atag_list+sizeof(structtag_header);+setprop(fdt,"/","atags",atag_list,atag_size);+if(memcount){setprop(fdt,"/memory","reg",mem_reg_property,4*memcount*memsize);
And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
@@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)if(prop)system_rev=fdt32_to_cpu(*prop);+/* Save atags */+prop=of_get_flat_dt_prop(dt_root,"atags",NULL);+if(prop)+save_atags((void*)prop);+returnmdesc;}
Some userspace applications needs access to ATAG structure where can be stored some information passed
from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
mode or device update mode).
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/f941725a/attachment.sig>
@@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)if(!dt_phys||!early_init_dt_verify(phys_to_virt(dt_phys)))returnNULL;+dt_root=of_get_flat_dt_root();mdesc=of_flat_dt_match_machine(mdesc_best,arch_get_next_mach);if(!mdesc){constchar*prop;intsize;-unsignedlongdt_root;early_print("\nError: unrecognized/unsupported ""device tree compatible list:\n[ ");-dt_root=of_get_flat_dt_root();prop=of_get_flat_dt_prop(dt_root,"compatible",&size);while(size>0){early_print("'%s' ",prop);
@@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)/* Change machine number to match the mdesc we're using */__machine_arch_type=mdesc->nr;+/* Set system revision from DT */+prop=of_get_flat_dt_prop(dt_root,"revision",NULL);+if(prop)+system_rev=fdt32_to_cpu(*prop);+returnmdesc;}
And here is patch which convert ATAG revision into DT revision property and append it into DT in
decompress code:
@@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)cpu_to_fdt32(atag->u.mem.size);}+}elseif(atag->hdr.tag==ATAG_REVISION){+setprop_cell(fdt,"/","revision",atag->u.revision.rev);}elseif(atag->hdr.tag==ATAG_INITRD2){uint32_tinitrd_start,initrd_size;initrd_start=atag->u.initrd.start;
I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.
I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one,
let me know what to use instead. Also you can add my Signed-off-by for both patches.
It is the correct property, but /revision in DT is a string.
You need to add your own sign-off.
Rob
@@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)*addressandsizeforeachbank*/uint32_tmem_reg_property[2*2*NR_BANKS];intmemcount=0;-intret,memsize;+intret,memsize,atag_size;/* make sure we've got an aligned pointer */if((u32)atag_list&0x3)
@@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)}}+/* include the terminating ATAG_NONE */+atag_size=(char*)atag-(char*)atag_list+sizeof(structtag_header);+setprop(fdt,"/","atags",atag_list,atag_size);+if(memcount){setprop(fdt,"/memory","reg",mem_reg_property,4*memcount*memsize);
And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
@@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)if(prop)system_rev=fdt32_to_cpu(*prop);+/* Save atags */+prop=of_get_flat_dt_prop(dt_root,"atags",NULL);+if(prop)+save_atags((void*)prop);+returnmdesc;}
Some userspace applications needs access to ATAG structure where can be stored some information passed
from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
mode or device update mode).
This goes in the commit message.
These would be non-standard fields which are not upstream. I don't
know that we care in that case...
Rob
From: Russell King - ARM Linux <hidden> Date: 2015-01-26 20:38:09
On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Roh?r wrote:
This patch will cause that decompressor store full ATAG structure into
DT tree ("/atags"):
How about something a little more radical.
Rather than trying to squeeze various ATAGs into DT, why don't we add a
standard ATAG to contain the DT and pass that through into the kernel.
This is IMHO how we _should_ have done the ATAG compatibility from the
start.
That means we could get rid of most of the libfdt in the decompressor,
and instead resolve the differences in the kernel.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Monday 26 January 2015 21:37:51 Russell King - ARM Linux
wrote:
On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Roh?r wrote:
quoted
This patch will cause that decompressor store full ATAG
structure into
quoted
DT tree ("/atags"):
How about something a little more radical.
Rather than trying to squeeze various ATAGs into DT, why don't
we add a standard ATAG to contain the DT and pass that
through into the kernel. This is IMHO how we _should_ have
done the ATAG compatibility from the start.
That means we could get rid of most of the libfdt in the
decompressor, and instead resolve the differences in the
kernel.
This sounds good. Now when I patched decompressor myself with
Revision property support, I wanted to ask same question: Why to
convert some part from ATAGs to DT instead to pass both ATAGs and
DT to kernel?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/76bf758b/attachment.sig>
Probably the use of two differently typed variables of name "prop" in
this function is not intentional?
Regards,
Andreas
quoted hunk
int size;
- unsigned long dt_root;
early_print("\nError: unrecognized/unsupported "
"device tree compatible list:\n[ ");
- dt_root = of_get_flat_dt_root();
prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
while (size > 0) {
early_print("'%s' ", prop);
@@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys) /* Change machine number to match the mdesc we're using */ __machine_arch_type = mdesc->nr;+ /* Set system revision from DT */+ prop = of_get_flat_dt_prop(dt_root, "revision", NULL);+ if (prop)+ system_rev = fdt32_to_cpu(*prop);+ return mdesc; }
[snip]
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG N?rnberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/a6b5053f/attachment.sig>
From: Pavel Machek <hidden> Date: 2015-01-27 13:21:32
On Mon 2015-01-26 14:33:21, Rob Herring wrote:
On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r [off-list ref] wrote:
quoted
This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
quoted
+ /* include the terminating ATAG_NONE */
+ atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
+ setprop(fdt, "/", "atags", atag_list, atag_size);
+
if (memcount) {
setprop(fdt, "/memory", "reg", mem_reg_property,
4 * memcount * memsize);
And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
Please properly send your patches.
Actually, when sending patches for discussion, this is format easier
to read.
quoted
Some userspace applications needs access to ATAG structure where can be stored some information passed
from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
mode or device update mode).
This goes in the commit message.
These would be non-standard fields which are not upstream. I don't
know that we care in that case...
From: Rob Herring <hidden> Date: 2015-01-27 14:17:10
On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek [off-list ref] wrote:
On Mon 2015-01-26 14:33:21, Rob Herring wrote:
quoted
On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r [off-list ref] wrote:
quoted
This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
quoted
quoted
+ /* include the terminating ATAG_NONE */
+ atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
+ setprop(fdt, "/", "atags", atag_list, atag_size);
+
if (memcount) {
setprop(fdt, "/memory", "reg", mem_reg_property,
4 * memcount * memsize);
And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
Please properly send your patches.
Actually, when sending patches for discussion, this is format easier
to read.
Some people might prefer them as attachments too...
quoted
quoted
Some userspace applications needs access to ATAG structure where can be stored some information passed
from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
mode or device update mode).
This goes in the commit message.
These would be non-standard fields which are not upstream. I don't
know that we care in that case...
Other devices are going to care about boot reason, too, and we might
as well be compatible...
What other devices? Where is bootreason in the list of ATAGS:
#define ATAG_MEM 0x54410002
#define ATAG_VIDEOTEXT 0x54410003
#define ATAG_RAMDISK 0x54410004
#define ATAG_INITRD 0x54410005
#define ATAG_INITRD2 0x54420005
#define ATAG_SERIAL 0x54410006
#define ATAG_REVISION 0x54410007
#define ATAG_VIDEOLFB 0x54410008
#define ATAG_CMDLINE 0x54410009
#define ATAG_ACORN 0x41000101
#define ATAG_MEMCLK 0x41000402
Rob
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek [off-list ref]
wrote:
quoted
On Mon 2015-01-26 14:33:21, Rob Herring wrote:
quoted
On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r
[off-list ref] wrote:
quoted
quoted
quoted
This patch will cause that decompressor store full ATAG
structure into DT tree ("/atags"):
+ /* include the terminating ATAG_NONE */
+ atag_size = (char *)atag - (char *)atag_list +
sizeof(struct tag_header); + setprop(fdt, "/",
"atags", atag_list, atag_size); +
if (memcount) {
setprop(fdt, "/memory", "reg",
mem_reg_property,
4 * memcount * memsize);
And this patch will export ATAG structure from DT tree
("/atags") into /proc/atags file:
quoted
quoted
Please properly send your patches.
Actually, when sending patches for discussion, this is
format easier to read.
Some people might prefer them as attachments too...
quoted
quoted
quoted
Some userspace applications needs access to ATAG
structure where can be stored some information passed
from bootloader to kernel. Example is Nokia N900 device
and NOLO bootloader which provides information about
bootreason (device was started by power button or by
alarm or restarted...) and bootmode (normal mode or
device update mode).
This goes in the commit message.
These would be non-standard fields which are not upstream.
I don't know that we care in that case...
Other devices are going to care about boot reason, too, and
we might as well be compatible...
What other devices? Where is bootreason in the list of ATAGS:
#define ATAG_MEM 0x54410002
#define ATAG_VIDEOTEXT 0x54410003
#define ATAG_RAMDISK 0x54410004
#define ATAG_INITRD 0x54410005
#define ATAG_INITRD2 0x54420005
#define ATAG_SERIAL 0x54410006
#define ATAG_REVISION 0x54410007
#define ATAG_VIDEOLFB 0x54410008
#define ATAG_CMDLINE 0x54410009
#define ATAG_ACORN 0x41000101
#define ATAG_MEMCLK 0x41000402
Rob
Each device is using own proprietary atag (or other information)
to pass bootreason from bootloader to kernel. No standard way :-(
I think Pavel mean to introduce some standard way how *new*
version of bootloaders can pass boot reason to kernel and how
kernel tell it to userspace...
E.g. NOLO -- bootloader for Nokia N900 -- pass this information
in ATAG_OMAP (0x414f4d50) and Nokia kernel exports it via procfs
file /proc/bootreason.
Also NOLO pass some other information via ATAGs, but those are
static and now part of n900 DT file. But bootreason is not static
information so cannot be hardcoded into static DT file which is
part of kernel.
I think this kind of information (how was board/computer started)
can be useful also for other architectures. E.g. on laptop you
would like to know if if was started by RTC, power button,
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc...
And scripts can act depending on this event (when by RTC, you
need to run some planned job, when by watchdog reset you should
check what caused that reason...).
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/f0b0c2da/attachment.sig>
From: Russell King - ARM Linux <hidden> Date: 2015-01-27 17:48:35
On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
quoted
What other devices? Where is bootreason in the list of ATAGS:
#define ATAG_MEM 0x54410002
#define ATAG_VIDEOTEXT 0x54410003
#define ATAG_RAMDISK 0x54410004
#define ATAG_INITRD 0x54410005
#define ATAG_INITRD2 0x54420005
#define ATAG_SERIAL 0x54410006
#define ATAG_REVISION 0x54410007
#define ATAG_VIDEOLFB 0x54410008
#define ATAG_CMDLINE 0x54410009
#define ATAG_ACORN 0x41000101
#define ATAG_MEMCLK 0x41000402
Rob
Each device is using own proprietary atag (or other information)
to pass bootreason from bootloader to kernel. No standard way :-(
The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people. This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.
We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."
Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".
Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.
I think this kind of information (how was board/computer started)
can be useful also for other architectures. E.g. on laptop you
would like to know if if was started by RTC, power button,
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc...
And scripts can act depending on this event (when by RTC, you
need to run some planned job, when by watchdog reset you should
check what caused that reason...).
There is a standard way to get the boot information already: look at
the watchdog API:
#define WDIOC_GETBOOTSTATUS _IOR(WATCHDOG_IOCTL_BASE, 2, int)
which uses the WDIOF_* flags to indicate the last boot reason. It
probably isn't as flexible as some may desire, but it should provide
at least the "watchdog rebooted us" vs "over temperature" vs some
other boot reason.
The other thing to consider is whether we have a way to know what
the boot reason was, and what we should do if we do not have a way
of supporting some of the boot reasons. For example, if we have
support for RTC alarm based booting, but no way to actually tell
if the boot was caused by the RTC alarm triggering.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
From: Nicolas Pitre <nico@fluxnic.net> Date: 2015-01-27 20:03:25
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
quoted
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
quoted
What other devices? Where is bootreason in the list of ATAGS:
#define ATAG_MEM 0x54410002
#define ATAG_VIDEOTEXT 0x54410003
#define ATAG_RAMDISK 0x54410004
#define ATAG_INITRD 0x54410005
#define ATAG_INITRD2 0x54420005
#define ATAG_SERIAL 0x54410006
#define ATAG_REVISION 0x54410007
#define ATAG_VIDEOLFB 0x54410008
#define ATAG_CMDLINE 0x54410009
#define ATAG_ACORN 0x41000101
#define ATAG_MEMCLK 0x41000402
Rob
Each device is using own proprietary atag (or other information)
to pass bootreason from bootloader to kernel. No standard way :-(
So that's what Pavel was alluding to.
The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people. This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.
We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."
Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".
Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.
If the method is: "let's pass non-standard ATAGs around and have ad-hoc
user space code interpret it in some arbitrary way" then it's a complete
abomination.
quoted
I think this kind of information (how was board/computer started)
can be useful also for other architectures. E.g. on laptop you
would like to know if if was started by RTC, power button,
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc...
And scripts can act depending on this event (when by RTC, you
need to run some planned job, when by watchdog reset you should
check what caused that reason...).
Useful when properly designed and generic enough to be shared.
I'd suggest a DT property be proposed for that purpose if it doesn't
already exist. That at least has a chance to be generically useful.
Nicolas
From: Russell King - ARM Linux <hidden> Date: 2015-01-27 21:09:58
On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
quoted
On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
quoted
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
quoted
What other devices? Where is bootreason in the list of ATAGS:
#define ATAG_MEM 0x54410002
#define ATAG_VIDEOTEXT 0x54410003
#define ATAG_RAMDISK 0x54410004
#define ATAG_INITRD 0x54410005
#define ATAG_INITRD2 0x54420005
#define ATAG_SERIAL 0x54410006
#define ATAG_REVISION 0x54410007
#define ATAG_VIDEOLFB 0x54410008
#define ATAG_CMDLINE 0x54410009
#define ATAG_ACORN 0x41000101
#define ATAG_MEMCLK 0x41000402
Rob
Each device is using own proprietary atag (or other information)
to pass bootreason from bootloader to kernel. No standard way :-(
So that's what Pavel was alluding to.
quoted
The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people. This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.
We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."
Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".
Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.
If the method is: "let's pass non-standard ATAGs around and have ad-hoc
user space code interpret it in some arbitrary way" then it's a complete
abomination.
quoted
quoted
I think this kind of information (how was board/computer started)
can be useful also for other architectures. E.g. on laptop you
would like to know if if was started by RTC, power button,
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc...
And scripts can act depending on this event (when by RTC, you
need to run some planned job, when by watchdog reset you should
check what caused that reason...).
Useful when properly designed and generic enough to be shared.
I'd suggest a DT property be proposed for that purpose if it doesn't
already exist. That at least has a chance to be generically useful.
What this means is that we have to further augment the atags-to-dt code
in the decompressor with the platform specific ATAGs to parse this
information and merge it into the appended DT before passing the
resulting DT blob to the kernel.
Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.
Or we /could/ say that mainline never supported it, and we aren't going
to add support for "new" tags to the mainline kernel. It wouldn't be
a regression, because mainline hasn't ever supported them (that's been
said before about such things on other platforms.)
However, there's another consideration to be had here before we can say
that: how many people out there want to run a mainline (or even an
updated kernel derived from mainline) on this device? If there's a
sizable following for the device wanting updated support, then it's
something we really need to consider supporting inspite of our
disappointment with Nokia inventing these "proprietary" tags.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
From: Nicolas Pitre <nico@fluxnic.net> Date: 2015-01-27 21:34:50
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
quoted
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
quoted
On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
quoted
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
quoted
What other devices? Where is bootreason in the list of ATAGS:
#define ATAG_MEM 0x54410002
#define ATAG_VIDEOTEXT 0x54410003
#define ATAG_RAMDISK 0x54410004
#define ATAG_INITRD 0x54410005
#define ATAG_INITRD2 0x54420005
#define ATAG_SERIAL 0x54410006
#define ATAG_REVISION 0x54410007
#define ATAG_VIDEOLFB 0x54410008
#define ATAG_CMDLINE 0x54410009
#define ATAG_ACORN 0x41000101
#define ATAG_MEMCLK 0x41000402
Rob
Each device is using own proprietary atag (or other information)
to pass bootreason from bootloader to kernel. No standard way :-(
So that's what Pavel was alluding to.
quoted
The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people. This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.
We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."
Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".
Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.
If the method is: "let's pass non-standard ATAGs around and have ad-hoc
user space code interpret it in some arbitrary way" then it's a complete
abomination.
quoted
quoted
I think this kind of information (how was board/computer started)
can be useful also for other architectures. E.g. on laptop you
would like to know if if was started by RTC, power button,
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc...
And scripts can act depending on this event (when by RTC, you
need to run some planned job, when by watchdog reset you should
check what caused that reason...).
Useful when properly designed and generic enough to be shared.
I'd suggest a DT property be proposed for that purpose if it doesn't
already exist. That at least has a chance to be generically useful.
What this means is that we have to further augment the atags-to-dt code
in the decompressor with the platform specific ATAGs to parse this
information and merge it into the appended DT before passing the
resulting DT blob to the kernel.
That would be only 2 new lines of code in the best case.
Still, I opposed such platform specific hacks in the past, suggesting
that a separate shim be used instead, which was done successfully.
Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.
... which would be a step backward in the context of the transition to
DT we accepted. People will have even less of an incentive to fix their
stuff.
Or we /could/ say that mainline never supported it, and we aren't going
to add support for "new" tags to the mainline kernel. It wouldn't be
a regression, because mainline hasn't ever supported them (that's been
said before about such things on other platforms.)
That would be my stance.
However, there's another consideration to be had here before we can say
that: how many people out there want to run a mainline (or even an
updated kernel derived from mainline) on this device? If there's a
sizable following for the device wanting updated support, then it's
something we really need to consider supporting inspite of our
disappointment with Nokia inventing these "proprietary" tags.
If there is indeed a sizable following for the device then someone
should figure out how to cope with upstream kernels, either through the
installation of some intermediate bootloader that can talk FDT directly,
or via a shim layer. None of that has to be performed by nor linked
with the kernel binary, nor maintained in the kernel tree. And it's not
even that hard to do: we have precedents on other platforms with crappy
bootloaders where this just works.
Nicolas
From: Nicolas Pitre <nico@fluxnic.net> Date: 2015-01-27 21:58:20
On Tue, 27 Jan 2015, Nicolas Pitre wrote:
If there is indeed a sizable following for the device then someone
should figure out how to cope with upstream kernels, either through the
installation of some intermediate bootloader that can talk FDT directly,
or via a shim layer. None of that has to be performed by nor linked
with the kernel binary, nor maintained in the kernel tree. And it's not
even that hard to do: we have precedents on other platforms with crappy
bootloaders where this just works.
From: Russell King - ARM Linux <hidden> Date: 2015-01-27 22:33:46
On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
quoted
Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.
... which would be a step backward in the context of the transition to
DT we accepted. People will have even less of an incentive to fix their
stuff.
Where's the people fixing their stuff today? I think your position is
something of an idealist rather than a realist - the reality is that
five years down the line of DT, the platforms which have not converted
are now *never* going to convert, irrespective of how much "incentive"
we may think we should apply to the situation.
So, at some point we have to start thinking as a realist rather than
an idealist, and realise that there are platforms out there which are
/never/ going to convert.
Most of my platforms here are /never/ going to convert to DT-only
booting quite simply because they don't have anyone working on that
stuff, and no one is willing to put the effort in.
The only platforms which I have which have converted are:
- OMAP SDP4430
- Versatile Express
- SolidRun Hummingboard & Cubox-i
Quite literally everything else is *never* going to support native DT
booting - and I'd go as far as to say that if I ever wanted to put the
effort in, I probably couldn't, because the boot loader sources aren't
available anymore. (eg, the LDP3430 situation is such a mess that even
if the boot loader source is still available, identifying the correct
board version is near on impossible given the multitude of different
variants of the same product.)
The older Versatile and Integrator platforms, for example, are going
to be booting with the appended DTB for as long as they're around.
Most likely all the PXA platforms too, and, the IOP32x based N2100
boxes (which already need their kernels wrapped because the provided
boot loader has had environment saving disabled.)
As much as you may not like it, ATAGs are here to stay now, at least
on the older platforms, and no amount of "incentives" will change that.
quoted
However, there's another consideration to be had here before we can say
that: how many people out there want to run a mainline (or even an
updated kernel derived from mainline) on this device? If there's a
sizable following for the device wanting updated support, then it's
something we really need to consider supporting inspite of our
disappointment with Nokia inventing these "proprietary" tags.
If there is indeed a sizable following for the device then someone
should figure out how to cope with upstream kernels, either through the
installation of some intermediate bootloader that can talk FDT directly,
or via a shim layer. None of that has to be performed by nor linked
with the kernel binary, nor maintained in the kernel tree. And it's not
even that hard to do: we have precedents on other platforms with crappy
bootloaders where this just works.
That's a rediculous position if you want something which "just works"
on as much hardware as possible, which is, after all, what the single
zImage project is all about.
To be pro single-zImage, and anti popular hardware is quite contradictory.
You only have to look at x86 for this: just because ACPI came along does
not mean that the Linux kernel started demanding that ACPI is the only
way to describe the world. Linux continues to directly support all the
old boot protocols that it did since the days of i386, such as the e820
memory interface and doesn't convert these to an ACPI table just because
it can.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
From: Pavel Machek <hidden> Date: 2015-01-27 23:10:11
Hi!
quoted
quoted
Useful when properly designed and generic enough to be shared.
I'd suggest a DT property be proposed for that purpose if it doesn't
already exist. That at least has a chance to be generically useful.
What this means is that we have to further augment the atags-to-dt code
in the decompressor with the platform specific ATAGs to parse this
information and merge it into the appended DT before passing the
resulting DT blob to the kernel.
That would be only 2 new lines of code in the best case.
From: Tony Lindgren <tony@atomide.com> Date: 2015-01-28 00:53:50
* Russell King - ARM Linux [off-list ref] [150127 09:51]:
We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."
Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".
Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.
I believe after N900 Nokia dropped the custom ATAGs and used the
kernel cmdline instead. And most of the n900 custom ATAGs are not
even needed any longer.
The ATAG_REVISION is a standard feature that we should support
naturally. I don't think we should add any custom ATAGs, except
maybe for the bootreason.
quoted
I think this kind of information (how was board/computer started)
can be useful also for other architectures. E.g. on laptop you
would like to know if if was started by RTC, power button,
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc...
And scripts can act depending on this event (when by RTC, you
need to run some planned job, when by watchdog reset you should
check what caused that reason...).
There is a standard way to get the boot information already: look at
the watchdog API:
#define WDIOC_GETBOOTSTATUS _IOR(WATCHDOG_IOCTL_BASE, 2, int)
which uses the WDIOF_* flags to indicate the last boot reason. It
probably isn't as flexible as some may desire, but it should provide
at least the "watchdog rebooted us" vs "over temperature" vs some
other boot reason.
The other thing to consider is whether we have a way to know what
the boot reason was, and what we should do if we do not have a way
of supporting some of the boot reasons. For example, if we have
support for RTC alarm based booting, but no way to actually tell
if the boot was caused by the RTC alarm triggering.
On omaps, the bootrom passes the bootreason in r1 to the bootloader
that can do whatever it wants with it. We could maybe pass it
in the kernel cmdline to the watchdog driver for user space?
Of course the problem is that the signed bootloader on n900 cannot
be modified so the pass through u-boot would have to translate
the custom ATAG for bootreason into a kernel cmdline..
But it may actually make sense to add the bootreason ATAGs, it
seems quite generic to me.
AFAIK, the other n900 ATAGs can be just ignored.
Regards,
Tony
From: Nicolas Pitre <nico@fluxnic.net> Date: 2015-01-28 02:07:49
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
quoted
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
quoted
Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.
... which would be a step backward in the context of the transition to
DT we accepted. People will have even less of an incentive to fix their
stuff.
Where's the people fixing their stuff today?
At least some people in this thread are, otherwise they'd still be away
hacking on their own.
I think your position is something of an idealist rather than a
realist - the reality is that five years down the line of DT, the
platforms which have not converted are now *never* going to convert,
irrespective of how much "incentive" we may think we should apply to
the situation.
Don't get me wrong. I'm not expecting those platforms to do native DT
booting ever. However "faking" DT booting with already proven solutions
that don't bastardize the kernel further should be encouraged.
quoted
If there is indeed a sizable following for the device then someone
should figure out how to cope with upstream kernels, either through the
installation of some intermediate bootloader that can talk FDT directly,
or via a shim layer. None of that has to be performed by nor linked
with the kernel binary, nor maintained in the kernel tree. And it's not
even that hard to do: we have precedents on other platforms with crappy
bootloaders where this just works.
That's a rediculous position if you want something which "just works"
on as much hardware as possible, which is, after all, what the single
zImage project is all about.
Agreed.
To be pro single-zImage, and anti popular hardware is quite contradictory.
Indeed. I'm not against popular hardware.
You only have to look at x86 for this: just because ACPI came along does
not mean that the Linux kernel started demanding that ACPI is the only
way to describe the world. Linux continues to directly support all the
old boot protocols that it did since the days of i386, such as the e820
memory interface and doesn't convert these to an ACPI table just because
it can.
Booting from a floppy boot sector is no longer supported though.
But that's besides the point. If someone needs a 5-line addition to
atags_to_fdt.c in order to boot some old stuff then let's just do it and
move on. I'll happily ACK the patch. The code is there and it is not
going away soon.
However, if something more involved is needed, is platform specific and
is likely to require about as many lines in the kernel than it would
need in some externat shim then the shim solution should be encouraged
instead. After all that's why LILO, Syslinux and Grub were created on
X86: to Supplement the crappy PC BIOS boot interface. And if the
hardware is popular, then finding a motivated hacker to do it shouldn't
be too hard, right?
In other words, what prevents someone from creating, say, a custom
minimal Barebox version that sits on top of the existing N900
bootloader? Wouldn't that provide a much better user experience?
Nicolas
On Jan 28, 2015, at 10:07 AM, Nicolas Pitre [off-list ref] wrote:
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
quoted
On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
quoted
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
quoted
Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.
... which would be a step backward in the context of the transition to
DT we accepted. People will have even less of an incentive to fix their
stuff.
Where's the people fixing their stuff today?
At least some people in this thread are, otherwise they'd still be away
hacking on their own.
quoted
I think your position is something of an idealist rather than a
realist - the reality is that five years down the line of DT, the
platforms which have not converted are now *never* going to convert,
irrespective of how much "incentive" we may think we should apply to
the situation.
Don't get me wrong. I'm not expecting those platforms to do native DT
booting ever. However "faking" DT booting with already proven solutions
that don't bastardize the kernel further should be encouraged.
quoted
quoted
If there is indeed a sizable following for the device then someone
should figure out how to cope with upstream kernels, either through the
installation of some intermediate bootloader that can talk FDT directly,
or via a shim layer. None of that has to be performed by nor linked
with the kernel binary, nor maintained in the kernel tree. And it's not
even that hard to do: we have precedents on other platforms with crappy
bootloaders where this just works.
That's a rediculous position if you want something which "just works"
on as much hardware as possible, which is, after all, what the single
zImage project is all about.
Agreed.
quoted
To be pro single-zImage, and anti popular hardware is quite contradictory.
Indeed. I'm not against popular hardware.
quoted
You only have to look at x86 for this: just because ACPI came along does
not mean that the Linux kernel started demanding that ACPI is the only
way to describe the world. Linux continues to directly support all the
old boot protocols that it did since the days of i386, such as the e820
memory interface and doesn't convert these to an ACPI table just because
it can.
Booting from a floppy boot sector is no longer supported though.
But that's besides the point. If someone needs a 5-line addition to
atags_to_fdt.c in order to boot some old stuff then let's just do it and
move on. I'll happily ACK the patch. The code is there and it is not
going away soon.
However, if something more involved is needed, is platform specific and
is likely to require about as many lines in the kernel than it would
need in some externat shim then the shim solution should be encouraged
instead. After all that's why LILO, Syslinux and Grub were created on
X86: to Supplement the crappy PC BIOS boot interface. And if the
hardware is popular, then finding a motivated hacker to do it shouldn't
be too hard, right?
In other words, what prevents someone from creating, say, a custom
minimal Barebox version that sits on top of the existing N900
bootloader? Wouldn't that provide a much better user experience?
I do agree with Nicolas
If I can get my hand on a phone I?ll put barebox on it
Best Regards,
J.
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
quoted
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We could
maybe pass it in the kernel cmdline to the watchdog driver
for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was power key
pressed, R&D data stored in CAL partition and other undocumented
registers for omap HS devices. I already tried to implement at
least some subset of it in userspace (or kernel), but it is
impossible because NOLO bootloader clear status of PRM_RSTST
register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten (probably
by kernel), so we really cannot implement reading bootreason in
kernel.
But in early stage in uboot it is possible to read 0x4020FFB8
address and get some part of bootreason. But still PRM_RSTST is
not enough!
I would be happy if DT kernel can export /proc/atags file with
ATAGs passed by bootloader. It would be enough for me. In
userspace I can parse content and do what is needed.
What about defining a DT boot reason property instead?
Maybe it already exists? If not, it's something that could certainly be
generically used on other platforms too.
Converting the special ATAG into its standard DT equivalent would then
be trivial and much cleaner overall.
Nicolas
From: Pavel Machek <hidden> Date: 2015-01-28 20:14:14
On Wed 2015-01-28 16:06:17, Jean-Christophe PLAGNIOL-VILLARD wrote:
quoted
On Jan 28, 2015, at 3:19 PM, Pavel Machek [off-list ref] wrote:
Hi!
quoted
quoted
In other words, what prevents someone from creating, say, a custom
minimal Barebox version that sits on top of the existing N900
bootloader? Wouldn't that provide a much better user experience?
I do agree with Nicolas
If I can get my hand on a phone I?ll put barebox on it
Grab it in the nearest "second hand cellphones" shop, and have fun! It
should be less than $70.
will see if I can found one in Shanghai at the second hand market
Does it exist a qemu emulation?
From: Pavel Machek <hidden> Date: 2015-01-28 20:14:16
Hi!
In other words, what prevents someone from creating, say, a custom
minimal Barebox version that sits on top of the existing N900
bootloader? Wouldn't that provide a much better user experience?
Lot of useless work, that would make user experience worse?
We have mostly working u-boot on N900. Its there, useful for boot
menus, but makes debugging tricky, so we want to keep working with
internal bootloader, too. And I have already explained this to you
before.
Now, would you stop assigning work to other people?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
From: Pavel Machek <hidden> Date: 2015-01-28 20:19:10
Hi!
quoted
In other words, what prevents someone from creating, say, a custom
minimal Barebox version that sits on top of the existing N900
bootloader? Wouldn't that provide a much better user experience?
I do agree with Nicolas
If I can get my hand on a phone I?ll put barebox on it
On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL-
VILLARD wrote:
quoted
On Jan 28, 2015, at 11:57 PM, Rob Herring
[off-list ref] wrote:
On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre
[off-list ref] wrote:
quoted
quoted
On Wed, 28 Jan 2015, Pali Roh?r wrote:
quoted
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
quoted
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We
could maybe pass it in the kernel cmdline to the
watchdog driver for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was
power key pressed, R&D data stored in CAL partition and
other undocumented registers for omap HS devices. I
already tried to implement at least some subset of it in
userspace (or kernel), but it is impossible because NOLO
bootloader clear status of PRM_RSTST register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten
(probably by kernel), so we really cannot implement
reading bootreason in kernel.
But in early stage in uboot it is possible to read
0x4020FFB8 address and get some part of bootreason. But
still PRM_RSTST is not enough!
I would be happy if DT kernel can export /proc/atags file
with ATAGs passed by bootloader. It would be enough for
me. In userspace I can parse content and do what is
needed.
What about defining a DT boot reason property instead?
Maybe it already exists? If not, it's something that could
certainly be generically used on other platforms too.
I'm fine with that, but we just need to have a standard
kernel userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the
default implementation for the watchdog dev. Someday when
we decide DT is crap and have a new boot interface, we'll
have people relying on /proc/device-tree. I hope to be
retired when that happens?
but if we try to do this generic, where will you store the
boot mode
I mean where the SoC boot from
useful to for the Userspace to known where is the bootloader
in case of multi boot mode
Best Regards,
J.
quoted
Rob
I think in this discussion we are mixing two parts which should
be designed & solved separately.
1) How should bootloader tell to kernel what is bootreason
2) How should kernel export bootreason to userspace
In modern x86 laptop world bootreason can be requested from
BIOS/WMI/firmware by special proprietary vendor specific command.
So we should not lock bootreason to DT or ATAG only. Or only
bootloader --> kernel transition. For other platforms, board or
even architectures (x86) there can runtime way (for kernel) how
to read bootreason...
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/cc59673e/attachment-0001.sig>
From: Tony Lindgren <tony@atomide.com> Date: 2015-01-28 20:36:47
* Nicolas Pitre [off-list ref] [150128 06:37]:
On Wed, 28 Jan 2015, Pali Roh?r wrote:
quoted
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
quoted
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We could
maybe pass it in the kernel cmdline to the watchdog driver
for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was power key
pressed, R&D data stored in CAL partition and other undocumented
registers for omap HS devices. I already tried to implement at
least some subset of it in userspace (or kernel), but it is
impossible because NOLO bootloader clear status of PRM_RSTST
register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten (probably
by kernel), so we really cannot implement reading bootreason in
kernel.
But in early stage in uboot it is possible to read 0x4020FFB8
address and get some part of bootreason. But still PRM_RSTST is
not enough!
I would be happy if DT kernel can export /proc/atags file with
ATAGs passed by bootloader. It would be enough for me. In
userspace I can parse content and do what is needed.
What about defining a DT boot reason property instead?
Maybe it already exists? If not, it's something that could certainly be
generically used on other platforms too.
Converting the special ATAG into its standard DT equivalent would then
be trivial and much cleaner overall.
Sounds good to me as then we don't have to add any legacy custom
Nokia specific atag. And it won't prevent us from adding a generic
ATAG_BOOTREASON if really needed.
Regards,
Tony
From: Russell King - ARM Linux <hidden> Date: 2015-01-28 20:41:39
On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
quoted
On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
quoted
I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...
Anyone who thinks that DT can be replaced in the same way that we made
the mistake with ATAGs would really need their head examined.
As you point out, removing DT removes the /proc/device-tree/ sub-tree.
Whether we like it or not, that is a userspace API, one which we have
users of already. That pretty much means that we can't remove DT for
existing platforms or any platform we have now converted to DT.
<ok, I'll go there!>
... and for platforms that can also be booted via ACPI? If we have to
convert the ACPI tables into a device-tree purely for /proc/device-tree,
then we may as well boot with the thing too :)
Seriously though, I don't see how we can maintain this directory for
ACPI, regardless of whether or not it's ABI.
And if it needs stating more clearly, you have just shown why adding
a boot reason to devicetree is the wrong thing to do.
Let's say that we do decide to convert the boot reason atag to a device
tree property. As soon as we do that, it appears in the /proc/device-tree
sub-tree, whether we like it or not, because that sub-tree exports
*everything* mentioned in the DT blob.
So, as soon as we put anything into the DT blob, it immediately becomes
part of the kernel's userspace API, whether we like it or not. That
means it becomes available for userspace to start (ab)using - again,
whether or not we provide a saner firmware independent interface.
The more we mess around converting crap from one firmware interface to
another, the more problems we're creating for ourselves. We really
need to re-think our approach to this, and stop this religous "DT is
everything, we must convert everything to DT."
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
From: Russell King - ARM Linux <hidden> Date: 2015-01-28 20:41:42
On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...
Anyone who thinks that DT can be replaced in the same way that we made
the mistake with ATAGs would really need their head examined.
As you point out, removing DT removes the /proc/device-tree/ sub-tree.
Whether we like it or not, that is a userspace API, one which we have
users of already. That pretty much means that we can't remove DT for
existing platforms or any platform we have now converted to DT.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
* Russell King - ARM Linux [off-list ref] [150127
09:51]:
quoted
We _could_ (and have in the past) turned round and refused
to support these kinds of hacks - which IMHO is quite a
reasonable stance to take: the message we should be sending
is "if you wish to design new methods without discussing it
with us, we reserve the right not to support them in
mainline kernels; please discuss with us your
requirements."
Each time that we accept one of these hacks, we're sending a
message that says "it's okay to work in this crappy way".
Yes, I realise that the N900 has little in the way of
support, and we can't exert that kind of back pressure
(since there's no one to direct that onto to effect any
change) so I guess we just have to live with it.
I believe after N900 Nokia dropped the custom ATAGs and used
the kernel cmdline instead. And most of the n900 custom ATAGs
are not even needed any longer.
Yes, almost all N900 ATAGs are static and are already hardcoded
into kernel or DT file.
Basically there are 4 non static values which are used:
1. ATAG_REVISION
2. ATAG_OMAP
2.1 OMAP_TAG_BOOT_REASON --> boot reason
2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version
2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or "update"
ATAG_OMAP is non standard and contains sub-atags.
bootloader version is static now (as Nokia does not develop it
anymore), but boot reason and boot mode are set by bootloader and
are needed for userspace. boot mode tells init system/userspace
if to start normal OS or only small subset for flashing.
The ATAG_REVISION is a standard feature that we should support
naturally. I don't think we should add any custom ATAGs,
except maybe for the bootreason.
quoted
quoted
I think this kind of information (how was board/computer
started) can be useful also for other architectures. E.g.
on laptop you would like to know if if was started by
RTC, power button, WakeOnLan, another ACPI event,
rebooted machine, watchdog, etc... And scripts can act
depending on this event (when by RTC, you need to run
some planned job, when by watchdog reset you should check
what caused that reason...).
There is a standard way to get the boot information already:
look at the watchdog API:
#define WDIOC_GETBOOTSTATUS _IOR(WATCHDOG_IOCTL_BASE, 2,
int)
which uses the WDIOF_* flags to indicate the last boot
reason. It probably isn't as flexible as some may desire,
but it should provide at least the "watchdog rebooted us"
vs "over temperature" vs some other boot reason.
The other thing to consider is whether we have a way to know
what the boot reason was, and what we should do if we do
not have a way of supporting some of the boot reasons. For
example, if we have support for RTC alarm based booting,
but no way to actually tell if the boot was caused by the
RTC alarm triggering.
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We could
maybe pass it in the kernel cmdline to the watchdog driver
for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was power key
pressed, R&D data stored in CAL partition and other undocumented
registers for omap HS devices. I already tried to implement at
least some subset of it in userspace (or kernel), but it is
impossible because NOLO bootloader clear status of PRM_RSTST
register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten (probably
by kernel), so we really cannot implement reading bootreason in
kernel.
But in early stage in uboot it is possible to read 0x4020FFB8
address and get some part of bootreason. But still PRM_RSTST is
not enough!
I would be happy if DT kernel can export /proc/atags file with
ATAGs passed by bootloader. It would be enough for me. In
userspace I can parse content and do what is needed.
In non DT kernel file /proc/atags is always exported.
Of course the problem is that the signed bootloader on n900
cannot be modified so the pass through u-boot would have to
translate the custom ATAG for bootreason into a kernel
cmdline..
But it may actually make sense to add the bootreason ATAGs, it
seems quite generic to me.
Which bootreason atag? Invent new? Or use above big ATAG_OMAP
structure? Inventing new does not solve anything because all
developers does not boot kernel for debugging from uboot -- but
directly.
AFAIK, the other n900 ATAGs can be just ignored.
Regards,
Tony
From: Russell King - ARM Linux <hidden> Date: 2015-01-28 21:39:48
On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
quoted
On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
quoted
I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...
Anyone who thinks that DT can be replaced in the same way that we made
the mistake with ATAGs would really need their head examined.
As you point out, removing DT removes the /proc/device-tree/ sub-tree.
Whether we like it or not, that is a userspace API, one which we have
users of already. That pretty much means that we can't remove DT for
existing platforms or any platform we have now converted to DT.
<ok, I'll go there!>
... and for platforms that can also be booted via ACPI? If we have to
convert the ACPI tables into a device-tree purely for /proc/device-tree,
then we may as well boot with the thing too :)
Seriously though, I don't see how we can maintain this directory for
ACPI, regardless of whether or not it's ABI.
Welcome to the problem that exporting information to userspace creates.
The same problem is also true where ACPI is exported to userspace too.
As soon as ACPI is exported to userspace, it also becomes part of the
userspace API that the kernel provides - even if it is merely passing
through the data that it received from the firmware.
(I'm not saying that the kernel is ultimately responsible for the
contents of the blob.)
If we took the idea that the kernel receives a blob from the firmware,
and it parses it to discover whatever it needs using the appropriate
parser for that blob, and then passes the blob to userspace, then it's
pretty clear that where a platform switches between providing DT or
ACPI tables is neither here nor there, and can't cause a kernel
regression. The specification for such an API is that the kernel
provides userspace with whatever data the firmware provided it.
If we take the idea that the kernel receives a blob from the firmware,
decodes it, and then provides the decoded form to userspace, then we're
vulnerable to changes in firmware providers causing regressions for us
because they've changed the way that that information is provided to us.
That's the difference, and this is why I feel that a lack of thought has
been put into stuff like the /sys/firmware/device-tree and similar which
provides the decoded forms of the "blob". It's far too easy to export
a string or number to userspace, which then becomes part of the user API,
and which can then later become quite a headache later.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
From: Tony Lindgren <tony@atomide.com> Date: 2015-01-28 21:48:00
* Pali Roh?r [off-list ref] [150128 07:50]:
On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
quoted
* Nicolas Pitre [off-list ref] [150128 06:37]:
quoted
On Wed, 28 Jan 2015, Pali Roh?r wrote:
quoted
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
quoted
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We
could maybe pass it in the kernel cmdline to the
watchdog driver for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was
power key pressed, R&D data stored in CAL partition and
other undocumented registers for omap HS devices. I
already tried to implement at least some subset of it in
userspace (or kernel), but it is impossible because NOLO
bootloader clear status of PRM_RSTST register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten
(probably by kernel), so we really cannot implement
reading bootreason in kernel.
But in early stage in uboot it is possible to read
0x4020FFB8 address and get some part of bootreason. But
still PRM_RSTST is not enough!
I would be happy if DT kernel can export /proc/atags file
with ATAGs passed by bootloader. It would be enough for
me. In userspace I can parse content and do what is
needed.
What about defining a DT boot reason property instead?
Maybe it already exists? If not, it's something that could
certainly be generically used on other platforms too.
Converting the special ATAG into its standard DT equivalent
would then be trivial and much cleaner overall.
Sounds good to me as then we don't have to add any legacy
custom Nokia specific atag. And it won't prevent us from
adding a generic ATAG_BOOTREASON if really needed.
And what would new atag ATAG_BOOTREASON solve for Nokia N900?
Nothing.
Right, so probably no need to add it then :) But what Nico is
saying we can translate the Nokia custom bootreason to a
standard DT property if I'm reading right.
Regards,
Tony
From: Pavel Machek <hidden> Date: 2015-01-28 21:54:48
On Wed 2015-01-28 09:57:18, Rob Herring wrote:
On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre [off-list ref] wrote:
quoted
On Wed, 28 Jan 2015, Pali Roh?r wrote:
quoted
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
quoted
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We could
maybe pass it in the kernel cmdline to the watchdog driver
for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was power key
pressed, R&D data stored in CAL partition and other undocumented
registers for omap HS devices. I already tried to implement at
least some subset of it in userspace (or kernel), but it is
impossible because NOLO bootloader clear status of PRM_RSTST
register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten (probably
by kernel), so we really cannot implement reading bootreason in
kernel.
But in early stage in uboot it is possible to read 0x4020FFB8
address and get some part of bootreason. But still PRM_RSTST is
not enough!
I would be happy if DT kernel can export /proc/atags file with
ATAGs passed by bootloader. It would be enough for me. In
userspace I can parse content and do what is needed.
What about defining a DT boot reason property instead?
Maybe it already exists? If not, it's something that could certainly be
generically used on other platforms too.
I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...
On Jan 28, 2015, at 11:57 PM, Rob Herring [off-list ref] wrote:
On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre [off-list ref] wrote:
quoted
On Wed, 28 Jan 2015, Pali Roh?r wrote:
quoted
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
quoted
On omaps, the bootrom passes the bootreason in r1 to the
bootloader that can do whatever it wants with it. We could
maybe pass it in the kernel cmdline to the watchdog driver
for user space?
Not truth for N900. Bootreason depends on PRM_RSTST omap
register, state of vbat charger pins, time how long was power key
pressed, R&D data stored in CAL partition and other undocumented
registers for omap HS devices. I already tried to implement at
least some subset of it in userspace (or kernel), but it is
impossible because NOLO bootloader clear status of PRM_RSTST
register.
There is also copy of PRM_RSTST register stored at address
0x4020FFB8 (tracing data) but that address is rewritten (probably
by kernel), so we really cannot implement reading bootreason in
kernel.
But in early stage in uboot it is possible to read 0x4020FFB8
address and get some part of bootreason. But still PRM_RSTST is
not enough!
I would be happy if DT kernel can export /proc/atags file with
ATAGs passed by bootloader. It would be enough for me. In
userspace I can parse content and do what is needed.
What about defining a DT boot reason property instead?
Maybe it already exists? If not, it's something that could certainly be
generically used on other platforms too.
I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens?
but if we try to do this generic, where will you store the boot mode
I mean where the SoC boot from
useful to for the Userspace to known where is the bootloader in case of multi boot mode
Best Regards,
J.