* Pali Roh?r [off-list ref] [141128 13:43]:

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

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