Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 10 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 7 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 4 hrs ago - more...
| The Following User Says Thank You to Estel For This Useful Post: | ||
|
2012-05-11
, 05:52
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#22
|
You can see it in bzr repo: https://code.launchpad.net/~pali/+ju...o_getbootstate
|
|
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.
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.
|
|
2012-11-13
, 12:49
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#25
|
Originally Posted by reinob
You are right.
@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).
Originally Posted by reinob
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.
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.
Originally Posted by reinob
No
So the first question is:
* do you know if stock getbootstate checks the cmdline first?
Originally Posted by reinob
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 :-))
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.
Originally Posted by reinob
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.
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 ..."
Originally Posted by reinob
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
Cheers.
|
|
2012-11-13
, 19:19
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#26
|
Originally Posted by pali
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 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.
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: | ||
|
|
2012-11-13
, 19:22
|
|
Posts: 2,153 |
Thanked: 8,462 times |
Joined on May 2010
|
#27
|
Originally Posted by reinob
this is fixed in prepared bme replacement.
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.
| The Following 3 Users Say Thank You to pali For This Useful Post: | ||
|
|
2012-11-14
, 08:43
|
|
Posts: 1,808 |
Thanked: 4,272 times |
Joined on Feb 2011
@ Germany
|
#28
|
Originally Posted by pali
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
this is fixed in prepared bme replacement.
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.
 |
| Tags |
| getbootstate, preinit |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 13:47.
/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!