GP2X Gp2x Boot Procedure


bluey

Still Fresh
Joined
Jul 29, 2006
Messages
57
Age
43
Location
Lisbon, Portugal
Website
azulebanana.com
I'd like to know how's the state of alternative gp2x environments.

As usual, the boot sequence on the gp2x is an ugly hack, which is pretty usual on enterprise implementations of embedded Linux, they stop using the built in sysv init, let all the filesystem with unneeded files and links (all the rc stuff in etc is an example) call rc.sysinit from the inittab and from there call init scripts all over the place, and even from /root...

Why don't they build a good init script and call it from inittab, keep the rcs scripts (permitting to start the menu earlier and leave stuff booting in the background), or implement a set of scripts with priorities that permit the menu to start as soon as possible?

I'd even go to say that one could overclock the unit in the beggining to say 220 or 240, start up some of the boot services in parallel giving an almost instant boot sequence...

Anyone ever tried to repair the boot system of the gp2x?

Is the firmware update hardcoded in the sequence, and is that the fear people have to mess with the present image?
 
The problem goes a lot deeper than that. Strange as it may sound, the menu itself actually has a lot of the hardware setup hardcoded (poorly) into it! I'm working on an alternative firmware, and just by writing the boot scripts properly, I've halved the boot time.

However, you can't do much to help the official firmware, it is so poorly designed that you need to start from scratch to get those kinds of improvements. An instantaneous boot isn't ever going to happen on the GP2X, it will always be a few seconds at least.
 
Orkie posted on Dec 24 2006 at 04:21 PM said:
just by writing the boot scripts properly, I've halved the boot time.

That's expected.


Orkie posted on Dec 24 2006 at 04:21 PM said:
However, you can't do much to help the official firmware, it is so poorly designed that you need to start from scratch to get those kinds of improvements. An instantaneous boot isn't ever going to happen on the GP2X, it will always be a few seconds at least.

Of course, there isn't magic involved ;) Nevertheless a few seconds is completely different from the time it takes now...

Do your project have a place on the web? Are you using a framework like openembedded or coding everything yourself?

Having people close to GP, isn't there a possibility to reach them to improve the system? It seems they want to keep some bits of the menu closed (can't understand why, though), a better rom image would benefit everyone. It seems most companies pickup some basic distro and hack their way into a bootable system, instead of creating a tailored system for the device. I've had some experience with an old Zaurus and the Sharp system was alike this one, links everywhere, scripts here and there...

I hope your work is going well, some simple modular system is enough, and sysvinit already provides that facility, can't understand why they drop it... You have a default level, create the scripts for what you need to initialize (modules, daemons, the menu) and it should work.

Having GP taking the hardcoded bits from the menu would be nice. Have the ftp, webserver, etc boot defined in a normal way by flags in a config file, write to the file the changed flags, call the init script, and you can take responsibilities from the menu which shouldn't be there in the first place.
 
Last edited by a moderator:
I've been building it around buildroot from the uClibc project, which I like because it's simple to use and once the makefiles have been written, you just select programs/libraries from a list and it'll handle the compilation (same kind of idea as OE, different approach). I'm hoping to get it into the open2x SVN at some point, but I'll need to ask after Christmas.
 
I wish you good luck with this! ;)

A kind of automated process is wonderful as it makes it easier to be updated with the sources that GP launches, even though the only thing you'd need is the updates to the kernel, anyway. :)

Say something when you release anything related to this.

Thanks for your work!
 
I use the modified uboot that allows loading from the sd card, my non-linux, non-os binary is loaded into ram via uboot and executes.

Is this what you are talking about or are you looking to replace uboot itself? Uboot is way too bulky for my tastes, but it works and not a project I wanted to tackle so I just deal with it. If I had a jtag cable that would probably be another story.

Because it uses an sd card instead of say a rom cartridge, the bootloader has to be complicated enough to manage an sd card and filesystem. Also, probably more on target, how slow is the nand memory? Do we have control over how much of it needs to be copied to ram on power up?

David
 
I'm talking about the Linux boot process, which is the main bottleneck. Scripts aren't well planed and I believe there isn't parallel process booting. If something like a priority system would be used for booting (and sysvinit already provides that with the script number), we could have a usable system earlier. It looks like they ignored that function and instead use a hacked script to start the services. With so much power Linux gives, they use an ugly hack which makes it look bad. The time it takes to boot is a proof of that, and the new fw talked about in other thread says it will take longer. This is bad planning or/and bad programing. :(
 
Back
Top