If you read the brochure on Samsung OneNand, the 256MB model in fact is the lowest end model of the family. The siblings include 512Mb, 1Gb, 2Gb, 4Gb, and the largest 8Gb.

Has anyone contemplating swapping out the 256Mb for the 8Gb. I believe they should be pin compatible, just some fine art of soldering needed. Can such a trick be coordinated? and how much? Any possibility to get Nokia to do it for a bunch of us eager user to go full linux.

I would most prefer to have a full debian phone with a decent battery life.

Wilson
Supporter of Debian linux

I recall reading earlier in this thread that the NAND is located inside the OMAP3 core...

That is correct. It won't be possible to change without changing the processor, which is practically impossible.

EDIT: Turns out that I wasn't correct here.

No, that is wrong. The nand is soldered directly on the OMAP, a method called PoP (package on package), but they are still different packages.

Actually, being a Samsung part it is located in the same package as the 256MB of SDRAM, which is soldered on top of the processor. Theoretically you COULD replace it, but it would require access to some rather expensive hardware, and it is rather hard to buy such chips individually.

Also, wongdg, you may need to check your numbers as they typically sell flash memory in MegaBITS and not MegaBYTES, so divide by 8 to get the maximum capacity; Samsung's 8Gb (1GByte) didn't exit sampling and enter production until well after the N900's design cycle ended.

The chip in the N900 is a 2GigaBIT device, the one in the DROID and N1 are 4GigaBIT (512MByte,) and nothing I know of uses the 8GigaBIT (1GByte) chips.

Hello Ive been reading through some posts here..and this solution might be stupid call it solution D

So rootfs is to small 256MB and moving it to the /home partition in large flash will cause user data to disappear at reflash.

So what about repartitioning the large flash reducing the size of the 27GB partition creating a new root partition on the large flash lets say 1GB.

Now reflashing this partition should not overwrite any user data ?

Perhaps /dev/mmcblk0p1 could be shrunk and then remove the empty primary partition /dev/mmcblk0p4 and add it again just after /dev/mmcblk0p1 and make this the new rootfs.

Dunno how to do the last thing though.


Ohh I just realized solution D2

You could scrap the swap partition 768MB and use this as a new root partition.

Swap can then be added as a swap file (instead of a partition) inside the /home directory.

If you read through this thread you would have known that the very slow internal flash is no option.

Well what about getting bcache running on this device? It still is very alpha from what i've seen and we have the problem of different kernel versions (maybe on a meego kernel?), but that should solve the problem, right?

I think that the solutions from this thread boil down to four basic types:

1) Put most of the system in the big flash and manually selected files/directories in the fast flash (Brainstorm solutions #1 and #5)
2) Keep optification, but clean it up so that packages end up completely in /opt, without touching rootfs (currently, optification places some files in rootfs and some in /opt) (Brainstorm solution #2)
3) Put the whole system in the big flash and use the fast flash as an automatic cache (Brainstorm solution #3)
4) Don't run Maemo, run Debian (or something else) in a chroot

Of course, a fifth option is that no solution is needed:

5) Optification is not a problem, the systems work well and we have enough space in the rootfs as it is.

Some personal opinions of what I prefer after the discussions in this (and other) threads:

Out of (1) and (3), I believe mostly in (1), since I don't believe that automatic cache schedules will be precise enough to make me happy. However, to make (1) work, we need to figure out precisely what files/directories really need to be in fast flash. As an illustrating anecdote: If you move /lib/dsp to the big flash, the phone will still work fine, but CPU usage will go through the roof. Titan has done some nice work linked from Brainstorm Solution #5

(2) looks nice and clean, but I suspect that there will always be apps that need the performance of the fast flash, so reserving the fast flash only for the system is a bit too much of a limitation

I don't like (4) very much; I want to run Maemo, not Debian. If some Debian apps can easily be made to work under Maemo, that is a bonus. I don't mind if they are a few releases old (like back in Etch). Heck, I am still running XP on my Windows box at work, and that is a lot older! The main point is, I don't want to be running two different systems at the same time.

In my opinion, (5) is plain wrong, as seen from the large number of users that continue to have problems with limited rootfs space. This fact alone makes (5) wrong and is my main reason for starting this brainstorm.

Please go to the Brainstorm and vote for your preference!

I guess I was thinking that it should be like Brainstorm solutions #1 and #5
but this way you would get a partition free for it...

Also some people say the difference in speed between the flashes do not differ so much... or I am just plain crazy.. haaahh!!