Hi All,
I am new to linux kernel stuff. I am using Cogent CSB535FS board. I
have configured the kernel to include support for MMC card and also
i.MX MMC driver. When I insert the card, it says :
# imx-mmc imx-mmc.0: card inserted
So, the kernel has identified that MMC has been inserted. I have
the following dev entries for mmc on the target:
brwxrwxrwx 1 0 0 254, 0 Jun 26 2007 mmcblk0
brwxrwxrwx 1 0 0 254, 1 Jun 26 2007 mmcblk0p0
brwxrwxrwx 1 0 0 254, 2 Jun 26 2007 mmcblk0p1
brwxrwxrwx 1 0 0 254, 3 Jun 26 2007 mmcblk0p2
brwxrwxrwx 1 0 0 254, 4 Jun 26 2007 mmcblk0p3
How do I access the MMC card data now? If I try to mount it,
busybox doesnot mount it.
# mount /dev/mmcblk0p0 /mnt/mmc
mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed
I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How
do I access the contents of MMC card? Is there any thing missing in my
settings? Busybox does not say anything other than the above error
message.
Any clue will be appreciated,
Thanks,
Midhun.
Sorry for resending. I dont know if my previous mail has reached the
list with "Fwd" in the subject line. I am pretty sure there must a
filter in Majordomo to discard forwards. Actually I am resending the
mail I had sent to Linux-Arm-Kernel.
Thanks.
---------- Forwarded message ----------
From: Midhun Agnihotram <[email protected]>
Date: Jun 28, 2007 10:30 PM
Subject: Fwd: Mounting MMC card
To: [email protected]
Cc: [email protected]
Hi All,
I am new to linux kernel stuff. I am using Cogent CSB535FS board. I
have configured the kernel to include support for MMC card and also
i.MX MMC driver. When I insert the card, it says :
# imx-mmc imx-mmc.0: card inserted
So, the kernel has identified that MMC has been inserted. I have
the following dev entries for mmc on the target:
brwxrwxrwx 1 0 0 254, 0 Jun 26 2007 mmcblk0
brwxrwxrwx 1 0 0 254, 1 Jun 26 2007 mmcblk0p0
brwxrwxrwx 1 0 0 254, 2 Jun 26 2007 mmcblk0p1
brwxrwxrwx 1 0 0 254, 3 Jun 26 2007 mmcblk0p2
brwxrwxrwx 1 0 0 254, 4 Jun 26 2007 mmcblk0p3
How do I access the MMC card data now? If I try to mount it,
busybox doesnot mount it.
# mount /dev/mmcblk0p0 /mnt/mmc
mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed
I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How
do I access the contents of MMC card? Is there any thing missing in my
settings? Busybox does not say anything other than the above error
message.
Any clue will be appreciated,
Thanks,
Midhun.
Midhun Agnihotram wrote:
> Sorry for resending. I dont know if my previous mail has reached the
> list with "Fwd" in the subject line. I am pretty sure there must a
> filter in Majordomo to discard forwards. Actually I am resending the
> mail I had sent to Linux-Arm-Kernel.
The mail came already through the first time. It may take a while.
There are a _lot_ of subscribers and a _lot_ of mails.
> brwxrwxrwx 1 0 0 254, 0 Jun 26 2007 mmcblk0
> brwxrwxrwx 1 0 0 254, 1 Jun 26 2007 mmcblk0p0
> brwxrwxrwx 1 0 0 254, 2 Jun 26 2007 mmcblk0p1
> brwxrwxrwx 1 0 0 254, 3 Jun 26 2007 mmcblk0p2
> brwxrwxrwx 1 0 0 254, 4 Jun 26 2007 mmcblk0p3
>
> How do I access the MMC card data now? If I try to mount it,
> busybox doesnot mount it.
>
> # mount /dev/mmcblk0p0 /mnt/mmc
> mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed
>
> I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How
Try to mount mmcblk0 and/or try fdisk and look at the partition
table. dmesg output would also be helpful (after the failed mount).
Jan
Am Donnerstag 28 Juni 2007 19:08 schrieb Midhun Agnihotram:
> How do I access the MMC card data now? If I try to mount it,
> busybox doesnot mount it.
>
> # mount /dev/mmcblk0p0 /mnt/mmc
> mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed
>
> I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How
> do I access the contents of MMC card? Is there any thing missing in my
> settings? Busybox does not say anything other than the above error
> message.
Unfortunately, busybox mount is not very verbose. You get the above
mentioned error message even if the device file doesn't exist...
You should check:
* Is the driver for your MMC actually loaded?
* Did it initialize correctly? Does it find your MMC card?
* Is support for the file system on the MMC in your kernel?
* /dev/mmcblk0p0 and /mnt/mmc really exist? (sorry, but...)
Check the output of dmesg for messages from the mmc driver.
Hans
Midhun Agnihotram wrote:
>
> How do I access the MMC card data now? If I try to mount it,
> busybox doesnot mount it.
>
> # mount /dev/mmcblk0p0 /mnt/mmc
> mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed
>
Have you checked that your device nodes are correct? Since you use busybox I
assume the system is too lightweight to run udev.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Am Donnerstag 28 Juni 2007 21:22 schrieb Pierre Ossman:
> Since you use busybox I
> assume the system is too lightweight to run udev.
I run udev on an arm system, it costs you about 200kBytes,
and saves you all the trouble with creating device files.
Note that you don't need any rules files. If you want to write
rules, you can even implement a poor-man's hotplug without HAL.
If you can afford 200k, use udev.
Hans
Hi All,
>
> # mount /dev/mmcblk0p0 /mnt/mmc
> mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed
>
> I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How
>Try to mount mmcblk0 and/or try fdisk and look at the partition
>table. dmesg output would also be helpful (after the failed mount).
>
>Jan
I have tried mounting mmcblk0. But I get the same error from
mount. I have pasted the dmesg log at the end of the mail.
>You should check:
>
>* Is the driver for your MMC actually loaded?
>* Did it initialize correctly? Does it find your MMC card?
As far as I have seen the log, the device gets probed properly.
Also the kernel detects the MMC card when inserted. So there must be
no problem with the driver loading.
>* Is support for the file system on the MMC in your kernel?
Yes. There is support for MMC card in my kernel. The following is
from the .config file.
#
# MMC/SD Card support
#
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_IMX=y
>* /dev/mmcblk0p0 and /mnt/mmc really exist? (sorry, but...)
Yes they do. I have created the /dev/mmcblk0, /dev/mmcblk0p0,
/dev/mmcblk0p1, /dev/mmcblk0p2, /dev/mmcblk0p3, /dev/mmcblk0p4 entries
using mknod. Also I have created the /mnt and /mnt/mmc directories.
>
>Check the output of dmesg for messages from the mmc driver.
>
>Hans
I have checked the log and it is attached to the end of the mail.
The log contains debug messages for removing and inserting the MMC
card. But nothing specific relating to mount. Can you interpret
anything more from it?
>Have you checked that your device nodes are correct? Since you use busybox I
>assume the system is too lightweight to run udev.
Yes. I have checked the device nodes. They are fine for MMC. (I
have made them form what I got on the internet. BTW can anybody tell
me how can I find the corresponding major and minor number for my
device driver? This MMC driver is from Microcross. I have put the
device nodes as 254,0 - which are generic.).
>I run udev on an arm system, it costs you about 200kBytes,
>and saves you all the trouble with creating device files.
>Note that you don't need any rules files. If you want to write
>rules, you can even implement a poor-man's hotplug without HAL.
>If you can afford 200k, use udev.
I have seen the udev page. But I am a bit skeptic about
implementing it with my kernelas this kernel is from Microcross -
customized for CSB535FS board. I want to try udev only as my last
option.
Please help me resolve this issue. I have been on it for a week now.
Thanks a lot,
Midhun.
The dmesg log:
============
<7>jffs2_add_physical_node_ref(): Node at 0x160300(2), size 0x124
<7>jffs2_write_dnode wrote node at 0x00160300(2) with dsize 0x269,
csize 0xde, node_crc 0x7b52763e, data_crc 0x5a16f8e5, totlen
0x00000122
<7>[JFFS2 DBG] (673) jffs2_add_full_dnode_to_inode: adding node
0x00-0x269 @0x00160300 on flash, newfrag *c2d05fe0
<7>Obsoleting node at 0x001602bc of len 0x44: <7>Wasting
<7>obliterating obsoleted node at 0x001602bc
<7>jffs2_complete_reservation()
<7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0,
dirty_size 0x2f1e4: no
<7>increasing writtenlen by 617
<7>jffs2_commit_write() returning 0
<7>jffs2_lookup()
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 27
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #27
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #27 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #27
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x087618(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @00087618: ver 1, offset 0x00,
dsize 0x07, csize 0x07
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #27 were
read, the highest version is 1, latest_mctime 3269877536, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x087618(3), range 0-7.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x07, ver 1
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: symlink's target
'busybox' cached
<7>jffs2_read_inode() returning
<7>jffs2_follow_link(): target path is 'busybox'
<7>jffs2_follow_link(): target path is 'busybox'
<6>imx-mmc imx-mmc.0: card removed
<6>imx-mmc imx-mmc.0: card inserted
<7>jffs2_setattr(): ino #353
<7>jffs2_reserve_space(): Requested 0x44 bytes
<7>jffs2_reserve_space(): alloc sem got
<7>jffs2_do_reserve_space(): Giving 0x1fbdc bytes at 0x160424
<7>jffs2_add_physical_node_ref(): Node at 0x160424(2), size 0x44
<7>jffs2_write_dnode wrote node at 0x00160424(2) with dsize 0x0, csize
0x0, node_crc 0x93cbd6de, data_crc 0x00000000, totlen 0x00000044
<7>[JFFS2 DBG] (673) jffs2_truncate_fragtree: truncating fragtree to
0x00000000 bytes
<7>Obsoleting node at 0x00160300 of len 0x124: <7>Wasting
<7>obliterating obsoleted node at 0x00160300
<7>jffs2_complete_reservation()
<7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0,
dirty_size 0x2f1e4: no
<7>jffs2_prepare_write()
<7>jffs2_read_inode_range: ino #353, range 0x00000000-0x00001000
<7>Filling non-frag hole from 0-4096
<7>end prepare_write(). pg->flags 209
<7>jffs2_commit_write(): ino #353, page at 0x0, range 0-620, flags 209
<7>jffs2_write_inode_range(): Ino #353, ofs 0x0, len 0x26c
<7>jffs2_reserve_space(): Requested 0xc4 bytes
<7>jffs2_reserve_space(): alloc sem got
<7>jffs2_do_reserve_space(): Giving 0x1fb98 bytes at 0x160468
<7>calling deflate with avail_in 608, avail_out 608
<7>deflate returned with avail_in 0, avail_out 400, total_in 608, total_out 208
<7>calling deflate with avail_in 12, avail_out 400
<7>deflate returned with avail_in 0, avail_out 393, total_in 620, total_out 215
<7>zlib compressed 620 bytes into 221
<7>jffs2_add_physical_node_ref(): Node at 0x160468(2), size 0x124
<7>jffs2_write_dnode wrote node at 0x00160468(2) with dsize 0x26c,
csize 0xdd, node_crc 0xbb276af8, data_crc 0x6463d190, totlen
0x00000121
<7>[JFFS2 DBG] (673) jffs2_add_full_dnode_to_inode: adding node
0x00-0x26c @0x00160468 on flash, newfrag *c2d05fe0
<7>Obsoleting node at 0x00160424 of len 0x44: <7>Wasting
<7>obliterating obsoleted node at 0x00160424
<7>jffs2_complete_reservation()
<7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0,
dirty_size 0x2f1e4: no
<7>increasing writtenlen by 620
<7>jffs2_commit_write() returning 0
<7>jffs2_follow_link(): target path is 'busybox'
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 191
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #191
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #191 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #191
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x08e2ac(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @0008e2ac: ver 1, offset 0x00,
dsize 0x02, csize 0x02
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #191 were
read, the highest version is 1, latest_mctime 3269873816, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x08e2ac(3), range 0-2.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x02, ver 1
<7>Reading device numbers from flash
<7>Node read from 0008e2ac: node_crc 660cfdce, calculated CRC
660cfdce. dsize 2, csize 2, offset 0, buf c2e47ce0
<7>jffs2_read_inode() returning
<7>jffs2_readdir() for dir_i #3
<7>Dirent 0: ".", ino #3
<7>Dirent 1: "..", ino #1
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 362
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #362
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #362 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #362
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x1f533c(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @001f533c: ver 1, offset 0x00,
dsize 0x02, csize 0x02
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #362 were
read, the highest version is 1, latest_mctime 3269873940, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x1f533c(3), range 0-2.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x02, ver 1
<7>Reading device numbers from flash
<7>Node read from 001f533c: node_crc 51f8a8f5, calculated CRC
51f8a8f5. dsize 2, csize 2, offset 0, buf c2e47d10
<7>jffs2_read_inode() returning
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 363
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #363
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #363 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #363
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x1f5554(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @001f5554: ver 1, offset 0x00,
dsize 0x02, csize 0x02
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #363 were
read, the highest version is 1, latest_mctime 3269874064, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x1f5554(3), range 0-2.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x02, ver 1
<7>Reading device numbers from flash
<7>Node read from 001f5554: node_crc 5deb85e2, calculated CRC
5deb85e2. dsize 2, csize 2, offset 0, buf c2e47d10
<7>jffs2_read_inode() returning
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 364
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #364
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #364 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #364
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x1f576c(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @001f576c: ver 1, offset 0x00,
dsize 0x02, csize 0x02
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #364 were
read, the highest version is 1, latest_mctime 3269874188, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x1f576c(3), range 0-2.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x02, ver 1
<7>Reading device numbers from flash
<7>Node read from 001f576c: node_crc ce82a7a6, calculated CRC
ce82a7a6. dsize 2, csize 2, offset 0, buf c2e47d10
<7>jffs2_read_inode() returning
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 365
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #365
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #365 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #365
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x1f5980(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @001f5980: ver 1, offset 0x00,
dsize 0x02, csize 0x02
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #365 were
read, the highest version is 1, latest_mctime 3269874312, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x1f5980(3), range 0-2.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x02, ver 1
<7>Reading device numbers from flash
<7>Node read from 001f5980: node_crc 4423aa5b, calculated CRC
4423aa5b. dsize 2, csize 2, offset 0, buf c2e47d10
<7>jffs2_read_inode() returning
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 361
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #361
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #361 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #361
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x1f5130(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @001f5130: ver 1, offset 0x00,
dsize 0x02, csize 0x02
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #361 were
read, the highest version is 1, latest_mctime 3269874436, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x1f5130(3), range 0-2.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x02, ver 1
<7>Reading device numbers from flash
<7>Node read from 001f5130: node_crc 55539f75, calculated CRC
55539f75. dsize 2, csize 2, offset 0, buf c2e47d10
<7>jffs2_read_inode() returning
<7>jffs2_readdir() for dir_i #3
<7>jffs2_readdir() for dir_i #1
<7>Dirent 0: ".", ino #1
<7>Dirent 1: "..", ino #1
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 355
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #355
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #355 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #355
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x0f29dc(2).
<7>[JFFS2 DBG] (673) jffs2_add_fd_to_list: add dirent "mmc", ino #356
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x0f2824(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @000f2824: ver 2, offset 0x00,
dsize 0x00, csize 0x00
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #355 were
read, the highest version is 3, latest_mctime 534, mctime_ver 3.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
2, phys offset 0x0f2824(3), range 0-0.
<7>jffs2_read_inode() returning
<7>jffs2_readdir() for dir_i #1
<7>jffs2_readdir() for dir_i #355
<7>Dirent 0: ".", ino #355
<7>Dirent 1: "..", ino #1
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 356
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #356
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #356 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #356
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x0f2a08(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @000f2a08: ver 2, offset 0x00,
dsize 0x00, csize 0x00
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #356 were
read, the highest version is 2, latest_mctime 3269874684, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
2, phys offset 0x0f2a08(3), range 0-0.
<7>jffs2_read_inode() returning
<7>jffs2_readdir() for dir_i #355
<7>jffs2_setattr(): ino #353
<7>jffs2_reserve_space(): Requested 0x44 bytes
<7>jffs2_reserve_space(): alloc sem got
<7>jffs2_do_reserve_space(): Giving 0x1fa74 bytes at 0x16058c
<7>jffs2_add_physical_node_ref(): Node at 0x16058c(2), size 0x44
<7>jffs2_write_dnode wrote node at 0x0016058c(2) with dsize 0x0, csize
0x0, node_crc 0x17517d14, data_crc 0x00000000, totlen 0x00000044
<7>[JFFS2 DBG] (673) jffs2_truncate_fragtree: truncating fragtree to
0x00000000 bytes
<7>Obsoleting node at 0x00160468 of len 0x124: <7>Wasting
<7>obliterating obsoleted node at 0x00160468
<7>jffs2_complete_reservation()
<7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0,
dirty_size 0x2f1e4: no
<7>jffs2_prepare_write()
<7>jffs2_read_inode_range: ino #353, range 0x00000000-0x00001000
<7>Filling non-frag hole from 0-4096
<7>end prepare_write(). pg->flags 209
<7>jffs2_commit_write(): ino #353, page at 0x0, range 0-652, flags 209
<7>jffs2_write_inode_range(): Ino #353, ofs 0x0, len 0x28c
<7>jffs2_reserve_space(): Requested 0xc4 bytes
<7>jffs2_reserve_space(): alloc sem got
<7>jffs2_do_reserve_space(): Giving 0x1fa30 bytes at 0x1605d0
<7>calling deflate with avail_in 640, avail_out 640
<7>deflate returned with avail_in 0, avail_out 434, total_in 640, total_out 206
<7>calling deflate with avail_in 12, avail_out 434
<7>deflate returned with avail_in 0, avail_out 424, total_in 652, total_out 216
<7>zlib compressed 652 bytes into 222
<7>jffs2_add_physical_node_ref(): Node at 0x1605d0(2), size 0x124
<7>jffs2_write_dnode wrote node at 0x001605d0(2) with dsize 0x28c,
csize 0xde, node_crc 0xb28a4850, data_crc 0x35b0a0f9, totlen
0x00000122
<7>[JFFS2 DBG] (673) jffs2_add_full_dnode_to_inode: adding node
0x00-0x28c @0x001605d0 on flash, newfrag *c2d05fe0
<7>Obsoleting node at 0x0016058c of len 0x44: <7>Wasting
<7>obliterating obsoleted node at 0x0016058c
<7>jffs2_complete_reservation()
<7>jffs2_thread_should_wake(): nr_free_blocks 22, nr_erasing_blocks 0,
dirty_size 0x2f1e4: no
<7>increasing writtenlen by 652
<7>jffs2_commit_write() returning 0
<7>jffs2_follow_link(): target path is 'busybox'
<7>jffs2_follow_link(): target path is 'busybox'
<7>jffs2_lookup()
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 334
<7>[JFFS2 DBG] (679) jffs2_do_read_inode: read inode #334
<7>[JFFS2 DBG] (679) jffs2_do_read_inode_internal: ino #334 nlink is 1
<7>[JFFS2 DBG] (679) jffs2_get_inode_nodes: ino #334
<7>[JFFS2 DBG] (679) jffs2_get_inode_nodes: read 40 bytes at 0x0f0220(3).
<7>[JFFS2 DBG] (679) read_more: read more 28 bytes
<7>[JFFS2 DBG] (679) read_dnode: dnode @000f0220: ver 1, offset 0x00,
dsize 0x0e, csize 0x0e
<7>[JFFS2 DBG] (679) jffs2_get_inode_nodes: nodes of inode #334 were
read, the highest version is 1, latest_mctime 3269875428, mctime_ver
0.
<7>[JFFS2 DBG] (679) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x0f0220(3), range 0-14.
<7>[JFFS2 DBG] (679) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x0e, ver 1
<7>[JFFS2 DBG] (679) jffs2_do_read_inode_internal: symlink's target
'../bin/busybox' cached
<7>jffs2_read_inode() returning
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_lookup()
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_follow_link(): target path is '../bin/busybox'
<7>jffs2_lookup()
<7>jffs2_lookup()
<7>jffs2_read_inode(): inode->i_ino == 39
<7>[JFFS2 DBG] (673) jffs2_do_read_inode: read inode #39
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: ino #39 nlink is 1
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: ino #39
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: read 40 bytes at 0x087bcc(3).
<7>[JFFS2 DBG] (673) read_more: read more 28 bytes
<7>[JFFS2 DBG] (673) read_dnode: dnode @00087bcc: ver 1, offset 0x00,
dsize 0x07, csize 0x07
<7>[JFFS2 DBG] (673) jffs2_get_inode_nodes: nodes of inode #39 were
read, the highest version is 1, latest_mctime 3269875056, mctime_ver
0.
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: consider node ver
1, phys offset 0x087bcc(3), range 0-7.
<7>[JFFS2 DBG] (673) jffs2_add_older_frag_to_fragtree: insert fragment
0x00-0x07, ver 1
<7>[JFFS2 DBG] (673) jffs2_do_read_inode_internal: symlink's target
'busybox' cached
<7>jffs2_read_inode() returning
<7>jffs2_follow_link(): target path is 'busybox'
<7>jffs2_follow_link(): target path is 'busybox'
Am Freitag 29 Juni 2007 09:40 schrieb Midhun Agnihotram:
>
> >* Is support for the file system on the MMC in your kernel?
>
> Yes. There is support for MMC card in my kernel.
I was talking about the file system on the card. Usually, you've
got vfat on such a card. How about that?
BTW, You mounted proc on /proc and sysfs on /sys, I hope?
>
> I have checked the log and it is attached to the end of the mail.
> The log contains debug messages for removing and inserting the MMC
> card. But nothing specific relating to mount. Can you interpret
> anything more from it?
No. You don't have jffs2 on your MMC, do you?
>
> >Have you checked that your device nodes are correct? Since you use busybox I
> >assume the system is too lightweight to run udev.
>
> Yes. I have checked the device nodes. They are fine for MMC. (I
> have made them form what I got on the internet. BTW can anybody tell
> me how can I find the corresponding major and minor number for my
> device driver? This MMC driver is from Microcross. I have put the
> device nodes as 254,0 - which are generic.).
Here's what I have (nodes created by udev):
# ls -l /dev/mmc*
brw-rw---- 1 root root 254, 0 Jun 29 08:41 /dev/mmcblk0
brw-rw---- 1 root root 254, 1 Jun 29 08:41 /dev/mmcblk0p1
>
> >I run udev on an arm system, it costs you about 200kBytes,
> >and saves you all the trouble with creating device files.
> >Note that you don't need any rules files. If you want to write
> >rules, you can even implement a poor-man's hotplug without HAL.
> >If you can afford 200k, use udev.
>
> I have seen the udev page. But I am a bit skeptic about
> implementing it with my kernelas this kernel is from Microcross -
> customized for CSB535FS board.
As long as it's a reasonable recent kernel (>=2.6.15), it shouldn't
be a problem.
> I want to try udev only as my last
> option.
Your choice.
Hans
Hi,
> I was talking about the file system on the card. Usually, you've
> got vfat on such a card. How about that?
>
> BTW, You mounted proc on /proc and sysfs on /sys, I hope?
>
Yes I do have the support for vfat and msdos file system. I have
formatted the card on a Windows system with "FAT" file system.
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
Also, I have mounted proc and sysfs.
>
> No. You don't have jffs2 on your MMC, do you?
>
I do not have a jffs2 on my MMC.
> > I have seen the udev page. But I am a bit skeptic about
> > implementing it with my kernelas this kernel is from Microcross -
> > customized for CSB535FS board.
>
> As long as it's a reasonable recent kernel (>=2.6.15), it shouldn't
> be a problem.
>
The kernel version is 2.6.16. So I guess there should not be a
problem. Any more things that I need to check??
Thanks,
Midhun.
Midhun Agnihotram wrote:
>
> The kernel version is 2.6.16. So I guess there should not be a
> problem. Any more things that I need to check??
>
Let's try something a lot less complex than mounting. Try running:
dd if=/dev/mmcblk0 of=/dev/null count=100
If that fails, then you should either have some revealing output in dmesg or
your device nodes must be wrong somehow.
If it succeeds, then there is some problem reading the filesystem off the card.
Have you tried mounting the card in some other system?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Hi All,
> Let's try something a lot less complex than mounting. Try running:
> dd if=/dev/mmcblk0 of=/dev/null count=100
Here goes the output(error).
/ # dd if=/dev/mmcblk0 of=/dev/null count=100
dd: can't open '/dev/mmcblk0': No such device or address
The /dev is has the following:
/ # ls -l /dev | grep mmc
brwxrwxrwx 1 0 0 254, 0 Jun 26 2007 mmcblk0
brwxrwxrwx 1 0 0 254, 1 Jun 26 2007 mmcblk0p0
brwxrwxrwx 1 0 0 254, 2 Jun 26 2007 mmcblk0p1
brwxrwxrwx 1 0 0 254, 3 Jun 26 2007 mmcblk0p2
brwxrwxrwx 1 0 0 254, 4 Jun 26 2007 mmcblk0p3
So are the device nodes wrong? When i say `cat /proc/devices` it says :
/ # cat /proc/devices
Character devices:
1 mem
2 pty
3 ttyp
4 /dev/vc/0
4 tty
4 ttyS
5 /dev/tty
5 /dev/console
5 /dev/ptmx
7 vcs
10 misc
13 input
29 fb
90 mtd
128 ptm
136 pts
Block devices:
1 ramdisk
1 ramdisk
31 mtdblock
254 mmc
So is the major number 254 is correct for MMC ??
Midhun.
Midhun Agnihotram wrote:
>
> So are the device nodes wrong? When i say `cat /proc/devices` it says :
>
> So is the major number 254 is correct for MMC ??
>
This all looks correct. How about /proc/partitions? And what's in /sys/block?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
On Friday, 29. June 2007, Midhun Agnihotram wrote:
> Hi All,
>
> > Let's try something a lot less complex than mounting. Try running:
> > dd if=/dev/mmcblk0 of=/dev/null count=100
>
> Here goes the output(error).
>
> / # dd if=/dev/mmcblk0 of=/dev/null count=100
> dd: can't open '/dev/mmcblk0': No such device or address
>
> The /dev is has the following:
>
> / # ls -l /dev | grep mmc
> brwxrwxrwx 1 0 0 254, 0 Jun 26 2007 mmcblk0
> brwxrwxrwx 1 0 0 254, 1 Jun 26 2007 mmcblk0p0
> brwxrwxrwx 1 0 0 254, 2 Jun 26 2007 mmcblk0p1
> brwxrwxrwx 1 0 0 254, 3 Jun 26 2007 mmcblk0p2
> brwxrwxrwx 1 0 0 254, 4 Jun 26 2007 mmcblk0p3
>
If I remember correctly, mmc devices did not have fixed majors/minors
allocated until recently. Either get a recent kernel or use some kind of
hotplug (udev) scripts to create your device nodes with dynamically allocated
major/minors.
Regards
Uli
--
------- ROAD ...the handyPC Company - - - ) ) )
Uli Luckas
Software Development
ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 64 | fax: +49 (30) 230069 - 69
url: http://www.road.de
Amtsgericht Charlottenburg: HRB 96688 B
Managing directors: Hans-Peter Constien, Hubertus von Streit
>
> This all looks correct. How about /proc/partitions? And what's in /sys/block?
>
Both of them show no sign of MMC.
/ # cat /proc/partitions
major minor #blocks name
31 0 8192 mtdblock0
31 1 384 mtdblock1
31 2 1664 mtdblock2
31 3 2048 mtdblock3
31 4 4096 mtdblock4
/ # cd /sys/block/
/sys/block # ls -l
drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock0
drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock1
drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock2
drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock3
drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock4
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram0
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram1
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram10
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram11
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram12
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram13
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram14
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram15
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram2
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram3
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram4
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram5
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram6
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram7
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram8
drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram9
Midhun.
Am Freitag 29 Juni 2007 11:45 schrieb Midhun Agnihotram:
> >
> > This all looks correct. How about /proc/partitions? And what's in /sys/block?
> >
>
> Both of them show no sign of MMC.
>
> / # cat /proc/partitions
> major minor #blocks name
>
> 31 0 8192 mtdblock0
> 31 1 384 mtdblock1
> 31 2 1664 mtdblock2
> 31 3 2048 mtdblock3
> 31 4 4096 mtdblock4
>
>
>
> / # cd /sys/block/
> /sys/block # ls -l
> drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock0
> drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock1
> drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock2
> drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock3
> drwxr-xr-x 3 0 0 0 Jan 1 00:00 mtdblock4
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram0
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram1
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram10
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram11
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram12
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram13
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram14
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram15
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram2
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram3
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram4
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram5
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram6
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram7
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram8
> drwxr-xr-x 2 0 0 0 Jan 1 00:00 ram9
For comparison, here's what it looks like here (kernel 2.6.21.5, udev):
# cat /proc/partitions
major minor #blocks name
31 0 512 mtdblock0
31 1 4096 mtdblock1
31 2 28160 mtdblock2
254 0 250880 mmcblk0
254 1 250697 mmcblk0p1
# ls -l /sys/block/
drwxr-xr-x 6 root root 0 Jun 29 08:41 mmcblk0
drwxr-xr-x 5 root root 0 Jun 29 08:41 mtdblock0
drwxr-xr-x 5 root root 0 Jun 29 08:41 mtdblock1
drwxr-xr-x 5 root root 0 Jun 29 08:41 mtdblock2
# ls -l /sys/block/mmcblk0
-r--r--r-- 1 root root 4096 Jun 29 08:41 dev
lrwxrwxrwx 1 root root 0 Jun 29 10:07 device -> ../../class/mmc_host/mmc0/mmc0:0002
drwxr-xr-x 2 root root 0 Jan 1 1970 holders
drwxr-xr-x 3 root root 0 Jun 29 08:41 mmcblk0p1
drwxr-xr-x 3 root root 0 Jan 1 1970 queue
-r--r--r-- 1 root root 4096 Jun 29 08:41 range
-r--r--r-- 1 root root 4096 Jun 29 08:41 removable
-r--r--r-- 1 root root 4096 Jun 29 08:41 size
drwxr-xr-x 2 root root 0 Jan 1 1970 slaves
-r--r--r-- 1 root root 4096 Jun 29 08:41 stat
lrwxrwxrwx 1 root root 0 Jun 29 08:41 subsystem -> ../../block
--w------- 1 root root 4096 Jun 29 08:41 uevent
# ls -l mmcblk0p1
ls: mmcblk0p1: No such file or directory
# ls -l /sys/block/mmcblk0/mmcblk0p1
-r--r--r-- 1 root root 4096 Jun 29 10:08 dev
drwxr-xr-x 2 root root 0 Jan 1 1970 holders
-r--r--r-- 1 root root 4096 Jun 29 10:08 size
-r--r--r-- 1 root root 4096 Jun 29 10:08 start
-r--r--r-- 1 root root 4096 Jun 29 10:08 stat
lrwxrwxrwx 1 root root 0 Jun 29 10:08 subsystem -> ../../../block
--w------- 1 root root 4096 Jun 29 08:41 uevent
# cat /sys/block/mmcblk0/mmcblk0p1/size
501394
#
Hans
Midhun Agnihotram wrote:
>>
>> This all looks correct. How about /proc/partitions? And what's in
>> /sys/block?
>>
>
> Both of them show no sign of MMC.
>
Then you cannot mount them. What output did you see in dmesg when you inserted
the card?
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Uli Luckas wrote:
> If I remember correctly, mmc devices did not have fixed majors/minors
> allocated until recently. Either get a recent kernel or use some kind of
> hotplug (udev) scripts to create your device nodes with dynamically allocated
> major/minors.
>
Correct. But a double check in /proc/devices reveals the current allocation.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
Hi,
> > Both of them show no sign of MMC.
> >
>
> Then you cannot mount them. What output did you see in dmesg when you inserted
> the card?
>
The dmesg contains only the following when I remove and insert the card.
<6>imx-mmc imx-mmc.0: card removed
<6>imx-mmc imx-mmc.0: card inserted
Also I was looking through the code. I found this function for init
of mmc_blk (linux/drivers/mmc/mmc_block.c)
static int __init mmc_blk_init(void)
{
int res = -ENOMEM;
res = register_blkdev(major, "mmc");
if (res < 0) {
printk(KERN_WARNING "Unable to get major %d for MMC media: %d\n",
major, res);
goto out;
}
if (major == 0)
major = res;
devfs_mk_dir("mmc");
return mmc_register_driver(&mmc_driver);
out:
return res;
}
This uses the function devfs_mk_dir() - defined in
linux/fs/devfs/base.c. I don't have devfs enabled in my kernel (kernel
version 2.6.16. In fact I don't even get an option to enable it in
menuconfig.). Can this be the cause of the problem?? I have found the
same code in the original kernel version too (the one from
kernel.org).
Thanks,
Midhun.
Midhun Agnihotram wrote:
> linux/fs/devfs/base.c. I don't have devfs enabled in my kernel (kernel
> version 2.6.16. In fact I don't even get an option to enable it in
> menuconfig.). Can this be the cause of the problem?? I have found the
> same code in the original kernel version too (the one from
> kernel.org).
>
Not likely. It's probably a no-op when you don't have devfs.
You should enable CONFIG_MMC_DEBUG to see what is going wrong.
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
>
> Not likely. It's probably a no-op when you don't have devfs.
>
CONFIG_MMC_DEBUG is already enabled. This is not printing any debug
statements as such.
Midhun.
Midhun Agnihotram wrote:
>>
>> Not likely. It's probably a no-op when you don't have devfs.
>>
>
> CONFIG_MMC_DEBUG is already enabled. This is not printing any debug
> statements as such.
>
Then something is seriously broken with your kernel. I can only assume that this
is because of some vendor modifications. So I would suggest contacting them or
trying to get a vanilla kernel running.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
> Then something is seriously broken with your kernel. I can only assume that this
> is because of some vendor modifications. So I would suggest contacting them or
> trying to get a vanilla kernel running.
Hmm. I will try getting the vanilla kernel and putting the
required patches. Or rather see what can be done with this driver.
Thanks a lot for all the help.
Thanks,
Midhun.