All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Pavel Machek <pavel@ucw.cz>, Aaro Koskinen <aaro.koskinen@iki.fi>,
	linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Date: Thu, 4 Dec 2014 19:34:03 +0100	[thread overview]
Message-ID: <201412041934.03384@pali> (raw)
In-Reply-To: <20141128222424.GX2817@atomide.com>

[-- Attachment #1: Type: Text/Plain, Size: 5605 bytes --]

On Friday 28 November 2014 23:24:26 Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@gmail.com> [141128 13:43]:
> > On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> > > Are you saying there are some issues with that?
> > 
> > uboot (in mode when is loaded from NOLO) has those issues:
> > 
> > 1) uboot cannot read n900 onenand mtd (uboot onenand driver
> > not working, do not know why)
> > 2) missing support for battery charging (can totally
> > discharge battery)
> > 3) missing support for panel panel (so sometimes screen is
> > totally black until kernel is booted and loaded own drivers)
> > 4) limit for storing both uboot and kernel into MTD is
> > limited by 2MB (size of kernel nand partition)
> > 
> > Basically you can use uboot if you accept all above issues.
> > 
> > But there are people (Pavel CCed) who prefer to work without
> > uboot when testing kernel. So it is not good idea to lock
> > new kernel versions to depends on new uboot version.
> 
> OK thanks for the update, I was not aware of the issues above.
> 
> > > Are there other ATAGs needed beyond the ATAG_REVISION?
> > 
> > Sorry for longer email. I will provide some more info about
> > it. First I will describe that informations are passed from
> > NOLO to kernel. Note that all those informations are passed
> > also from uboot to kernel (uboot just reuse non static data
> > from NOLO). Then I will describe that we need in userspace.
> 
> > Here are all ATAGs from NOLO:
> ...
> 
> These we should not need, it's all coming from the .dts files.
> 
> > 0036 - 0003:54410007 ATAG REVISION revision=00002204
> > 
> >        0588 - 000c:4f80 BOOTREASON:   pwr_key
> >        0604 - 0018:4f82 VERSION:      product      = RX-51
> >        0632 - 0018:4f82 VERSION:      hw-build     = 2204
> >        0660 - 0018:4f82 VERSION:      nolo         = 1.4.14
> >        0688 - 0018:4f82 VERSION:      boot-mode    = normal
> 
> Seems like these are the ones we should somehow get. The
> others should be coming in the .dts file already, or can be
> deciphered based on the above in the kernel.
> 
> > ATAG MEM is generated by NOLO and also uboot at runtime. But
> > we have hardcoded memory values in n900 DT file. Maybe we
> > should use those generated by uboot bootloader (or reuse
> > uboot code for generating) instead using hardcoded one?
> 
> Yes we should not need ATAG MEM.
> 
> > ATAG REVISION is that which is magically generated by NOLO
> > and which we want to reuse. Better would be understand how
> > and why it NOLO generate (maybe there is something secret
> > register which can tell it?). But I was not able to find
> > out it.
> 
> I would assume that's also somewhere in the cal area.
> 
> > OMAP table is one big ATAG structure which contains lot of
> > other values. Basically all values (except uart, bootreason
> > and version) are static and on all n900 devices are same.
> > 
> > Partitions are generated by NOLO from CAL (/dev/mtd1) data,
> > but I think nobody ever changed them (but it is possible!).
> 
> AFAIK it's safe to assume they are coming in the .dts file.
> 
> > Uart is enabled when serial console is enabled via NOLO.
> 
> We can keep the UART enabled all the time no problem. It's
> timeouts just need to be configured for idle.
> 
> > Bootreason contains omap3 bootreason value from special
> > register (plus magic from NOLO) which is cleared
> > automatically by NOLO (so no way to read it from kernel).
> > 
> > Version contains some key-value data. Product is always
> > RX-51, hw-build is same as ATAG REVISION, nolo is nolo
> > version and value for boot-mode is ether normal or update.
> 
> OK
> 
> > What we need in userspace:
> > 
> > In file /proc/cpuinfo:
> > Hardware        : Nokia RX-51 board
> > Revision        : <hw_revision_number>
> > 
> > And in any file and any format (does not matter if text,
> > binary, whatever...) we need value from bootreason,
> > boot-mode (and maybe nolo version).
> 
> OK
> 
> > Current maemo applications are using files /proc/bootreason
> > (for bootreason) and /proc/component_version (for all
> > version) which are specific for Nokia 2.6.28 kernel. All
> > those applications (which reading ether bootreason or
> > bootmode proc files) are either shell scripts or open
> > source, so editing them is possible. I will start fixing
> > them once there will be *stable* ABI for those data.
> > 
> > With non DT (legacy) boot all above atags are present in
> > binary file /proc/atags.
> > 
> > But because DT boot does not provide /proc/atags file I need
> > some interface how to read above needed strings.
> > 
> > So I would like to know what is possible and how?
> 
> How about patch things so we see /proc/atags also for DT based
> booting, but in a way where the ATAGs don't do anything?
> 
> > Does kernel provide some interface for telling userspace
> > applications something like bootreason (e.g power key,
> > software reset, rtc alarm, charger connected, ...)?
> 
> I don't think we have anything like that currently.
> 
> Regards,
> 
> Tony

Hi Tony,

see last mail in thread (I CCed you):
"[PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible"

There is already some layer for converting ATAGs to DTB and it is 
in decompresser: arch/arm/boot/compressed/atags_to_fdt.c

I do not know if it can help us to provide /proc/cpuinfo and 
/proc/atags in DT boot, but at least this this transfer cmdline 
and mem ATAGs to DBT.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: pali.rohar@gmail.com (Pali Rohár)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Date: Thu, 4 Dec 2014 19:34:03 +0100	[thread overview]
Message-ID: <201412041934.03384@pali> (raw)
In-Reply-To: <20141128222424.GX2817@atomide.com>

On Friday 28 November 2014 23:24:26 Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [141128 13:43]:
> > On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
> > > Are you saying there are some issues with that?
> > 
> > uboot (in mode when is loaded from NOLO) has those issues:
> > 
> > 1) uboot cannot read n900 onenand mtd (uboot onenand driver
> > not working, do not know why)
> > 2) missing support for battery charging (can totally
> > discharge battery)
> > 3) missing support for panel panel (so sometimes screen is
> > totally black until kernel is booted and loaded own drivers)
> > 4) limit for storing both uboot and kernel into MTD is
> > limited by 2MB (size of kernel nand partition)
> > 
> > Basically you can use uboot if you accept all above issues.
> > 
> > But there are people (Pavel CCed) who prefer to work without
> > uboot when testing kernel. So it is not good idea to lock
> > new kernel versions to depends on new uboot version.
> 
> OK thanks for the update, I was not aware of the issues above.
> 
> > > Are there other ATAGs needed beyond the ATAG_REVISION?
> > 
> > Sorry for longer email. I will provide some more info about
> > it. First I will describe that informations are passed from
> > NOLO to kernel. Note that all those informations are passed
> > also from uboot to kernel (uboot just reuse non static data
> > from NOLO). Then I will describe that we need in userspace.
> 
> > Here are all ATAGs from NOLO:
> ...
> 
> These we should not need, it's all coming from the .dts files.
> 
> > 0036 - 0003:54410007 ATAG REVISION revision=00002204
> > 
> >        0588 - 000c:4f80 BOOTREASON:   pwr_key
> >        0604 - 0018:4f82 VERSION:      product      = RX-51
> >        0632 - 0018:4f82 VERSION:      hw-build     = 2204
> >        0660 - 0018:4f82 VERSION:      nolo         = 1.4.14
> >        0688 - 0018:4f82 VERSION:      boot-mode    = normal
> 
> Seems like these are the ones we should somehow get. The
> others should be coming in the .dts file already, or can be
> deciphered based on the above in the kernel.
> 
> > ATAG MEM is generated by NOLO and also uboot at runtime. But
> > we have hardcoded memory values in n900 DT file. Maybe we
> > should use those generated by uboot bootloader (or reuse
> > uboot code for generating) instead using hardcoded one?
> 
> Yes we should not need ATAG MEM.
> 
> > ATAG REVISION is that which is magically generated by NOLO
> > and which we want to reuse. Better would be understand how
> > and why it NOLO generate (maybe there is something secret
> > register which can tell it?). But I was not able to find
> > out it.
> 
> I would assume that's also somewhere in the cal area.
> 
> > OMAP table is one big ATAG structure which contains lot of
> > other values. Basically all values (except uart, bootreason
> > and version) are static and on all n900 devices are same.
> > 
> > Partitions are generated by NOLO from CAL (/dev/mtd1) data,
> > but I think nobody ever changed them (but it is possible!).
> 
> AFAIK it's safe to assume they are coming in the .dts file.
> 
> > Uart is enabled when serial console is enabled via NOLO.
> 
> We can keep the UART enabled all the time no problem. It's
> timeouts just need to be configured for idle.
> 
> > Bootreason contains omap3 bootreason value from special
> > register (plus magic from NOLO) which is cleared
> > automatically by NOLO (so no way to read it from kernel).
> > 
> > Version contains some key-value data. Product is always
> > RX-51, hw-build is same as ATAG REVISION, nolo is nolo
> > version and value for boot-mode is ether normal or update.
> 
> OK
> 
> > What we need in userspace:
> > 
> > In file /proc/cpuinfo:
> > Hardware        : Nokia RX-51 board
> > Revision        : <hw_revision_number>
> > 
> > And in any file and any format (does not matter if text,
> > binary, whatever...) we need value from bootreason,
> > boot-mode (and maybe nolo version).
> 
> OK
> 
> > Current maemo applications are using files /proc/bootreason
> > (for bootreason) and /proc/component_version (for all
> > version) which are specific for Nokia 2.6.28 kernel. All
> > those applications (which reading ether bootreason or
> > bootmode proc files) are either shell scripts or open
> > source, so editing them is possible. I will start fixing
> > them once there will be *stable* ABI for those data.
> > 
> > With non DT (legacy) boot all above atags are present in
> > binary file /proc/atags.
> > 
> > But because DT boot does not provide /proc/atags file I need
> > some interface how to read above needed strings.
> > 
> > So I would like to know what is possible and how?
> 
> How about patch things so we see /proc/atags also for DT based
> booting, but in a way where the ATAGs don't do anything?
> 
> > Does kernel provide some interface for telling userspace
> > applications something like bootreason (e.g power key,
> > software reset, rtc alarm, charger connected, ...)?
> 
> I don't think we have anything like that currently.
> 
> Regards,
> 
> Tony

Hi Tony,

see last mail in thread (I CCed you):
"[PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible"

There is already some layer for converting ATAGs to DTB and it is 
in decompresser: arch/arm/boot/compressed/atags_to_fdt.c

I do not know if it can help us to provide /proc/cpuinfo and 
/proc/atags in DT boot, but at least this this transfer cmdline 
and mem ATAGs to DBT.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/980c7f52/attachment-0001.sig>

  parent reply	other threads:[~2014-12-04 18:34 UTC|newest]

Thread overview: 95+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27 20:00 [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode Tony Lindgren
2014-10-27 20:00 ` Tony Lindgren
2014-10-27 23:01 ` Aaro Koskinen
2014-10-27 23:01   ` Aaro Koskinen
2014-10-28 22:12   ` Tony Lindgren
2014-10-28 22:12     ` Tony Lindgren
2014-10-29 13:43     ` Nishanth Menon
2014-10-29 13:43       ` Nishanth Menon
2014-10-29 18:59       ` Sebastian Reichel
2014-10-29 18:59         ` Sebastian Reichel
2014-10-29 19:39         ` Tony Lindgren
2014-10-29 19:39           ` Tony Lindgren
2014-10-29 21:45           ` Nishanth Menon
2014-10-29 21:45             ` Nishanth Menon
2014-10-29 22:15             ` Tony Lindgren
2014-10-29 22:15               ` Tony Lindgren
2014-10-29 22:31             ` Aaro Koskinen
2014-10-29 22:31               ` Aaro Koskinen
2014-10-30 13:55               ` Nishanth Menon
2014-10-30 13:55                 ` Nishanth Menon
2014-10-29 23:07           ` Sebastian Reichel
2014-10-29 23:07             ` Sebastian Reichel
2014-10-29 23:11           ` Aaro Koskinen
2014-10-29 23:11             ` Aaro Koskinen
2014-10-29 23:54             ` Javier Martinez Canillas
2014-10-29 23:54               ` Javier Martinez Canillas
2014-11-26 17:28   ` Pavel Machek
2014-11-26 17:28     ` Pavel Machek
2014-11-26 18:19     ` Tony Lindgren
2014-11-26 18:19       ` Tony Lindgren
2014-11-26 18:57       ` Pali Rohár
2014-11-26 18:57         ` Pali Rohár
2014-11-26 19:10         ` Tony Lindgren
2014-11-26 19:10           ` Tony Lindgren
2014-11-26 19:22           ` Pali Rohár
2014-11-26 19:22             ` Pali Rohár
2014-11-26 20:08             ` Tony Lindgren
2014-11-26 20:08               ` Tony Lindgren
2014-11-26 23:01               ` Pali Rohár
2014-11-26 23:01                 ` Pali Rohár
2014-11-26 23:14                 ` Tony Lindgren
2014-11-26 23:14                   ` Tony Lindgren
2014-11-26 23:38                   ` Pali Rohár
2014-11-26 23:38                     ` Pali Rohár
2014-11-27  1:12                     ` Tony Lindgren
2014-11-27  1:12                       ` Tony Lindgren
2014-11-27 11:32                       ` Pali Rohár
2014-11-27 11:32                         ` Pali Rohár
2014-11-28 20:27                         ` Tony Lindgren
2014-11-28 20:27                           ` Tony Lindgren
2014-11-28 21:41                           ` Pali Rohár
2014-11-28 21:41                             ` Pali Rohár
2014-11-28 22:24                             ` Tony Lindgren
2014-11-28 22:24                               ` Tony Lindgren
2014-11-28 22:42                               ` Pali Rohár
2014-11-28 22:42                                 ` Pali Rohár
2014-12-04 18:34                               ` Pali Rohár [this message]
2014-12-04 18:34                                 ` Pali Rohár
2014-12-04 18:40                                 ` Tony Lindgren
2014-12-04 18:40                                   ` Tony Lindgren
2014-12-04 19:01                                   ` Pali Rohár
2014-12-04 19:01                                     ` Pali Rohár
2014-11-28 22:26                             ` Aaro Koskinen
2014-11-28 22:26                               ` Aaro Koskinen
2014-11-28 22:43                               ` Pali Rohár
2014-11-28 22:43                                 ` Pali Rohár
2014-11-28 22:41                             ` Aaro Koskinen
2014-11-28 22:41                               ` Aaro Koskinen
2014-11-28 22:49                               ` Pali Rohár
2014-11-28 22:49                                 ` Pali Rohár
2014-11-28 22:54                                 ` Aaro Koskinen
2014-11-28 22:54                                   ` Aaro Koskinen
2014-12-02 21:28                           ` Pali Rohár
2014-12-02 21:28                             ` Pali Rohár
2014-12-03 16:52                           ` Pavel Machek
2014-12-03 16:52                             ` Pavel Machek
2014-12-03 22:22                             ` Dmitry Eremin-Solenikov
2014-11-27 11:18               ` Pavel Machek
2014-11-27 11:18                 ` Pavel Machek
2014-10-31 19:30 ` Russell King - ARM Linux
2014-10-31 19:30   ` Russell King - ARM Linux
2014-10-31 21:13   ` Tony Lindgren
2014-10-31 21:13     ` Tony Lindgren
2014-10-31 22:12     ` Tony Lindgren
2014-10-31 22:12       ` Tony Lindgren
2014-10-31 22:33     ` Russell King - ARM Linux
2014-10-31 22:33       ` Russell King - ARM Linux
2014-10-31 23:37       ` Tony Lindgren
2014-10-31 23:37         ` Tony Lindgren
2014-11-01  0:44         ` Russell King - ARM Linux
2014-11-01  0:44           ` Russell King - ARM Linux
2014-11-01 21:57           ` Tony Lindgren
2014-11-01 21:57             ` Tony Lindgren
2014-11-02 18:15             ` Tony Lindgren
2014-11-02 18:15               ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201412041934.03384@pali \
    --to=pali.rohar@gmail.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.