Armand Ciejak <armand.ciejak@free.fr> wrote:
Here is how the flash is connected, could you confirm that it’s the
reason of the driver failure?
I can’t confirm that this is the problem, but it seems likely…
CPU BUS D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
FLASH D7 D6 D5 D4 D3 D2 D1 D0 D15 D14 D13 D12 D11 D10 D9 D8
To me it looks like a “wrong” connection since the byte should be swapped
which would lead to:
CPU BUS D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
FLASH D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0
If this is the reason of the problem, which part of the driver must be
customized?
It’s difficult to say which components need to be modified, without
seeing exactly what is going out on the bus, and what is coming back from
the flash chip. To get a better understanding of this, I would start manually
sending commands to the flash, and then reading back what the flash chip
is returning. For example, on a ‘normally’ wired system, with this particular
flash part, writing a command of 0x0090 (read identifier codes) should return
the following data: 0x0089 for manufacturer ID, and 0x0017 for device ID:
out16 0xff800000 0x0090
in16 0xff800000 (should get 0x0089)
in16 0xff800002 (should get 0x0017)
If you just get back array data instead of a response to the command, then
the flash chip likely didn’t recognise the command. I would then try reversing
the byte order of the command:
out16 0xff800000 0x9000
and see what that returns, etc., until you can determine how the CPU and
the flash ‘see’ each other.
If it’s a matter of command bytes needing to be swapped, then you would
modify the send_command() routine in mem_access.c of the flash mtd code.
If data bytes need to be swapped, then you may need to modify the readmem16()
and writemem16() routines of the same file.
Thanks
Armand
On Tue, 10 May 2005 15:16:31 +0200, Dave Green <> dgreen@qnx.com> > wrote:
Armand Ciejak <> armand.ciejak@free.fr> > wrote:
Thanks for the explanations!!!
I still have a question about the driver, what exactly mean those terms:
- device width (??? not shure, my assemption is: bus size of 1 chip)
- bus width (CPU bus size in byte)
- chip inter (number of physical chip)
Which would lead to: device width = bus width / chip inter
Yes, this is correct.
If i’m right, in my case the configuration should be:
- device width = 2 (16bit bus)
- bus width = 2 (16bit bus)
- chip inter = 1 (1 chip)
I have only 1 Flash chip (Intel 28F640J3) connected to the local bus.
Everything is configured in 16bit CPU bus and Flash memory.
Armand
Dave Green wrote:
Armand Ciejak <> armand.ciejak@free.fr> > wrote:
Since we are designing a custom board, it would be helpfull to know
what’s
the “standard” way of wiring the flash.
It would save some time if we can directly use the devf-generic driver
with our custom board.
What I mean is that some boards are wired with board-specific GPIO
pins being used to suppliment flash address control. Sometimes
the flash is on a chip select which can only deal with specific width
reads and writes (ex. a 16 bit read is fine, but a 32 bit read will
cause a bus fault), so devf-generic’s probing routines will cause the
fault to occur. In a recent system that I worked on, 16 bit flash was
wired to a bus where 16 bit writes worked fine, but 16 bit reads had
to be done as a sequence of two 8 bit reads. Sometimes boards will have
two boot-block flash devices mapped linearly, one after the other, so
special code has to be written to deal with the boot blocks in the
middle of the flash array. Sometimes hardware designers don’t offset
the address pins properly when interleaving flash. I recall a board
which had two banks of flash, and the bytes were swapped on the
upper bank, because the hardware designer intended to use a different
type of flash in that bank in the future. The list goes on…
None of these things are necessarily ‘wrong’, but all of them prevented
the devf-generic driver from working, and made it necessary to develop
a custom flash driver.
Thanks.
Armand
On Thu, 05 May 2005 15:40:38 +0200, Dave Green <> dgreen@qnx.com> > wrote:
Hello Armand,
While we try to make the devf-generic driver as ‘generic’ as
possible,
there are many boards we have encountered where the flash is wired in
such a way that devf-generic simply doesn’t work. In some cases (like
yours) it fails to correctly identify the flash array configuration,
and in other cases, it won’t detect any flash at all. This can
sometimes
be worked around by passing different options to devf-generic, but
not
always.
In these situations, it is necessary to use the flash TDK to identify
the problem, and then modify the various flash probe and ident
routines,
and create a custom flash driver which works with the board. Even
though
the flash on the board is a standard supported part, the way that
Metroworks
wired the flash may be non-standard.
In short, devf-generic is not meant to be a panacea, just a driver
which will hopefully work in most cases.
Dave
bilouteQNX <> armand.ciejak@studer-dot-ch.no-spam.invalid> > wrote:
I’m using the MPC8540ADS bsp on a metrowerks board. Until now it
worked perfectly with some very small changes.
But now I’ve got a problem using the devf-generic to create a
partition on the flash memory (Intel 28F640J3).
The Flash is configured with 16bit bus width but the driver always
detect 8 bit port:
devf-generic -s0xFF800000,8M -vvv
devf: fs0 socket generic
trying device width = 4
devf: bus width = 8
devf: trying chip inter = 2
devf: bus width = 4
devf: trying chip inter = 1
.
.
.
trying device width = 1
devf: bus width = 8
devf: trying chip inter = 8
devf: bus width = 4
devf: trying chip inter = 4
devf: bus width = 2
devf: trying chip inter = 2
devf: bus width = 1
devf: trying chip inter = 1
devf: chip total = 1
devf: bus width = 1
devf: chip interleave = 1
devf: fs0 array CFI U: 40 S: 020000
devf: fs0p0 raw U: 40
If I try to force the bus width to 16 bit then it fails:
[code:1:4f0ef354bd]# devf-generic -s0xFF800000,8M,2 -vvv
devf: fs0 socket generic
devf: Unable to properly identify any flash devices
#[/code:1:4f0ef354bd]
OR
[code:1:4f0ef354bd]# devf-generic -s0xFF800000,8M,128k,2,1 -vvv
devf: fs0 socket generic
devf: Unable to properly identify any flash devices
#[/code:1:4f0ef354bd]
With the auto detect mode I can erase the flash but not format it:
[code:1:4f0ef354bd]# flashctl -p /dev/fs0 -l1M -e -vvv
Erasing device /dev/fs0
…
devf: fs0p0 raw U: 40
flashctl -p /dev/fs0p0 -l1M -f -vvv
Formatting device /dev/fs0p0
devf: over poll waiting for buffered write completion in
f3s_iCFI_v2write()
devf: fs0p0 bad H[00] P[00] # 000010 (3)
DCMD_F3S_FORMAT failed (errno 5)
flashctl: format failed
#[/code:1:4f0ef354bd]
Any
idea?
\
Using Opera’s revolutionary e-mail client: > http://www.opera.com/mail/
\
–
Using Opera’s revolutionary e-mail client: > http://www.opera.com/mail/
–
David Green (dgreen@qnx.com)
QNX Software Systems Ltd.
http://www.qnx.com