Gp2x Bootchart


theoddbot

Certified Guru
Joined
Sep 25, 2005
Messages
341
Website
oddbot.googlepages.com
I risked bricking my unit for this rather boring chart.

Seems most of the boot is spent doing sfa, but we don't have disk usage stats available in this kernel version, so it's likely that its reading from nand for a lot of the boot time.



Clicky for the full chart, but I've pasted the interesting part here.
 
It's replacing init, the kernel is decompressed when the green screen comes up, and theres usually a few seconds of initialization before init is run. The menu is loaded at 16 seconds on this chart.
 
So would I be right in saying all this dead time supports the theory that boot up can be reduced through firmware as suspected?

Certainly looks that way doesn't it?
 
I'd say you can remove everything from 11s to 16s on that chart without trying too hard, but I'd rather someone with a serial cable and debricking skills tried it :).

From what I can tell, init could be replaced with a small shell script that:

Code:
mount -a # mount extra filesystems
automount & # start automount in the background

# any suggestions as to what else we need ?

# run the menu in a loop so we never exit
while ((1)); do
    cd /usr/gp2x
    ./gp2xmenu
done

Also, using a static /dev rather than devfs would probably free 1.4mb of ram. Piss all on a desktop system, but the gp2x needs all it can get.
 
That is interesting info. Too bad the source wasn't released by GPH so it could be cleaned up :ph34r: It looks sloppy and slow to me.
 
I've just loved bootchart ever since I heard of it. It produces pretty pictures. Its nice to see it utilised in this way where it acually has some value.


OOoooh devfs now thats a blast from the past.
 
The graph starts at the point linux has finished initializing its drivers and it begins running the startup scripts from NAND.
 
Ok now that we have kernel source I've done some playing with the filesystems. I cloned the root partition onto the spare nand as both a jffs2 image and a cramfs image.

jffs2:
mount: 20 seconds
find /: 3 seconds

cramfs:
mount: 0.03 seconds
find / : 0.32 seconds

Also, the cramfs image is only 5mb, compared to 13.4mb or so for the jffs2.

I think the 43 seconds figure is a bit out, it's probably scanning the whole 39mb partition in 43 seconds, compared to 24mb for the real one, so realistically its about 20 seconds.

I anticipate that this will wipe about 12 seconds off the boot time, but we'll have to see.

Robster will take a look at my modified kernel and try and use a cramfs root partition, and see how much it speeds up boot time.

Whoever I flamed about jffs2 not being slow, I humbly apologise :)
 
isn't cramfs read-only?

Even if you are using something like Unionfs to add wrte support. You would be missing wear-levelling.

I rather have a slow boot, than a dead nand.
 
At the current rate jffs2 will kill your nand anyway. Unionfs needs another partition to work, so you could make a very small jffs2 partition for it, and not cop this speed penalty, or at least mount it somewhere later in the boot, in the background.
 
theoddbot posted on Feb 18 2006 at 02:35 PM said:
OK, thanks to art103 for trying this out, we have a total boot time of 12.2 seconds from power on !!!
And this is less than a day after the source release.
Stupid GPL zealots.
 
Last edited by a moderator:
Sorry just to understand all this because I'm a little confused, and obviosly have only the understanding from web pages.

Is cramfs being suggested over squashfs for a reason i.e kernel source not being available?

I thought unionfs was a method of mixing read-only and read-write filesystems, so wouldn't you use both, and only if nand needs to be updated at all?

Is the compression high enough to fit multiple "firmwares" on there for safe experimentation yet?

Hanz™ posted on Feb 18 2006 at 03:18 PM said:
theoddbot posted on Feb 18 2006 at 02:35 PM said:
OK, thanks to art103 for trying this out, we have a total boot time of 12.2 seconds from power on !!!
And this is less than a day after the source release.
Stupid GPL zealots.

Don't think there is any point in dwelling on the past. Is it true :blink:
 
Last edited by a moderator:
This IS the most exciting news since the release of the gp2x! Well this and the breakout box that's comming. To say I'm anxious for the distribution would be an understatement! Great work! Exciting times eh?

CoinOp
 
Back
Top