Trouble indetifying FLASH part

Trouble indetifying FLASH part

[Ho-Kuo Chan]

Hi,
    I have a PPC405GP based board with a single AMD compatible Toshiba
TC58FVB321FT 4MB flash in word mode. The chip is physically mapped to
address 0x8000000 and according to the Data Sheet, is CFI compatible. I
believe I have properly configured the kernel but I can't seem to get my
chip identified. Am I missing sonething? Any help is greatly appreciated!!

This is my config:

# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
CONFIG_MTD_DEBUG=y
CONFIG_MTD_DEBUG_VERBOSE=3
# CONFIG_MTD_PARTITIONS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CHAR=y
# CONFIG_MTD_BLOCK is not set
# CONFIG_MTD_BLOCK_RO is not set
CONFIG_FTL=y
# CONFIG_NFTL is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
CONFIG_MTD_CFI_ADV_OPTIONS=y
CONFIG_MTD_CFI_NOSWAP=y
# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
CONFIG_MTD_CFI_GEOMETRY=y
CONFIG_MTD_CFI_B1=y
CONFIG_MTD_CFI_B2=y
CONFIG_MTD_CFI_B4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_INTELEXT is not set
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_RAM=y
CONFIG_MTD_ROM=y
CONFIG_MTD_ABSENT=y
CONFIG_MTD_OBSOLETE_CHIPS=y
CONFIG_MTD_AMDSTD=y
# CONFIG_MTD_SHARP is not set
CONFIG_MTD_JEDEC=y

#
# Mapping drivers for chip access
#
CONFIG_MTD_PHYSMAP=y
CONFIG_MTD_PHYSMAP_START=0x8000000
CONFIG_MTD_PHYSMAP_LEN=0x4000000
CONFIG_MTD_PHYSMAP_BUSWIDTH=2
# CONFIG_MTD_TQM8XXL is not set
# CONFIG_MTD_RPXLITE is not set
# CONFIG_MTD_DBOX2 is not set
# CONFIG_MTD_CFI_FLAGADM is not set
# CONFIG_MTD_REDWOOD is not set

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set



Ho-Kuo Chan

Re: Trouble indetifying FLASH part

[David Woodhouse]

hchan@wavesat.com said:
>  I believe I have properly configured the kernel but I can't seem to
> get my chip identified. Am I missing sonething? Any help is greatly
> appreciated!! 

It looks like what you have should work. What messages do you get when you 
boot? 

--
dwmw2

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

Hi,
    I turned on LE_BYTE_SWAP as you requested, with similar results:

physmap flash device: 4000000 at 8000000
HKC: output of ioremap: Map Priv 1 = 0xc2003000
HKC: Calling cfi_probe_chip with bus width 2, interleave 1 and device_type
16
HKC: cfi_send_gen_cmd: Addr = 0x0
HKC: cfi_send_gen_cmd: Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x1, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0xf000
HKC: cfi_send_gen_cmd: Addr = 0xaa
HKC: cfi_send_gen_cmd: Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x1, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0x9800
CFI Query Failed for driver
HKC: Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 8
HKC: cfi_send_gen_cmd: Addr = 0x0
HKC: cfi_send_gen_cmd: Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x2, type = 0x1
HKC: cfi_send_gen_cmd: Val = 0xf0f0
HKC: cfi_send_gen_cmd: Addr = 0xaa
HKC: cfi_send_gen_cmd: Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x2, type = 0x1
HKC: cfi_send_gen_cmd: Val = 0x9898
CFI Query Failed for driver
HKC: Calling cfi_probe_chip with bus width 2, interleave 2 and device_type
16
HKC: cfi_send_gen_cmd: Addr = 0x0
HKC: cfi_send_gen_cmd: Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x2, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0xf0f0
HKC: cfi_send_gen_cmd: Addr = 0x154
HKC: cfi_send_gen_cmd: Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x2, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0x9898
CFI Query Failed for driver
CFI: Found no Physically mapped flash device at location zero

I have also tried replacing the ioremap call in init)physmap with
ioremap_nocache() but with no byte swapping. Should I try it with
LE_BYTE_SWAP?

Re: Trouble indetifying FLASH part

[David Woodhouse]

hchan@wavesat.com said:
>  I have also tried replacing the ioremap call in init)physmap with
> ioremap_nocache() but with no byte swapping. Should I try it with
> LE_BYTE_SWAP? 

Yes, that could be useful -- although I don't think you should have got a 
cached mapping by default, it's worth a try.

Can you make it print the contents of the region at 0x8000000 and check it
matches what you expect to be in the flash chip? Are you sure that's
supposed to be 0x8000000 and not 0x80000000?

--
dwmw2

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

> >  I have also tried replacing the ioremap call in init)physmap with
> > ioremap_nocache() but with no byte swapping. Should I try it with
> > LE_BYTE_SWAP?
>
> Yes, that could be useful -- although I don't think you should have got a
> cached mapping by default, it's worth a try.
The ioremap_nocache with LE_BYTE_SWAP didn't help. I will return it ioremap.

>
> Can you make it print the contents of the region at 0x8000000 and check it
> matches what you expect to be in the flash chip?
I tried printk("HKC: Raw output of flash address =0x%x\n", *(unsigned
int*)0x8000000) but resulted in kernel panic. I'm starting to think this is
a virtual memory problem. Do I need a TLB entry for the device?

> Are you sure that's
> supposed to be 0x8000000 and not 0x80000000?
Yes, I have double-checked the hardware specs. I also have the board and
flash working with VxWorks which has a flat memory model.

Any other ideas?

Thanks.

HK

Re: Trouble indetifying FLASH part

[David Woodhouse]

hchan@wavesat.com said:
> I tried printk("HKC: Raw output of flash address =0x%x\n", *(unsigned
> int*)0x8000000) but resulted in kernel panic. I'm starting to think
> this is a virtual memory problem. Do I need a TLB entry for the
> device?

Yes. That's what ioremap() does for you. But the map driver will already be
setting that up -- just call the map->copy_from function in the chip probe,
to read the first 0x40-odd bytes into a buffer, and then print them and
compare with what you expected to see.

--
dwmw2

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

David Woodhouse wrote:
> Yes. That's what ioremap() does for you. But the map driver will already
be
> setting that up -- just call the map->copy_from function in the chip
probe,
> to read the first 0x40-odd bytes into a buffer, and then print them and
> compare with what you expected to see.

OK, this is what I did:
char buffer[0x40];

map->copy_from(map, (void*)buffer, 0, 0x40);

for (i = 0; i < 0x40; i++)
{
    printk("HKC: map->copy_from copied 0x%x to buffer\n", buffer[i];
}

The result was a continuous stream of 0xf0's. In VxWorks I get
0x1303434953463900 which is "..CIS59.". Does this tell you anything?

HK

Re: Trouble indetifying FLASH part

[David Woodhouse]

hchan@wavesat.com said:
>  The result was a continuous stream of 0xf0's. In VxWorks I get
> 0x1303434953463900 which is "..CIS59.". Does this tell you anything?

Yeah. It really does look like the chip isn't where you think it is.

Can you get Linux to boot anyway, with NFSroot or something? 

od -A x -t x1 /dev/mem | grep "13 03 43 49 53 46 39 00"

Or you could code the equivalent in the kernel.

--
dwmw2

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

dwmw2 wrote:
> Yeah. It really does look like the chip isn't where you think it is.
>
> Can you get Linux to boot anyway, with NFSroot or something?
>
> od -A x -t x1 /dev/mem | grep "13 03 43 49 53 46 39 00"

I am booting over tftp with nfs mounted root already. I executed the command
you provided at the console with no matches. I noted that the highest memory
address tested was ffffff which makes sense considering the system has 16 MB
RAM. Here is my physical memory map:
0x0 - 0xfffff : SDRAM
0x8000000 - 0x83FFFFF : Flash
0x9000000 - 0x90FFFFF : FPGA
0xEF600000 - 0xEFFFFFF : PPC405GP memory mapped registers
0xFFE00000 - 0xFFFFFFFF : BootPROM

Does this help?

Thanks again,
HK

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

Hi David,
    I have partially solved the problem. The PPC405GP multiplexes its GPIO
lines with the External Bus Chip Select lines. In fact, what was occurring
was that my GPIO's were misconfigured and were not acting as Chip Select
Lines. However, it's not quite working:

physmap flash device: 400000 at 8000000
HKC: Map Priv 1 = 0xc2003000
HKC: Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 8
HKC: Output Reg: 0x45480000        -------> Correct value
HKC: TCR: 0x750a0000                    -------> Correct value
HKC: ODR: 0x20000                        -------> Correct value
Control 0: 0x17ee616                        -------> Correct value
Addr = 0x0
Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x2, type = 0x1
Val = 0xf0f0
Addr = 0xaa
Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x2, type = 0x1
Val = 0x9898
Read 0x=51, cmd = 0x5151   -----> the correct value is read, but it is being
compared to a value returned by cfi_build_cmd('Q',map,cfi) in qry_present
Read 0x=52, cmd = 0x5252
Read = 0x59, cmd = 0x5959
CFI Query Failed for driver
Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 16
Output Reg: 0x45480000
TCR: 0x750a0000
ODR: 0x20000
Control 0: 0x17ee616
Addr = 0x0
Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x2, type = 0x2
Val = 0xf0f0
Addr = 0x154
Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x2, type = 0x2
Val = 0x9898
Read 0x=ffff, cmd = 0x5151
Read 0x=3000, cmd = 0x5252
Read = 0x3000, cmd = 0x5959
CFI Query Failed for driver
CFI: Found no Physically mapped flash device at location zero

The value read above is the return value of cfi_read as in the qry_present
function. I am no expert but should the comparison in qry_present:

if (cfi_read(map, base+osf*0x10)==cfi_buil_cmd('Q', map, cfi) &&
    cfi_read(map, base+osf*0x11)==cfi_buil_cmd('R', map, cfi) &&
    cfi_read(map, base+osf*0x12)==cfi_buil_cmd('Y', map, cfi))

be simply:

if (cfi_read(map, base+osf*0x10)=='Q' &&
    cfi_read(map, base+osf*0x11)=='R' &&
    cfi_read(map, base+osf*0x12)=='Y')

Thanks for all your help!!!!

Ho-Kuo Chan
Software Designer, Digital Division
Wavesat Wireless Inc.
(514) 956-6322
----- Original Message -----
From: "David Woodhouse" <dwmw2@infradead.org>
To: "Ho-Kuo Chan" <hchan@wavesat.com>
Cc: <linux-mtd@lists.infradead.org>
Sent: Thursday, May 16, 2002 11:01 AM
Subject: Re: Trouble indetifying FLASH part


>
> hchan@wavesat.com said:
> >  The result was a continuous stream of 0xf0's. In VxWorks I get
> > 0x1303434953463900 which is "..CIS59.". Does this tell you anything?
>
> Yeah. It really does look like the chip isn't where you think it is.
>
> Can you get Linux to boot anyway, with NFSroot or something?
>
> od -A x -t x1 /dev/mem | grep "13 03 43 49 53 46 39 00"
>
> Or you could code the equivalent in the kernel.
>
> --
> dwmw2
>
>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

Re: Trouble indetifying FLASH part

[David Woodhouse]

hchan@wavesat.com said:
> Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 8
> Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 16

What you have is a single chip, isn't it?

Why does it never probe for bus width 2, interleave 1 and device_type 16?

--
dwmw2

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

Hi David,
> hchan@wavesat.com said:
> > Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 8
> > Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 16
>
> What you have is a single chip, isn't it?
>
> Why does it never probe for bus width 2, interleave 1 and device_type 16?
>
> --
> dwmw2
Ooops, sorry, I missed part of the copy/paste. This is the result with
interleave at 1 with device_type 16:

Calling cfi_probe_chip with bus width 2, interleave 1 and device_type 16
Output Reg: 0x45480000
TCR: 0x750a0000
ODR: 0x20000
Control 0: 0x17ee616
Addr = 0x0
Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x1, type = 0x2
Val = 0xf000
Addr = 0xaa
Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x1, type = 0x2
Val = 0x9800
Read 0x=0, cmd = 0x5100
Read 0x=100, cmd = 0x5200
Read = 0x3e00, cmd = 0x5900
CFI Query Failed for driver

Something just occurred to me: the calculated cmd values are endian swapped.
I just checked and LE_BYTE_SWAP is still on, I have just turned it off and
the device is now recognied:

Calling cfi_probe_chip with bus width 2, interleave 1 and device_type 16
Output Reg: 0x45480000
TCR: 0x750a0000
ODR: 0x20000
Control 0: 0x17ee616
Addr = 0x0
Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x1, type = 0x2
Val = 0xf0
Addr = 0xaa
Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x1, type = 0x2
Val = 0x98
Read 0x=51, cmd = 0x51
Read 0x=52, cmd = 0x52
Read = 0x59, cmd = 0x59
Number of erase regions: 2
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 µs
Maximum byte/word write timeout: 512 µs
Full buffer write not supported
Typical block erase timeout: 1024 µs
Maximum block erase timeout: 16384 µs
Chip erase not supported
Device size: 0x400000 bytes (4 MiB)
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: 2
  Erase Region #0: BlockSize 0x2000 bytes, 8 blocks
  Erase Region #1: BlockSize 0x10000 bytes, 63 blocks
<snip>
number of CFI chips: 1
mtd: Giving out device 0 to Physically mapped flash

Thanks for your help!!!!

HK

Re: Trouble indetifying FLASH part

[Jim Zeus]

--- "Ho-Kuo Chan" <hchan@wavesat.com> wrote:
>    I have a PPC405GP based board with a single AMD compatible Toshiba
>TC58FVB321FT 4MB flash in word mode. The chip is physically mapped to
>address 0x8000000 and according to the Data Sheet, is CFI compatible. I
>believe I have properly configured the kernel but I can't seem to get my
>chip identified. Am I missing sonething? Any help is greatly appreciated!!

You should write own map code in maps directory. 



Jim Zeus

_____________________________________________________________
Want a new web-based email account ? ---> http://www.firstlinux.net

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

Re: Trouble indetifying FLASH part

[Ho-Kuo Chan]

 Hi,
     I suppose I should mention that I am using kernel 2.4.19-pre3.

> It looks like what you have should work. What messages do you get when you
> boot?

 Here is the outpt, note that lines that start with HKC are debugging
printk's I have put in:

physmap flash device: 4000000 at 8000000
HKC: output of ioremap: Map Priv 1 = 0xc2003000
HKC: Calling cfi_probe_chip with bus width 2, interleave 1 and device_type
16
HKC: cfi_send_gen_cmd: Addr = 0x0
HKC: cfi_send_gen_cmd: Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x1, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0xf0
HKC: cfi_send_gen_cmd: Addr = 0xaa
HKC: cfi_send_gen_cmd: Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x1, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0x98
CFI Query Failed for driver
HKC: Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 8
HKC: cfi_send_gen_cmd: Addr = 0x0
HKC: cfi_send_gen_cmd: Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x2, type = 0x1
HKC: cfi_send_gen_cmd: Val = 0xf0f0
HKC: cfi_send_gen_cmd: Addr = 0xaa
Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x2, type = 0x1
HKC: cfi_send_gen_cmd: Val = 0x9898
CFI Query Failed for driver
Calling cfi_probe_chip with bus width 2, interleave 2 and device_type 16
HKC: cfi_send_gen_cmd: Addr = 0x0
HKC: cfi_send_gen_cmd: Cmd_addr = 0x0, CFIDEV_INTERLEAVE = 0x2, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0xf0f0
HKC: cfi_send_gen_cmd: Addr = 0x154
HKC: cfi_send_gen_cmd: Cmd_addr = 0x55, CFIDEV_INTERLEAVE = 0x2, type = 0x2
HKC: cfi_send_gen_cmd: Val = 0x9898
CFI Query Failed for driver
CFI: Found no Physically mapped flash device at location zero