Initial Load And Splash Screens


Aimless_E posted on Feb 15 2006 at 10:34 AM said:
DID HE SAY SOURCE CODE!!!!!! :)

When we get the source to the kernel it will be easy to add our own splash screens. Maybe even Animated ones. B)
No, he said Sauce Toad! Its a delicacy in my country :p
 
Last edited by a moderator:
Squidge posted on Feb 16 2006 at 01:24 AM said:
It's most likely because redirecting input/output to the serial port is far easier than writing it to the LCD, and most people would just get confused if they saw it anyway.
Yup, but it woud be nice for us geeks to have the option to see it.

I suspect that we'd be watching it scroll through tons of lines in a second and then see something like "starting httpd" on screen for 18 seconds.

Maybe they have something to hide? :ph34r:
 
Last edited by a moderator:
1 problem with displaying the console on the LCD:

I don't think you want to see the console when the menu(or any other app/game) loads. Think sterm + gp2xmenu.

Something would have to unload fbcon(frame buffer console) before the menu is loaded.(and redirect stdout back to the serial port)

edit:

FluffyPanda: you can see the startup using a serial cable.

It looks something like
http://www.distant-earth.com/gp2x/files/unbrick/flashlog.txt

minus the NAND flash. :D
 
Thanks for the link by the way BBTroll.

These lines are interesting:
Code:
Starting kswapd
Journalled Block Device driver loaded

A journalled file system seems like an unnecessary overhead to me, and I'm not too sure about the idea of using flash memory for a swap file. When the hardware is fixed and people know exactly how much memory they are writing for there isn't much need to swap stuff to NAND. Actually, this may well be the cause of the annoying pauses in execution that we're all experiencing.
 
jffs2 is specifically designed for use on raw flash devices and embedded systems.

It's a log structured file system designed to level to wear on these devices. It's not like the journalling has just been bolted on (ext3)

If anyone has a better idea I'm sure lots of people would be interested in hearing it.

Personally, I'd have the main filesystem on a cramfs (read-only) filesystem and use a jffs2 overlay to make it modifiable. This way the system can still work if the writes wear out, just with reduced functionality.

ps. there is no swap file
 
There is no swap file on the gp2x.

The journalled file system is the most appropriate for a flash file system. The GP2X uses JFFS2, a log-structured file system designed for use on flash devices in embedded systems. Rather than using a kind of translation layer on flash devices to emulate a normal hard drive, as is the case with older flash solutions, it places the filesystem directly on the flash chips (http://sourceware.org/jffs2/)
 
theoddbot posted on Feb 16 2006 at 07:38 AM said:
Personally, I'd have the main filesystem on a cramfs (read-only) filesystem and use a jffs2 overlay to make it modifiable. This way the system can still work if the writes wear out, just with reduced functionality.

I was thinking the same thing about using cramfs, or possibly squashfs - but using a jffs2 overlay to make it modifiable is a very nice idea. At any rate it will be nice to start working on this stuff once GPH straightens out their licensing.
 
Last edited by a moderator:
Last edited by a moderator:
Back
Top