Fujitsu MBM29LV160

Fujitsu MBM29LV160

[Masami Komiya]

We try to port Linux kernel to our embedded system that has Fujitsu's
NOR type Flash memory MBM29LV160.
If it is possible, we want to use MTD for our system. 
Does anyone let me know MTD support it or not?
Also wellcome any suggestions.

Best Regards.

Masami Komiya


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Fujitsu MBM29LV160

[David Woodhouse]

mkomiya@crossnet.co.jp said:
> We try to port Linux kernel to our embedded system that has Fujitsu's
> NOR type Flash memory MBM29LV160.

Is it CFI-compliant?

If so, it'll be at least detected by the current code. 

If it is capable of using the Intel command set, then it is supported. 
Otherwise, you will have a little bit of work to do to add support for it. 

It should be quite simple to add support for it if it doesn't support the 
Intel command set.

First you need to provide a 'map' driver which allows access to the flash 
chips. Look at something simple like nora.c for an example - if your flash 
chips are mapped into virtual memory then all you need to do is change a 
couple of defines in nora.c to drive your own board.

Then load the cfi_probe module and the nora module (or your own map driver).

Show me all the output you get from it.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Fujitsu MBM29LV160

[Masami Komiya]

It is CFI-compliant. May be, the command set is the different from
Intel's.

I changed the definition of the flash memory address in nora.c
according to our board. Kernel can detects flash momeries correctly.
But the module cfi_cmdset_0002 is required.   

The messages from kernel are:

Main: Initialising MTD Drivers
nora flash device: 200000 at bf000000
NORA: Found a coupled pair of CFI devices at location 0 in 16 bit mode
Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
Primary Algorithm Table at 0040
Alternative Vendor Command Set: 0000 (None)
No Alternate Algorithm Table
Vcc Minimum: 2.7 V
Vcc Maximum: 3.6 V
No Vpp line
Typical byte/word write timeout: 16 sssss
Maximum byte/word write timeout: 512 sssss
Full buffer write not supported
Typical block erase timeout: 1024 sssss
Maximum block erase timeout: 16384 sssss
Chip erase not supported
Device size: 0x200000 bytes (2 Mb)
Flash Device Interface description: 0x0002
  - supports x8 and x16 via BYTE# with asynchronous interface
Max. bytes in buffer write: 0x1
Number of Erase Block Regions: 4
  Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
  Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
  Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
  Erase Region #3: BlockSize 0x10000 bytes, 31 blocks

request_module[cfi_cmdset_0002]: Root fs not mounted
Invalid Extended Query Table at 0040: 40 C0 80
No supported Vendor Command Set found
ftl_cs: FTL header not found.


Should I make cfi_cmdset_0002? Is there the another resources ?

Best regards.

Masami Komiiya


David Woodhouse wrote:
> 
> mkomiya@crossnet.co.jp said:
> > We try to port Linux kernel to our embedded system that has Fujitsu's
> > NOR type Flash memory MBM29LV160.
> 
> Is it CFI-compliant?
> 
> If so, it'll be at least detected by the current code.
> 
> If it is capable of using the Intel command set, then it is supported.
> Otherwise, you will have a little bit of work to do to add support for it.
> 
> It should be quite simple to add support for it if it doesn't support the
> Intel command set.
> 
> First you need to provide a 'map' driver which allows access to the flash
> chips. Look at something simple like nora.c for an example - if your flash
> chips are mapped into virtual memory then all you need to do is change a
> couple of defines in nora.c to drive your own board.
> 
> Then load the cfi_probe module and the nora module (or your own map driver).
> 
> Show me all the output you get from it.
> 
> --
> dwmw2


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Fujitsu MBM29LV160

[David Woodhouse]

On Wed, 5 Jul 2000, Masami Komiya wrote:

> 
> It is CFI-compliant. May be, the command set is the different from
> Intel's.
> 
> The messages from kernel are:
> 
> NORA: Found a coupled pair of CFI devices at location 0 in 16 bit mode
> Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)

Excellent.

> Number of Erase Block Regions: 4
>   Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
>   Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
>   Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
>   Erase Region #3: BlockSize 0x10000 bytes, 31 blocks

> Should I make cfi_cmdset_0002? Is there the another resources ?

Yes, you need to make cfi_cmdset_0002 for that particular
configuration (2x16bit). It should be quite simple t copy cfi_cmdset_0001
and modify it accordingly - not only changing the command set used 
but also changing it to drive two interleaved chips at once. You'll need
the AMD data sheets for those chips.

For now, I'd suggest that you combine all the smaller erase blocks at the
beginning of the device, and pretend that the erase size is always 0x10000
(actually 0x20000 because you have two chips interleaved).  Then when you
receive an erase request at location zero, erase all the smaller blocks at
once.

We'll work out how to handle that properly, but not quite yet. Probably
the cfi_probe routine needs to be able to return more than one MTD device.

-- 
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Fujitsu MBM29LV160

[Masami Komiya]

I will try to make cfi_cmdset_0002. After making it,
I want to use FTL and JFFS for our system.
These filesystems can be used on AMD's flash chips?

Our system has two interleaved flash in 32 bit mode.
So I want to implement only 32bit read & write
routines instead of 16 bit if it is allowed.
FTL or JFFS require 16bit read & write routines ?

Best Regards.

Masami Komiya


David Woodhouse wrote:
> 
> On Wed, 5 Jul 2000, Masami Komiya wrote:
> 
> >
> > It is CFI-compliant. May be, the command set is the different from
> > Intel's.
> >
> > The messages from kernel are:
> >
> > NORA: Found a coupled pair of CFI devices at location 0 in 16 bit mode
> > Primary Vendor Command Set: 0002 (AMD/Fujitsu Standard)
> 
> Excellent.
> 
> > Number of Erase Block Regions: 4
> >   Erase Region #0: BlockSize 0x4000 bytes, 1 blocks
> >   Erase Region #1: BlockSize 0x2000 bytes, 2 blocks
> >   Erase Region #2: BlockSize 0x8000 bytes, 1 blocks
> >   Erase Region #3: BlockSize 0x10000 bytes, 31 blocks
> 
> > Should I make cfi_cmdset_0002? Is there the another resources ?
> 
> Yes, you need to make cfi_cmdset_0002 for that particular
> configuration (2x16bit). It should be quite simple t copy cfi_cmdset_0001
> and modify it accordingly - not only changing the command set used
> but also changing it to drive two interleaved chips at once. You'll need
> the AMD data sheets for those chips.
> 
> For now, I'd suggest that you combine all the smaller erase blocks at the
> beginning of the device, and pretend that the erase size is always 0x10000
> (actually 0x20000 because you have two chips interleaved).  Then when you
> receive an erase request at location zero, erase all the smaller blocks at
> once.
> 
> We'll work out how to handle that properly, but not quite yet. Probably
> the cfi_probe routine needs to be able to return more than one MTD device.
> 
> --
> dwmw2


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Fujitsu MBM29LV160

[David Woodhouse]

mkomiya@crossnet.co.jp said:
> I want to use FTL and JFFS for our system. These filesystems can be
> used on AMD's flash chips?

FTL provides a block device, on which you put a 'normal' filesystem.
JFFS runs directly on the flash.

You don't need both, and FTL is patented in some jurisdictions so you're 
not permitted to use it on non-PCMCIA devices.


mkomiya@crossnet.co.jp said:
> Our system has two interleaved flash in 32 bit mode. So I want to
> implement only 32bit read & write routines instead of 16 bit if it is
> allowed. FTL or JFFS require 16bit read & write routines ?

FTL and JFFS can't actually tell what the underlying MTD driver uses to 
talk to the flash chips. So it doesn't matter. 

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org