ARM: /proc/cpuinfo: Use DT machine name when possible
diff mbox

Message ID CAL_JsqKw-C6uZBU3hccGmdofXcCcUKTV6z7Af6KwYwnZiy3HoQ@mail.gmail.com
State New
Headers show

Commit Message

Rob Herring June 18, 2014, 7:07 p.m. UTC
On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Machine name from board description is some generic name on DT kernel.
> DT provides machine name property which is specific for board, so use
> it instead generic one when possible.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  arch/arm/kernel/setup.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a16ee5..fbc7b4f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
>
>         setup_processor();
>         mdesc = setup_machine_fdt(__atags_pointer);
> -       if (!mdesc)
> +       if (mdesc)
> +               machine_name = of_flat_dt_get_machine_name();
> +       else
>                 mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
>         machine_desc = mdesc;
> -       machine_name = mdesc->name;
> +       if (!machine_name)
> +               machine_name = mdesc->name;
>
>         if (mdesc->reboot_mode != REBOOT_HARD)
>                 reboot_mode = mdesc->reboot_mode;

I did a similar patch previously[1]. Like my original patch, your
patch unconditionally changes the name which could be considered part
of the userspace ABI. It's arguably not good practice for userspace to
depend on the name, but there are likely cases that do. So I think
this needs to be optional and only use the DT name if the machine desc
name is NULL.

So something like the below and then change the machine descriptors
you care about. The default generic DT machine desc should definitely
be changed.

I had a follow-up discussion with Grant about his concerns in the
thread about knowing which machine desc used to boot. He said he was
okay if just the machine desc address is printed out.


        if (mdesc->reboot_mode != REBOOT_HARD)
                reboot_mode = mdesc->reboot_mode;


[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/208878.html

Comments

Pali Rohár June 18, 2014, 7:22 p.m. UTC | #1
On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > Machine name from board description is some generic name on
> > DT kernel. DT provides machine name property which is
> > specific for board, so use it instead generic one when
> > possible.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > 
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c
> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > **cmdline_p)
> > 
> >         setup_processor();
> >         mdesc = setup_machine_fdt(__atags_pointer);
> > 
> > -       if (!mdesc)
> > +       if (mdesc)
> > +               machine_name =
> > of_flat_dt_get_machine_name(); +       else
> > 
> >                 mdesc = setup_machine_tags(__atags_pointer,
> >                 __machine_arch_type);
> >         
> >         machine_desc = mdesc;
> > 
> > -       machine_name = mdesc->name;
> > +       if (!machine_name)
> > +               machine_name = mdesc->name;
> > 
> >         if (mdesc->reboot_mode != REBOOT_HARD)
> >         
> >                 reboot_mode = mdesc->reboot_mode;
> 
> I did a similar patch previously[1]. Like my original patch,
> your patch unconditionally changes the name which could be
> considered part of the userspace ABI. It's arguably not good
> practice for userspace to depend on the name, but there are
> likely cases that do. So I think this needs to be optional
> and only use the DT name if the machine desc name is NULL.
> 
> So something like the below and then change the machine
> descriptors you care about. The default generic DT machine
> desc should definitely be changed.
> 
> I had a follow-up discussion with Grant about his concerns in
> the thread about knowing which machine desc used to boot. He
> said he was okay if just the machine desc address is printed
> out.
> 
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 50e198c..1479250 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
>         if (!mdesc)
>                 mdesc = setup_machine_tags(__atags_pointer,
> __machine_arch_type);
>         machine_desc = mdesc;
> -       machine_name = mdesc->name;
> +       machine_name = mdesc->name ? mdesc->name :
> of_flat_dt_get_machine_name();
> 
>         if (mdesc->reboot_mode != REBOOT_HARD)
>                 reboot_mode = mdesc->reboot_mode;
> 
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No
> vember/208878.html

Hi,

now legacy board code for Nokia N900 (RX-51) is migrating to DT  
kernel and there is problem with info which /proc/cpuinfo reports

New DT kernel (3.16-rc1) reports:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Generic OMAP3 (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

But legacy board code kernel reports:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000

Basically in DT kernel is missing Hardware, Revision and probably 
also Serial key. (Now I used only qemu for testing which set 
serial key to 0). All these informations is used by userspace 
applications which determinate how to behave.

So without this patch DT migration for Nokia N900 cannot be done 
without breaking userspace - which is not acceptable...

Also I still did not know why DT kernel does not report Revision 
number which is passed by bootloader via atags. Any idea?
Russell King - ARM Linux June 18, 2014, 8 p.m. UTC | #2
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.)
Pali Rohár June 18, 2014, 8:20 p.m. UTC | #3
On Wednesday 18 June 2014 22:00:54 Russell King - ARM Linux 
wrote:
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> > 
> > Also I still did not know why DT kernel does not report
> > Revision number which is passed by bootloader via atags.
> > Any idea?
> 
> It was a concious decision by the DT people to exclude most of
> the ATAGs which provide that information.  Only memory
> information and command line ATAGs are merged into DT.  Every
> other tag is ignored (as there's no place for it in DT.)

So how to read Revision and Serial number in DT based kernel?
Rob Herring June 18, 2014, 8:46 p.m. UTC | #4
On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > Machine name from board description is some generic name on
>> > DT kernel. DT provides machine name property which is
>> > specific for board, so use it instead generic one when
>> > possible.
>> >
>> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>> > ---
>> >
>> >  arch/arm/kernel/setup.c |    7 +++++--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c
>> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -875,10 +875,13 @@ void __init setup_arch(char
>> > **cmdline_p)
>> >
>> >         setup_processor();
>> >         mdesc = setup_machine_fdt(__atags_pointer);
>> >
>> > -       if (!mdesc)
>> > +       if (mdesc)
>> > +               machine_name =
>> > of_flat_dt_get_machine_name(); +       else
>> >
>> >                 mdesc = setup_machine_tags(__atags_pointer,
>> >                 __machine_arch_type);
>> >
>> >         machine_desc = mdesc;
>> >
>> > -       machine_name = mdesc->name;
>> > +       if (!machine_name)
>> > +               machine_name = mdesc->name;
>> >
>> >         if (mdesc->reboot_mode != REBOOT_HARD)
>> >
>> >                 reboot_mode = mdesc->reboot_mode;
>>
>> I did a similar patch previously[1]. Like my original patch,
>> your patch unconditionally changes the name which could be
>> considered part of the userspace ABI. It's arguably not good
>> practice for userspace to depend on the name, but there are
>> likely cases that do. So I think this needs to be optional
>> and only use the DT name if the machine desc name is NULL.
>>
>> So something like the below and then change the machine
>> descriptors you care about. The default generic DT machine
>> desc should definitely be changed.
>>
>> I had a follow-up discussion with Grant about his concerns in
>> the thread about knowing which machine desc used to boot. He
>> said he was okay if just the machine desc address is printed
>> out.
>>
>>
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 50e198c..1479250 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
>>         if (!mdesc)
>>                 mdesc = setup_machine_tags(__atags_pointer,
>> __machine_arch_type);
>>         machine_desc = mdesc;
>> -       machine_name = mdesc->name;
>> +       machine_name = mdesc->name ? mdesc->name :
>> of_flat_dt_get_machine_name();
>>
>>         if (mdesc->reboot_mode != REBOOT_HARD)
>>                 reboot_mode = mdesc->reboot_mode;
>>
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No
>> vember/208878.html
>
> Hi,
>
> now legacy board code for Nokia N900 (RX-51) is migrating to DT
> kernel and there is problem with info which /proc/cpuinfo reports

Thanks for providing your motivation which was missing from the commit message.

>
> New DT kernel (3.16-rc1) reports:
>
> # busybox cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 3 (v7l)
> Features        : swp half thumb fastmult vfp edsp thumbee neon
> vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 3
>
> Hardware        : Generic OMAP3 (Flattened Device Tree)
> Revision        : 0000
> Serial          : 0000000000000000
>
> But legacy board code kernel reports:
>
> # busybox cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 3 (v7l)
> Features        : swp half thumb fastmult vfp edsp thumbee neon
> vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 3
>
> Hardware        : Nokia RX-51 board
> Revision        : 0012
> Serial          : 0000000000000000
>
> Basically in DT kernel is missing Hardware, Revision and probably
> also Serial key. (Now I used only qemu for testing which set
> serial key to 0). All these informations is used by userspace
> applications which determinate how to behave.

It is somewhat fragile to expect the name in the DT to match the old
name from the kernel. As your patch to n900 dts shows, we'd probably
have to update every dts file to make them match. While I think we
should work to remove this string from the kernel, userspace depending
on the DT model string is a bad idea. For example, if you had some
platform with multiple OEMs just rebranding the same base design, they
may all want to put their own model string into each product. The true
h/w id is the compatible string.

Serial number is easy. There is already a standard although not widely
used property for it with "/serial-number". You just need to wire it
up to cpuinfo.

> So without this patch DT migration for Nokia N900 cannot be done
> without breaking userspace - which is not acceptable...

I agree, but I would like to come up with something that prevents
future dependence on this string.

> Also I still did not know why DT kernel does not report Revision
> number which is passed by bootloader via atags. Any idea?

Probably because no one cared until now and revision info for every
SOC is different. I would like to see revision info set in the DT in a
standard way and remove the various SOC specific kernel
implementations.

Rob
Aaro Koskinen June 18, 2014, 9:10 p.m. UTC | #5
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.
Russell King - ARM Linux June 18, 2014, 9:47 p.m. UTC | #6
On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > Also I still did not know why DT kernel does not report Revision
> > number which is passed by bootloader via atags. Any idea?
> 
> Probably because no one cared until now and revision info for every
> SOC is different. I would like to see revision info set in the DT in a
> standard way and remove the various SOC specific kernel
> implementations.

Except... that's not what it is.  What that revision field was originally
invented for was the Netwinder to indicate the _platform_ revision.

>From what I've seen, almost everyone else sets this to zero in their
boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
it by putting the SoC revision into it at kernel boot time.  That's
not what it is supposed to be used for.

Others have already solved the problem of exporting SoC specific
information, such as SoC name, SoC revision, etc, if only people would
use it - drivers/base/soc.c.  This gives machine, family, soc_id and
SoC revision information in a standard place - it /might/ have been
a good idea if the creation of that also contained documentation for
what was expected in each of the fields, rather than leaving it
open...
Fabio Estevam June 18, 2014, 9:53 p.m. UTC | #7
On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>
> So how to read Revision and Serial number in DT based kernel?

$ cat /sys/bus/soc/devices/soc0/soc_id
i.MX6SX

$ cat /sys/bus/soc/devices/soc0/revision
1.0

$ cat /sys/bus/soc/devices/soc0/machine
Freescale i.MX6 SoloX SDB Board
Rob Herring June 18, 2014, 10:27 p.m. UTC | #8
On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > Also I still did not know why DT kernel does not report Revision
>> > number which is passed by bootloader via atags. Any idea?
>>
>> Probably because no one cared until now and revision info for every
>> SOC is different. I would like to see revision info set in the DT in a
>> standard way and remove the various SOC specific kernel
>> implementations.
>
> Except... that's not what it is.  What that revision field was originally
> invented for was the Netwinder to indicate the _platform_ revision.

Okay. DT describes the platform, so having a top-level revision in the
DT could be similar, but...

>
> From what I've seen, almost everyone else sets this to zero in their
> boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> it by putting the SoC revision into it at kernel boot time.  That's
> not what it is supposed to be used for.

it could suffer the same abuse as the ATAG.

Perhaps if Revision in cpuinfo is never going to be set for DT based
platforms, then we should remove it from cpuinfo in that case.

> Others have already solved the problem of exporting SoC specific
> information, such as SoC name, SoC revision, etc, if only people would
> use it - drivers/base/soc.c.  This gives machine, family, soc_id and
> SoC revision information in a standard place - it /might/ have been
> a good idea if the creation of that also contained documentation for
> what was expected in each of the fields, rather than leaving it
> open...

The problem with soc-device is it is optional and at the whim of the
platform to add. Adding it also causes the the platform devices to
change paths because people make the soc device the bus parent. Sysfs
paths to devices are not considered part of the ABI, but still this is
a silly reason to change the path. If we want soc-device to be used,
then it should always exist and have a default version.

Rob
Russell King - ARM Linux June 18, 2014, 11:07 p.m. UTC | #9
On Wed, Jun 18, 2014 at 05:27:16PM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> >> > Also I still did not know why DT kernel does not report Revision
> >> > number which is passed by bootloader via atags. Any idea?
> >>
> >> Probably because no one cared until now and revision info for every
> >> SOC is different. I would like to see revision info set in the DT in a
> >> standard way and remove the various SOC specific kernel
> >> implementations.
> >
> > Except... that's not what it is.  What that revision field was originally
> > invented for was the Netwinder to indicate the _platform_ revision.
> 
> Okay. DT describes the platform, so having a top-level revision in the
> DT could be similar, but...
> 
> >
> > From what I've seen, almost everyone else sets this to zero in their
> > boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> > it by putting the SoC revision into it at kernel boot time.  That's
> > not what it is supposed to be used for.
> 
> it could suffer the same abuse as the ATAG.

I think the (ab)use I mentioned above has been eliminated (it was
being used for the SoC revision).  It's worth grepping for system_rev
to find where it's used now, and it's looks like it's all platform
level.

> The problem with soc-device is it is optional and at the whim of the
> platform to add. Adding it also causes the the platform devices to
> change paths because people make the soc device the bus parent.

It's got to be optional, but anyone with a SoC should be strongly
encouraged to use it, especially when converting to DT - again, this
is probably one of those numerous "missed opportunities" since the
DT conversion fundamentally changes the names of all platform
devices in that heirarchy.

I'm tempted to say that we went through that device name change,
and as far as I saw, there was not one complaint about those devices
changing names.  So, I suspect it isn't that big a deal to encourage
SoCs to make use of this.

> Sysfs
> paths to devices are not considered part of the ABI, but still this is
> a silly reason to change the path. If we want soc-device to be used,
> then it should always exist and have a default version.

So what do we do on systems which aren't a SoC?  Make up some random
information for the SoC stuff?  That's just wrong.
Pavel Machek July 11, 2014, 7:28 p.m. UTC | #10
On Thu 2014-06-19 00:10:39, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> > So without this patch DT migration for Nokia N900 cannot be done 
> > without breaking userspace - which is not acceptable...
> 
> I guess the fact is that the Nokia N900 proprietary userspace has
> never worked properly with the mainline kernel without severe patching,
> so you cannot really talk about any regression. If you cannot fix
> those programs, you could still probably emulate the old Nokia kernel's
> /proc/cpuinfo by providing some text file and bind mounting it, no?

Actually, yes, it worked pretty well with some close-to-mainline
kernels.

And bind-mount on /proc/cpuinfo is beyond ugly, don't you think?
									Pavel
Pali Rohár Nov. 24, 2014, 10:16 p.m. UTC | #11
On Wednesday 18 June 2014 23:53:00 Fabio Estevam wrote:
> On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > So how to read Revision and Serial number in DT based
> > kernel?
> 
> $ cat /sys/bus/soc/devices/soc0/soc_id
> i.MX6SX
> 
> $ cat /sys/bus/soc/devices/soc0/revision
> 1.0
> 
> $ cat /sys/bus/soc/devices/soc0/machine
> Freescale i.MX6 SoloX SDB Board

This does *not* working with DT based boot!

$ cat /sys/bus/soc/devices/soc0/soc_id
cat: can't open '/sys/bus/soc/devices/soc0/soc_id': No such file or directory
$ cat /sys/bus/soc/devices/soc0/revision 
ES3.1
$ cat /sys/bus/soc/devices/soc0/machine 
OMAP3430/3530


Here is output from *non* DT based boot:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000


As you can see in those files are totally *different* values.
Pali Rohár Nov. 24, 2014, 10:19 p.m. UTC | #12
On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > Machine name from board description is some generic name
> >> > on DT kernel. DT provides machine name property which is
> >> > specific for board, so use it instead generic one when
> >> > possible.
> >> > 
> >> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >> > ---
> >> > 
> >> >  arch/arm/kernel/setup.c |    7 +++++--
> >> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >> > 
> >> > diff --git a/arch/arm/kernel/setup.c
> >> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -875,10 +875,13 @@ void __init setup_arch(char
> >> > **cmdline_p)
> >> > 
> >> >         setup_processor();
> >> >         mdesc = setup_machine_fdt(__atags_pointer);
> >> > 
> >> > -       if (!mdesc)
> >> > +       if (mdesc)
> >> > +               machine_name =
> >> > of_flat_dt_get_machine_name(); +       else
> >> > 
> >> >                 mdesc =
> >> >                 setup_machine_tags(__atags_pointer,
> >> >                 __machine_arch_type);
> >> >         
> >> >         machine_desc = mdesc;
> >> > 
> >> > -       machine_name = mdesc->name;
> >> > +       if (!machine_name)
> >> > +               machine_name = mdesc->name;
> >> > 
> >> >         if (mdesc->reboot_mode != REBOOT_HARD)
> >> >         
> >> >                 reboot_mode = mdesc->reboot_mode;
> >> 
> >> I did a similar patch previously[1]. Like my original
> >> patch, your patch unconditionally changes the name which
> >> could be considered part of the userspace ABI. It's
> >> arguably not good practice for userspace to depend on the
> >> name, but there are likely cases that do. So I think this
> >> needs to be optional and only use the DT name if the
> >> machine desc name is NULL.
> >> 
> >> So something like the below and then change the machine
> >> descriptors you care about. The default generic DT machine
> >> desc should definitely be changed.
> >> 
> >> I had a follow-up discussion with Grant about his concerns
> >> in the thread about knowing which machine desc used to
> >> boot. He said he was okay if just the machine desc address
> >> is printed out.
> >> 
> >> 
> >> diff --git a/arch/arm/kernel/setup.c
> >> b/arch/arm/kernel/setup.c index 50e198c..1479250 100644
> >> --- a/arch/arm/kernel/setup.c
> >> +++ b/arch/arm/kernel/setup.c
> >> @@ -887,7 +887,7 @@ void __init setup_arch(char
> >> **cmdline_p)
> >> 
> >>         if (!mdesc)
> >>         
> >>                 mdesc = setup_machine_tags(__atags_pointer,
> >> 
> >> __machine_arch_type);
> >> 
> >>         machine_desc = mdesc;
> >> 
> >> -       machine_name = mdesc->name;
> >> +       machine_name = mdesc->name ? mdesc->name :
> >> of_flat_dt_get_machine_name();
> >> 
> >>         if (mdesc->reboot_mode != REBOOT_HARD)
> >>         
> >>                 reboot_mode = mdesc->reboot_mode;
> >> 
> >> [1]
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-> >> No vember/208878.html
> > 
> > Hi,
> > 
> > now legacy board code for Nokia N900 (RX-51) is migrating to
> > DT kernel and there is problem with info which
> > /proc/cpuinfo reports
> 
> Thanks for providing your motivation which was missing from
> the commit message.
> 
> > New DT kernel (3.16-rc1) reports:
> > 
> > # busybox cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 3 (v7l)
> > Features        : swp half thumb fastmult vfp edsp thumbee
> > neon vfpv3 tls vfpd32
> > CPU implementer : 0x41
> > CPU architecture: 7
> > CPU variant     : 0x2
> > CPU part        : 0xc08
> > CPU revision    : 3
> > 
> > Hardware        : Generic OMAP3 (Flattened Device Tree)
> > Revision        : 0000
> > Serial          : 0000000000000000
> > 
> > But legacy board code kernel reports:
> > 
> > # busybox cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 3 (v7l)
> > Features        : swp half thumb fastmult vfp edsp thumbee
> > neon vfpv3 tls vfpd32
> > CPU implementer : 0x41
> > CPU architecture: 7
> > CPU variant     : 0x2
> > CPU part        : 0xc08
> > CPU revision    : 3
> > 
> > Hardware        : Nokia RX-51 board
> > Revision        : 0012
> > Serial          : 0000000000000000
> > 
> > Basically in DT kernel is missing Hardware, Revision and
> > probably also Serial key. (Now I used only qemu for testing
> > which set serial key to 0). All these informations is used
> > by userspace applications which determinate how to behave.
> 
> It is somewhat fragile to expect the name in the DT to match
> the old name from the kernel. As your patch to n900 dts
> shows, we'd probably have to update every dts file to make
> them match. While I think we should work to remove this
> string from the kernel, userspace depending on the DT model
> string is a bad idea. For example, if you had some platform
> with multiple OEMs just rebranding the same base design, they
> may all want to put their own model string into each product.
> The true h/w id is the compatible string.
> 
> Serial number is easy. There is already a standard although
> not widely used property for it with "/serial-number". You
> just need to wire it up to cpuinfo.
> 

There is no "/serial-number" property in kernel:

$ ls -l -a /sys/bus/soc/devices/soc0/
drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
-r--r--r--    1 0        0             4096 Jan  1 00:00 family
-r--r--r--    1 0        0             4096 Jan  1 00:00 machine
drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
-r--r--r--    1 0        0             4096 Jan  1 00:00 revision
lrwxrwxrwx    1 0        0                0 Jan  1 00:00 
subsystem -> ../../bus/soc
-r--r--r--    1 0        0             4096 Jan  1 00:00 type
-rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent

> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> 
> I agree, but I would like to come up with something that
> prevents future dependence on this string.
> 
> > Also I still did not know why DT kernel does not report
> > Revision number which is passed by bootloader via atags.
> > Any idea?
> 
> Probably because no one cared until now and revision info for
> every SOC is different. I would like to see revision info set
> in the DT in a standard way and remove the various SOC
> specific kernel implementations.
> 
> Rob
Pali Rohár Nov. 24, 2014, 10:21 p.m. UTC | #13
On Wednesday 18 June 2014 23:10:39 Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> 
> I guess the fact is that the Nokia N900 proprietary userspace
> has never worked properly with the mainline kernel without
> severe patching, so you cannot really talk about any
> regression. If you cannot fix those programs, you could still
> probably emulate the old Nokia kernel's /proc/cpuinfo by
> providing some text file and bind mounting it, no?
> 
> A.

Mainline kernel (with patches for missing driver) working with 
Maemo CSSU-Devel userspace. So there are regressions.

Emulation of /proc/cpuinfo is possible if somebody provides 
needed info. But I still do not know from *where* to read 
machine, serial number and hw revision.
Rob Herring Dec. 4, 2014, 12:33 a.m. UTC | #14
On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > Machine name from board description is some generic name
>> >> > on DT kernel. DT provides machine name property which is
>> >> > specific for board, so use it instead generic one when
>> >> > possible.
>> >> >

[...]

>> > Basically in DT kernel is missing Hardware, Revision and
>> > probably also Serial key. (Now I used only qemu for testing
>> > which set serial key to 0). All these informations is used
>> > by userspace applications which determinate how to behave.
>>
>> It is somewhat fragile to expect the name in the DT to match
>> the old name from the kernel. As your patch to n900 dts
>> shows, we'd probably have to update every dts file to make
>> them match. While I think we should work to remove this
>> string from the kernel, userspace depending on the DT model
>> string is a bad idea. For example, if you had some platform
>> with multiple OEMs just rebranding the same base design, they
>> may all want to put their own model string into each product.
>> The true h/w id is the compatible string.
>>
>> Serial number is easy. There is already a standard although
>> not widely used property for it with "/serial-number". You
>> just need to wire it up to cpuinfo.
>>
>
> There is no "/serial-number" property in kernel:
>
> $ ls -l -a /sys/bus/soc/devices/soc0/
> drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> -r--r--r--    1 0        0             4096 Jan  1 00:00 family
> -r--r--r--    1 0        0             4096 Jan  1 00:00 machine
> drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
> -r--r--r--    1 0        0             4096 Jan  1 00:00 revision
> lrwxrwxrwx    1 0        0                0 Jan  1 00:00
> subsystem -> ../../bus/soc
> -r--r--r--    1 0        0             4096 Jan  1 00:00 type
> -rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent

Wrong place. If you put /serial-number in your DT, then it will be in
/proc/device-tree/serial-number.

If you want to wire that up to /proc/cpuinfo, I would be fine with that.

Rob
Pali Rohár Dec. 4, 2014, 12:48 a.m. UTC | #15
On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > Machine name from board description is some generic
> >> >> > name on DT kernel. DT provides machine name property
> >> >> > which is specific for board, so use it instead
> >> >> > generic one when possible.
> 
> [...]
> 
> >> > Basically in DT kernel is missing Hardware, Revision and
> >> > probably also Serial key. (Now I used only qemu for
> >> > testing which set serial key to 0). All these
> >> > informations is used by userspace applications which
> >> > determinate how to behave.
> >> 
> >> It is somewhat fragile to expect the name in the DT to
> >> match the old name from the kernel. As your patch to n900
> >> dts shows, we'd probably have to update every dts file to
> >> make them match. While I think we should work to remove
> >> this string from the kernel, userspace depending on the DT
> >> model string is a bad idea. For example, if you had some
> >> platform with multiple OEMs just rebranding the same base
> >> design, they may all want to put their own model string
> >> into each product. The true h/w id is the compatible
> >> string.
> >> 
> >> Serial number is easy. There is already a standard although
> >> not widely used property for it with "/serial-number". You
> >> just need to wire it up to cpuinfo.
> > 
> > There is no "/serial-number" property in kernel:
> > 
> > $ ls -l -a /sys/bus/soc/devices/soc0/
> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> > family -r--r--r--    1 0        0             4096 Jan  1
> > 00:00 machine drwxr-xr-x    2 0        0                0
> > Jan  1 00:00 power -r--r--r--    1 0        0            
> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0      
> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> > type -rw-r--r--    1 0        0             4096 Jan  1
> > 00:00 uevent
> 
> Wrong place. If you put /serial-number in your DT, then it
> will be in /proc/device-tree/serial-number.
> 
> If you want to wire that up to /proc/cpuinfo, I would be fine
> with that.
> 
> Rob

I cannot hardcode it into DT, because it is set by bootloader. 
And bootloader tell it to kernel via ATAGs structure. Bootloader 
is closed and proprietary and cannot be replaced (there is no 
documentation for hw init).
Russell King - ARM Linux Dec. 4, 2014, 10:59 a.m. UTC | #16
On Wed, Dec 03, 2014 at 06:33:08PM -0600, Rob Herring wrote:
> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > There is no "/serial-number" property in kernel:
> >
> > $ ls -l -a /sys/bus/soc/devices/soc0/
> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 family
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 machine
> > drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 revision
> > lrwxrwxrwx    1 0        0                0 Jan  1 00:00
> > subsystem -> ../../bus/soc
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 type
> > -rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent
> 
> Wrong place. If you put /serial-number in your DT, then it will be in
> /proc/device-tree/serial-number.
> 
> If you want to wire that up to /proc/cpuinfo, I would be fine with that.

That would be fine for me too.  Then it's just a matter of how to copy
the contents of the ATAG into the DT (I assume it's possible in a
similar way to the memory and command line information.)  That's
something I know nothing about though.
Rob Herring Dec. 4, 2014, 4:49 p.m. UTC | #17
On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >> >
>> >> > <pali.rohar@gmail.com> wrote:
>> >> >> > Machine name from board description is some generic
>> >> >> > name on DT kernel. DT provides machine name property
>> >> >> > which is specific for board, so use it instead
>> >> >> > generic one when possible.
>>
>> [...]
>>
>> >> > Basically in DT kernel is missing Hardware, Revision and
>> >> > probably also Serial key. (Now I used only qemu for
>> >> > testing which set serial key to 0). All these
>> >> > informations is used by userspace applications which
>> >> > determinate how to behave.
>> >>
>> >> It is somewhat fragile to expect the name in the DT to
>> >> match the old name from the kernel. As your patch to n900
>> >> dts shows, we'd probably have to update every dts file to
>> >> make them match. While I think we should work to remove
>> >> this string from the kernel, userspace depending on the DT
>> >> model string is a bad idea. For example, if you had some
>> >> platform with multiple OEMs just rebranding the same base
>> >> design, they may all want to put their own model string
>> >> into each product. The true h/w id is the compatible
>> >> string.
>> >>
>> >> Serial number is easy. There is already a standard although
>> >> not widely used property for it with "/serial-number". You
>> >> just need to wire it up to cpuinfo.
>> >
>> > There is no "/serial-number" property in kernel:
>> >
>> > $ ls -l -a /sys/bus/soc/devices/soc0/
>> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
>> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
>> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> > family -r--r--r--    1 0        0             4096 Jan  1
>> > 00:00 machine drwxr-xr-x    2 0        0                0
>> > Jan  1 00:00 power -r--r--r--    1 0        0
>> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
>> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
>> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> > type -rw-r--r--    1 0        0             4096 Jan  1
>> > 00:00 uevent
>>
>> Wrong place. If you put /serial-number in your DT, then it
>> will be in /proc/device-tree/serial-number.
>>
>> If you want to wire that up to /proc/cpuinfo, I would be fine
>> with that.
>>
>> Rob
>
> I cannot hardcode it into DT, because it is set by bootloader.
> And bootloader tell it to kernel via ATAGs structure. Bootloader
> is closed and proprietary and cannot be replaced (there is no
> documentation for hw init).

Either the bootloader can put the serial number into the DTB instead
of ATAGs or the kernel decompressor can copy it from ATAGs to DTB like
is done already for other ATAGs. I presume you cannot update the
bootloader and will need the latter.

Rob
Pali Rohár Dec. 4, 2014, 5:57 p.m. UTC | #18
On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >> > 
> >> >> > <pali.rohar@gmail.com> wrote:
> >> >> >> > Machine name from board description is some generic
> >> >> >> > name on DT kernel. DT provides machine name
> >> >> >> > property which is specific for board, so use it
> >> >> >> > instead generic one when possible.
> >> 
> >> [...]
> >> 
> >> >> > Basically in DT kernel is missing Hardware, Revision
> >> >> > and probably also Serial key. (Now I used only qemu
> >> >> > for testing which set serial key to 0). All these
> >> >> > informations is used by userspace applications which
> >> >> > determinate how to behave.
> >> >> 
> >> >> It is somewhat fragile to expect the name in the DT to
> >> >> match the old name from the kernel. As your patch to
> >> >> n900 dts shows, we'd probably have to update every dts
> >> >> file to make them match. While I think we should work
> >> >> to remove this string from the kernel, userspace
> >> >> depending on the DT model string is a bad idea. For
> >> >> example, if you had some platform with multiple OEMs
> >> >> just rebranding the same base design, they may all want
> >> >> to put their own model string into each product. The
> >> >> true h/w id is the compatible string.
> >> >> 
> >> >> Serial number is easy. There is already a standard
> >> >> although not widely used property for it with
> >> >> "/serial-number". You just need to wire it up to
> >> >> cpuinfo.
> >> > 
> >> > There is no "/serial-number" property in kernel:
> >> > 
> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
> >> > . drwxr-xr-x   18 0        0                0 Jan  1
> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
> >> >  1 00:00 family -r--r--r--    1 0        0            
> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0    
> >> >            0 Jan  1 00:00 power -r--r--r--    1 0       
> >> > 0
> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
> >> > 
> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> >> > 
> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> >> > type -rw-r--r--    1 0        0             4096 Jan  1
> >> > 00:00 uevent
> >> 
> >> Wrong place. If you put /serial-number in your DT, then it
> >> will be in /proc/device-tree/serial-number.
> >> 
> >> If you want to wire that up to /proc/cpuinfo, I would be
> >> fine with that.
> >> 
> >> Rob
> > 
> > I cannot hardcode it into DT, because it is set by
> > bootloader. And bootloader tell it to kernel via ATAGs
> > structure. Bootloader is closed and proprietary and cannot
> > be replaced (there is no documentation for hw init).
> 
> Either the bootloader can put the serial number into the DTB
> instead of ATAGs or the kernel decompressor can copy it from
> ATAGs to DTB like is done already for other ATAGs. I presume
> you cannot update the bootloader and will need the latter.
> 
> Rob

Rob, thanks for info! Btw, theoretically I can update bootloader 
if someone write it. So in practise I need to use second option.

Can you tell me which CONFIG_ needs to be enabled for kernel 
decompressor (so it copy some ATAGs) and where to start looking 
at code (for adding new code for copying other ATAGs)?
Rob Herring Dec. 4, 2014, 6:10 p.m. UTC | #19
On Thu, Dec 4, 2014 at 11:57 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
>> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
>> >> >
>> >> > <pali.rohar@gmail.com> wrote:
>> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >> >> >
>> >> >> > <pali.rohar@gmail.com> wrote:
>> >> >> >> > Machine name from board description is some generic
>> >> >> >> > name on DT kernel. DT provides machine name
>> >> >> >> > property which is specific for board, so use it
>> >> >> >> > instead generic one when possible.
>> >>
>> >> [...]
>> >>
>> >> >> > Basically in DT kernel is missing Hardware, Revision
>> >> >> > and probably also Serial key. (Now I used only qemu
>> >> >> > for testing which set serial key to 0). All these
>> >> >> > informations is used by userspace applications which
>> >> >> > determinate how to behave.
>> >> >>
>> >> >> It is somewhat fragile to expect the name in the DT to
>> >> >> match the old name from the kernel. As your patch to
>> >> >> n900 dts shows, we'd probably have to update every dts
>> >> >> file to make them match. While I think we should work
>> >> >> to remove this string from the kernel, userspace
>> >> >> depending on the DT model string is a bad idea. For
>> >> >> example, if you had some platform with multiple OEMs
>> >> >> just rebranding the same base design, they may all want
>> >> >> to put their own model string into each product. The
>> >> >> true h/w id is the compatible string.
>> >> >>
>> >> >> Serial number is easy. There is already a standard
>> >> >> although not widely used property for it with
>> >> >> "/serial-number". You just need to wire it up to
>> >> >> cpuinfo.
>> >> >
>> >> > There is no "/serial-number" property in kernel:
>> >> >
>> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
>> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
>> >> > . drwxr-xr-x   18 0        0                0 Jan  1
>> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
>> >> >  1 00:00 family -r--r--r--    1 0        0
>> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0
>> >> >            0 Jan  1 00:00 power -r--r--r--    1 0
>> >> > 0
>> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
>> >> >
>> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
>> >> >
>> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> >> > type -rw-r--r--    1 0        0             4096 Jan  1
>> >> > 00:00 uevent
>> >>
>> >> Wrong place. If you put /serial-number in your DT, then it
>> >> will be in /proc/device-tree/serial-number.
>> >>
>> >> If you want to wire that up to /proc/cpuinfo, I would be
>> >> fine with that.
>> >>
>> >> Rob
>> >
>> > I cannot hardcode it into DT, because it is set by
>> > bootloader. And bootloader tell it to kernel via ATAGs
>> > structure. Bootloader is closed and proprietary and cannot
>> > be replaced (there is no documentation for hw init).
>>
>> Either the bootloader can put the serial number into the DTB
>> instead of ATAGs or the kernel decompressor can copy it from
>> ATAGs to DTB like is done already for other ATAGs. I presume
>> you cannot update the bootloader and will need the latter.
>>
>> Rob
>
> Rob, thanks for info! Btw, theoretically I can update bootloader
> if someone write it. So in practise I need to use second option.
>
> Can you tell me which CONFIG_ needs to be enabled for kernel
> decompressor (so it copy some ATAGs) and where to start looking
> at code (for adding new code for copying other ATAGs)?

See CONFIG_ARM_ATAG_DTB_COMPAT and arch/arm/boot/compressed/atags_to_fdt.c.

Rob
Pali Rohár Dec. 4, 2014, 7 p.m. UTC | #20
On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >> > 
> >> >> > <pali.rohar@gmail.com> wrote:
> >> >> >> > Machine name from board description is some generic
> >> >> >> > name on DT kernel. DT provides machine name
> >> >> >> > property which is specific for board, so use it
> >> >> >> > instead generic one when possible.
> >> 
> >> [...]
> >> 
> >> >> > Basically in DT kernel is missing Hardware, Revision
> >> >> > and probably also Serial key. (Now I used only qemu
> >> >> > for testing which set serial key to 0). All these
> >> >> > informations is used by userspace applications which
> >> >> > determinate how to behave.
> >> >> 
> >> >> It is somewhat fragile to expect the name in the DT to
> >> >> match the old name from the kernel. As your patch to
> >> >> n900 dts shows, we'd probably have to update every dts
> >> >> file to make them match. While I think we should work
> >> >> to remove this string from the kernel, userspace
> >> >> depending on the DT model string is a bad idea. For
> >> >> example, if you had some platform with multiple OEMs
> >> >> just rebranding the same base design, they may all want
> >> >> to put their own model string into each product. The
> >> >> true h/w id is the compatible string.
> >> >> 
> >> >> Serial number is easy. There is already a standard
> >> >> although not widely used property for it with
> >> >> "/serial-number". You just need to wire it up to
> >> >> cpuinfo.
> >> > 
> >> > There is no "/serial-number" property in kernel:
> >> > 
> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
> >> > . drwxr-xr-x   18 0        0                0 Jan  1
> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
> >> >  1 00:00 family -r--r--r--    1 0        0            
> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0    
> >> >            0 Jan  1 00:00 power -r--r--r--    1 0       
> >> > 0
> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
> >> > 
> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> >> > 
> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> >> > type -rw-r--r--    1 0        0             4096 Jan  1
> >> > 00:00 uevent
> >> 
> >> Wrong place. If you put /serial-number in your DT, then it
> >> will be in /proc/device-tree/serial-number.
> >> 
> >> If you want to wire that up to /proc/cpuinfo, I would be
> >> fine with that.
> >> 
> >> Rob
> > 
> > I cannot hardcode it into DT, because it is set by
> > bootloader. And bootloader tell it to kernel via ATAGs
> > structure. Bootloader is closed and proprietary and cannot
> > be replaced (there is no documentation for hw init).
> 
> Either the bootloader can put the serial number into the DTB
> instead of ATAGs or the kernel decompressor can copy it from
> ATAGs to DTB like is done already for other ATAGs. I presume
> you cannot update the bootloader and will need the latter.
> 
> Rob

And what about copying also Revision ATAG (passed by bootloader) 
to DTB (in compressed code) and then show DTB revision in 
/proc/cpuinfo file?

Would be something like this for Revision acceptable for 
upstream?

Rob, and what about exporting /proc/atags file (to userspace) 
also in DT boot if bootloader provides ATAG structure? It is 
possible? Would be something like that accepted to upstream?
Rob Herring Jan. 26, 2015, 8:22 p.m. UTC | #21
On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT
> revision property:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..9946c1b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -19,6 +19,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/smp.h>
> +#include <linux/libfdt_env.h>
>
>  #include <asm/cputype.h>
>  #include <asm/setup.h>
> @@ -26,6 +27,7 @@
>  #include <asm/smp_plat.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
> +#include <asm/system_info.h>
>
>
>  #ifdef CONFIG_SMP
> @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match)
>  const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  {
>         const struct machine_desc *mdesc, *mdesc_best = NULL;
> +       unsigned long dt_root;
> +       const u32 *prop;
>
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>         DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
>                 return NULL;
>
> +       dt_root = of_get_flat_dt_root();
>         mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
>
>         if (!mdesc) {
>                 const char *prop;
>                 int size;
> -               unsigned long dt_root;
>
>                 early_print("\nError: unrecognized/unsupported "
>                             "device tree compatible list:\n[ ");
>
> -               dt_root = of_get_flat_dt_root();
>                 prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
>                 while (size > 0) {
>                         early_print("'%s' ", prop);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         /* Change machine number to match the mdesc we're using */
>         __machine_arch_type = mdesc->nr;
>
> +       /* Set system revision from DT */
> +       prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> +       if (prop)
> +               system_rev = fdt32_to_cpu(*prop);
> +
>         return mdesc;
>  }
>
>
> And here is patch which convert ATAG revision into DT revision property and append it into DT in
> decompress code:
>
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index 9448aa0..e7e1cc9 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>                                         cpu_to_fdt32(atag->u.mem.size);
>                         }
>
> +               } else if (atag->hdr.tag == ATAG_REVISION) {
> +                       setprop_cell(fdt, "/", "revision", atag->u.revision.rev);
>                 } else if (atag->hdr.tag == ATAG_INITRD2) {
>                         uint32_t initrd_start, initrd_size;
>                         initrd_start = atag->u.initrd.start;
>
>
> I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.
>
> I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one,
> let me know what to use instead. Also you can add my Signed-off-by for both patches.

It is the correct property, but /revision in DT is a string.

You need to add your own sign-off.

Rob
Rob Herring Jan. 26, 2015, 8:33 p.m. UTC | #22
On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
>
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index e7e1cc9..1975d7c 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>          * address and size for each bank */
>         uint32_t mem_reg_property[2 * 2 * NR_BANKS];
>         int memcount = 0;
> -       int ret, memsize;
> +       int ret, memsize, atag_size;
>
>         /* make sure we've got an aligned pointer */
>         if ((u32)atag_list & 0x3)
> @@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>                 }
>         }
>
> +       /* include the terminating ATAG_NONE */
> +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
> +       setprop(fdt, "/", "atags", atag_list, atag_size);
> +
>         if (memcount) {
>                 setprop(fdt, "/memory", "reg", mem_reg_property,
>                         4 * memcount * memsize);
>
>
>
> And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:

Please properly send your patches.

> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 9946c1b..0f249a3 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -29,6 +29,7 @@
>  #include <asm/mach-types.h>
>  #include <asm/system_info.h>
>
> +#include "atags.h"
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];
> @@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         if (prop)
>                 system_rev = fdt32_to_cpu(*prop);
>
> +       /* Save atags */
> +       prop = of_get_flat_dt_prop(dt_root, "atags", NULL);
> +       if (prop)
> +               save_atags((void *)prop);
> +
>         return mdesc;
>  }
>
>
> Some userspace applications needs access to ATAG structure where can be stored some information passed
> from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
> about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
> mode or device update mode).

This goes in the commit message.

These would be non-standard fields which are not upstream. I don't
know that we care in that case...

Rob
Russell King - ARM Linux Jan. 26, 2015, 8:37 p.m. UTC | #23
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.
Pali Rohár Jan. 26, 2015, 8:44 p.m. UTC | #24
On Monday 26 January 2015 21:37:51 Russell King - ARM Linux 
wrote:
> On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Rohár wrote:
> > This patch will cause that decompressor store full ATAG
> > structure into
> 
> > DT tree ("/atags"):
> How about something a little more radical.
> 
> Rather than trying to squeeze various ATAGs into DT, why don't
> we add a standard ATAG to contain the DT and pass that
> through into the kernel. This is IMHO how we _should_ have
> done the ATAG compatibility from the start.
> 
> That means we could get rid of most of the libfdt in the
> decompressor, and instead resolve the differences in the
> kernel.

This sounds good. Now when I patched decompressor myself with 
Revision property support, I wanted to ask same question: Why to 
convert some part from ATAGs to DT instead to pass both ATAGs and 
DT to kernel?
Andreas Färber Jan. 26, 2015, 10:34 p.m. UTC | #25
Am 26.01.2015 um 20:09 schrieb Pali Rohár:
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..9946c1b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
[...]
> @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char *const **match)
>  const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  {
>  	const struct machine_desc *mdesc, *mdesc_best = NULL;
> +	unsigned long dt_root;
> +	const u32 *prop;
>  
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  	if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
>  		return NULL;
>  
> +	dt_root = of_get_flat_dt_root();
>  	mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
>  
>  	if (!mdesc) {
>  		const char *prop;

Probably the use of two differently typed variables of name "prop" in
this function is not intentional?

Regards,
Andreas

>  		int size;
> -		unsigned long dt_root;
>  
>  		early_print("\nError: unrecognized/unsupported "
>  			    "device tree compatible list:\n[ ");
>  
> -		dt_root = of_get_flat_dt_root();
>  		prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
>  		while (size > 0) {
>  			early_print("'%s' ", prop);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  	/* Change machine number to match the mdesc we're using */
>  	__machine_arch_type = mdesc->nr;
>  
> +	/* Set system revision from DT */
> +	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> +	if (prop)
> +		system_rev = fdt32_to_cpu(*prop);
> +
>  	return mdesc;
>  }
[snip]
Pavel Machek Jan. 27, 2015, 1:21 p.m. UTC | #26
On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
> >

> > +       /* include the terminating ATAG_NONE */
> > +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
> > +       setprop(fdt, "/", "atags", atag_list, atag_size);
> > +
> >         if (memcount) {
> >                 setprop(fdt, "/memory", "reg", mem_reg_property,
> >                         4 * memcount * memsize);
> >
> >
> >
> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
> 
> Please properly send your patches.

Actually, when sending patches for discussion, this is format easier
to read.

> > Some userspace applications needs access to ATAG structure where can be stored some information passed
> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
> > mode or device update mode).
> 
> This goes in the commit message.
> 
> These would be non-standard fields which are not upstream. I don't
> know that we care in that case...

Other devices are going to care about boot reason, too, and we might
as well be compatible...
									Pavel
Rob Herring Jan. 27, 2015, 2:16 p.m. UTC | #27
On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2015-01-26 14:33:21, Rob Herring wrote:
>> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
>> >
>
>> > +       /* include the terminating ATAG_NONE */
>> > +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
>> > +       setprop(fdt, "/", "atags", atag_list, atag_size);
>> > +
>> >         if (memcount) {
>> >                 setprop(fdt, "/memory", "reg", mem_reg_property,
>> >                         4 * memcount * memsize);
>> >
>> >
>> >
>> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
>>
>> Please properly send your patches.
>
> Actually, when sending patches for discussion, this is format easier
> to read.

Some people might prefer them as attachments too...

>> > Some userspace applications needs access to ATAG structure where can be stored some information passed
>> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
>> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
>> > mode or device update mode).
>>
>> This goes in the commit message.
>>
>> These would be non-standard fields which are not upstream. I don't
>> know that we care in that case...
>
> Other devices are going to care about boot reason, too, and we might
> as well be compatible...

What other devices? Where is bootreason in the list of ATAGS:

#define ATAG_MEM        0x54410002
#define ATAG_VIDEOTEXT  0x54410003
#define ATAG_RAMDISK    0x54410004
#define ATAG_INITRD     0x54410005
#define ATAG_INITRD2    0x54420005
#define ATAG_SERIAL     0x54410006
#define ATAG_REVISION   0x54410007
#define ATAG_VIDEOLFB   0x54410008
#define ATAG_CMDLINE    0x54410009
#define ATAG_ACORN      0x41000101
#define ATAG_MEMCLK     0x41000402

Rob
Pavel Machek Jan. 27, 2015, 2:24 p.m. UTC | #28
On Tue 2015-01-27 08:16:45, Rob Herring wrote:
> On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:

> >> This goes in the commit message.
> >>
> >> These would be non-standard fields which are not upstream. I don't
> >> know that we care in that case...
> >
> > Other devices are going to care about boot reason, too, and we might
> > as well be compatible...
> 
> What other devices? Where is bootreason in the list of ATAGS:
> 
> #define ATAG_MEM        0x54410002
> #define ATAG_VIDEOTEXT  0x54410003
> #define ATAG_RAMDISK    0x54410004
> #define ATAG_INITRD     0x54410005
> #define ATAG_INITRD2    0x54420005
> #define ATAG_SERIAL     0x54410006
> #define ATAG_REVISION   0x54410007
> #define ATAG_VIDEOLFB   0x54410008
> #define ATAG_CMDLINE    0x54410009
> #define ATAG_ACORN      0x41000101
> #define ATAG_MEMCLK     0x41000402

Anyone, whose charging involves userspace.

But the fact that it is needed on n900 should be enough.
								Pavel
Pali Rohár Jan. 27, 2015, 2:32 p.m. UTC | #29
On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> 
wrote:
> > On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> >> > This patch will cause that decompressor store full ATAG
> >> > structure into DT tree ("/atags"):
> >> > 
> >> > 
> >> > +       /* include the terminating ATAG_NONE */
> >> > +       atag_size = (char *)atag - (char *)atag_list +
> >> > sizeof(struct tag_header); +       setprop(fdt, "/",
> >> > "atags", atag_list, atag_size); +
> >> > 
> >> >         if (memcount) {
> >> >         
> >> >                 setprop(fdt, "/memory", "reg",
> >> >                 mem_reg_property,
> >> >                 
> >> >                         4 * memcount * memsize);
> >> > 
> >> > And this patch will export ATAG structure from DT tree 
("/atags") into /proc/atags file:
> >> Please properly send your patches.
> > 
> > Actually, when sending patches for discussion, this is
> > format easier to read.
> 
> Some people might prefer them as attachments too...
> 
> >> > Some userspace applications needs access to ATAG
> >> > structure where can be stored some information passed
> >> > from bootloader to kernel. Example is Nokia N900 device
> >> > and NOLO bootloader which provides information about
> >> > bootreason (device was started by power button or by
> >> > alarm or restarted...) and bootmode (normal mode or
> >> > device update mode).
> >> 
> >> This goes in the commit message.
> >> 
> >> These would be non-standard fields which are not upstream.
> >> I don't know that we care in that case...
> > 
> > Other devices are going to care about boot reason, too, and
> > we might as well be compatible...
> 
> What other devices? Where is bootreason in the list of ATAGS:
> 
> #define ATAG_MEM        0x54410002
> #define ATAG_VIDEOTEXT  0x54410003
> #define ATAG_RAMDISK    0x54410004
> #define ATAG_INITRD     0x54410005
> #define ATAG_INITRD2    0x54420005
> #define ATAG_SERIAL     0x54410006
> #define ATAG_REVISION   0x54410007
> #define ATAG_VIDEOLFB   0x54410008
> #define ATAG_CMDLINE    0x54410009
> #define ATAG_ACORN      0x41000101
> #define ATAG_MEMCLK     0x41000402
> 
> Rob

Each device is using own proprietary atag (or other information) 
to pass bootreason from bootloader to kernel. No standard way :-(

I think Pavel mean to introduce some standard way how *new* 
version of bootloaders can pass boot reason to kernel and how 
kernel tell it to userspace...

E.g. NOLO -- bootloader for Nokia N900 -- pass this information 
in ATAG_OMAP (0x414f4d50) and Nokia kernel exports it via procfs 
file /proc/bootreason.

Also NOLO pass some other information via ATAGs, but those are 
static and now part of n900 DT file. But bootreason is not static 
information so cannot be hardcoded into static DT file which is 
part of kernel.

I think this kind of information (how was board/computer started) 
can be useful also for other architectures. E.g. on laptop you 
would like to know if if was started by RTC, power button, 
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
And scripts can act depending on this event (when by RTC, you 
need to run some planned job, when by watchdog reset you should 
check what caused that reason...).
Russell King - ARM Linux Jan. 27, 2015, 5:48 p.m. UTC | #30
On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > What other devices? Where is bootreason in the list of ATAGS:
> > 
> > #define ATAG_MEM        0x54410002
> > #define ATAG_VIDEOTEXT  0x54410003
> > #define ATAG_RAMDISK    0x54410004
> > #define ATAG_INITRD     0x54410005
> > #define ATAG_INITRD2    0x54420005
> > #define ATAG_SERIAL     0x54410006
> > #define ATAG_REVISION   0x54410007
> > #define ATAG_VIDEOLFB   0x54410008
> > #define ATAG_CMDLINE    0x54410009
> > #define ATAG_ACORN      0x41000101
> > #define ATAG_MEMCLK     0x41000402
> > 
> > Rob
> 
> Each device is using own proprietary atag (or other information) 
> to pass bootreason from bootloader to kernel. No standard way :-(

The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people.  This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.

We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."

Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".

Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.

> I think this kind of information (how was board/computer started) 
> can be useful also for other architectures. E.g. on laptop you 
> would like to know if if was started by RTC, power button, 
> WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> And scripts can act depending on this event (when by RTC, you 
> need to run some planned job, when by watchdog reset you should 
> check what caused that reason...).

There is a standard way to get the boot information already: look at
the watchdog API:

#define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2, int)

which uses the WDIOF_* flags to indicate the last boot reason.  It
probably isn't as flexible as some may desire, but it should provide
at least the "watchdog rebooted us" vs "over temperature" vs some
other boot reason.

The other thing to consider is whether we have a way to know what
the boot reason was, and what we should do if we do not have a way
of supporting some of the boot reasons.  For example, if we have
support for RTC alarm based booting, but no way to actually tell
if the boot was caused by the RTC alarm triggering.
Nicolas Pitre Jan. 27, 2015, 7:40 p.m. UTC | #31
On Tue, 27 Jan 2015, Pavel Machek wrote:

> On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> > These would be non-standard fields which are not upstream. I don't
> > know that we care in that case...
> 
> Other devices are going to care about boot reason, too, and we might
> as well be compatible...

Care to elaborate on that statement please?  What does this have to do 
with ATAGs?


Nicolas
Nicolas Pitre Jan. 27, 2015, 8:03 p.m. UTC | #32
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > What other devices? Where is bootreason in the list of ATAGS:
> > > 
> > > #define ATAG_MEM        0x54410002
> > > #define ATAG_VIDEOTEXT  0x54410003
> > > #define ATAG_RAMDISK    0x54410004
> > > #define ATAG_INITRD     0x54410005
> > > #define ATAG_INITRD2    0x54420005
> > > #define ATAG_SERIAL     0x54410006
> > > #define ATAG_REVISION   0x54410007
> > > #define ATAG_VIDEOLFB   0x54410008
> > > #define ATAG_CMDLINE    0x54410009
> > > #define ATAG_ACORN      0x41000101
> > > #define ATAG_MEMCLK     0x41000402
> > > 
> > > Rob
> > 
> > Each device is using own proprietary atag (or other information) 
> > to pass bootreason from bootloader to kernel. No standard way :-(

So that's what Pavel was alluding to.

> The reason that happens is because people refuse to discuss their
> requirements here - just like people refuse to report userspace API
> regressions to kernel people.  This rather pisses me off, because
> it creates all sorts of horrid per-platform yuck.
> 
> We _could_ (and have in the past) turned round and refused to support
> these kinds of hacks - which IMHO is quite a reasonable stance to
> take: the message we should be sending is "if you wish to design
> new methods without discussing it with us, we reserve the right not
> to support them in mainline kernels; please discuss with us your
> requirements."
> 
> Each time that we accept one of these hacks, we're sending a message
> that says "it's okay to work in this crappy way".
> 
> Yes, I realise that the N900 has little in the way of support, and we
> can't exert that kind of back pressure (since there's no one to direct
> that onto to effect any change) so I guess we just have to live with it.

If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
user space code interpret it in some arbitrary way" then it's a complete 
abomination.

> > I think this kind of information (how was board/computer started) 
> > can be useful also for other architectures. E.g. on laptop you 
> > would like to know if if was started by RTC, power button, 
> > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > And scripts can act depending on this event (when by RTC, you 
> > need to run some planned job, when by watchdog reset you should 
> > check what caused that reason...).

Useful when properly designed and generic enough to be shared.

I'd suggest a DT property be proposed for that purpose if it doesn't 
already exist.  That at least has a chance to be generically useful.


Nicolas
Russell King - ARM Linux Jan. 27, 2015, 9:09 p.m. UTC | #33
On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > > What other devices? Where is bootreason in the list of ATAGS:
> > > > 
> > > > #define ATAG_MEM        0x54410002
> > > > #define ATAG_VIDEOTEXT  0x54410003
> > > > #define ATAG_RAMDISK    0x54410004
> > > > #define ATAG_INITRD     0x54410005
> > > > #define ATAG_INITRD2    0x54420005
> > > > #define ATAG_SERIAL     0x54410006
> > > > #define ATAG_REVISION   0x54410007
> > > > #define ATAG_VIDEOLFB   0x54410008
> > > > #define ATAG_CMDLINE    0x54410009
> > > > #define ATAG_ACORN      0x41000101
> > > > #define ATAG_MEMCLK     0x41000402
> > > > 
> > > > Rob
> > > 
> > > Each device is using own proprietary atag (or other information) 
> > > to pass bootreason from bootloader to kernel. No standard way :-(
> 
> So that's what Pavel was alluding to.
> 
> > The reason that happens is because people refuse to discuss their
> > requirements here - just like people refuse to report userspace API
> > regressions to kernel people.  This rather pisses me off, because
> > it creates all sorts of horrid per-platform yuck.
> > 
> > We _could_ (and have in the past) turned round and refused to support
> > these kinds of hacks - which IMHO is quite a reasonable stance to
> > take: the message we should be sending is "if you wish to design
> > new methods without discussing it with us, we reserve the right not
> > to support them in mainline kernels; please discuss with us your
> > requirements."
> > 
> > Each time that we accept one of these hacks, we're sending a message
> > that says "it's okay to work in this crappy way".
> > 
> > Yes, I realise that the N900 has little in the way of support, and we
> > can't exert that kind of back pressure (since there's no one to direct
> > that onto to effect any change) so I guess we just have to live with it.
> 
> If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
> user space code interpret it in some arbitrary way" then it's a complete 
> abomination.
> 
> > > I think this kind of information (how was board/computer started) 
> > > can be useful also for other architectures. E.g. on laptop you 
> > > would like to know if if was started by RTC, power button, 
> > > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > > And scripts can act depending on this event (when by RTC, you 
> > > need to run some planned job, when by watchdog reset you should 
> > > check what caused that reason...).
> 
> Useful when properly designed and generic enough to be shared.
> 
> I'd suggest a DT property be proposed for that purpose if it doesn't 
> already exist.  That at least has a chance to be generically useful.

What this means is that we have to further augment the atags-to-dt code
in the decompressor with the platform specific ATAGs to parse this
information and merge it into the appended DT before passing the
resulting DT blob to the kernel.

Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.

Or we /could/ say that mainline never supported it, and we aren't going
to add support for "new" tags to the mainline kernel.  It wouldn't be
a regression, because mainline hasn't ever supported them (that's been
said before about such things on other platforms.)

However, there's another consideration to be had here before we can say
that: how many people out there want to run a mainline (or even an
updated kernel derived from mainline) on this device?  If there's a
sizable following for the device wanting updated support, then it's
something we really need to consider supporting inspite of our
disappointment with Nokia inventing these "proprietary" tags.
Nicolas Pitre Jan. 27, 2015, 9:34 p.m. UTC | #34
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> > > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > > > What other devices? Where is bootreason in the list of ATAGS:
> > > > > 
> > > > > #define ATAG_MEM        0x54410002
> > > > > #define ATAG_VIDEOTEXT  0x54410003
> > > > > #define ATAG_RAMDISK    0x54410004
> > > > > #define ATAG_INITRD     0x54410005
> > > > > #define ATAG_INITRD2    0x54420005
> > > > > #define ATAG_SERIAL     0x54410006
> > > > > #define ATAG_REVISION   0x54410007
> > > > > #define ATAG_VIDEOLFB   0x54410008
> > > > > #define ATAG_CMDLINE    0x54410009
> > > > > #define ATAG_ACORN      0x41000101
> > > > > #define ATAG_MEMCLK     0x41000402
> > > > > 
> > > > > Rob
> > > > 
> > > > Each device is using own proprietary atag (or other information) 
> > > > to pass bootreason from bootloader to kernel. No standard way :-(
> > 
> > So that's what Pavel was alluding to.
> > 
> > > The reason that happens is because people refuse to discuss their
> > > requirements here - just like people refuse to report userspace API
> > > regressions to kernel people.  This rather pisses me off, because
> > > it creates all sorts of horrid per-platform yuck.
> > > 
> > > We _could_ (and have in the past) turned round and refused to support
> > > these kinds of hacks - which IMHO is quite a reasonable stance to
> > > take: the message we should be sending is "if you wish to design
> > > new methods without discussing it with us, we reserve the right not
> > > to support them in mainline kernels; please discuss with us your
> > > requirements."
> > > 
> > > Each time that we accept one of these hacks, we're sending a message
> > > that says "it's okay to work in this crappy way".
> > > 
> > > Yes, I realise that the N900 has little in the way of support, and we
> > > can't exert that kind of back pressure (since there's no one to direct
> > > that onto to effect any change) so I guess we just have to live with it.
> > 
> > If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
> > user space code interpret it in some arbitrary way" then it's a complete 
> > abomination.
> > 
> > > > I think this kind of information (how was board/computer started) 
> > > > can be useful also for other architectures. E.g. on laptop you 
> > > > would like to know if if was started by RTC, power button, 
> > > > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > > > And scripts can act depending on this event (when by RTC, you 
> > > > need to run some planned job, when by watchdog reset you should 
> > > > check what caused that reason...).
> > 
> > Useful when properly designed and generic enough to be shared.
> > 
> > I'd suggest a DT property be proposed for that purpose if it doesn't 
> > already exist.  That at least has a chance to be generically useful.
> 
> What this means is that we have to further augment the atags-to-dt code
> in the decompressor with the platform specific ATAGs to parse this
> information and merge it into the appended DT before passing the
> resulting DT blob to the kernel.

That would be only 2 new lines of code in the best case.

Still, I opposed such platform specific hacks in the past, suggesting 
that a separate shim be used instead, which was done successfully.

> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> and let the kernel deal with it in a much saner environment than the
> restricted decompressor environment.

... which would be a step backward in the context of the transition to 
DT we accepted.  People will have even less of an incentive to fix their 
stuff.

> Or we /could/ say that mainline never supported it, and we aren't going
> to add support for "new" tags to the mainline kernel.  It wouldn't be
> a regression, because mainline hasn't ever supported them (that's been
> said before about such things on other platforms.)

That would be my stance.

> However, there's another consideration to be had here before we can say
> that: how many people out there want to run a mainline (or even an
> updated kernel derived from mainline) on this device?  If there's a
> sizable following for the device wanting updated support, then it's
> something we really need to consider supporting inspite of our
> disappointment with Nokia inventing these "proprietary" tags.

If there is indeed a sizable following for the device then someone 
should figure out how to cope with upstream kernels, either through the 
installation of some intermediate bootloader that can talk FDT directly, 
or via a shim layer.  None of that has to be performed by nor linked 
with the kernel binary, nor maintained in the kernel tree. And it's not 
even that hard to do: we have precedents on other platforms with crappy 
bootloaders where this just works.


Nicolas
Nicolas Pitre Jan. 27, 2015, 9:58 p.m. UTC | #35
On Tue, 27 Jan 2015, Nicolas Pitre wrote:

> If there is indeed a sizable following for the device then someone 
> should figure out how to cope with upstream kernels, either through the 
> installation of some intermediate bootloader that can talk FDT directly, 
> or via a shim layer.  None of that has to be performed by nor linked 
> with the kernel binary, nor maintained in the kernel tree. And it's not 
> even that hard to do: we have precedents on other platforms with crappy 
> bootloaders where this just works.

For reference I recommend the following threads:

http://comments.gmane.org/gmane.linux.kbuild.devel/10722

http://www.spinics.net/lists/arm-kernel/msg249719.html


Nicolas
Russell King - ARM Linux Jan. 27, 2015, 10:33 p.m. UTC | #36
On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> > and let the kernel deal with it in a much saner environment than the
> > restricted decompressor environment.
> 
> ... which would be a step backward in the context of the transition to 
> DT we accepted.  People will have even less of an incentive to fix their 
> stuff.

Where's the people fixing their stuff today?  I think your position is
something of an idealist rather than a realist - the reality is that
five years down the line of DT, the platforms which have not converted
are now *never* going to convert, irrespective of how much "incentive"
we may think we should apply to the situation.

So, at some point we have to start thinking as a realist rather than
an idealist, and realise that there are platforms out there which are
/never/ going to convert.

Most of my platforms here are /never/ going to convert to DT-only
booting quite simply because they don't have anyone working on that
stuff, and no one is willing to put the effort in.

The only platforms which I have which have converted are:
- OMAP SDP4430
- Versatile Express
- SolidRun Hummingboard & Cubox-i

Quite literally everything else is *never* going to support native DT
booting - and I'd go as far as to say that if I ever wanted to put the
effort in, I probably couldn't, because the boot loader sources aren't
available anymore.  (eg, the LDP3430 situation is such a mess that even
if the boot loader source is still available, identifying the correct
board version is near on impossible given the multitude of different
variants of the same product.)

The older Versatile and Integrator platforms, for example, are going
to be booting with the appended DTB for as long as they're around.
Most likely all the PXA platforms too, and, the IOP32x based N2100
boxes (which already need their kernels wrapped because the provided
boot loader has had environment saving disabled.)

As much as you may not like it, ATAGs are here to stay now, at least
on the older platforms, and no amount of "incentives" will change that.

> > However, there's another consideration to be had here before we can say
> > that: how many people out there want to run a mainline (or even an
> > updated kernel derived from mainline) on this device?  If there's a
> > sizable following for the device wanting updated support, then it's
> > something we really need to consider supporting inspite of our
> > disappointment with Nokia inventing these "proprietary" tags.
> 
> If there is indeed a sizable following for the device then someone 
> should figure out how to cope with upstream kernels, either through the 
> installation of some intermediate bootloader that can talk FDT directly, 
> or via a shim layer.  None of that has to be performed by nor linked 
> with the kernel binary, nor maintained in the kernel tree. And it's not 
> even that hard to do: we have precedents on other platforms with crappy 
> bootloaders where this just works.

That's a rediculous position if you want something which "just works"
on as much hardware as possible, which is, after all, what the single
zImage project is all about.

To be pro single-zImage, and anti popular hardware is quite contradictory.

You only have to look at x86 for this: just because ACPI came along does
not mean that the Linux kernel started demanding that ACPI is the only
way to describe the world.  Linux continues to directly support all the
old boot protocols that it did since the days of i386, such as the e820
memory interface and doesn't convert these to an ACPI table just because
it can.
Pavel Machek Jan. 27, 2015, 11:10 p.m. UTC | #37
Hi!

> > > Useful when properly designed and generic enough to be shared.
> > > 
> > > I'd suggest a DT property be proposed for that purpose if it doesn't 
> > > already exist.  That at least has a chance to be generically useful.
> > 
> > What this means is that we have to further augment the atags-to-dt code
> > in the decompressor with the platform specific ATAGs to parse this
> > information and merge it into the appended DT before passing the
> > resulting DT blob to the kernel.
> 
> That would be only 2 new lines of code in the best case.

Yes, instead of 2 new lines of code, let people write, debug, and
flash 1000 lines shim. Completely makes sense.
									Pavel
Tony Lindgren Jan. 28, 2015, 12:50 a.m. UTC | #38
* Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 09:51]:
> 
> We _could_ (and have in the past) turned round and refused to support
> these kinds of hacks - which IMHO is quite a reasonable stance to
> take: the message we should be sending is "if you wish to design
> new methods without discussing it with us, we reserve the right not
> to support them in mainline kernels; please discuss with us your
> requirements."
> 
> Each time that we accept one of these hacks, we're sending a message
> that says "it's okay to work in this crappy way".
> 
> Yes, I realise that the N900 has little in the way of support, and we
> can't exert that kind of back pressure (since there's no one to direct
> that onto to effect any change) so I guess we just have to live with it.

I believe after N900 Nokia dropped the custom ATAGs and used the
kernel cmdline instead. And most of the n900 custom ATAGs are not
even needed any longer.

The ATAG_REVISION is a standard feature that we should support
naturally. I don't think we should add any custom ATAGs, except
maybe for the bootreason.
 
> > I think this kind of information (how was board/computer started) 
> > can be useful also for other architectures. E.g. on laptop you 
> > would like to know if if was started by RTC, power button, 
> > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > And scripts can act depending on this event (when by RTC, you 
> > need to run some planned job, when by watchdog reset you should 
> > check what caused that reason...).
> 
> There is a standard way to get the boot information already: look at
> the watchdog API:
> 
> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2, int)
> 
> which uses the WDIOF_* flags to indicate the last boot reason.  It
> probably isn't as flexible as some may desire, but it should provide
> at least the "watchdog rebooted us" vs "over temperature" vs some
> other boot reason.
> 
> The other thing to consider is whether we have a way to know what
> the boot reason was, and what we should do if we do not have a way
> of supporting some of the boot reasons.  For example, if we have
> support for RTC alarm based booting, but no way to actually tell
> if the boot was caused by the RTC alarm triggering.

On omaps, the bootrom passes the bootreason in r1 to the bootloader
that can do whatever it wants with it. We could maybe pass it
in the kernel cmdline to the watchdog driver for user space?

Of course the problem is that the signed bootloader on n900 cannot
be modified so the pass through u-boot would have to translate
the custom ATAG for bootreason into a kernel cmdline..

But it may actually make sense to add the bootreason ATAGs, it
seems quite generic to me.

AFAIK, the other n900 ATAGs can be just ignored.

Regards,

Tony
Nicolas Pitre Jan. 28, 2015, 2:07 a.m. UTC | #39
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > > Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> > > and let the kernel deal with it in a much saner environment than the
> > > restricted decompressor environment.
> > 
> > ... which would be a step backward in the context of the transition to 
> > DT we accepted.  People will have even less of an incentive to fix their 
> > stuff.
> 
> Where's the people fixing their stuff today?

At least some people in this thread are, otherwise they'd still be away 
hacking on their own.

> I think your position is something of an idealist rather than a 
> realist - the reality is that five years down the line of DT, the 
> platforms which have not converted are now *never* going to convert, 
> irrespective of how much "incentive" we may think we should apply to 
> the situation.

Don't get me wrong.  I'm not expecting those platforms to do native DT 
booting ever.  However "faking" DT booting with already proven solutions 
that don't bastardize the kernel further should be encouraged.

> > If there is indeed a sizable following for the device then someone 
> > should figure out how to cope with upstream kernels, either through the 
> > installation of some intermediate bootloader that can talk FDT directly, 
> > or via a shim layer.  None of that has to be performed by nor linked 
> > with the kernel binary, nor maintained in the kernel tree. And it's not 
> > even that hard to do: we have precedents on other platforms with crappy 
> > bootloaders where this just works.
> 
> That's a rediculous position if you want something which "just works"
> on as much hardware as possible, which is, after all, what the single
> zImage project is all about.

Agreed.

> To be pro single-zImage, and anti popular hardware is quite contradictory.

Indeed.  I'm not against popular hardware.

> You only have to look at x86 for this: just because ACPI came along does
> not mean that the Linux kernel started demanding that ACPI is the only
> way to describe the world.  Linux continues to directly support all the
> old boot protocols that it did since the days of i386, such as the e820
> memory interface and doesn't convert these to an ACPI table just because
> it can.

Booting from a floppy boot sector is no longer supported though.

But that's besides the point.  If someone needs a 5-line addition to 
atags_to_fdt.c in order to boot some old stuff then let's just do it and 
move on. I'll happily ACK the patch. The code is there and it is not 
going away soon.

However, if something more involved is needed, is platform specific and 
is likely to require about as many lines in the kernel than it would 
need in some externat shim then the shim solution should be encouraged 
instead.  After all that's why LILO, Syslinux and Grub were created on 
X86: to Supplement the crappy PC BIOS boot interface.  And if the 
hardware is popular, then finding a motivated hacker to do it shouldn't 
be too hard, right?

In other words, what prevents someone from creating, say, a custom 
minimal Barebox version that sits on top of the existing N900 
bootloader?  Wouldn't that provide a much better user experience?


Nicolas
Jean-Christophe PLAGNIOL-VILLARD Jan. 28, 2015, 6:21 a.m. UTC | #40
> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>>>> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
>>>> and let the kernel deal with it in a much saner environment than the
>>>> restricted decompressor environment.
>>> 
>>> ... which would be a step backward in the context of the transition to 
>>> DT we accepted.  People will have even less of an incentive to fix their 
>>> stuff.
>> 
>> Where's the people fixing their stuff today?
> 
> At least some people in this thread are, otherwise they'd still be away 
> hacking on their own.
> 
>> I think your position is something of an idealist rather than a 
>> realist - the reality is that five years down the line of DT, the 
>> platforms which have not converted are now *never* going to convert, 
>> irrespective of how much "incentive" we may think we should apply to 
>> the situation.
> 
> Don't get me wrong.  I'm not expecting those platforms to do native DT 
> booting ever.  However "faking" DT booting with already proven solutions 
> that don't bastardize the kernel further should be encouraged.
> 
>>> If there is indeed a sizable following for the device then someone 
>>> should figure out how to cope with upstream kernels, either through the 
>>> installation of some intermediate bootloader that can talk FDT directly, 
>>> or via a shim layer.  None of that has to be performed by nor linked 
>>> with the kernel binary, nor maintained in the kernel tree. And it's not 
>>> even that hard to do: we have precedents on other platforms with crappy 
>>> bootloaders where this just works.
>> 
>> That's a rediculous position if you want something which "just works"
>> on as much hardware as possible, which is, after all, what the single
>> zImage project is all about.
> 
> Agreed.
> 
>> To be pro single-zImage, and anti popular hardware is quite contradictory.
> 
> Indeed.  I'm not against popular hardware.
> 
>> You only have to look at x86 for this: just because ACPI came along does
>> not mean that the Linux kernel started demanding that ACPI is the only
>> way to describe the world.  Linux continues to directly support all the
>> old boot protocols that it did since the days of i386, such as the e820
>> memory interface and doesn't convert these to an ACPI table just because
>> it can.
> 
> Booting from a floppy boot sector is no longer supported though.
> 
> But that's besides the point.  If someone needs a 5-line addition to 
> atags_to_fdt.c in order to boot some old stuff then let's just do it and 
> move on. I'll happily ACK the patch. The code is there and it is not 
> going away soon.
> 
> However, if something more involved is needed, is platform specific and 
> is likely to require about as many lines in the kernel than it would 
> need in some externat shim then the shim solution should be encouraged 
> instead.  After all that's why LILO, Syslinux and Grub were created on 
> X86: to Supplement the crappy PC BIOS boot interface.  And if the 
> hardware is popular, then finding a motivated hacker to do it shouldn't 
> be too hard, right?
> 
> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone I’ll put barebox on it

Best Regards,
J.
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Pavel Machek Jan. 28, 2015, 7:18 a.m. UTC | #41
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
Pavel Machek Jan. 28, 2015, 7:19 a.m. UTC | #42
Hi!

> > In other words, what prevents someone from creating, say, a custom 
> > minimal Barebox version that sits on top of the existing N900 
> > bootloader?  Wouldn't that provide a much better user experience?
> 
> I do agree with Nicolas
> 
> If I can get my hand on a phone I’ll put barebox on it

Grab it in the nearest "second hand cellphones" shop, and have fun! It
should be less than $70.
									Pavel
Jean-Christophe PLAGNIOL-VILLARD Jan. 28, 2015, 8:06 a.m. UTC | #43
> On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote:
> 
> Hi!
> 
>>> In other words, what prevents someone from creating, say, a custom 
>>> minimal Barebox version that sits on top of the existing N900 
>>> bootloader?  Wouldn't that provide a much better user experience?
>> 
>> I do agree with Nicolas
>> 
>> If I can get my hand on a phone I’ll put barebox on it
> 
> Grab it in the nearest "second hand cellphones" shop, and have fun! It
> should be less than $70.

will see if I can found one in Shanghai at the second hand market

Does it exist a qemu emulation?

Best Regards,
J.
> 									Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek Jan. 28, 2015, 8:25 a.m. UTC | #44
On Wed 2015-01-28 16:06:17, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > Hi!
> > 
> >>> In other words, what prevents someone from creating, say, a custom 
> >>> minimal Barebox version that sits on top of the existing N900 
> >>> bootloader?  Wouldn't that provide a much better user experience?
> >> 
> >> I do agree with Nicolas
> >> 
> >> If I can get my hand on a phone I’ll put barebox on it
> > 
> > Grab it in the nearest "second hand cellphones" shop, and have fun! It
> > should be less than $70.
> 
> will see if I can found one in Shanghai at the second hand market
> 
> Does it exist a qemu emulation?

Yes, linaro-qemu supports it. (But people are trying to break it
"because it is not real hardware so it can be fixed").

									Pavel
Pali Rohár Jan. 28, 2015, 1:38 p.m. UTC | #45
On Wednesday 28 January 2015 03:07:43 Nicolas Pitre wrote:
> In other words, what prevents someone from creating, say, a
> custom minimal Barebox version that sits on top of the
> existing N900 bootloader?  Wouldn't that provide a much
> better user experience?
> 

Strong cryptography used for signing first stage bootloader, 
undocumented interface and other stuff which initialize HW and 
small memory (about 100kB) for second stage non-signed 
bootloader. Next kernel image is limited to size 2MB. And 
currently uboot can be compiled to act as "kernel" image, so 
second stage bootloader can boot it.

I spend some time to replace second (non signed) bootloader with 
something other, but really it is not possible.
Pali Rohár Jan. 28, 2015, 1:58 p.m. UTC | #46
On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 
09:51]:
> > We _could_ (and have in the past) turned round and refused
> > to support these kinds of hacks - which IMHO is quite a
> > reasonable stance to take: the message we should be sending
> > is "if you wish to design new methods without discussing it
> > with us, we reserve the right not to support them in
> > mainline kernels; please discuss with us your
> > requirements."
> > 
> > Each time that we accept one of these hacks, we're sending a
> > message that says "it's okay to work in this crappy way".
> > 
> > Yes, I realise that the N900 has little in the way of
> > support, and we can't exert that kind of back pressure
> > (since there's no one to direct that onto to effect any
> > change) so I guess we just have to live with it.
> 
> I believe after N900 Nokia dropped the custom ATAGs and used
> the kernel cmdline instead. And most of the n900 custom ATAGs
> are not even needed any longer.
> 

Yes, almost all N900 ATAGs are static and are already hardcoded 
into kernel or DT file.

Basically there are 4 non static values which are used:

1. ATAG_REVISION

2. ATAG_OMAP
2.1 OMAP_TAG_BOOT_REASON --> boot reason
2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version
2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or "update"

ATAG_OMAP is non standard and contains sub-atags.

bootloader version is static now (as Nokia does not develop it 
anymore), but boot reason and boot mode are set by bootloader and 
are needed for userspace. boot mode tells init system/userspace 
if to start normal OS or only small subset for flashing.

> The ATAG_REVISION is a standard feature that we should support
> naturally. I don't think we should add any custom ATAGs,
> except maybe for the bootreason.
> 
> > > I think this kind of information (how was board/computer
> > > started) can be useful also for other architectures. E.g.
> > > on laptop you would like to know if if was started by
> > > RTC, power button, WakeOnLan, another ACPI event,
> > > rebooted machine, watchdog, etc... And scripts can act
> > > depending on this event (when by RTC, you need to run
> > > some planned job, when by watchdog reset you should check
> > > what caused that reason...).
> > 
> > There is a standard way to get the boot information already:
> > look at the watchdog API:
> > 
> > #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
> > int)
> > 
> > which uses the WDIOF_* flags to indicate the last boot
> > reason.  It probably isn't as flexible as some may desire,
> > but it should provide at least the "watchdog rebooted us"
> > vs "over temperature" vs some other boot reason.
> > 
> > The other thing to consider is whether we have a way to know
> > what the boot reason was, and what we should do if we do
> > not have a way of supporting some of the boot reasons.  For
> > example, if we have support for RTC alarm based booting,
> > but no way to actually tell if the boot was caused by the
> > RTC alarm triggering.
> 
> On omaps, the bootrom passes the bootreason in r1 to the
> bootloader that can do whatever it wants with it. We could
> maybe pass it in the kernel cmdline to the watchdog driver
> for user space?
> 

Not truth for N900. Bootreason depends on PRM_RSTST omap 
register, state of vbat charger pins, time how long was power key 
pressed, R&D data stored in CAL partition and other undocumented 
registers for omap HS devices. I already tried to implement at 
least some subset of it in userspace (or kernel), but it is 
impossible because NOLO bootloader clear status of PRM_RSTST 
register.

There is also copy of PRM_RSTST register stored at address 
0x4020FFB8 (tracing data) but that address is rewritten (probably 
by kernel), so we really cannot implement reading bootreason in 
kernel.

But in early stage in uboot it is possible to read 0x4020FFB8 
address and get some part of bootreason. But still PRM_RSTST is 
not enough!

I would be happy if DT kernel can export /proc/atags file with 
ATAGs passed by bootloader. It would be enough for me. In 
userspace I can parse content and do what is needed.

In non DT kernel file /proc/atags is always exported.

> Of course the problem is that the signed bootloader on n900
> cannot be modified so the pass through u-boot would have to
> translate the custom ATAG for bootreason into a kernel
> cmdline..
> 
> But it may actually make sense to add the bootreason ATAGs, it
> seems quite generic to me.
> 

Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
structure? Inventing new does not solve anything because all 
developers does not boot kernel for debugging from uboot -- but 
directly.

> AFAIK, the other n900 ATAGs can be just ignored.
> 
> Regards,
> 
> Tony
Nicolas Pitre Jan. 28, 2015, 2:33 p.m. UTC | #47
On Wed, 28 Jan 2015, Pali Rohár wrote:

> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > On omaps, the bootrom passes the bootreason in r1 to the
> > bootloader that can do whatever it wants with it. We could
> > maybe pass it in the kernel cmdline to the watchdog driver
> > for user space?
> > 
> 
> Not truth for N900. Bootreason depends on PRM_RSTST omap 
> register, state of vbat charger pins, time how long was power key 
> pressed, R&D data stored in CAL partition and other undocumented 
> registers for omap HS devices. I already tried to implement at 
> least some subset of it in userspace (or kernel), but it is 
> impossible because NOLO bootloader clear status of PRM_RSTST 
> register.
> 
> There is also copy of PRM_RSTST register stored at address 
> 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> by kernel), so we really cannot implement reading bootreason in 
> kernel.
> 
> But in early stage in uboot it is possible to read 0x4020FFB8 
> address and get some part of bootreason. But still PRM_RSTST is 
> not enough!
> 
> I would be happy if DT kernel can export /proc/atags file with 
> ATAGs passed by bootloader. It would be enough for me. In 
> userspace I can parse content and do what is needed.

What about defining a DT boot reason property instead?
Maybe it already exists?  If not, it's something that could certainly be 
generically used on other platforms too.

Converting the special ATAG into its standard DT equivalent would then 
be trivial and much cleaner overall.


Nicolas
Jean-Christophe PLAGNIOL-VILLARD Jan. 28, 2015, 2:46 p.m. UTC | #48
> On Jan 28, 2015, at 9:58 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> 
> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 
> 09:51]:
>>> We _could_ (and have in the past) turned round and refused
>>> to support these kinds of hacks - which IMHO is quite a
>>> reasonable stance to take: the message we should be sending
>>> is "if you wish to design new methods without discussing it
>>> with us, we reserve the right not to support them in
>>> mainline kernels; please discuss with us your
>>> requirements."
>>> 
>>> Each time that we accept one of these hacks, we're sending a
>>> message that says "it's okay to work in this crappy way".
>>> 
>>> Yes, I realise that the N900 has little in the way of
>>> support, and we can't exert that kind of back pressure
>>> (since there's no one to direct that onto to effect any
>>> change) so I guess we just have to live with it.
>> 
>> I believe after N900 Nokia dropped the custom ATAGs and used
>> the kernel cmdline instead. And most of the n900 custom ATAGs
>> are not even needed any longer.
>> 
> 
> Yes, almost all N900 ATAGs are static and are already hardcoded 
> into kernel or DT file.
> 
> Basically there are 4 non static values which are used:
> 
> 1. ATAG_REVISION
> 
> 2. ATAG_OMAP
> 2.1 OMAP_TAG_BOOT_REASON --> boot reason

you can pass it via DT I already do it on other platform such as amineoIP
which is full DT with barebox as bootloader

> 2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version

do you really need such information in the kernel as we have a standard boot API?

> 2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or “update"

this is application specific not related to the kernel just pass it via cmdline

Best Regards,
J.
> 
> ATAG_OMAP is non standard and contains sub-atags.
> 
> bootloader version is static now (as Nokia does not develop it 
> anymore), but boot reason and boot mode are set by bootloader and 
> are needed for userspace. boot mode tells init system/userspace 
> if to start normal OS or only small subset for flashing.
> 
>> The ATAG_REVISION is a standard feature that we should support
>> naturally. I don't think we should add any custom ATAGs,
>> except maybe for the bootreason.
>> 
>>>> I think this kind of information (how was board/computer
>>>> started) can be useful also for other architectures. E.g.
>>>> on laptop you would like to know if if was started by
>>>> RTC, power button, WakeOnLan, another ACPI event,
>>>> rebooted machine, watchdog, etc... And scripts can act
>>>> depending on this event (when by RTC, you need to run
>>>> some planned job, when by watchdog reset you should check
>>>> what caused that reason...).
>>> 
>>> There is a standard way to get the boot information already:
>>> look at the watchdog API:
>>> 
>>> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
>>> int)
>>> 
>>> which uses the WDIOF_* flags to indicate the last boot
>>> reason.  It probably isn't as flexible as some may desire,
>>> but it should provide at least the "watchdog rebooted us"
>>> vs "over temperature" vs some other boot reason.
>>> 
>>> The other thing to consider is whether we have a way to know
>>> what the boot reason was, and what we should do if we do
>>> not have a way of supporting some of the boot reasons.  For
>>> example, if we have support for RTC alarm based booting,
>>> but no way to actually tell if the boot was caused by the
>>> RTC alarm triggering.
>> 
>> On omaps, the bootrom passes the bootreason in r1 to the
>> bootloader that can do whatever it wants with it. We could
>> maybe pass it in the kernel cmdline to the watchdog driver
>> for user space?
>> 
> 
> Not truth for N900. Bootreason depends on PRM_RSTST omap 
> register, state of vbat charger pins, time how long was power key 
> pressed, R&D data stored in CAL partition and other undocumented 
> registers for omap HS devices. I already tried to implement at 
> least some subset of it in userspace (or kernel), but it is 
> impossible because NOLO bootloader clear status of PRM_RSTST 
> register.
> 
> There is also copy of PRM_RSTST register stored at address 
> 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> by kernel), so we really cannot implement reading bootreason in 
> kernel.
> 
> But in early stage in uboot it is possible to read 0x4020FFB8 
> address and get some part of bootreason. But still PRM_RSTST is 
> not enough!
> 
> I would be happy if DT kernel can export /proc/atags file with 
> ATAGs passed by bootloader. It would be enough for me. In 
> userspace I can parse content and do what is needed.
> 
> In non DT kernel file /proc/atags is always exported.
> 
>> Of course the problem is that the signed bootloader on n900
>> cannot be modified so the pass through u-boot would have to
>> translate the custom ATAG for bootreason into a kernel
>> cmdline..
>> 
>> But it may actually make sense to add the bootreason ATAGs, it
>> seems quite generic to me.
>> 
> 
> Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
> structure? Inventing new does not solve anything because all 
> developers does not boot kernel for debugging from uboot -- but 
> directly.
> 
>> AFAIK, the other n900 ATAGs can be just ignored.
>> 
>> Regards,
>> 
>> Tony
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Tony Lindgren Jan. 28, 2015, 3:39 p.m. UTC | #49
* Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> On Wed, 28 Jan 2015, Pali Rohár wrote:
> 
> > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > On omaps, the bootrom passes the bootreason in r1 to the
> > > bootloader that can do whatever it wants with it. We could
> > > maybe pass it in the kernel cmdline to the watchdog driver
> > > for user space?
> > > 
> > 
> > Not truth for N900. Bootreason depends on PRM_RSTST omap 
> > register, state of vbat charger pins, time how long was power key 
> > pressed, R&D data stored in CAL partition and other undocumented 
> > registers for omap HS devices. I already tried to implement at 
> > least some subset of it in userspace (or kernel), but it is 
> > impossible because NOLO bootloader clear status of PRM_RSTST 
> > register.
> > 
> > There is also copy of PRM_RSTST register stored at address 
> > 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> > by kernel), so we really cannot implement reading bootreason in 
> > kernel.
> > 
> > But in early stage in uboot it is possible to read 0x4020FFB8 
> > address and get some part of bootreason. But still PRM_RSTST is 
> > not enough!
> > 
> > I would be happy if DT kernel can export /proc/atags file with 
> > ATAGs passed by bootloader. It would be enough for me. In 
> > userspace I can parse content and do what is needed.
> 
> What about defining a DT boot reason property instead?
> Maybe it already exists?  If not, it's something that could certainly be 
> generically used on other platforms too.
> 
> Converting the special ATAG into its standard DT equivalent would then 
> be trivial and much cleaner overall.

Sounds good to me as then we don't have to add any legacy custom
Nokia specific atag. And it won't prevent us from adding a generic
ATAG_BOOTREASON if really needed.

Regards,

Tony
Pali Rohár Jan. 28, 2015, 3:47 p.m. UTC | #50
On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> > On Wed, 28 Jan 2015, Pali Rohár wrote:
> > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > > On omaps, the bootrom passes the bootreason in r1 to the
> > > > bootloader that can do whatever it wants with it. We
> > > > could maybe pass it in the kernel cmdline to the
> > > > watchdog driver for user space?
> > > 
> > > Not truth for N900. Bootreason depends on PRM_RSTST omap
> > > register, state of vbat charger pins, time how long was
> > > power key pressed, R&D data stored in CAL partition and
> > > other undocumented registers for omap HS devices. I
> > > already tried to implement at least some subset of it in
> > > userspace (or kernel), but it is impossible because NOLO
> > > bootloader clear status of PRM_RSTST register.
> > > 
> > > There is also copy of PRM_RSTST register stored at address
> > > 0x4020FFB8 (tracing data) but that address is rewritten
> > > (probably by kernel), so we really cannot implement
> > > reading bootreason in kernel.
> > > 
> > > But in early stage in uboot it is possible to read
> > > 0x4020FFB8 address and get some part of bootreason. But
> > > still PRM_RSTST is not enough!
> > > 
> > > I would be happy if DT kernel can export /proc/atags file
> > > with ATAGs passed by bootloader. It would be enough for
> > > me. In userspace I can parse content and do what is
> > > needed.
> > 
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could
> > certainly be generically used on other platforms too.
> > 
> > Converting the special ATAG into its standard DT equivalent
> > would then be trivial and much cleaner overall.
> 
> Sounds good to me as then we don't have to add any legacy
> custom Nokia specific atag. And it won't prevent us from
> adding a generic ATAG_BOOTREASON if really needed.
> 
> Regards,
> 
> Tony

And what would new atag ATAG_BOOTREASON solve for Nokia N900? 
Nothing.
Tony Lindgren Jan. 28, 2015, 3:48 p.m. UTC | #51
* Pali Rohár <pali.rohar@gmail.com> [150128 07:50]:
> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> > > On Wed, 28 Jan 2015, Pali Rohár wrote:
> > > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > > > On omaps, the bootrom passes the bootreason in r1 to the
> > > > > bootloader that can do whatever it wants with it. We
> > > > > could maybe pass it in the kernel cmdline to the
> > > > > watchdog driver for user space?
> > > > 
> > > > Not truth for N900. Bootreason depends on PRM_RSTST omap
> > > > register, state of vbat charger pins, time how long was
> > > > power key pressed, R&D data stored in CAL partition and
> > > > other undocumented registers for omap HS devices. I
> > > > already tried to implement at least some subset of it in
> > > > userspace (or kernel), but it is impossible because NOLO
> > > > bootloader clear status of PRM_RSTST register.
> > > > 
> > > > There is also copy of PRM_RSTST register stored at address
> > > > 0x4020FFB8 (tracing data) but that address is rewritten
> > > > (probably by kernel), so we really cannot implement
> > > > reading bootreason in kernel.
> > > > 
> > > > But in early stage in uboot it is possible to read
> > > > 0x4020FFB8 address and get some part of bootreason. But
> > > > still PRM_RSTST is not enough!
> > > > 
> > > > I would be happy if DT kernel can export /proc/atags file
> > > > with ATAGs passed by bootloader. It would be enough for
> > > > me. In userspace I can parse content and do what is
> > > > needed.
> > > 
> > > What about defining a DT boot reason property instead?
> > > Maybe it already exists?  If not, it's something that could
> > > certainly be generically used on other platforms too.
> > > 
> > > Converting the special ATAG into its standard DT equivalent
> > > would then be trivial and much cleaner overall.
> > 
> > Sounds good to me as then we don't have to add any legacy
> > custom Nokia specific atag. And it won't prevent us from
> > adding a generic ATAG_BOOTREASON if really needed.
> 
> And what would new atag ATAG_BOOTREASON solve for Nokia N900? 
> Nothing.

Right, so probably no need to add it then :) But what Nico is
saying we can translate the Nokia custom bootreason to a
standard DT property if I'm reading right.

Regards,

Tony
Rob Herring Jan. 28, 2015, 3:57 p.m. UTC | #52
On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 28 Jan 2015, Pali Rohár wrote:
>
>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> > On omaps, the bootrom passes the bootreason in r1 to the
>> > bootloader that can do whatever it wants with it. We could
>> > maybe pass it in the kernel cmdline to the watchdog driver
>> > for user space?
>> >
>>
>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>> register, state of vbat charger pins, time how long was power key
>> pressed, R&D data stored in CAL partition and other undocumented
>> registers for omap HS devices. I already tried to implement at
>> least some subset of it in userspace (or kernel), but it is
>> impossible because NOLO bootloader clear status of PRM_RSTST
>> register.
>>
>> There is also copy of PRM_RSTST register stored at address
>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>> by kernel), so we really cannot implement reading bootreason in
>> kernel.
>>
>> But in early stage in uboot it is possible to read 0x4020FFB8
>> address and get some part of bootreason. But still PRM_RSTST is
>> not enough!
>>
>> I would be happy if DT kernel can export /proc/atags file with
>> ATAGs passed by bootloader. It would be enough for me. In
>> userspace I can parse content and do what is needed.
>
> What about defining a DT boot reason property instead?
> Maybe it already exists?  If not, it's something that could certainly be
> generically used on other platforms too.

I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...

Rob
Russell King - ARM Linux Jan. 28, 2015, 4:13 p.m. UTC | #53
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.
Will Deacon Jan. 28, 2015, 4:19 p.m. UTC | #54
On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > I'm fine with that, but we just need to have a standard kernel
> > userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps this can be the default
> > implementation for the watchdog dev. Someday when we decide DT is crap
> > and have a new boot interface, we'll have people relying on
> > /proc/device-tree. I hope to be retired when that happens...
> 
> Anyone who thinks that DT can be replaced in the same way that we made
> the mistake with ATAGs would really need their head examined.
> 
> As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> Whether we like it or not, that is a userspace API, one which we have
> users of already.  That pretty much means that we can't remove DT for
> existing platforms or any platform we have now converted to DT.

<ok, I'll go there!>

... and for platforms that can also be booted via ACPI? If we have to
convert the ACPI tables into a device-tree purely for /proc/device-tree,
then we may as well boot with the thing too :)

Seriously though, I don't see how we can maintain this directory for
ACPI, regardless of whether or not it's ABI.

Will
Jason Cooper Jan. 28, 2015, 4:31 p.m. UTC | #55
On 1/28/15 10:48 AM, Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@gmail.com> [150128 07:50]:
>> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
>>> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
>>>> On Wed, 28 Jan 2015, Pali Rohár wrote:
>>>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>>>>>> On omaps, the bootrom passes the bootreason in r1 to the
>>>>>> bootloader that can do whatever it wants with it. We
>>>>>> could maybe pass it in the kernel cmdline to the
>>>>>> watchdog driver for user space?
>>>>>
>>>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>>>> register, state of vbat charger pins, time how long was
>>>>> power key pressed, R&D data stored in CAL partition and
>>>>> other undocumented registers for omap HS devices. I
>>>>> already tried to implement at least some subset of it in
>>>>> userspace (or kernel), but it is impossible because NOLO
>>>>> bootloader clear status of PRM_RSTST register.
>>>>>
>>>>> There is also copy of PRM_RSTST register stored at address
>>>>> 0x4020FFB8 (tracing data) but that address is rewritten
>>>>> (probably by kernel), so we really cannot implement
>>>>> reading bootreason in kernel.
>>>>>
>>>>> But in early stage in uboot it is possible to read
>>>>> 0x4020FFB8 address and get some part of bootreason. But
>>>>> still PRM_RSTST is not enough!
>>>>>
>>>>> I would be happy if DT kernel can export /proc/atags file
>>>>> with ATAGs passed by bootloader. It would be enough for
>>>>> me. In userspace I can parse content and do what is
>>>>> needed.
>>>>
>>>> What about defining a DT boot reason property instead?
>>>> Maybe it already exists?  If not, it's something that could
>>>> certainly be generically used on other platforms too.
>>>>
>>>> Converting the special ATAG into its standard DT equivalent
>>>> would then be trivial and much cleaner overall.
>>>
>>> Sounds good to me as then we don't have to add any legacy
>>> custom Nokia specific atag. And it won't prevent us from
>>> adding a generic ATAG_BOOTREASON if really needed.
>>
>> And what would new atag ATAG_BOOTREASON solve for Nokia N900?
>> Nothing.
>
> Right, so probably no need to add it then :) But what Nico is
> saying we can translate the Nokia custom bootreason to a
> standard DT property if I'm reading right.

Well, it's mostly been forgotten now, but the pxa-impedance-matcher 
could do the proprietary ATAGS -> standard DT conversion before booting 
the kernel.

   https://github.com/zonque/pxa-impedance-matcher.git

Don't let the 'pxa' fool you, it's grown (slightly) beyond it's original 
purpose.

We augmented it to facilitate booting DT kernels from legacy bootloaders 
to prevent polluting the kernel with random vendor ATAG crap.

Ping me or Daniel Mack if you have any questions.

hth,

Jason.
Russell King - ARM Linux Jan. 28, 2015, 5:01 p.m. UTC | #56
On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

Welcome to the problem that exporting information to userspace creates.
The same problem is also true where ACPI is exported to userspace too.
As soon as ACPI is exported to userspace, it also becomes part of the
userspace API that the kernel provides - even if it is merely passing
through the data that it received from the firmware.

(I'm not saying that the kernel is ultimately responsible for the
contents of the blob.)

If we took the idea that the kernel receives a blob from the firmware,
and it parses it to discover whatever it needs using the appropriate
parser for that blob, and then passes the blob to userspace, then it's
pretty clear that where a platform switches between providing DT or
ACPI tables is neither here nor there, and can't cause a kernel
regression.  The specification for such an API is that the kernel
provides userspace with whatever data the firmware provided it.

If we take the idea that the kernel receives a blob from the firmware,
decodes it, and then provides the decoded form to userspace, then we're
vulnerable to changes in firmware providers causing regressions for us
because they've changed the way that that information is provided to us.

That's the difference, and this is why I feel that a lack of thought has
been put into stuff like the /sys/firmware/device-tree and similar which
provides the decoded forms of the "blob".  It's far too easy to export
a string or number to userspace, which then becomes part of the user API,
and which can then later become quite a headache later.
Pali Rohár Jan. 28, 2015, 5:18 p.m. UTC | #57
On Wednesday 28 January 2015 16:57:18 Rob Herring wrote:
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@fluxnic.net> wrote:
> > On Wed, 28 Jan 2015, Pali Rohár wrote:
> >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >> > On omaps, the bootrom passes the bootreason in r1 to the
> >> > bootloader that can do whatever it wants with it. We
> >> > could maybe pass it in the kernel cmdline to the
> >> > watchdog driver for user space?
> >> 
> >> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >> register, state of vbat charger pins, time how long was
> >> power key pressed, R&D data stored in CAL partition and
> >> other undocumented registers for omap HS devices. I
> >> already tried to implement at least some subset of it in
> >> userspace (or kernel), but it is impossible because NOLO
> >> bootloader clear status of PRM_RSTST register.
> >> 
> >> There is also copy of PRM_RSTST register stored at address
> >> 0x4020FFB8 (tracing data) but that address is rewritten
> >> (probably by kernel), so we really cannot implement
> >> reading bootreason in kernel.
> >> 
> >> But in early stage in uboot it is possible to read
> >> 0x4020FFB8 address and get some part of bootreason. But
> >> still PRM_RSTST is not enough!
> >> 
> >> I would be happy if DT kernel can export /proc/atags file
> >> with ATAGs passed by bootloader. It would be enough for
> >> me. In userspace I can parse content and do what is
> >> needed.
> > 
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could
> > certainly be generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT
> is crap and have a new boot interface, we'll have people
> relying on /proc/device-tree. I hope to be retired when that
> happens...
> 
> Rob

Then what about exporting bootreason as /proc/bootreason?
Russell King - ARM Linux Jan. 28, 2015, 5:29 p.m. UTC | #58
On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

And if it needs stating more clearly, you have just shown why adding
a boot reason to devicetree is the wrong thing to do.

Let's say that we do decide to convert the boot reason atag to a device
tree property.  As soon as we do that, it appears in the /proc/device-tree
sub-tree, whether we like it or not, because that sub-tree exports
*everything* mentioned in the DT blob.

So, as soon as we put anything into the DT blob, it immediately becomes
part of the kernel's userspace API, whether we like it or not.  That
means it becomes available for userspace to start (ab)using - again,
whether or not we provide a saner firmware independent interface.

The more we mess around converting crap from one firmware interface to
another, the more problems we're creating for ourselves.  We really
need to re-think our approach to this, and stop this religous "DT is
everything, we must convert everything to DT."
Jean-Christophe PLAGNIOL-VILLARD Jan. 28, 2015, 6 p.m. UTC | #59
> On Jan 28, 2015, at 11:57 PM, Rob Herring <robherring2@gmail.com> wrote:
> 
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Wed, 28 Jan 2015, Pali Rohár wrote:
>> 
>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>>>> On omaps, the bootrom passes the bootreason in r1 to the
>>>> bootloader that can do whatever it wants with it. We could
>>>> maybe pass it in the kernel cmdline to the watchdog driver
>>>> for user space?
>>>> 
>>> 
>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>> register, state of vbat charger pins, time how long was power key
>>> pressed, R&D data stored in CAL partition and other undocumented
>>> registers for omap HS devices. I already tried to implement at
>>> least some subset of it in userspace (or kernel), but it is
>>> impossible because NOLO bootloader clear status of PRM_RSTST
>>> register.
>>> 
>>> There is also copy of PRM_RSTST register stored at address
>>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>>> by kernel), so we really cannot implement reading bootreason in
>>> kernel.
>>> 
>>> But in early stage in uboot it is possible to read 0x4020FFB8
>>> address and get some part of bootreason. But still PRM_RSTST is
>>> not enough!
>>> 
>>> I would be happy if DT kernel can export /proc/atags file with
>>> ATAGs passed by bootloader. It would be enough for me. In
>>> userspace I can parse content and do what is needed.
>> 
>> What about defining a DT boot reason property instead?
>> Maybe it already exists?  If not, it's something that could certainly be
>> generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens…

but if we try to do this generic, where will you store the boot mode

I mean where the SoC boot from

useful to for the Userspace to known where is the bootloader in case of multi boot mode

Best Regards,
J.
> 
> Rob
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Pavel Machek Jan. 28, 2015, 6:03 p.m. UTC | #60
On Wed 2015-01-28 09:57:18, Rob Herring wrote:
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Wed, 28 Jan 2015, Pali Rohár wrote:
> >
> >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >> > On omaps, the bootrom passes the bootreason in r1 to the
> >> > bootloader that can do whatever it wants with it. We could
> >> > maybe pass it in the kernel cmdline to the watchdog driver
> >> > for user space?
> >> >
> >>
> >> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >> register, state of vbat charger pins, time how long was power key
> >> pressed, R&D data stored in CAL partition and other undocumented
> >> registers for omap HS devices. I already tried to implement at
> >> least some subset of it in userspace (or kernel), but it is
> >> impossible because NOLO bootloader clear status of PRM_RSTST
> >> register.
> >>
> >> There is also copy of PRM_RSTST register stored at address
> >> 0x4020FFB8 (tracing data) but that address is rewritten (probably
> >> by kernel), so we really cannot implement reading bootreason in
> >> kernel.
> >>
> >> But in early stage in uboot it is possible to read 0x4020FFB8
> >> address and get some part of bootreason. But still PRM_RSTST is
> >> not enough!
> >>
> >> I would be happy if DT kernel can export /proc/atags file with
> >> ATAGs passed by bootloader. It would be enough for me. In
> >> userspace I can parse content and do what is needed.
> >
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could certainly be
> > generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens...

Huh. Who thought putting device-tree into /proc was good idea? That
should have gone to /sys, as it is not process related...

Anyway, bootreason does not depend on device-tree, so it should not be
in device-tree specific subdirectory.
									Pavel
Arnd Bergmann Jan. 28, 2015, 7:27 p.m. UTC | #61
On Wednesday 28 January 2015 19:03:22 Pavel Machek wrote:
> > /proc/device-tree. I hope to be retired when that happens...
> 
> Huh. Who thought putting device-tree into /proc was good idea? That
> should have gone to /sys, as it is not process related...
> 

I think /proc/device-tree predates sysfs by about six years. These
days, it is a symlink to /sys/firmware/devicetree/base.

	Arnd
Pali Rohár Jan. 28, 2015, 7:33 p.m. UTC | #62
On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL-
VILLARD wrote:
> > On Jan 28, 2015, at 11:57 PM, Rob Herring
> > <robherring2@gmail.com> wrote:
> > 
> > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@fluxnic.net> wrote:
> >> On Wed, 28 Jan 2015, Pali Rohár wrote:
> >>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >>>> On omaps, the bootrom passes the bootreason in r1 to the
> >>>> bootloader that can do whatever it wants with it. We
> >>>> could maybe pass it in the kernel cmdline to the
> >>>> watchdog driver for user space?
> >>> 
> >>> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >>> register, state of vbat charger pins, time how long was
> >>> power key pressed, R&D data stored in CAL partition and
> >>> other undocumented registers for omap HS devices. I
> >>> already tried to implement at least some subset of it in
> >>> userspace (or kernel), but it is impossible because NOLO
> >>> bootloader clear status of PRM_RSTST register.
> >>> 
> >>> There is also copy of PRM_RSTST register stored at address
> >>> 0x4020FFB8 (tracing data) but that address is rewritten
> >>> (probably by kernel), so we really cannot implement
> >>> reading bootreason in kernel.
> >>> 
> >>> But in early stage in uboot it is possible to read
> >>> 0x4020FFB8 address and get some part of bootreason. But
> >>> still PRM_RSTST is not enough!
> >>> 
> >>> I would be happy if DT kernel can export /proc/atags file
> >>> with ATAGs passed by bootloader. It would be enough for
> >>> me. In userspace I can parse content and do what is
> >>> needed.
> >> 
> >> What about defining a DT boot reason property instead?
> >> Maybe it already exists?  If not, it's something that could
> >> certainly be generically used on other platforms too.
> > 
> > I'm fine with that, but we just need to have a standard
> > kernel userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps this can be the
> > default implementation for the watchdog dev. Someday when
> > we decide DT is crap and have a new boot interface, we'll
> > have people relying on /proc/device-tree. I hope to be
> > retired when that happens…
> 
> but if we try to do this generic, where will you store the
> boot mode
> 
> I mean where the SoC boot from
> 
> useful to for the Userspace to known where is the bootloader
> in case of multi boot mode
> 
> Best Regards,
> J.
> 
> > Rob
> > 

I think in this discussion we are mixing two parts which should 
be designed & solved separately.

1) How should bootloader tell to kernel what is bootreason

2) How should kernel export bootreason to userspace

In modern x86 laptop world bootreason can be requested from 
BIOS/WMI/firmware by special proprietary vendor specific command.

So we should not lock bootreason to DT or ATAG only. Or only 
bootloader --> kernel transition. For other platforms, board or 
even architectures (x86) there can runtime way (for kernel) how 
to read bootreason...
Pali Rohár Jan. 30, 2015, 2:14 p.m. UTC | #63
On Monday 26 January 2015 21:22:27 Rob Herring wrote:
> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > Ok, here is patch which set Revision field (global variable
> > system_rev) in /proc/cpuinfo from DT revision property:
> > 
> > diff --git a/arch/arm/kernel/devtree.c
> > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -19,6 +19,7 @@
> > 
> >  #include <linux/of_irq.h>
> >  #include <linux/of_platform.h>
> >  #include <linux/smp.h>
> > 
> > +#include <linux/libfdt_env.h>
> > 
> >  #include <asm/cputype.h>
> >  #include <asm/setup.h>
> > 
> > @@ -26,6 +27,7 @@
> > 
> >  #include <asm/smp_plat.h>
> >  #include <asm/mach/arch.h>
> >  #include <asm/mach-types.h>
> > 
> > +#include <asm/system_info.h>
> > 
> >  #ifdef CONFIG_SMP
> > 
> > @@ -204,6 +206,8 @@ static const void * __init
> > arch_get_next_mach(const char *const **match)
> > 
> >  const struct machine_desc * __init
> >  setup_machine_fdt(unsigned int dt_phys) {
> >  
> >         const struct machine_desc *mdesc, *mdesc_best =
> >         NULL;
> > 
> > +       unsigned long dt_root;
> > +       const u32 *prop;
> > 
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  
> >         DT_MACHINE_START(GENERIC_DT, "Generic DT based
> >         system")
> > 
> > @@ -215,17 +219,16 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >         if (!dt_phys ||
> >         !early_init_dt_verify(phys_to_virt(dt_phys)))
> >         
> >                 return NULL;
> > 
> > +       dt_root = of_get_flat_dt_root();
> > 
> >         mdesc = of_flat_dt_match_machine(mdesc_best,
> >         arch_get_next_mach);
> >         
> >         if (!mdesc) {
> >         
> >                 const char *prop;
> >                 int size;
> > 
> > -               unsigned long dt_root;
> > 
> >                 early_print("\nError:
> >                 unrecognized/unsupported "
> >                 
> >                             "device tree compatible list:\n[
> >                             ");
> > 
> > -               dt_root = of_get_flat_dt_root();
> > 
> >                 prop = of_get_flat_dt_prop(dt_root,
> >                 "compatible", &size); while (size > 0) {
> >                 
> >                         early_print("'%s' ", prop);
> > 
> > @@ -246,5 +249,10 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >         /* Change machine number to match the mdesc we're
> >         using */ __machine_arch_type = mdesc->nr;
> > 
> > +       /* Set system revision from DT */
> > +       prop = of_get_flat_dt_prop(dt_root, "revision",
> > NULL); +       if (prop)
> > +               system_rev = fdt32_to_cpu(*prop);
> > +
> > 
> >         return mdesc;
> >  
> >  }
> > 
> > And here is patch which convert ATAG revision into DT
> > revision property and append it into DT in decompress code:
> > 
> > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c
> > b/arch/arm/boot/compressed/atags_to_fdt.c index
> > 9448aa0..e7e1cc9 100644
> > --- a/arch/arm/boot/compressed/atags_to_fdt.c
> > +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void
> > *fdt, int total_space)
> > 
> >                                         cpu_to_fdt32(atag->u
> >                                         .mem.size);
> >                         
> >                         }
> > 
> > +               } else if (atag->hdr.tag == ATAG_REVISION) {
> > +                       setprop_cell(fdt, "/", "revision",
> > atag->u.revision.rev);
> > 
> >                 } else if (atag->hdr.tag == ATAG_INITRD2) {
> >                 
> >                         uint32_t initrd_start, initrd_size;
> >                         initrd_start = atag->u.initrd.start;
> > 
> > I tested it on DT booted Nokia N900 and it is working, in
> > /proc/cpuinfo is revision from ATAG.
> > 
> > I do not know which DT property to use for storing HW
> > Revision, so if "/revision" is not correct one, let me know
> > what to use instead. Also you can add my Signed-off-by for
> > both patches.
> 
> It is the correct property, but /revision in DT is a string.
> 
> You need to add your own sign-off.
> 
> Rob

Any documentation which says that /revision is string?

If it is really string, how to store ATAG_REVISON (number) to 
string? dec or hex?
Rob Herring Jan. 30, 2015, 9:03 p.m. UTC | #64
lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Monday 26 January 2015 21:22:27 Rob Herring wrote:
>> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > Ok, here is patch which set Revision field (global variable
>> > system_rev) in /proc/cpuinfo from DT revision property:

[...]

>> > I do not know which DT property to use for storing HW
>> > Revision, so if "/revision" is not correct one, let me know
>> > what to use instead. Also you can add my Signed-off-by for
>> > both patches.
>>
>> It is the correct property, but /revision in DT is a string.
>>
>> You need to add your own sign-off.
>>
>> Rob
>
> Any documentation which says that /revision is string?

Sorry, I was confusing this with serial-number, so I guess a number is
fine here.

> If it is really string, how to store ATAG_REVISON (number) to
> string? dec or hex?

However /proc/cpuinfo displays it would be fine if you stay with a string.

Rob
Pali Rohár Feb. 27, 2015, 3:45 p.m. UTC | #65
On Friday 30 January 2015 22:03:36 Rob Herring wrote:
> lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Monday 26 January 2015 21:22:27 Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > Ok, here is patch which set Revision field (global
> >> > variable
> 
> >> > system_rev) in /proc/cpuinfo from DT revision property:
> [...]
> 
> >> > I do not know which DT property to use for storing HW
> >> > Revision, so if "/revision" is not correct one, let me
> >> > know what to use instead. Also you can add my
> >> > Signed-off-by for both patches.
> >> 
> >> It is the correct property, but /revision in DT is a
> >> string.
> >> 
> >> You need to add your own sign-off.
> >> 
> >> Rob
> > 
> > Any documentation which says that /revision is string?
> 
> Sorry, I was confusing this with serial-number, so I guess a
> number is fine here.
> 
> > If it is really string, how to store ATAG_REVISON (number)
> > to string? dec or hex?
> 
> However /proc/cpuinfo displays it would be fine if you stay
> with a string.
> 
> Rob

I will send new patch which will store number value as string. So 
same output will be in /proc/cpuinfo and in DT /revision.
Pali Rohár Feb. 27, 2015, 3:55 p.m. UTC | #66
This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.

Pali Rohár (2):
  arm: devtree: Set system_rev from DT revision
  arm: boot: convert ATAG_REVISION to DT revision field

 arch/arm/boot/compressed/atags_to_fdt.c |   37 +++++++++++++++++++++++++++++++
 arch/arm/kernel/devtree.c               |   20 ++++++++++++-----
 2 files changed, 52 insertions(+), 5 deletions(-)
Pali Rohár Feb. 27, 2015, 3:56 p.m. UTC | #67
On Monday 26 January 2015 23:34:34 Andreas Färber wrote:
> Am 26.01.2015 um 20:09 schrieb Pali Rohár:
> > diff --git a/arch/arm/kernel/devtree.c
> > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> 
> [...]
> 
> > @@ -204,6 +206,8 @@ static const void * __init
> > arch_get_next_mach(const char *const **match)
> > 
> >  const struct machine_desc * __init
> >  setup_machine_fdt(unsigned int dt_phys) {
> >  
> >  	const struct machine_desc *mdesc, *mdesc_best = NULL;
> > 
> > +	unsigned long dt_root;
> > +	const u32 *prop;
> > 
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  
> >  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> > 
> > @@ -215,17 +219,16 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >  	if (!dt_phys ||
> >  	!early_init_dt_verify(phys_to_virt(dt_phys)))
> >  	
> >  		return NULL;
> > 
> > +	dt_root = of_get_flat_dt_root();
> > 
> >  	mdesc = of_flat_dt_match_machine(mdesc_best,
> >  	arch_get_next_mach);
> >  	
> >  	if (!mdesc) {
> >  	
> >  		const char *prop;
> 
> Probably the use of two differently typed variables of name
> "prop" in this function is not intentional?
> 

Fixed in PATCH v2.

> Regards,
> Andreas
> 
> >  		int size;
> > 
> > -		unsigned long dt_root;
> > 
> >  		early_print("\nError: unrecognized/unsupported "
> >  		
> >  			    "device tree compatible list:\n[ ");
> > 
> > -		dt_root = of_get_flat_dt_root();
> > 
> >  		prop = of_get_flat_dt_prop(dt_root, "compatible", 
&size);
> >  		while (size > 0) {
> >  		
> >  			early_print("'%s' ", prop);
> > 
> > @@ -246,5 +249,10 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >  	/* Change machine number to match the mdesc we're using */
> >  	__machine_arch_type = mdesc->nr;
> > 
> > +	/* Set system revision from DT */
> > +	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> > +	if (prop)
> > +		system_rev = fdt32_to_cpu(*prop);
> > +
> > 
> >  	return mdesc;
> >  
> >  }
> 
> [snip]
Pavel Machek March 2, 2015, 11:28 a.m. UTC | #68
On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> 
> Pali Rohár (2):
>   arm: devtree: Set system_rev from DT revision
>   arm: boot: convert ATAG_REVISION to DT revision field

Acked-by: Pavel Machek <pavel@ucw.cz>
Tony Lindgren March 16, 2015, 3:44 p.m. UTC | #69
* Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > 
> > Pali Rohár (2):
> >   arm: devtree: Set system_rev from DT revision
> >   arm: boot: convert ATAG_REVISION to DT revision field
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>

Are these queued somewhere now? Sounds like this is the last pending
issue for n900 to use legacy user space with current mainline kernels,
so I'd like to get these in so we can get closer to making omap3 boot
in device tree only mode.

Regards,

Tony
Russell King - ARM Linux March 16, 2015, 4:14 p.m. UTC | #70
On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > 
> > > Pali Rohár (2):
> > >   arm: devtree: Set system_rev from DT revision
> > >   arm: boot: convert ATAG_REVISION to DT revision field
> > 
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> Are these queued somewhere now? Sounds like this is the last pending
> issue for n900 to use legacy user space with current mainline kernels,
> so I'd like to get these in so we can get closer to making omap3 boot
> in device tree only mode.

Not that I know of.  As everyone is aware, patches need to be in my
patch system if they want me to apply them - which would've been
especially important as I was away from kernel stuff for a week at
the start of March (for medical reasons) and I can't be expected to
track the status of stuff which is buried behind 1000+ extra mails.

In any case, I'm currently not accepting /any/ patches into my tree at
present; I'm chasing a horrid instability on one of my test platforms
which is making it impossible to tell whether any particular change or
changes in my tree is responsible or not for it.  It doesn't seem to be
a hardware failure (if it was, I'd simply take the board out of the
nightly test system.)

It's quite literally taking hours to figure out what's going on - I've
been on this for about 12 hours now and still not much closer to knowing
what's causing it (other than I know that -rc1 plus my queue seems to be
fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
something I'm already carrying seems to be responsible, but each time I
identify a particular patch and drop _just_ that change, I find that the
problem is back when I try my queue minus the bad changes.  With a test
cycle time of 20+ minutes (due to the number of boots required to make
certain of a dependable result), this is /really/ slow progress.

Right now, I can't be positively sure that /anything/ I have already
merged isn't a factor in causing this problem, so I don't want to
augment my tree with any additional patches which would upset my
ability to move about in the tree, and get reproducable results from
repeated testing.  To merge something else will probably mean I'll
have to start again from the beginning and the last 12 hours spent
testing will have been wasted.

Sorry.
Nicolas Pitre March 16, 2015, 4:43 p.m. UTC | #71
On Mon, 16 Mar 2015, Russell King - ARM Linux wrote:

> In any case, I'm currently not accepting /any/ patches into my tree at
> present; I'm chasing a horrid instability on one of my test platforms
> which is making it impossible to tell whether any particular change or
> changes in my tree is responsible or not for it.  It doesn't seem to be
> a hardware failure (if it was, I'd simply take the board out of the
> nightly test system.)
> 
> It's quite literally taking hours to figure out what's going on - I've
> been on this for about 12 hours now and still not much closer to knowing
> what's causing it (other than I know that -rc1 plus my queue seems to be
> fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
> something I'm already carrying seems to be responsible, but each time I
> identify a particular patch and drop _just_ that change, I find that the
> problem is back when I try my queue minus the bad changes.  With a test
> cycle time of 20+ minutes (due to the number of boots required to make
> certain of a dependable result), this is /really/ slow progress.
> 
> Right now, I can't be positively sure that /anything/ I have already
> merged isn't a factor in causing this problem, so I don't want to
> augment my tree with any additional patches which would upset my
> ability to move about in the tree, and get reproducable results from
> repeated testing.  To merge something else will probably mean I'll
> have to start again from the beginning and the last 12 hours spent
> testing will have been wasted.

Your publicly visible tree contains only a few mundane patches.
Is that the tree you're testing with?  If no then could you publish it 
for others to have a look and test?


Nicolas
Tony Lindgren March 16, 2015, 6:10 p.m. UTC | #72
* Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]:
> On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > > 
> > > > Pali Rohár (2):
> > > >   arm: devtree: Set system_rev from DT revision
> > > >   arm: boot: convert ATAG_REVISION to DT revision field
> > > 
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > 
> > Are these queued somewhere now? Sounds like this is the last pending
> > issue for n900 to use legacy user space with current mainline kernels,
> > so I'd like to get these in so we can get closer to making omap3 boot
> > in device tree only mode.
> 
> Not that I know of.  As everyone is aware, patches need to be in my
> patch system if they want me to apply them - which would've been
> especially important as I was away from kernel stuff for a week at
> the start of March (for medical reasons) and I can't be expected to
> track the status of stuff which is buried behind 1000+ extra mails.

Pali, care to upload these two patches to Russell's patch tracking
system if no other comments?
 
> In any case, I'm currently not accepting /any/ patches into my tree at
> present; I'm chasing a horrid instability on one of my test platforms
> which is making it impossible to tell whether any particular change or
> changes in my tree is responsible or not for it.  It doesn't seem to be
> a hardware failure (if it was, I'd simply take the board out of the
> nightly test system.)
> 
> It's quite literally taking hours to figure out what's going on - I've
> been on this for about 12 hours now and still not much closer to knowing
> what's causing it (other than I know that -rc1 plus my queue seems to be
> fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
> something I'm already carrying seems to be responsible, but each time I
> identify a particular patch and drop _just_ that change, I find that the
> problem is back when I try my queue minus the bad changes.  With a test
> cycle time of 20+ minutes (due to the number of boots required to make
> certain of a dependable result), this is /really/ slow progress.
> 
> Right now, I can't be positively sure that /anything/ I have already
> merged isn't a factor in causing this problem, so I don't want to
> augment my tree with any additional patches which would upset my
> ability to move about in the tree, and get reproducable results from
> repeated testing.  To merge something else will probably mean I'll
> have to start again from the beginning and the last 12 hours spent
> testing will have been wasted.

Oh debugging those things sucks. Maybe try with CONFIG_DEBUG_SLAB to
see if you trigger any poison.

Regards,

Tony
Russell King - ARM Linux March 16, 2015, 7:21 p.m. UTC | #73
On Mon, Mar 16, 2015 at 12:43:47PM -0400, Nicolas Pitre wrote:
> Your publicly visible tree contains only a few mundane patches.
> Is that the tree you're testing with?  If no then could you publish it 
> for others to have a look and test?

Okay, having investigated three cases of this, ended up mostly at
dead-ends, and having talked to Will, I think the conclusion is that
no one really understands what's going on here. :p

A number of people (including people within ARM) have seen the problem
that I've seen with a variety of kernel versions, including versions
which I haven't seen a problem with.

My own investigations turn up patches which don't have that much to do
with the SMP booting itself: yes, one was a L2C patch, but I've had
that for a very long time.  The FIQ changes for the GIC which shouldn't
have affected it.  Olof's MMC patches to support resets and regulators
which we don't even get to, so couldn't affect it /code-wise/.

What all these have in common is an influence on the layout of the
kernel image.  Exactly what that is, I don't know yet - I've not had
the time to be able to investigate that deeply as I've been trying to
characterise the failure and track it down to an easy "this works,
this doesn't" test case.  I now have that with a kernel without MMC
changes vs a kernel with MMC changes - where I know that the actual
changes have nothing to do with the problem itself.

There's only one person (not me) who has been able to get a reasonable
amount of debug so far - Sudeep (@arm) has found that both CPU0 and CPU1
are stuck in the radix code, but merely using the debugger "frees" them
from there.

Now that I'm aware that _others_ are or have seen the same issue I am,
I can worry slightly less about the issue... and what it confirms to
me is that it's less about what the kernel code is, more about the
placement of kernel code.

The unfortunate side effect is that it cuts down on the amount of useful
testing I can do prior to sending stuff to Linus... but C'est la vie.
Russell King - ARM Linux March 16, 2015, 7:59 p.m. UTC | #74
On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]:
> > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > > > 
> > > > > Pali Rohár (2):
> > > > >   arm: devtree: Set system_rev from DT revision
> > > > >   arm: boot: convert ATAG_REVISION to DT revision field
> > > > 
> > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > 
> > > Are these queued somewhere now? Sounds like this is the last pending
> > > issue for n900 to use legacy user space with current mainline kernels,
> > > so I'd like to get these in so we can get closer to making omap3 boot
> > > in device tree only mode.
> > 
> > Not that I know of.  As everyone is aware, patches need to be in my
> > patch system if they want me to apply them - which would've been
> > especially important as I was away from kernel stuff for a week at
> > the start of March (for medical reasons) and I can't be expected to
> > track the status of stuff which is buried behind 1000+ extra mails.
> 
> Pali, care to upload these two patches to Russell's patch tracking
> system if no other comments?

If it's done soon, I should be able to send them to Linus fairly quickly,
since this problem I'm grappling with is being seen by others who have
better tools to be able to investigate the problem (and hence they're in
a better position to investigate what's going on.)
Pali Rohár March 16, 2015, 8:54 p.m. UTC | #75
On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote:
> On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316
> > 09:15]:
> > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren
> > > wrote:
> > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > > > This patch adds support for DT "/revision" and
> > > > > > convert ATAG_REVISION to DT.
> > > > > > 
> > > > > > Pali Rohár (2):
> > > > > >   arm: devtree: Set system_rev from DT revision
> > > > > >   arm: boot: convert ATAG_REVISION to DT revision
> > > > > >   field
> > > > > 
> > > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > 
> > > > Are these queued somewhere now? Sounds like this is the
> > > > last pending issue for n900 to use legacy user space
> > > > with current mainline kernels, so I'd like to get these
> > > > in so we can get closer to making omap3 boot in device
> > > > tree only mode.
> > > 
> > > Not that I know of.  As everyone is aware, patches need to
> > > be in my patch system if they want me to apply them -
> > > which would've been especially important as I was away
> > > from kernel stuff for a week at the start of March (for
> > > medical reasons) and I can't be expected to track the
> > > status of stuff which is buried behind 1000+ extra mails.
> > 
> > Pali, care to upload these two patches to Russell's patch
> > tracking system if no other comments?
> 
> If it's done soon, I should be able to send them to Linus
> fairly quickly, since this problem I'm grappling with is
> being seen by others who have better tools to be able to
> investigate the problem (and hence they're in a better
> position to investigate what's going on.)

I have no idea how to upload those patches into tracking system. 
Right now I do not have enough time for testing any patches...

Tony, or somebody else, if you have free time, can you upload 
(my) patches to that needed tracking system?
Tony Lindgren March 16, 2015, 8:59 p.m. UTC | #76
* Pali Rohár <pali.rohar@gmail.com> [150316 13:54]:
> On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote:
> > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316
> > > 09:15]:
> > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren
> > > > wrote:
> > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > > > > This patch adds support for DT "/revision" and
> > > > > > > convert ATAG_REVISION to DT.
> > > > > > > 
> > > > > > > Pali Rohár (2):
> > > > > > >   arm: devtree: Set system_rev from DT revision
> > > > > > >   arm: boot: convert ATAG_REVISION to DT revision
> > > > > > >   field
> > > > > > 
> > > > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > > 
> > > > > Are these queued somewhere now? Sounds like this is the
> > > > > last pending issue for n900 to use legacy user space
> > > > > with current mainline kernels, so I'd like to get these
> > > > > in so we can get closer to making omap3 boot in device
> > > > > tree only mode.
> > > > 
> > > > Not that I know of.  As everyone is aware, patches need to
> > > > be in my patch system if they want me to apply them -
> > > > which would've been especially important as I was away
> > > > from kernel stuff for a week at the start of March (for
> > > > medical reasons) and I can't be expected to track the
> > > > status of stuff which is buried behind 1000+ extra mails.
> > > 
> > > Pali, care to upload these two patches to Russell's patch
> > > tracking system if no other comments?
> > 
> > If it's done soon, I should be able to send them to Linus
> > fairly quickly, since this problem I'm grappling with is
> > being seen by others who have better tools to be able to
> > investigate the problem (and hence they're in a better
> > position to investigate what's going on.)
> 
> I have no idea how to upload those patches into tracking system. 
> Right now I do not have enough time for testing any patches...

Well it's pretty easy, all you have to do is upload them to:

http://www.arm.linux.org.uk/developer/patches/

There's an email interface it too.
 
> Tony, or somebody else, if you have free time, can you upload 
> (my) patches to that needed tracking system?

Eeek, I'm swamped too, probably best that you do it yourself
since they're your patches.

Regards,

Tony

Patch
diff mbox

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 50e198c..1479250 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -887,7 +887,7 @@  void __init setup_arch(char **cmdline_p)
        if (!mdesc)
                mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
        machine_desc = mdesc;
-       machine_name = mdesc->name;
+       machine_name = mdesc->name ? mdesc->name :
of_flat_dt_get_machine_name();