Thread (47 messages) 47 messages, 9 authors, 2014-12-04
STALE4214d

[PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode

From: Pali Rohár <hidden>
Date: 2014-11-28 22:42:12
Also in: linux-omap

On Friday 28 November 2014 23:24:26 Tony Lindgren wrote:
* Pali Roh?r [off-list ref] [141128 13:43]:
quoted
On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
quoted
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.
quoted
quoted
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.
quoted
Here are all ATAGs from NOLO:
...

These we should not need, it's all coming from the .dts files.
quoted
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.
quoted
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.
Ok.
quoted
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.
In CAL can be stored "forced" value which overwrite that one 
automagically detected.
quoted
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.
Yes, using DTS values is OK. I did not heard about anybody who 
modifying partition table. Personally, sometimes I'm doing it -- 
but only in qemu and only to increase kernel partition with 
decreasing size of initfs partition (which is not used) to make 
sure that offset of root partition is same (so nothing breaks).
quoted
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.
Probably we can ignore it. Serial console is used now maybe only 
in qemu. No idea if UART is even used.
quoted
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
quoted
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
quoted
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?
Ok. Exporting /proc/atags file is good idea (even if it do 
nothing). But it is possible from pdata-quirks? Or how to achieve 
this? And once we can read atags in pdata-quirks we can parse it 
and find revision info (which needs to be changed for 
/proc/cpuinfo).
quoted
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
Ok. If there will be some interface (in future) it would be good 
idea to add n900 bootreason (passed from bootloader) to that 
interface...

-- 
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/20141128/ac896cad/attachment.sig>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help