On Friday 28 November 2014 23:24:26 Tony Lindgren wrote: > * Pali Rohár <pali.rohar@xxxxxxxxx> [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@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
