256mb for installable aplications?? Am I awake or is this only a bad dream? [Archive] - maemo.org

mgtman

2009-09-30, 16:46

The extensive and detailed Michal Jerz preview of the N900 at My-Symbian (http://my-symbian.com/other/preview_n900.php) showed up what seems to be a HUGE PROBLEM in this otherwise terrific device. Jerz found out that in spite of the huge 32gb of internal memory, only 256mb are defined for "installable aplications", as you can see in the picture below. Well, if this limitation happens to be maintained in the final N900 release, we can say it will be an ENORMOUS DRAWBACK in the device, since Jerz was able to easily fill the entire 256mbs dedicated to 3rd party software, and needed to uninstall several programs in order to test new ones. How come does Nokia do that to a device with so much potential? Does Nokia desire to bury the pontenciality of the N900 right from scratch, just like it did to the N97 which could have been a cutting edge smartphone but, instead, was granted the outdated ARM11 with no GPU and only 128Mb of RAM?

http://my-symbian.com/other/show2.php?pic=scr64.jpg

frals

2009-09-30, 16:50

Hi! This has been discussed with the previewer and members of the community at http://talk.maemo.org/showthread.php?t=32182&page=9 (somewhere around that page). :)

UCOMM

2009-09-30, 16:50

no you'll have 1gb to install stuff, possible 2gb, and if you're an enterprising fellow you could have more than that

romanianusa

2009-09-30, 16:54

Yea i don't understand why memory can't be shared across the board...just like a PC. If i have 32GIG of memory, I know i can rely on it for application installation and not just dedicated to video and photos ect.. Maybe they dedicated certain segment of memory in order to speed up the loading process...but you're right...whatever it maybe, the app memory shouldn't be that low. I am betting that it is not the final stage of development. Maybe that's why they delayed it to modify it and iron out other things too.

GeneralAntilles

2009-09-30, 17:01

Maybe that's why they delayed it to modify it and iron out other things too.

Yes, it'll be different in the production device. No, this is not a reason for delay.

mgtman

2009-09-30, 17:14

pycage

2009-09-30, 17:25

Because it's a _mobile_ computer and people will want to attach it to their non-mobile computer via USB. This only works if the data and the OS are on different partitions due to technical reasons.

iKneaDough

2009-09-30, 17:25

If the N900 is really a mobile computer as Nokia advertises it, there should be NO separate memory for applications at all! We should be able to use its 32gbs with whatever we want - applications, data or documents. If I can do that with my humble 5800XM, why can't we in a powerful linux mobile computer??

Probably because applications need to be on the ext3 filesystem, which is not readable in windows (unless using a special driver or other software), whereas the documents and other media can work fine from a FAT filesystem, and then can be read by almost any other OS when plugged in via USB.

javispedro

2009-09-30, 17:26

Choose: ability to use the device as a Windows-compatible mass storage device, or ability to use the full 32 GiB for apps.

You'll be able to change between the two by reformatting the internal card at your pleasure. This is the reason this device is a mobile computer, and not because Nokia put this or forgot to put that.

solideogloria

2009-09-30, 17:32

... why can't we in a powerful linux mobile computer??

because it is linux! the os and the applications are stored on a seperate partition formatted with linux file system (ext3)
The mass-storage partition is formatted with a FAT32(?) filesystem to be compatible with windows. If the whole filesystem was formatted with ext3 (in order to use it as application memory), there would be no usb mass storage for windows computers.
The same applies to desktop PCs: i have two dedicated partitions, one for windows and one for linux.

However it might be possible to change the size of the partition. i assume the community will figure it out.

EDIT: whoops! 2 posters where faster than me.i definitly need to type faster :)

eber42

2009-09-30, 17:34

I'm not sure I understand why we can't solve the problem the same way as it has been done with n810 : just move the root filesystem to the large device and use something like Fanoush boot menu.

That was the first thing I did after unpacking my new n810, and now I've got a 2GB root filesystem (and no ugly symlinks or modified debs).

So let's go for a 32Go (minus swap) ext2/3 root filesystem, or split it between ext&vfat if you really want windows compatibility with USB

mgtman

2009-09-30, 17:35

Well, if that is the case, 256mb still seems to be a very small partition. There should be an option in Maemo itself to let the user reconfigure manually the size of this partition.

zerojay

2009-09-30, 17:44

Relax, guys. It's not going to be a big deal and yes, I'm sure some of our more enterprising community members will decide to do things differently and pass on their efforts to you if the partitioning really does end up being a big deal for some reason.

attila77

2009-09-30, 19:16

I'm not sure I understand why we can't solve the problem the same way as it has been done with n810 : just move the root filesystem to the large device and use something like Fanoush boot menu.

That was the first thing I did after unpacking my new n810, and now I've got a 2GB root filesystem (and no ugly symlinks or modified debs).

There is no reason why you couldn't do that on a N900. However, if it was the first thing you did with your N810, you probably didn't notice that the original root flash is significantly faster than the internal MMC :) Also, there are several reasons why you don't want to be swapping on the same card on which your root is on.

qgil

2009-09-30, 19:35

I'm sure it's been said somewhere but the canonical reference is http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs

ruskie

2009-10-01, 06:05

I'll definitley be one of the enterprising people that will modify the emmc partitions to better fit with what I consider standard layouts(as in FHS)

Bytales

2009-10-01, 07:18

That's the smartest way to do it. If you happen to need more than 2 gbs for apps, just use this option to extend the apps partition using memory from the 32gb internal.
This seems to me the most logical way to solve things, if indeed you need different partition for the linux apps

TA-t3

2009-10-01, 10:22

In any case, the 256 MB (and not mb, millibit) is a compressed filesystem, it can take a lot more than what it seems to. And the applications are much smaller than your desktop variants, Nokia likes to automatically remove the documentation part etc. etc.

I haven't yet filled the NAND in my N800 and I believe I have installed just about everything of interest, the major difference from some other folks around here is that I haven't installed any of the multi-media applications (canola etc.).

And, as has been said already, you're free to organize things differently in any case. And a common way to do this is also in planning[1], so there just is no reason to panic at all.

[1] Check the link in post #15 above.

Matan

2009-10-01, 10:50

However, if it was the first thing you did with your N810, you probably didn't notice that the original root flash is significantly faster than the internal MMC.

Are you sure about that? Even if the physical underlying flash is faster, the internal NAND goes through ECC and compression (JFFS2), so it is unlikely to come out faster in the end.

Both benchmark tests and subjective impression of the boot times suggest to me that the internal MMC is faster.

Also, there are several reasons why you don't want to be swapping on the same card on which your root is on.

That might be so, but since practically every computer in the world does that, and at least one issue for hard drives (seek time) is irrelevant for flash memory, I expect it is not really a great problem.

I think every user of the N900 should move the root to the 32GB, if only for backup. That way, even if you somehow mess your system until it is unbootable (and let's face it, if it is a computer then everyone will do that once in a while), you can still boot from the NAND, and have a working phone.

attila77

2009-10-01, 11:22

Are you sure about that? Even if the physical underlying flash is faster, the internal NAND goes through ECC and compression (JFFS2), so it is unlikely to come out faster in the end.

Both benchmark tests and subjective impression of the boot times suggest to me that the internal MMC is faster.

No, I didn't mean the physical flash, but the process - compression does not necessarily slow you down (if you can (de)compress faster than you can read/write, you're actually better off). When I discussed some loopfile-related projects with Nokia folks it has been suggested that they *did* benchmark it and the internal flash was significantly slower. I would reference it, but it was in an off-list reply so for now you will have to take my word for it unless the original author chimes in :)

That might be so, but since practically every computer in the world does that, and at least one issue for hard drives (seek time) is irrelevant for flash memory, I expect it is not really a great problem.

Actually, no. Flash is good at big, continuous reads and writes, but a lot of small parallel operations can bring it to it's knees with regard to overall performance. Try starting a larger Qt app on a cloned setup and you'll se the problem - it will read the Qt libs from the card and as it takes up memory start to swap on the same card, resulting in abysmal startup times and several seconds of total unresponsiveness.

This is also one of the main reasons Qt and Python are not optified in Fremantle - so they would not be on the same device as the swap.

andree

2009-10-01, 12:21

attila77

2009-10-01, 12:25

Oh, we're way beyond the question IF it can be done, the question is what's the easiest/best way to do it :)

chemist

2009-10-01, 12:30

guys, maemo is linux, you really don't have to worry about how the disk is partitioned - it sure as hell will be 'fixable' one way or the another (if not by repartitioning, then by using some loopback mount etc. etc.)..

I would consider this being a trivial problem - as soon as I have the device in my hands, I'll post some how-to.. But I'm quite sure this will be solved as soon as any other linux-user has the device in his hands ;-)

and also prototype devices setup might be just that way as its for testing stuff... if id like (just example) to test speeds I would get a bunch of files in 25GB overall size and transfer them, to do that I would need to partition just like it was shown in the reviews, after I setup my testing device I need to prepare the SW for those prototypes (some lazy guy left on my desk this morning) to be shipped to those review guys today, so to save some time (I am lazy as well) I'd just copy the system I just setup for myself to those 20 N900 on my desk to get early out for lunch cause I will meet this adorable blonde if I get there by time! (and maybe the dishes are hot aswell :p )

do you get the point?
if its that way we need a howto to change it if we like but I honestly think it wont be...

fanoush

2009-10-01, 12:35

No, I didn't mean the physical flash, but the process - compression does not necessarily slow you down (if you can (de)compress faster than you can read/write, you're actually better off).

at least it eats a lot of CPU which is bad if the CPU time is needed somwhere else. Maybe with N900 cpu being faster this is not such big issue but with 700 and N8x0 the CPU hit is IMO significant. Also CPU usage = battery drain.

When I discussed some loopfile-related projects with Nokia folks it has been suggested that they *did* benchmark it and the internal flash was significantly slower. I would reference it, but it was in an off-list reply so for now you will have to take my word for it unless the original author chimes in :)

would like to see some data because I don't believe it too. Both with 770 and N8x0 root on SD/MMC is faster than jffs2 in my experience. There are some specific use cases where it is slower (like using sqlite which does fsync after each database write see https://bugs.maemo.org/show_bug.cgi?id=1842#c13 ) but overall it feels faster to me. Even with swapping it shouldn't be so bad. As for benchmarks simple read only or write only tests should be definitely faster with sd/mmc. I never did some concurrent read/write benchmark but can see that this may indeed be a problem. But how often we see concurrent read and write except swapping?

Try starting a larger Qt app on a cloned setup and you'll se the problem - it will read the Qt libs from the card and as it takes up memory start to swap on the same card, resulting in abysmal startup times and several seconds of total unresponsiveness.

swap is slow in any case. I don't think actively using more memory than available is good idea in any case. And BTW one can swap to (or boot from) other SD/MMC card if this is really a bottleneck in real life.

This is also one of the main reasons Qt and Python are not optified in Fremantle - so they would not be on the same device as the swap.
Oh really? Hmm, I know for N900 they configured 756 MB for swap, this also feels very strange to me with only 256MB of real RAM. Planning to use so much swap feels somehow wrong to me. Well we'll see once we have real devices in our hands. I definitely plan to boot from something else than internal NAND.

attila77

2009-10-01, 12:57

would like to see some data because I don't believe it too.

Hey, don't shoot the messenger :) My sources are Antonio and Kimitake/Kimmo, so you can ask them for specific figures.

fanoush

2009-10-01, 13:13

Hey, don't shoot the messenger :) My sources are Antonio and Kimitake/Kimmo, so you can ask them for specific figures.
I'm not shooting anyone and I heard the 'mmc is slower' story in maemo-developers before (without any numbers as a proof). i do believe there are issues with concurrent read/write mmc access, ext3 filesystem and also other significant issues (like firmware flashing) which caused Nokia to stay away from having rootfs on mmc but still it does not mean rootfs on MMC is bad idea or is slower in general.

HangLoose

2009-10-01, 13:19

attila77

2009-10-01, 13:20

I wish I could just post that mail over here to avoid getting anecdotal... :(

attila77

2009-10-01, 13:25

There should be a option in the phone of how much memory (between max and min) one wants to allocate to applications. PERIOD.

It's not that easy. The space is provided by two (or three) different devices with different underlying technologies, filesystems, etc. ANY choice made will be a compromise. A slider can be made (in fact, there is one, called AppSpace, by yours truly :) ), but it doesn't change the fact there is no universally superior solution, the question is only what are you willing to sacrifice.

TA-t3

2009-10-01, 13:34

There should be a option in the phone of how much memory (between max and min) one wants to allocate to applications. PERIOD.

Maybe some noble soul will develop something as straight forward as a panel with a slider...
That's something you can do if you have a PDA with memory, as in battery-backed RAM (e.g. windows mobile PDAs). That concept makes no sense at all when you have proper filesystems, shared between different physical parts. On a WinCE device like I described above you have to reduce actual memory (as in RAM, not as in mass storage) to make room for applications.

IMHO, this is unacceptable that a mobile computer should have this kind of restriction.
You haven't read the thread. This is all a red herring. There will be no problem getting enough space for applications.

HangLoose

2009-10-01, 14:02

You haven't read the thread. This is all a red herring. There will be no problem getting enough space for applications.

Funny you telling me that I have *NOT* read the thread... I am not going to argue about this since I did and unless you are spying over my back this is just a weird assumption... :eek:

And about getting enough space... There will *ALWAYS* be users trying to stuff the device with zillions of apps and whatever restrictions in terms of space, no matter how technical, will not convince the-average-joe. :cool:

iKneaDough

2009-10-01, 14:13

swap is slow in any case. I don't think actively using more memory than available is good idea in any case. And BTW one can swap to (or boot from) other SD/MMC card if this is really a bottleneck in real life.

I have an N800 and boot from mmc, and tried a swap partition on both the same, and on the secondary mmc, and in either case it was always slow and laggy.

I recently installed Ramzez, and turned off the swap partition, now things run a lot smoother, but I can't open as many programs at once since the swap size now is much smaller than my swap partition.

TA-t3

2009-10-01, 14:20

Funny you telling me that I have *NOT* read the thread... I am not going to argue about this since I did and unless you are spying over my back this is just a weird assumption... :eek:
Why weird? If you want to find out how I reasoned about that, see below.

And about getting enough space... There will *ALWAYS* be users trying to stuff the device with zillions of apps and whatever restrictions in terms of space, no matter how technical, will not convince the-average-joe. :cool:
The thread has made it pretty clear that, if you want to, you can install applications using every available byte in the mass storage available on the device, if that is NAND or whatever monster micro-SD card you install. So: The problem raised in the original posting is a red herring, and continuing to complaining about it doesn't make any sense.

(If, on the other hand, your meaning was that people will start complaining not because they can't use all the room, but that there isn't enough room (as in: wanting to install 70GB of applications), then there's no reason to continue the discussion either.)

DaveP1

2009-10-01, 14:28

PetriS

2009-10-01, 14:40

IMHO, this is unacceptable that a mobile computer should have this kind of restriction.

Hi! Please see the post number 6 and its responses on the first page of this thread for your concerns.

This thread topic wording is severely misleading at this point. I am also a bit sorry that I pointed (http://talk.maemo.org/showthread.php?t=32182) this memory thing out too as an example of silly misinformation contained in proto previews. A bit similarly, have been watching very amused by the spreading of my awkward chosen term "extensive" preview in the web lately.. :)

Jack6428

2009-10-01, 16:24

Hogwash

2009-10-01, 16:35

Choose: ability to use the device as a Windows-compatible mass storage device, or ability to use the full 32 GiB for apps.

Fsck Windoze....I'll use the full 32Gb as ext3 ;)

I haven't touched M$ crap for over a decade.

eber42

2009-10-02, 05:42

There is no reason why you couldn't do that on a N900. However, if it was the first thing you did with your N810, you probably didn't notice that the original root flash is significantly faster than the internal MMC :) Also, there are several reasons why you don't want to be swapping on the same card on which your root is on.
I've also used OS from original root flash sometime, and i agree it was a bit faster (main difference is large applications start time and boot time), but that was not a big change in usability for me. I feel the main performance limitation on n810 has been small RAM + slow swap.

But I think Nokia choose the right solution for N900, because it will be adequate for 99% of users, and any performance improvement is important because i'm sure people will post video on youtube with speed comparison between iphone and n900 for basic tasks :).

And people who will prefer to have the convenience of a large root filesystem (even with some trade-off) will be able to do it.

BTW N900 will also run "optified" applications from mmc, so I assume you'll get no gain (or small one because of system shared libs used) for third party applications.

PS: You gave me an idea: I'll try to put my swap on the small and fast flash memory. Anyone tried this ?

eber42

2009-10-02, 06:06

I recently installed Ramzez, and turned off the swap partition, now things run a lot smoother, but I can't open as many programs at once since the swap size now is much smaller than my swap partition.

You can use ramzez and swap partition at the same time.
Just make sure ramzez has an higher swap priority so it will be used first. Swap partition will be used only when ramzez is full.
Maybe some information here: http://talk.maemo.org/showthread.php?t=32105

fanoush

2009-10-02, 07:58

I've also used OS from original root flash sometime, and i agree it was a bit faster (main difference is large applications start time and boot time)

Hmm, even boot times? That's interesting. I haven't noticed anything like that. Maybe there is some difference in setup? here are my details:

- I'm using ext2 (with noatime) for N8x0. It is pretty stable so ext3 is not needed, For 770 I was using ext3 since it reboots more often. ext2 block size is default (4096), I've experimented with smaller block (to save space with small files) but it was slower. Most probably the bigger block the better (default FAT filesystem on SD cards uses 32kilobytes) but maybe it is not so critical, linux kernel should merge I/O requests for adjacent blocks.

- I'm also using kernel with high-speed (48MHz) sd/mmc mode (on N8x0 it speeds up mmc raw read speed from ~6MB/s to ~10MB/s).

- I have metalayer-crawler disabled (it does a lot of card scanning which takes many minutes after boot or card change, bugzilla link mentioned in previous post).

- I have also lowered priority of mmcqd kernel threads from -5(?) to 0 since with default raised priority it sometimes causes audio skips in playback and may block other threads. 0 was default in kernels before 2.6.18, I never understood why they raised it (bug or feature?). maybe this is the reason why your device freezes when swapping? mmcqd eats a lot of cpu when writing to the card. This can be changed by running renice 0 `pidof mmcqd` as root (in some startup script and when cards are inserted (/usr/sbin/osso-mmc-mount.sh).

- it should also help to change cpu frequency setting from ondemand to performance or raise the minimum frequency (to 330 or even 400) since there is a kernel bug/feature (https://bugs.maemo.org/show_bug.cgi?id=2838) - lower cpu clock lowers also mmc bus clock which slows sd/mmc I/O down when cpu is idle (can happen quite often when CPU waits for data). It can make battery life shorter when cpu is used a lot, it shouldn't make much difference when cpu is idle.

I'll try to put my swap on the small and fast flash memory. Anyone tried this ?
you mean the internal 256MB flash? Well it is not a block device so there is no simple and effective way to swap to it. It would need some FTL that will emulate block device over it.

As for ramzez, thanks for link. Will try.

eber42

2009-10-02, 10:15

Hmm, even boot times? That's interesting. I haven't noticed anything like that.

In fact I was comparing an "out of the box" Diablo install on the 256MB internal flash and an OS with many applications and widgets installed on the internal mmc, sorry for my inaccurate comment.

I've just tried to make a more valid comparison and copied my standard Diablo install to internal mmc (just rsync to an ext2 FS and reboot), and you're right, boot time is actually faster on mmc/ext2 than on the 256MB flash (25 seconds instead of 30). This test was done without any of the optimizations you described.

you mean the internal 256MB flash? Well it is not a block device so there is no simple and effective way to swap to it. It would need some FTL that will emulate block device over it.
I assumed i could just mkswap and addswap the /dev/mtdblock4, but i won't even try as it's not that fast.

But I'll just try the high-speed sd/mmc kernel you talked about, thanks for the information (i'm already using the other tricks you described :) )

fanoush

2009-10-02, 10:42

I assumed i could just mkswap and addswap the /dev/mtdblock4,
mtdblock is not meant for heavy usage and ideally should not be used at all for reading/writing, it is here just for occasional/emergency use, there is always better way than blindly using /dev/mtdblock or /dev/mtd
http://www.linux-mtd.infradead.org/faq/general.html#L_ext2_mtd
http://www.linux-mtd.infradead.org/faq/nand.html#L_nand_copyimg

jukey

2009-10-12, 21:26

According to a thread on conversations.nokia.com (via Engadget):

Peter@MaemoMarketing Reply:
August 28th, 2009 at 8:00 am

Eldar from Mobile-Review has quite old software, so, please don’t read his review as representative of the final software. We have changed the partitioning of the storage to give more install space to apps. Final numbers will be visible closer to sales start, but there is already now plenty.

http://conversations.nokia.com/2009/08/27/finding-maemo-the-new-nokia-n900/#comment-10175

Not 24 hours after getting the n900 on the summit the rootfs partition was at 100%: there is no space left. All I did was installing fennec and some of the applications in extras-testing. I removed fennec but for example at the moment I only have 5 MB free memory in this partition and for me as normal power user there is no way to see why 45 of the 50 MB I had when started the device for the first time are already used now.

The usr/lib and user/share directory consume the most memory. But what files inside of these directories are needed and what files could better be placed somewhere else I don't know. I know the /opt directory is linked to a dir at the 2 GB partition on the memory card. Could I link other directories to a path in this partition too? If yes which exactly?

At the moment this point is the only one I don't like at the n900.

Bundyo

2009-10-13, 05:13

Yes, not every application is optified at the moment. Fennec being one of the biggest examples. :)

Jaffa

2009-10-13, 12:06

...and the stuff which goes into the user-facing Extras repository will be.

You're testing stuff by using Extras Testing, and that beholdens you to reporting problems (such as "Doesn't use /opt!"). Also, you're taking your life into your own hands by using an arbitrary third party repo ;-)

There was a good discussion BOF about /opt at the summit, and the results are being discussed on maemo-developers.

qgil

2009-10-13, 12:44

Please share the list of applications you have installed in order to make easier the detection of apps that need the optify urgently. Thank you!

jukey

2009-10-14, 13:16

Okay, it seems to be a failur alert. After 2 days now I restarted my n900 and without changing somthing now there are 50 MB of free space in rootfs available.

So it seems to be an other problem than only applications hungry for / - Memory.

If I remeber correctly I was sharing a 100 MB video file (I was uploading it) via flickr. Than the internet connection was gone and the next I remeber was that there was left no space. maybe this could be a possible reason?

I will keep my eyes open and fill a bug report if I am able to reproduce the memory loosing in a good way.

Thanks for your hints and descriptions!

Ciao jukey

attila77

2009-10-14, 15:00

mplayer is a non-optified biggie

jukey

2009-10-21, 07:26

mplayer is a non-optified biggie

Canola2 RC4 is an other giant. It uses at least 4.2 MB space. I opened a bug for this:
https://bugs.maemo.org/show_bug.cgi?id=5661

It would be nice to have a special keyword in bugzilla for these issues. My suggestion is: non-optified

What do you think?

pycage

2009-10-21, 09:19

Another problem even with all 3rd party packages optified (or relocated to /opt which I prefer as being less of an ugly hack) is the apt-system with it's indexes, caches, and database. It can easily eat up 30 MB or more of your root fs even though there's not much stuff installed. Heck, solely disabling the extras-devel repo freed 3 MB on my root fs because the index files were that big.

mece

2009-10-21, 09:50

Just wondering, is there some relatively easy method to repartition the whole thing? If I wanted to say use 16 Gb for rootfs and opt or something, are there limitations to this? How would I go about doing that?

EDIT to make sense

pycage

2009-10-21, 10:46

I think the limitation there is that the rootfs and the 32 GB flash are on differerent flash chips. The rootfs one being tiny and fast.

mece

2009-10-21, 10:57

Are we sure about this or is it just speculation?
If yes then the way to go would be to have a big opt then i suppose. hmpf. Not really what I wanted to hear. Either way, reparitioning the opt should work without reinstalling anything as long as it's empty, and the rest is empty, right?

pycage

2009-10-21, 11:09

As of now, /opt is a symlink to /home/opt which resides a 2 GiB partition. /home/user/MyDocs occupies the rest of the 32 GB (note that this is GB, not GiB).

mece

2009-10-21, 11:20

What I meant was is it a confirmed fact that
[...] the rootfs and the 32 GB flash are on differerent flash chips. [...]
Or is it just speculations?

And the opt and home partitions can be resized as one wishes, amIright?

pycage

2009-10-21, 11:46

This is what sfdisk -l shows:

This is the 32 GB flash:

/dev/mmcblk0p1 28 GB FAT 32
/dev/mmcblk0p2 2 GB Linux
/dev/mmcblk0p3 768 MB Linux swap
/dev/mmcblk0p4 Empty

I can't ssh into the device right now at work, so I can't copy&paste the sfdisk -l output. Maybe someone else can. I don't see the rootfs here. But you can see from the output that it's not on the internal 32 GB flash.

fanoush

2009-10-21, 11:49

And the opt and home partitions can be resized as one wishes
Yes, of course, just like you would do it on any other linux machine :) /opt should be a filesystem with unix permissions (currently ext3?), /home/user/MyDocs is fat32 and is exported over USB.

Once I get the device I definitely plan to play with this a lot (i.e. repartition, move whole system to eMMC, boot from microSD).

mece

2009-10-21, 11:53

I can't ssh into the device right now at work, so I can't copy&paste the sfdisk -l output. Maybe someone else can. I don't see the rootfs here. But you can see from the output that it's not on the internal 32 GB flash.

Nice to see the swap there at least, so you can resize that if needed. I wonder how much slower it would be to have everything on the 32GB flash.

fanoush

2009-10-21, 11:54

I can't ssh into the device right now at work, so I can't copy&paste the sfdisk -l output. Maybe someone else can.
It would be great if anyone with device would care to update http://wiki.maemo.org/Nokia_World_2009_QA#Maemo_5 (the 'output of' part)

Heck, I would love to get N900 firmware image, that would answer me a lot of questions :-)

Jaffa

2009-10-21, 12:46

What I meant was is it a confirmed fact that
[/opt and / are on different flash chips, with the 256MB rootfs one being faster]
Or is it just speculations?

It's not speculation. It has been discussed on the PyMaemo and maemo-developers mailing lists. It was re-mentioned by Marius Vollmer (a Nokian) at the /opt BOF at the summit.

One thing which was suggested was putting swap on the fast, 256MB chip and the whole rootfs on the eMMC (32GB, partitioned into both VFAT and ext3).

And the opt and home partitions can be resized as one wishes, amIright?

Correct.

javispedro

2009-10-21, 12:54

One thing which was suggested was putting swap on the fast, 256MB chip and the whole rootfs on the eMMC
With a proper swap configuration, that may actually help, even considering the slow eMMC.

Jaffa

2009-10-21, 12:56

It would be great if anyone with device would care to update http://wiki.maemo.org/Nokia_World_2009_QA#Maemo_5 (the 'output of' part)

Given the NDAs are now up, anyone with a device can do this. So, see: http://bleb.org/software/maemo/maemo5-dump.txt

Heck, I would love to get N900 firmware image, that would answer me a lot of questions :-)

No firmware images have been distributed yet, even then redistributing the N8x0 images was a breach of the T&Cs.

fanoush

2009-10-21, 13:23

see: http://bleb.org/software/maemo/maemo5-dump.txt

Thanks.

dmesg would be best done early after boot (like adding dmesg >/dmesg.txt to /etc/init.d/rcS or similar early boot script), there is one here http://talk.maemo.org/showthread.php?p=343952#post343952 done by hand after device boots. With the boot script we could get a few more lines but it is nothing critical.

As for swapping to internal flash... I'm not sure why the current flash partition size is 768MB (maybe because of wear leveling?) but maybe 256MB only should do too. And while mtd is not a block device so one cannot swap to it direcly, there appears to be one old attempt of mtdswap driver done/paid by Nokia
http://www.infradead.org/pipermail/linux-mtd/2007-March/017603.html and there are also attempts to implement block layer over UBI http://lists.infradead.org/pipermail/linux-mtd/2008-May/021609.html so swapping to internal flash might be good idea when system is on MMC.

qwerty12

2009-10-21, 13:39

dmesg would be best done early after boot (like adding dmesg >/dmesg.txt to /etc/init.d/rcS or similar early boot script), there is one here http://talk.maemo.org/showthread.php?p=343952#post343952 done by hand after device boots. With the boot script we could get a few more lines but it is nothing critical.

Here is the output of a "dmesg" ran right at the start of rcS: http://qwerty12.qole.org/dmesgb4script.txt

And here is one ran before the rcS script exits: http://qwerty12.qole.org/dmesgafterscript.txt

mece

2009-10-21, 13:45

One thing which was suggested was putting swap on the fast, 256MB chip and the whole rootfs on the eMMC (32GB, partitioned into both VFAT and ext3).

I was thinking that too. But would 512Mb of memory be enough?

Perfect would be to have two swap partitions first the fast small one with 256Mb and a secondary ~1Gb. Not doable (in practice) afaik, but a man can dream.

javispedro

2009-10-21, 14:00

It's doable, I currently do that on my desktop computer...

mece

2009-10-21, 14:03

Ok, so, is it doable on the N900?

fanoush

2009-10-21, 14:03

Here is the output of a "dmesg" ran right at the start of rcS: http://qwerty12.qole.org/dmesgb4script.txt
Cool, thanks, so it is all there right from the zero. And btw the equivalent of old /linuxrc is /sbin/preinit, it should be simple script doing some magic and exec-ing /sbin/init in the end. Also BTW there is still initfs partition in the flash, I wonder if it is just some unused leftover?

qwerty12

2009-10-21, 14:15

And btw the equivalent of old /linuxrc is /sbin/preinit, it should be simple script doing some magic and exec-ing /sbin/init in the end.

Right on.

It does do "similar" to the N8x0s' linuxrc, but unlike linuxrc, it has an explicit clause saying that redistribution is forbidden. :)

Also BTW there is still initfs partition in the flash, I wonder if it is just some unused leftover?

I'm pretty sure it isn't mounted. ;)
But, instead of "$T2S -t "initfs version:" -s 2 -x $x -y $y -B $bg_color", we now have: "text2screen -t " no initfs \o/" -s 2 -x $x -y $y -B $bg_color"

:p