I have tried to change size from u_int32_t to u_int64_t, but kernel had 
unrsolved symbol: __udivdi3 and __moddi3 while linking,  I thought those two 
functions should come from libgcc.a, if I link to libgcc, the problem should 
be resolved, or I can just use do_div() from asm/div64 to replace "/" and 
"%" for mtd_info->size.

I used do_div() method, and modified source line that use __udivdi3 and 
__moddi3 to use do_div() instead, after that the linking probem was gone, 
but kernel had some problem showing MTD partition names:

Using physmap partition information
Creating 6 MTD partitions on "physmap-flash.0":
0x00000000-0x00040000 : "<NULL>"
0x00040000-0x00080000 : "<NULL>"
0x00080000-0x00300000 : "<NULL>"
0x00300000-0x00320000 : "<NULL>"
0x00320000-0x00a00000 : "<NULL>"
0x00a00000-0x01000000 : "<NULL>"
NAND device: Manufacturer ID: 0xec, Chip ID: 0x73 (Samsung NAND 16MiB 3,3V 
8-bit)
Scanning device for bad blocks
Bad eraseblock 979 at 0x00f4c000
Creating 1 MTD partitions on "NAND 16MiB 3,3V 8-bit":
0x00000000-0x01000000 : "<NULL>"

If i cat /proc/mtd the kernel Oops:

ARM ~]# cat /proc/mtd
Unable to handle kernel paging request at virtual address 00004000
pgd = c1800000
[00004000] *pgd=21e5b031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
Modules linked in:
CPU: 0
PC is at strnlen+0x1c/0x44
LR is at vsnprintf+0x304/0x588
...

I think it must be a printk problem, and I'm still trying to resolve this...


>From: "Josh Boyer" <jwboyer@gmail.com>
>To: "Charles Manning" <manningc2@actrix.gen.nz>
>CC: linux-mtd@lists.infradead.org
>Subject: Re: mtd_info/mtd_info_user>size wrong type
>Date: Fri, 6 Apr 2007 20:26:55 -0500
>
>On 4/6/07, Charles Manning <manningc2@actrix.gen.nz> wrote:
> > Folks
> > As people are starting to use larger NAND partitions (4GB+), an 
>inconsistency
> > in the size field has become apparent.
> >
> > This is a unint32_t which is clearly too small for modern NAND arrays.
>
>Yes, known issue.
>
> > The read/write funcions use loff_t which is correct.
> >
> > It would seem that size needs to be increated to loff_t too.
>
>Have you tried doing that?  I seem to recall hearing that it was a bit
>more involved than just changing the size member to be 64 bit.
>
>josh
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/