Page 3 of 3 12 3
Reply
Thread Tools
Estel's Avatar
Estel is offline Estel
2012-05-11 , 04:26
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#21
Just a little bump - Pali and others, how rewriting/fixing preinit goes on?

/Estel
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 

The Following User Says Thank You to Estel For This Useful Post:
pali is offline pali
2012-05-11 , 05:52
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#22
You can see it in bzr repo: https://code.launchpad.net/~pali/+ju...o_getbootstate
 

The Following 2 Users Say Thank You to pali For This Useful Post:
ivgalvez is offline ivgalvez
2012-05-11 , 08:06
Posts: 1,397 | Thanked: 2,126 times | Joined on Nov 2009 @ Dublin, Ireland
#23
Will it be included in CSSU anytime soon?
 

The Following 3 Users Say Thank You to ivgalvez For This Useful Post:
reinob is offline reinob
2012-11-13 , 12:20
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#24
@pali,

I have a question about getbootstate, in particular regarding bootmode and bootreason:

AFAIK the Fremantle version reads bootreason from /proc/bootreason and bootmode from /proc/component_version. The Harmattan version (again, AFAIK) takes these two values from the kernel commandline (bootreason=X, bootmode=Y).

I remember having read a getbootstate.c where both methods were attempted (first Harmattan, then Maemo), but it was not clear if that was the stock Fremantle getbootstate, or what.

So the first question is:
* do you know if stock getbootstate checks the cmdline first?

And the first "request" is:
* can you make it that way on the open-source version of getbootstate?

This way one could, e.g. make a U-boot entry for booting Maemo with a chosen bootmode/bootreason (e.g. always "pwr_key" and "normal"), in case something goes bad.

It would be also *very* nice if we could include in the kernel commandline a kind of "bypass" for the whole getbootstate, e.g. "init=... bootstate=USER ..."

This way getbootstate would check if that parameter was included in the command line and immediately return it, without checking anything else (no BSI, no boot count, no thing).

This would provide an additional back-up in case something goes horribly wrong.

I don't think anyone will have anything against the proposal here. After all, as long as you don't touch the kernel commandline everything will work as normal.

If I find the time I will try to do it myself (I have now installed gcc and libcal-dev in my spare-N900s so I could do this while on the train but obviously it would be good if you did that for my benefit (oh, and for the rest of the community, natürlich

Cheers.
 
pali is offline pali
2012-11-13 , 12:49
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#25
Originally Posted by reinob View Post
@pali,

I have a question about getbootstate, in particular regarding bootmode and bootreason:

AFAIK the Fremantle version reads bootreason from /proc/bootreason and bootmode from /proc/component_version. The Harmattan version (again, AFAIK) takes these two values from the kernel commandline (bootreason=X, bootmode=Y).
You are right.

Originally Posted by reinob View Post
I remember having read a getbootstate.c where both methods were attempted (first Harmattan, then Maemo), but it was not clear if that was the stock Fremantle getbootstate, or what.
Closed fremantle version read only from /proc. Harmannan version read only from cmdline. In my previous open source version there was implementation of both methods. But I decided to drop harmattan method to have same functionality in new open source version.

Originally Posted by reinob View Post
So the first question is:
* do you know if stock getbootstate checks the cmdline first?
No

Originally Posted by reinob View Post
And the first "request" is:
* can you make it that way on the open-source version of getbootstate?

This way one could, e.g. make a U-boot entry for booting Maemo with a chosen bootmode/bootreason (e.g. always "pwr_key" and "normal"), in case something goes bad.
Not needed. Last u-boot version has option to force bootreason and bootmode via env variables. I will write documentation for rx51 uboot port when I will have time. (BTW, rx51 port without bootmenu is in upstream now :-))

Originally Posted by reinob View Post
It would be also *very* nice if we could include in the kernel commandline a kind of "bypass" for the whole getbootstate, e.g. "init=... bootstate=USER ..."
This is possible now too. Just enable R&D mode (which is designed for above problematic situations) nad getbootstate (both closed and my new open) will set USER bootstate if you are booting from power off.

Originally Posted by reinob View Post
This way getbootstate would check if that parameter was included in the command line and immediately return it, without checking anything else (no BSI, no boot count, no thing).

This would provide an additional back-up in case something goes horribly wrong.

I don't think anyone will have anything against the proposal here. After all, as long as you don't touch the kernel commandline everything will work as normal.

If I find the time I will try to do it myself (I have now installed gcc and libcal-dev in my spare-N900s so I could do this while on the train but obviously it would be good if you did that for my benefit (oh, and for the rest of the community, natürlich

Cheers.
 

The Following 2 Users Say Thank You to pali For This Useful Post:
reinob is offline reinob
2012-11-13 , 19:19
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#26
Originally Posted by pali View Post
This is possible now too. Just enable R&D mode (which is designed for above problematic situations) nad getbootstate (both closed and my new open) will set USER bootstate if you are booting from power off.
Yeah, I have activated R&D mode with pwr_key. It's just that on my N900 without bme I sometimes forget to tell dsme that the charger is not connected, so instead of powering off it goes to some half-act-dead-but-not-quite-nirvana state, so when I turn it on again it doesn't quite know what to do (I think it gets bootstate = ACTDEAD even though pwr_key is forced) until it reboots again, this time with pwr_key/normal/USER bootstate.

I was thinking that if I force it to always use USER mode no-matter-what this problem would be solved. But just in case I'd like to have it configurable.

But I'll take care of that. I want to write a manual getbootstate where the user is presented with a menu, where the "standard" bootstate (according to the stock getbootstate algorithm) is pre-selected but you have the option of selecting another one, with a timeout or something.
 

The Following User Says Thank You to reinob For This Useful Post:
pali is offline pali
2012-11-13 , 19:22
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#27
Originally Posted by reinob View Post
Yeah, I have activated R&D mode with pwr_key. It's just that on my N900 without bme I sometimes forget to tell dsme that the charger is not connected, so instead of powering off it goes to some half-act-dead-but-not-quite-nirvana state, so when I turn it on again it doesn't quite know what to do (I think it gets bootstate = ACTDEAD even though pwr_key is forced) until it reboots again, this time with pwr_key/normal/USER bootstate.
this is fixed in prepared bme replacement.
 

The Following 3 Users Say Thank You to pali For This Useful Post:
reinob is offline reinob
2012-11-14 , 08:43
Posts: 1,808 | Thanked: 4,272 times | Joined on Feb 2011 @ Germany
#28
Originally Posted by pali View Post
this is fixed in prepared bme replacement.
Well, strictly speaking, this is also solved in stock bme. I assume that if I hadn't purged bme I wouldn't have that problem

But, regardless of how dumb this may be, my goal (if you can call it a goal) is to have a perfectly working N900 without bme. But this (apparently) requires completely getting rid of actdead, which can only be achieved if getbootstate never returns ACTDEAD

But yeah, I'll take care of that one myself.
 
pali is offline pali
2012-11-14 , 09:58
Posts: 2,154 | Thanked: 8,464 times | Joined on May 2010
#29
bme replacement is project to move charging to kernel. so it is what you want.
 

The Following 2 Users Say Thank You to pali For This Useful Post:
Reply
Page 3 of 3 12 3

Tags
getbootstate, preinit

« Previous Thread | Next Thread »
Thread Tools

 
Forum Jump


All times are GMT. The time now is 02:28.

Contact Us - Home - Archive - Top