RAM and ext2

[Stefan Sperling]

Hi,

I'd like to add support for ext2 to the RAM build somehow,
so DSLinux can be used with 2GB SD cards without crashing. The
"tab-completion -> crash" problem was apparently due to a bug
in the msdos filesystem code, I have confirmed that it does not
occur when ext2 is used instead.

I've been thinking about the best way to do this, and there
are a couple of things I'd like to have opinions on.

The general idea is to have two partitions on the media,
be it SD or CF:

	Partition 1 is FAT16 and used to run dslinux.nds from.
	Partition 2 is ext2.

Of course one question is where to mount the ext2 filesystem.
Another one is whether or not to create a new build type for ext2 support.

These are options I came up with (any other ideas?):

1.	Create a RAM-EXT2 build that uses ext2 instead of vfat.
	ext2 is mounted on /media.

2.	Make the RAM build support both vfat and ext2.	
	Either one mounted at /media.

3. 	Create a RAM-EXT2 build that mounts the ext2 filesystem
        as root filesystem. This means that we might loose XIP support
	(e.g. to run madplay at full speed) because we have no
	romfs anymore, unless we can somehow mount a romfs on /bin
	or something...
	Another problem:
	    How do we make the kernel find the root filesystem?
	    It could be /dev/hda2 or /dev/mmcblk0p2, depending
	    on the hardware. GBAMP-EXT2 has /dev/hda2 hardcoded.
	    Is there any way to change the kernel command line
	    before booting?


And there is the necessity to check the ext2 filesystem before
mounting it. We could have a simple bootscript that tries to e2fsck
all possible devices, namely /dev/hda2 and /dev/mmcblk0p2.

While at it I also tried to add support for checking FAT filesystems
but that made things really ugly because there's 4 possible FAT
devices (/dev/hda1, /dev/hda, /dev/mmcblk0p1, /dev/mmcbkl0).

In case of approach 2 (RAM supports both vfat and ext2) this leads to
a screenfull of error messages from dosfsck and e2fsck on boot, and even
though this is harmless since they find the right filesystem eventually,
it is ugly and might confuse people. I guess the best solution to this
problem is to change to tools so they fail silently if they cannot check
the filesystem on the device specified.

Oh, and we definitely need to update e2fstools. The version in
our tree refuses to check filesystems created with current
mkfs.ext2 versions. There's a recent enough port of e2fstools in
the latest uClinux release. What happened to merging that release?

-- 
stefan
http://stsp.in-berlin.de                                 PGP Key: 0xF59D25F0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.dslinux.in-berlin.de/pipermail/dslinux-devel-dslinux.in-berlin.de/attachments/20070407/16f1ccfb/attachment.pgp