Cramfsldr


Orkie

Super Duper Mega GP Mania
Joined
Mar 22, 2006
Messages
2,373
Location
UK
Website
www.gp2x.dev
This is a first version of my suite of tools for making single file executables for the GP2X. This
version uses cramfs images to store the actual game data.

It hasn't been particularly extensively tested, but it should work on any GP2X since it is mostly script based (though these binaries won't run on custom firmwares unless they use the GPH kernel or provide their own cramfs modules). I will be working on this again in the near future and will be providing more tools and more information on writing your run.sh scripts (I may even be able to eliminate that entirely though the use of a tool I intend to write).
UPDATE: 0.2 has been released to fix a mistake which prevented packages running on Open2x. All packages should be recreated with this release.

Download: http://x11.gp2x.de/open2x/cramfsldr/cramfsldr-0.2.zip
Download (Boomshine2x example): http://x11.gp2x.de/tempfiles/boomshine2x.gpe
[cut]
I'll just paste the README here since it covers pretty much everything:
CODE

cramfsldr 0.1 by Orkie (orkie@gp2x.de)

This is a first version of my suite of tools for making single file executables for the GP2X. This
version uses cramfs images to store the actual game data.

Advantages of cramfs images:
* Can be used compressed
* Filesystem has no 'blocks' so many tiny files don't take up lots of space
* Easy to organise (just need a file and a save directory on SD) and can be run from anywhere
* No need to extract or set up, just copy it over and run as normal (could be downloaded straight to SD)
* Feasible to use for a one-click downloader in the future

Disadvantages of cramfs images:
* Extra 0.5 seconds load time in worst case (generally much less)
* Read-only filesystem, so config files and saves have to be stored in a separate directory for
each application

Myths:
* It is not possible to extract them
> cramfsck can extract cramfs loopback images
* You can only make them on Linux
> mkcramfs and cramfsck can both run on Windows and in pretty much any other OS
* They are slow
> A small extra load time is added, which is often not noticeable
* The size difference is negligible
> egoboo2x went from 130MB to 12MB with this process, and Boomshine2x from 6MB to 4MB
* It is harder for a user to set up
> A user simply has to copy a single file onto SD. How could that be more difficult than having to
extract it and occasionally copy into certain places?

How to use:
1. Write a run.sh script and include this in the root directory of your application. This is
what will be executed by the loader, so it needs to mount any files that have to be writable,
and are stored in a writable directory outside the image, using "mount -o bind src dest".
See the included Boomshine2x image contents for an example of how to write a run.sh.
> $MNTDIR is the directory the game is being run rom (i.e. the root of the game)
> $RUNDIR is the directory the image is stored in. The save/config directory should be
created here
2. Mark your application's executable "+x" using chmod (should not be needed in Windows).
3. Make an image using mkcramfs (no label is needed for the filesystem). A Windows binary is
included, but for all other operating systems, it will be neccessary to compile from source.
See the links section for this.
4. Merge the files in the order cramfsldr.gpe, cramfs.o, zlib_inflate.o, cramfs image.
> e.g. cat cramfsldr.gpe cramfs.o zlib_inflate.o cramfs.img > runme.gpe (*NIX)
> e.g. COPY /B cramfsldr.gpe+cramfs.o+zlib_inflate.o+cramfs.img runme.gpe (Windows)
5. Done! runme.gpe will now be treated as a normal application by the GP2X.

NOTE: Your application should not launch the menu itself if at all possible - leave it to the
script please! That way, it can clean up properly without being interrupted.

How it works:
It work in the same way as most self extracting archives on *NIX, but doesn't extract anything.
At the start of the file, there is a script. This first checks if cramfs modules are installed and
copies them into place if they are not. Next it creates a mount point in /tmp (so it is erased at
every power-down) and mounts the image. It sets some environment variables and executes run.sh, which
is a shell script inside the image. After application execution has finished, it cleans up and re-launches
the menu.

Future plans:
* Work on mkcramfs/cramfsck a bit to make them more user-friendly
* Examine ways of adding writable sections to the image
* Automated download service?

Thanks:
ParkyDR



Comments and constructive criticism are appreciated, mindless ranting and flaming is not.
[/cut]
 
Well, it works really good. I took exult (91MB) and got it down to 61.5MB. Start times changed from 5 seconds to 7 seconds. I didn't convert all save files, but I could continue a game just fine. Sound would not work with the music.raw mount, though. Probably a config issue on my part. Good idea for saving space.
 
Glad to hear it's working. If you upload your image somewhere, I'll take a look and see if I can figure out why the sound isn't working.
It's a shame about the load time, but when Open2x is released, most of the original 5 seconds will likely be eliminated anyway if it gets recompiled :).
 
This sounds interesting. Not meaning to sound stupid but with a Fenix game does this also include the runtime in the finished image? Providing it does I'm sure I'll use it.
 
It includes whatever you decide to bundle :). I experimented on Boomshine2x (which is a Fenix game) and if you download the cramfsldr-0.1.zip file, you'll see that I included the runtime in the image. You can literally copy the file onto SD, select it from the menu and it'll run without any external dependencies (other than a few shell commands, which are in the standard firmware anyway).
 
Orkie said:
Glad to hear it's working. If you upload your image somewhere, I'll take a look and see if I can figure out why the sound isn't working.
It's a shame about the load time, but when Open2x is released, most of the original 5 seconds will likely be eliminated anyway if it gets recompiled :).
A little too big to post. Don't have a file account anywhere.
I built a running exult with music support as described in ReadMe.
created run.sh
created cramfs and gpe

It may want some r/w access I did not define (like gamedata I left out)

here is the run.sh

#!/bin/sh
if [ -d "$RUNDIR/exult" ]
then
echo "Using existing exult save directory"
else
echo "Creating exult save directory"
mkdir -p $RUNDIR/exult
fi
echo "Creating music buffer"
touch $RUNDIR/exult/music.raw
mount -o bind $RUNDIR/exult/music.raw $MNTDIR/music.raw
echo "Creating settings files"
if [ -a "$RUNDIR/exult/.exult.cfg" ]
then
echo ".exult.cfg "
else
cp -f $MNTDIR/.exult.cfg $RUNDIR/exult/.exult.cfg
fi

mount -o bind $RUNDIR/exult/.exult.cfg $MNTDIR/.exult.cfg
./exult.gpe
sync
umount $MNTDIR/music.raw
umount $MNTDIR/.exult.cfg
 
Last edited by a moderator:
Wow, very impressive.

This could make a kick@rse combination with the Gp2x Emudownloader. (But not just emulators).

Hopefully something like this will be included in the initial release of the Pandora to save a lot of installation pain.
 
i have some questions stuff to add up... specially about packaging fenix games with the runtime in one binary. anyone has more details on this yet? if it's working flawless, we could allow fenix that way in pdrc 3.99.
 
Well I've not had any problems. Download the boomshine2x binary linked to in the first post if you want to try it for yourself (it is a Fenix game). I'll probably be on IRC tomorrow evening if you have any specific questions.
 
I tried to cramfs a Doom2 mod (AV, from 22MB down to 6MB) and it seems to load just fine, but it doesn't use it. prboom says "loaded /tmp/game/mods/av.wad" but it still starts just Doom2. Is there a size limitation with cramfs or a corruption issue where prboom will load it and ignore it if it can't read it in?
 
I believe there is a size limit of 16MB on files by default, but it can be expanded. For 0.3, I'll make the limit significantly higher (it is set to 24 bits by default, but if I bump it up to 32 we'll get 4GB maximum file sizes). Sorry about that - it didn't even cross my mind :).
 
Sounds good. Now if someone would throw together a nice GUI that would make this a killer application and there would be no reason for anyone not to use it.
 
Peter R said:
Sounds good. Now if someone would throw together a nice GUI that would make this a killer application and there would be no reason for anyone not to use it.
Hmm, I guess you could simplify it. But this is already way too easy.
1)extract data to DIR
2)edit DIR/run.sh
3)mkcramfs DIR datafile
4)copy /b file1+file2+file3+datafile datafile.gpe

If it doesn't work, edit, up arrow and try again :)

OK, so a GUI would be nice. Maybe one that can handle music.raw, config, and other misc r/w data options to make writing the run.sh easier. I spent 3 hours trying to get that mod working before I realized it wasn't my fault. I'll wait for someone more competent than me to do it (like I am for a new prboom that will run Strife and the new Eternal Doom 4) <_<
 
Last edited by a moderator:
Back
Top