reinob | # 11 | 2012-11-21, 22:06 | Report

@mr_pingu,

matchbox is not running when hildon-desktop is running (check with ps for yourself . What matchbox-remote does is, presumably, to send a standardized message to the window manager (and hildon-desktop is a window manager). I bet if you were running KDE on your N900 matchbox-remote would still work, assuming that KDE (or whatever WM you'd be using) would follow the "standards" (if you can call it a standard anyway).

In short: think of matchbox-remote as a synonym for wm-remote

Hurrian | # 12 | 2012-11-21, 22:43 | Report

That would be matchbox1. Matchbox2 is statically linked into hildon-desktop, according to the documentation on the gitorious.

Sourav.dubey | # 13 | 2012-11-24, 15:07 | Report

Knowing boot process of N900 will help in reparing unbootable device
but what happens in reboot loops
Is any file on opt or rootfs is damaged ?

reinob | # 14 | 2012-11-29, 12:13 | Report

A reboot loop may be caused by all sorts of different things. The N900 may be rebooted by:
[1] user action (N/A in a reboot loop)
[2] a critical dsme-executed system process being killed
[3] a startup script actively deciding to reboot/change runlevel
[4] hardware watchdog
[5] kernel panic (indirectly, the reboot is done by the HW watchdog)

I suppose a "typical" reboot loop is caused by [2] or [3].

[2] may happen if the user has tweaked/modded/deleted something so as to may a daemon crash/exit (e.g. Xorg configuration).

[3] is something I want to investigate: some startup scripts *do* actively decide to reboot, either for good reasons (e.g. after flashing the eMMC) or because they think they're doing something smart (/sbin/preinit, bme, rcS-late, others?)

An example is in /etc/event.d/rcS-late

"If failed to mount /home and system has already been optified - reboot"

Obviously, if getbootstate returns BOOT or SHUTDOWN or an invalid boot state ("Houston, we have a problem") then the N900 will also be rebooted.

This can happen if e.g. the battery is not properly recognized.

I'll try to make a list of things that can go (horribly) wrong while booting.

vi_ | # 15 | 2012-11-29, 12:38 | Report

On an n900, this will be a very long list!

mr_pingu | # 16 | 2012-12-26, 13:46 | Report

So I have removed the bootvideo, the 5 dots and inserted loading from framebuffer in preinit. Now what strikes me is that there's some placeholder where the 5 dots once were, black screen no framebuffer output; Is the device actually doing something at the moment that's important for the booting process? More exactly, what is it doing and can we reduce the time the screen is black?

---

Last edited by mr_pingu; 2012-12-26 at 14:16.

raaj13 | # 17 | 2012-12-26, 13:59 | Report

Esssential system programs maybe
[Hint: type ps in terminal you will get a list. Most of the programs are the ones that are loaded at boot time(I mean the system ones)]

---

Last edited by raaj13; 2012-12-26 at 14:24.

mr_pingu | # 18 | 2012-12-26, 14:44 | Report

That's not what I meant, I am curious what is exactly executed at that time. What is running before is not interesting, regarding the purpose of my question.

My hope was that Reinob knows exactly what it is doing, if its uberhaupt doing anything

I guess it may be related to this:
http://talk.maemo.org/showpost.php?p...98&postcount=8

Also, I am just thinking aloud, I didn't investigate it that much myself.

raaj13 | # 19 | 2012-12-26, 15:46 | Report

Then i can think of only 1 thing maemo optify boottime
checking /var/log/maemo-optify-boottime.log might help
causes around 2 sec(1.91272 sec) delay for me.

reinob | # 20 | 2012-12-27, 22:28 | Report

That must be when X is loaded but hildon-desktop is still not started. During that time, either there's no window manager running, or matchbox is running. When matchbox is running, the lock code/PIN code is asked (if required), and the time/date/regional settings are set (if required).

Have a look in /etc/X11/Xsession.d (might have a typo in there, I'm not particularly concentrated now .