Active Topics

 


Reply
Thread Tools
jayholler's Avatar
Posts: 128 | Thanked: 4 times | Joined on Feb 2006 @ Philadelphia, PA
#61
Originally Posted by fanoush View Post
Not sure if this is still needed. This is historic issue related to bug in old ms-dos format.exe and/or fdisk.exe commands. They were too clever and were confused by previous data in the partition. I guess you can skip it but it shouldn't hurt.

If it hurts then something is seriously wrong, did you really used /dev/mmcblk1p1 and not /dev/mmcblk1 with dd command?


This is not good idea, default Nokia system expects first partition on card being FAT, if you insist on this you will need to modify few things or it will complain or fail.

This is the problem, looks like partitioning by sfdisk somehow doesn't work for you (or you erased if via bad dd above). Can you repartition card in desktop linux via usb card reader?


You can use swap on internal card partiton 1 (FAT) and still boot from partition 2 (ext2) on same card. This is IMHO the best setup. Then you have external slot completely free for other cards.

Yes, I'd guess some problem with partitioning the card. Try also 'dmesg' command to see kernel log, if you don't see i/o errors card is probably not bad.
OK, you rule fanoush. I think i must have screwed something up somewhere along the way, I can't even remember how many times I have tried the partition part, and i have done it before, I know it shouldn't be this difficult. I must have screwed something up. I do have a linux system. I can partition the card using Ubuntu, and then finish on the N800?

THanks for your help and severe patience!!
 
jayholler's Avatar
Posts: 128 | Thanked: 4 times | Joined on Feb 2006 @ Philadelphia, PA
#62
So now I've been able to partition the card appropriately:

Disk /dev/mmcblk1: 62032 cylinders, 4 heads, 16 sectors/track
Warning: The partition table looks like it was made
for C/H/S=*/255/63 (instead of 62032/4/16). For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/mmcblk1p1 0+ 60 61- 489951 6 FAT16
/dev/mmcblk1p2 61 246 186 1494045 83 Linux
/dev/mmcblk1p3 0 - 0 0 0 Empty
/dev/mmcblk1p4 0 - 0 0 0 Empty
but now the next step is failing me:

/home/user # mount /dev/mmcblk1p2 /opt
mount: Mounting /dev/mmcblk1p2 on /opt failed: Invalid argument

Last edited by jayholler; 2007-02-17 at 14:55.
 
sebastian.linux's Avatar
Posts: 91 | Thanked: 2 times | Joined on Jan 2007 @ Spain
#63
Originally Posted by jayholler View Post
So now I've been able to partition the card appropriately:
but now the next step is failing me:
You need to format the partition before mounting it.
 
Posts: 3,401 | Thanked: 1,255 times | Joined on Nov 2005 @ London, UK
#64
Also make sure ext2.ko and mbcache.ko are loaded.
 
Posts: 152 | Thanked: 6 times | Joined on Dec 2006
#65
Originally Posted by Milhouse View Post
Also make sure ext2.ko and mbcache.ko are loaded.
I think some of the modules have to be loaded in certain order. I'm not sure if you have to load mbcache.ko first or not. Also, you can't use modeprobe to load it, you have to use insmod and point to the correct folder.
 
Posts: 3,401 | Thanked: 1,255 times | Joined on Nov 2005 @ London, UK
#66
Yes - mbcache.ko first, followed by ext2.ko using insmod. As it says in the howto
 
Posts: 150 | Thanked: 3 times | Joined on Jan 2007
#67
Guys, I have two little questions. I have no experience with that kind of "deep" booting related stuff on Linux systems. That are subjects, I alwasys missed somehow So the first question is:
Why should there be at least one FAT partition on the mmc/sd card when booting from it? Ext2 is the boot partition with rootfs, so what's the FAT partition for?
The second interrogation mark in my head is the wear issue. Jffs2 uses wear leveling to harmonize the write cycles throughout the jffs2 partition. So if we have a 512 mb parition, we have to commit about 50tb of traffic (512 * 10^-6*100000) to reach the 100k cycles limit. By the time we reach this amount there should be Nokia Internet Tablet OS 2280, so that's not a problem.
But what about ext2? If we are unlucky, we can wear out some specific blocks in a few months and had to suffer from read errors. Does the SD Controller have error correction? 2bit errors in one word (does not matter that much wich size, imho) are unlikely and 1bit errors can be corrected easily... Hmmm.. just some thoughts on it.
 
jayholler's Avatar
Posts: 128 | Thanked: 4 times | Joined on Feb 2006 @ Philadelphia, PA
#68
Originally Posted by Milhouse View Post
Yes - mbcache.ko first, followed by ext2.ko using insmod. As it says in the howto
Yeah, I have those loading in the rcS file, which works nicely on the N800. Turns out that sfdisk formating the card too many times has screwed something up. I am going to see what some othr utilities can do for me. I tried the process again with a 128MB card, and it worked great until tar ran out of room. I appreciate all the help, but I've got to figure out what is wrong with the card before I can get this dual boot situation working.
 
Posts: 152 | Thanked: 6 times | Joined on Dec 2006
#69
Originally Posted by DCr33P View Post
Why should there be at least one FAT partition on the mmc/sd card when booting from it? Ext2 is the boot partition with rootfs, so what's the FAT partition for?
The fat partition is to store data, well at least data that used by the application that nokia made, stuff like contact, backup, etc. Which make good sense, because in windows world, FAT is the best compatibility FS between all OSes. It make things a lots easier to move data around between Windows&Linux&n800.
Originally Posted by DCr33P View Post
The second interrogation mark in my head is the wear issue. Jffs2 uses wear leveling to harmonize the write cycles throughout the jffs2 partition. So if we have a 512 mb parition, we have to commit about 50tb of traffic (512 * 10^-6*100000) to reach the 100k cycles limit. By the time we reach this amount there should be Nokia Internet Tablet OS 2280, so that's not a problem.
Well, there is no way to predict when the flash will fail or how many write it will take. So, moving the written part to the SD card is better because it's replacable regardless of when or how it fails.
Originally Posted by DCr33P View Post
But what about ext2? If we are unlucky, we can wear out some specific blocks in a few months and had to suffer from read errors. Does the SD Controller have error correction? 2bit errors in one word (does not matter that much wich size, imho) are unlikely and 1bit errors can be corrected easily... Hmmm.. just some thoughts on it.
well, if you like you don't have to use ext2 as a rootfs, you can still use jffs2. The problem is that jffs2 is compressed fs therefore, overhead. You could also make it use other fs also, like ext3 or jfs, but you will have to compile the kernel yourself. The kernel&loader are store on flash, and those things are read-only. The root can be store anywhere.
 
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#70
Originally Posted by DCr33P View Post
Why should there be at least one FAT partition on the mmc/sd card when booting from it? Ext2 is the boot partition with rootfs, so what's the FAT partition for?
it is easier this way, nokia system expect first partition to be FAT. it is also great for interoperability, other systems expect memory cards to be FAT too. For SD cards filesystem specification is even part of SD standard. All SD cards should be FAT (FAT16), all SDHC cards should be FAT32.

Originally Posted by DCr33P View Post
But what about ext2? If we are unlucky, we can wear out some specific blocks in a few months and had to suffer from read errors. Does the SD Controller have error correction?
As cards are expected to be FAT and this is very unfriendly filesystem for flash memory I wouldn't bother with ext2 :-)

SD/MMC memory cards (must) have its own internal logic for block management similar to hard disks. You can't tell which block is really used by the card when writing same block of filesystem. There are many reasons for this
- wear levelling and bad block management
- physical block size of NAND flash memory is different than filesystem block size and writing rules are much more complicated - blocks need to be written as a whole and erased before writing, it is better to handle this transparently inside card (i.e. pre-erase them and keep a pool of such fresh blocks ready for writing for better speed )
 
Reply


 
Forum Jump


All times are GMT. The time now is 06:02.