Decreasing Boot Time

[AireTamStorm]

I figured, you could easily fix the boot time issue by having the kernel boot once, then dump the RAM it occupies and the stack into a file in NAND/SD. Then to boot, copy the file from NAND/SD back into the RAM it was located in, and restore the stack, then reset the stack pointer.

It still wouldn't be instant, but it would sure be faster than the current boot up times.
The boot loader would give you the option "speed boot" or something like that where it tries to boot from the restoreable file, and if it can't, just boot the kernel normally and then remake the "freeze fyle". This is the conceptional part.

But I figure a PC like feature such as suspend to disk would be awesome to improve boot times. Have a script run after restoration to load cfg settings for various programs off CF/etc.....

Any thoughts?

Edit: Oh, and give me back my Reiser.

 

[PSyMastR]

I could have sworn someone else posted this exact method already, but ya that could be a possability.

 

[AireTamStorm]

That was me ;- )

 

[Vimacs]

have been posted a milion times, dont post about it again until you are actualy working on it.

 

[Squidge]

Nice idea, but considering GPH ignored my "Why compress the kernel when the compressed size is bigger than the uncompressed size", I don't think it's going to happen anytime soon...

 

[TelcoLou]

have been posted a milion times, dont post about it again until you are actualy working on it.

​

And thusly, you have been warned by the mighty Vimcas h34r:

 

[Vimacs]

Nice idea, but considering GPH ignored my "Why compress the kernel when the compressed size is bigger than the uncompressed size", I don't think it's going to happen anytime soon...

​

ouch.... just ouch...

 

[AireTamStorm]

Nice idea, but considering GPH ignored my "Why compress the kernel when the compressed size is bigger than the uncompressed size", I don't think it's going to happen anytime soon...

​

Wow. Smart of them, wasting space and device resources to decompress it.

 

[iignotus]

That was me ;- )

​

And me But it wont work too well since it will thrash your SD card. I'm sure some people would be able to live with that, though.

 

[codesmith]

Nice idea, but considering GPH ignored my "Why compress the kernel when the compressed size is bigger than the uncompressed size", I don't think it's going to happen anytime soon...

​

Wow. Smart of them, wasting space and device resources to decompress it.

​

My guess is that they have bigger problems to solve than boot time (eg fitting in the newer SD card driver for > 1GB cards and making assorted tweaks/bugfixes), and if they're not very used to working on linux they probably don't want to risk introducing new bugs while fixing something that's essentially cosmetic (you and I know it's just a small change when running "make config", but they might not know this).

 

[craigix]

Ah everything will be cool soon enough.

Various ideas for new firmware are being worked on already, its all going to be nice. Multiboot, raw hardware, faster booting.

Once you have the GP2X in your hands you will know its all going to work out ok.

 

[icurafu]

I had a motherboard that would power the ram when it went into hibernation. So that it would not have to transfer to HDD and back again. Would it be practical to add a hibinate mode, to just keep enough power running to power the SDRAM.

How much power would that be?

 

[codeninja]

http://www.gpx2.co.kr/support/support_faq_...hk=&direc=&sub=

This is from GPH's official FAQ page, so stop whining rumors, unfounded hearsays. I'm not bringing anything unless it's directly from GPH, even though 90% of stuffs that I reported turned out to be true regardless of the sources, such as turning the joystick to fix joystick input issue and headphone soldering problem that even Craig comfirmed in his emails.

Apparently, GPH is blaming Linux for slow boot time in this FAQ. They'll try to reduce the boot time down to 20sec, and eventually 16sec. I don't know whose ass they got the numbers from, but that's what they are saying at the moment.

[my opinion based on reading other sources so ignore this if you want] By the way, if you receive your unit, and don't have big issues, don't upgrade your firmware just yet. It seems to introduce its own issues including darker screen. GPH will announce firmware update roadmap by the end of the week.

 

[AireTamStorm]

Linux does by nature take a while to boot, loading various modules, etc... I'm actually amazed that they got it as low as it is now on the GP2X (well not many devices to initialize, and the hardware set is consistent). However, skipping the OS initialization would be much faster than it is now, I don't think many people want to wait almost 30 seconds for their -handheld- of all things to boot. I'm discussing a way to improve this time, because 30 seconds = 30 seconds of battery out the window. And if the OS has to boot every time you shut off the power, this can definitely add up.

Edit: Oh, my iPAQ 3600 Took longer to boot than that when I *nixed it, kudos to GPH!

 

[Talyz]

Wasn't the open2x project started for such reasons; developers can create their own "firmware" from it?

 

[jedthehumanoid]

As said before, linux does not "by nature" take long to boot.
Just look at a router, gateway, or some other device with embedded linux.

It all depends on what it does, not which operating system is used to do it.

 

[Radek]

As said before, linux does not "by nature" take long to boot.
Just look at a router, gateway, or some other device with embedded linux.

It all depends on what it does, not which operating system is used to do it.

​

There in other topic developer confirmed that Linux in the GP2x is actually running Bash and typical init starting sequence. Therefore for sure booting time could be improved just by removing Bash and all its scripts. The kernel image is compressed too without reason as it isn't smaller this way but decompressing it takes some time.

 

[kzar]

Isn't bash a shell? Without a keyboard that is totaly useless right? Doh!

 

[gfoot]

Shells also interpret scripts - it's kind of like the BASIC ROM in old home computers. e.g. somebody posted a script file to launch a game by changing to its directory first - that's a shell script, and won't work if you don't have a shell of some kind!

bash is quite a powerful shell, and there are certainly more lightweight shells than bash which could be used - unlike DOS, Unix has a multitude of shells with different feature sets but generally the same basic features. Beyond that, it depends what the init script is actually doing, and whether it really needs to do it.

 

[torpor]

bash as [it sounds like] it is being delivered on the gp2x is through busybox, which looks at argv[0] to learn what function it should perform, depending on disk symlinks, which is to say that the 'slow boot' through the init script is because busybox, the one sysbin that probably provides so, so much more to the gp2x [mount mgmt, etc.] is being loaded .. and it is, yup, large and bloaty, or .. at least .. it can be. 

if we s/init/gp2xShell/ or 'ln -s /bin/gp2xShell /bin/init' [or, whatever gp2XShell is..], things might get a little bit zippier on bootup perception, especially since that'd be doing a bit of the ol' threadiness business a bit more, too .. no need to load busybox, make it pretend to be init, then again pretend to be bash, then use bash to spawn gp2xShell, unless of course, there is a reason to wrap the launch of that business in shell script ..

either way, i'm sure the bootup script can be tweaked to max zippiness, or at least .. a good first hack would be to do a 'real' init replacement [spit, busybox!] that gets the GUI up faster ..