Re: File System on 64-bit-bus-width Flash memory

In message [off-list ref] you wrote:

Hi,
I want to make a flash file system on a custom MPC755 board with a 64-bit (bus width) flash memory.
I set CONFIG_MTD_PHYSMAP_BUSWIDTH = 8 at kernel configure, and when it boots the following message appears.

physmap flash device: 400000 at 7c000000
genprobe_new_chip called with unsupported buswidth 8

Seems your MTD drivers are missing support for 64 bit buswidth.

Is it possible to make a flash file system with a flash memory of  64 bit bus width? If possible, what's the method? Please let me know.

We implemented this long ago. See our kernel source tree at
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/

For example:

...
TQM8260 flash bank 0: Using static image partition definition
Creating 4 MTD partitions on "TQM8260 Bank 0":
0x00000000-0x00040000 : "ppcboot"
0x00040000-0x00100000 : "kernel"
0x00100000-0x00400000 : "initrd"
0x00400000-0x00800000 : "jffs"
...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There are two ways to write error-free programs. Only the  third  one
works.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

MTD has support for 64-bit bus. They have not pushed the code the main tree.
Goto www.infradead.org and checkout the CVS tree. (I have not personally
used this code version. I implemented modified MTD myself last December)

-----Original Message-----
From: owner-linuxppc-embedded@lists.linuxppc.org
[mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Wolfgang
Denk
Sent: Tuesday, May 14, 2002 4:14 AM
To: Sangmoon Kim
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: File System on 64-bit-bus-width Flash memory



In message
[off-list ref] you wrote:

quoted

Hi,
I want to make a flash file system on a custom MPC755 board

with a 64-bit (bus width) flash memory.

quoted

I set CONFIG_MTD_PHYSMAP_BUSWIDTH = 8 at kernel configure, and

when it boots the following message appears.

quoted

physmap flash device: 400000 at 7c000000
genprobe_new_chip called with unsupported buswidth 8

Seems your MTD drivers are missing support for 64 bit buswidth.

quoted

Is it possible to make a flash file system with a flash memory

of  64 bit bus width? If possible, what's the method? Please let me know.

We implemented this long ago. See our kernel source tree at
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/

For example:

...
TQM8260 flash bank 0: Using static image partition definition
Creating 4 MTD partitions on "TQM8260 Bank 0":
0x00000000-0x00040000 : "ppcboot"
0x00040000-0x00100000 : "kernel"
0x00100000-0x00400000 : "initrd"
0x00400000-0x00800000 : "jffs"
...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
There are two ways to write error-free programs. Only the  third  one
works.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hi, all,

Thanks for the helps.
The 64bit buswith MTD support in ftp://ftp.denx.de/pub/LinuxPPC/usr/src/linux-2.4.4-2002-03-21.tar.bz2, which is Wolfgang Denk recommanded, is nice. But... Though it probably works well with MPC8260, it doesn't work with MPC107 which is a memory controller / PCI bridge from motorola. With MPC107 you can't access high 32 bit and low 32 bit separately. Because it doesn't have byte select or word select. Unfortunately my board uses MPC107.
The code in http://www.infradead.org/, which is Allen Curtis recommanded, has a different approach, but with some rack of functionality. First, It did not support probing for 64bit buswidth flash. Second, __raw_readll and __raw_writell, which may be 64bit read write functions, are not exist in kernel.
I changed the infradead code to support 64-bit buswith probing(I referenced the denx code). And made the __raw_writell and __raw_readll using floating load load store operation. I disabled the floating point interrupt to avoid the 'floating point used in kernel' message and re-enabled it. For now I only succeed in probing the chip. Does my approach correct? Is it OK to use floating point operations in kernel or device driver code?
Thank you.
-Sangmoon Kim-

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/