I am able now to run Maemo 5 PR1.2 from internal eMMC with working cell phone after some modifications. So, UBIFS is not used after boot and root is located in eMMC.

No root FS limitations, anything works... well, one small problem still exists but there are workarounds.

First impression performance: something different. Sometime it can be a little slow but in many cases it has definitely a faster reaction. Of course, I set swap into external MMC.

Looking now into battery performance. Without GSM it is of course very good, but now I have it with working GSM/3G/WiFI, so - still collecting measurements.

Your battery results are going to be very interesting. I had a strange experience with moving /lib/dsp to the eMMC. Granted, it might have been a fluke, but when I did so, the CPU got stuck at 500MHz and never went below. When I moved the directory back, it fell back to normal.

OK, couple of day passed and my N900 works fine from eMMC (swap on uSD).

Now I am ready to say that there is no notable difference in power consumption. Actually, it looks like it is a little better (around 20%) but it is in error margin - I rebooted multiple times and it takes battery resource.

Speed. Sometime it is worse but most of it during reboot until I attach uSD swap instead of /dev/mmcblk0p3. However, in day-to day clicks it looks better during changing menus etc.

No problem with phone call receiption - I means, no delays, no sound distortion etc.

No problem with e-mail - it looks like it works a little better: I have a big e-mail account (thousands mails) and it handle it's retrieval now without any problem. In vanilla boot from UBIFS it can sometime hangs (lack of memory) or do it long time.

No any problem with video playback. At least a couple of my video files play smooth.

Of course, no problem with browser or RSS feed.

I even tested google latitude - it works fine too.

It is possible to note an existence of some intermediate windows during starting some applications (like e-mail) - it blinks a fraction of second and disappears before I can read it's content during e-mail application start. But overall reaction is the same.

Two problem still exist with MCE - it doesn't work correctly with power button and doesn't finish "screen slide unlock" (MCE is a buggy application anywhere). But side slider works fine. And there is some another problems with power-button menu like some woodoe needs to be done to see it and switch OFF position doesn't work. All of them are easy to workaround and for now it is not a stop-gap.


But biggest advantage - 2GB root FS, of course - no problem with installing new applications...

Yet another day passed and I am able to compile and build the whole kernel in my N900 - full power development cycle.

Wall time - 3h 1m 21s.
eMMC space - 943MB.

I did a couple of phone calls in a middle without compilation interruption Skype was working too - anything as usual. Delayed reaction on button press was expected and I observed it but it was reasonable.

N900 was warm but not very. It took around 3/4 of battery resource.

I wish i had the guts and knowledge like you Egoshin. Good work!

I prepared tool scripts and published it here - http://talk.maemo.org/showthread.php?t=59374

After applying this scripts you can have a 2GB (or 32GB - depending from your /home partition size) root file system.

This is really great Egoshin! You should package the scripts and put them in extras-devel as soon as some people have tried them out. Apart from easy availability and official endorsement (as it moves into extras-testing, etc), it will also let un-optified packages simply be made dependent on your package and people could still install them. Oh, and perhaps find a name that is a bit more descriptive than M32GB... ;-)

First of all, sorry if I am posting about something that have already been covered. I have had my N900 for less than a month so I may have missed some older threads/posts even as much as I have tried to read everything related before posting.

At the first moment I saw the rootfs limitation on N900 I thought about the simple yet elegant way it is solved in OpenWRT:

A root filesystem (squashfs) + an overlay with mini_fo (jffs). This gives a readonly basic install plus an additional space for modifications.

I have been holding from trying before I read all I can about this subject in the forum, considering that if it hasn't been done yet must be for a good reason.

Anyway, before going any deeper into this subject, I would like to understand what is the reason because this option was ruled out.

I have only been able to to find a reference in a several months old post from @SR:


What is the reason that both fs need to be writable? The idea would be to have "original" root fs mounted as read only and a writeable overlay using mini_fo the same way is done in OpenWRT.

Reads would still be faster as mini_fo doesn't have a big impact performance (needs to be confirmed in this case though) and writes would be directly into the overlay, which wouldn't be significantly slower than writing to the emmc.

About renames... well, that would be obviously much slower but... I don't see a reason for almost any rename of the original binaries much less a non-empty original dir.

Also, simply not mounting, or clearing the overlay would leave a perfectly clean fresh device. And mounting different overlays allows for some easy multiple system.

P.S.: Perhaps Egoshian way has better performance, but anyways I still I would like to understand why this simple solution was ruled out.

I don't quite get it.

Why would You want to use the 2GB "/home" partition as Your / partition ?

Instead of using the 256MB NAND + 2GB /home You end up with "only" 2GB in total (+ possible trouble upgrading to next PR)...

On PR1.2 I haven't had any problems with / being filled up. I do, however, believe that /home (containing /home/opt) is a bit restricted in size (2GB). It can easily be filled up by installing lots of games etc.

I'd rather just shrink the FAT32 filesystem by let's say 3GB and add them to /home.

This is what my disk usage looks like:

So IF I were to repartition I'd rather see something like this:
/ 256MB ubifs on NAND
swap 768MB/1GB on eMMC
/home 1GB on eMMC *
/opt 4GB on eMMC *
(/usr 512MB on eMMC *)

* Or You could just make /home 5GB (though I'm not that big a fan of the /opt symlinking - it's just ugly). I'd also like to get rid of the /opt/pymaemo symlinks. Maybe we could create a /usr filesystem too (~512MB).

And the rest for the FAT partition.

EDIT -> Guess that *solution* is discussed here.

Because a Nokia-blessed solution would have needed to accommodate for over the air updates, which require a writable rootfs.

Of course, for your own use you can completely ignore updates.