Booting from cramfs with 2.6.11

Pawel Studencki pstudencki at yahoo.com
Thu Apr 14 01:48:24 EST 2005


 hallo,
  
 after solving some problems I got 2.6.11 kernel
 booting on my board with
 8xx.
 Now I'm trying to mount cramfs root filesystem from
 flash. I've debuged this
 until inode->i_op->lookup in real_lookup function -
 I hoped to see here
 cramfs_lookup, but simple_lookup was called instead
 of that...
 
 From the beginning: mounting process starts in
 do_mount, where with call
 path_lookup it is looked for mount point. Actually
 it is function
 link_path_walk, where do_lookup is called - it
 returns a dentry using
 function real_lookup (and i_op->lookup is equal
 simple_lookup). inode of the
 returned dentry is NULL. So link_path_walk returns
 -ENOENT (-2), the same
 value returns than path_lookup and do_mount.
 
 I thought, the problem is wrong i_op->lookup
 function (simple_lookup instead
 of cramfs_looup). But the right values will be set
 first in do_new_mount
 calling do_kern_mount.
 
 here is a simple draft to help you understand...
 
 sys_mount(name, "/root", fs, flags, data);  - in my
 case fs is cramfs.
 |
 |-->do_mount()
 	|
 	|-- some checks...
 	|
 	|-- path_lookup()
 	|		|
 	|		|-- link_path_walk() (fs/namei.c)
 	|				|
 	|				|-- do_lookup() (returns
 next.dentry)
 	|				|	|
 	|				|	|-- __d_lookup
 	|				|	|
 	|				|	|-- real_lookup(nd->dentry,
 name, nd);
 	|				|	   |
 	|				|	   |-- dentry =
 d_alloc(parent, name);
 	
 (dentry->d_inode=NULL)
 	|				|	   |
 	|				|	   |- result =
 dir->i_op->lookup(dir, dentry, nd);
 							 !!! result is a
 dentry with inode = NULL !!!	
 	|				|
 	|				|
 	|				|
 	|				|
 	|				|
 	|				|-- follow_mount()
 	|				|
 	|				|
 	|				| inode = next.dentry->d_inode;
 (inode is NULL!!!!)
       |          	
 	|
 	|
 	|-- do_new_mount()
 		|
 		|-- do_kern_mount() (fs/super.c)
 			|
 			|-- type->get_sb (type is cramfs, and first
 get_sb
 sets i_op....
 						see fs/cramfs/inode.c )
 
 
 I don't understand all dependances, so perhaps
 someone could give me a hint,
 what is wrong here...is this normal that a dentry
 hat inode NULL? should the
 function cramfs_lookup be called here? If so, is
 there another place, where
 i_op is set?
 
 best regards 
 
 Pawel
 
 

----------------------------------------------------------------------------
> ------
> Linux version 2.6.11 (nb221330 at nb2g156c) (gcc
> version 3.3.4) #29 Wed Apr 13
> 14:38:33 WEST 2005
> Built 1 zonelists
> Kernel command line: console=ttyCPM0, 57600
> root=/dev/mtdblock1
> rootfstype=cramfs ro
> PID hash table entries: 128 (order: 7, 2048 bytes)
> Decrementer Frequency = 187500000/60
> m8xx_wdt: wdt disabled (SYPCR: 0xFFFFFF88)
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 4096 (order: 2,
> 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192
> bytes)
> Memory: 14748k available (996k kernel code, 372k
> data, 60k init, 0k highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096
> bytes)
> NET: Registered protocol family 16
> JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat,
> Inc.
> Serial: CPM driver $Revision: 0.01 $
> ttyCPM0 at MMIO 0xff000a60 (irq = 43) is a CPM UART
> io scheduler noop registered
> loop: loaded (max 8 devices)
> physmap flash device: 400000 at ffc00000
> phys_mapped_flash: Found 1 x16 devices at 0x0 in
> 16-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due
> to code brokenness.
> Creating 5 MTD partitions on "phys_mapped_flash":
> 0x00000000-0x000d0000 : "Kernel"
> mtd: Giving out device 0 to Kernel
> 0x000d0000-0x001d0000 : "RootFS"
> mtd: Giving out device 1 to RootFS
> 0x001d0000-0x00300000 : "ApplFS1"
> mtd: Giving out device 2 to ApplFS1
> 0x00300000-0x00330000 : "U-Boot"
> mtd: Giving out device 3 to U-Boot
> 0x00330000-0x00400000 : "ApplFS2"
> mtd: Giving out device 4 to ApplFS2
> slram: not enough parameters.
> 
> VFS: Cannot open root device "mtdblock1" or
> unknown-block(31,1)
> Please append a correct "root=" boot option
> Kernel panic - not syncing: VFS: Unable to mount
> root fs on
> unknown-block(31,1)
>
----------------------------------------------------------------------------


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



More information about the Linuxppc-embedded mailing list