From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pali =?utf-8?q?Roh=C3=A1r?= Subject: Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode Date: Fri, 28 Nov 2014 23:42:12 +0100 Message-ID: <201411282342.12806@pali> References: <20141027200008.GR2560@atomide.com> <201411282241.12095@pali> <20141128222424.GX2817@atomide.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10278459.4BjLALXStZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f177.google.com ([209.85.212.177]:54343 "EHLO mail-wi0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751642AbaK1WmQ (ORCPT ); Fri, 28 Nov 2014 17:42:16 -0500 Received: by mail-wi0-f177.google.com with SMTP id l15so12408308wiw.16 for ; Fri, 28 Nov 2014 14:42:14 -0800 (PST) In-Reply-To: <20141128222424.GX2817@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Pavel Machek , Aaro Koskinen , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org --nextPart10278459.4BjLALXStZ Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Friday 28 November 2014 23:24:26 Tony Lindgren wrote: > * Pali Roh=C3=A1r [141128 13:43]: > > On Friday 28 November 2014 21:27:19 Tony Lindgren wrote: > > > Are you saying there are some issues with that? > >=20 > > uboot (in mode when is loaded from NOLO) has those issues: > >=20 > > 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) > >=20 > > Basically you can use uboot if you accept all above issues. > >=20 > > 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. >=20 > OK thanks for the update, I was not aware of the issues above. >=20 > > > Are there other ATAGs needed beyond the ATAG_REVISION? > >=20 > > 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. >=20 > > Here are all ATAGs from NOLO: > ... >=20 > These we should not need, it's all coming from the .dts files. >=20 > > 0036 - 0003:54410007 ATAG REVISION revision=3D00002204 > >=20 > > 0588 - 000c:4f80 BOOTREASON: pwr_key > > 0604 - 0018:4f82 VERSION: product =3D RX-51 > > 0632 - 0018:4f82 VERSION: hw-build =3D 2204 > > 0660 - 0018:4f82 VERSION: nolo =3D 1.4.14 > > 0688 - 0018:4f82 VERSION: boot-mode =3D normal >=20 > 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. >=20 > > 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? >=20 > Yes we should not need ATAG MEM. >=20 Ok. > > 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. >=20 > I would assume that's also somewhere in the cal area. >=20 In CAL can be stored "forced" value which overwrite that one=20 automagically detected. > > 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. > >=20 > > Partitions are generated by NOLO from CAL (/dev/mtd1) data, > > but I think nobody ever changed them (but it is possible!). >=20 > AFAIK it's safe to assume they are coming in the .dts file. >=20 Yes, using DTS values is OK. I did not heard about anybody who=20 modifying partition table. Personally, sometimes I'm doing it --=20 but only in qemu and only to increase kernel partition with=20 decreasing size of initfs partition (which is not used) to make=20 sure that offset of root partition is same (so nothing breaks). > > Uart is enabled when serial console is enabled via NOLO. >=20 > We can keep the UART enabled all the time no problem. It's > timeouts just need to be configured for idle. >=20 Probably we can ignore it. Serial console is used now maybe only=20 in qemu. No idea if UART is even used. > > 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). > >=20 > > 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. >=20 > OK >=20 > > What we need in userspace: > >=20 > > In file /proc/cpuinfo: > > Hardware : Nokia RX-51 board > > Revision : > >=20 > > 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). >=20 > OK >=20 > > 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. > >=20 > > With non DT (legacy) boot all above atags are present in > > binary file /proc/atags. > >=20 > > But because DT boot does not provide /proc/atags file I need > > some interface how to read above needed strings. > >=20 > > So I would like to know what is possible and how? >=20 > 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? >=20 Ok. Exporting /proc/atags file is good idea (even if it do=20 nothing). But it is possible from pdata-quirks? Or how to achieve=20 this? And once we can read atags in pdata-quirks we can parse it=20 and find revision info (which needs to be changed for=20 /proc/cpuinfo). > > Does kernel provide some interface for telling userspace > > applications something like bootreason (e.g power key, > > software reset, rtc alarm, charger connected, ...)? >=20 > I don't think we have anything like that currently. >=20 > Regards, >=20 > Tony Ok. If there will be some interface (in future) it would be good=20 idea to add n900 bootreason (passed from bootloader) to that=20 interface... =2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com --nextPart10278459.4BjLALXStZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlR4+kQACgkQi/DJPQPkQ1Ir1wCgmm0c+VDCaeCiysn9Raf/fW/8 Uw8AnAp6TryBdJyX7eGC1wRuXwVFh/PH =cWiD -----END PGP SIGNATURE----- --nextPart10278459.4BjLALXStZ--