RE: [microblaze-uclinux] CFI Flash on 8bit bus?

["David Banas" <dbanas@xxxxxxxxxxxxxx>]

As I understand it,

- C_INCLUDE_DATAWIDTH_MATCHING
	Setting this parameter to "1" for a particular memory bank (any
type, FLASH or otherwise) causes the EMC peripheral to "report" its external
device as a 32-bit unit to the MicroBlaze and conduct as many consecutive
reads/writes as are necessary, in order to "fill" the internal 32-bit data
path of the OPB bus, whenever the MicroBlaze issues a read/write from/to
that particular peripheral. So, for instance, in the case of an external
16-bit wide FLASH chip, when the EMC receives a request from the MicroBlaze,
via the OPB bus, to read/write from/to the FLASH, that request comes in the
form of a 32-bit read/write. The EMC then performs 2 consecutive
reads/writes, in order to fulfill the request. In the case of FLASH memory,
this works fine for reads, but not for writes, due to the writing algorithm
used by most common FLASH memory chips, which requires that a command to
write data be written to the chip immediately before the actual data to be
stored is written. The assumptions being made by the EMC, when operated in
"data width matching" mode, break this algorithm. So, you must leave the
C_INCLUDE_DATAWIDTH_MATCHING parameter set to "0" for any EMC-controlled
memory banks that are FLASH.

- EMC Peripheral HDL hack
	This modification to the HDL code for the EMC peripheral, made by
Greg Miller of Avnet-Denver, forces EMC writes to use a "non-data width
matching" protocol, regardless of the state of the
C_INCLUDE_DATAWIDTH_MATCHING parameter.

Now, here's the problem with what I just wrote, above: if both paragraphs,
above, are correct, then we ought to be able to turn on data width matching,
reaping its rewards when reading from FLASH without breaking our writes to
FLASH. However, this doesn't seem to be the case, as you report needing to
set C_INCLUDE_DATAWIDTH_MATCHING to "0", in order to get things working. So,
there's something I still don't understand about all this.

Greg? John? Class? Anyone? Beuller?


David Banas
Field Applications Engineer
Nu Horizons Electronics Corp.
2070 Ringwood Avenue
San Jose, CA 95131
(408)434-0800 - office
(415)846-5837 - cell
http://www.nuhorizons.com
> -----Original Message-----
> From: owner-microblaze-uclinux@itee.uq.edu.au [mailto:owner-microblaze-
> uclinux@itee.uq.edu.au] On Behalf Of Michael Libeskind
> Sent: Thursday, July 07, 2005 6:36 AM
> To: microblaze-uclinux@itee.uq.edu.au
> Subject: Re: [microblaze-uclinux] CFI Flash on 8bit bus?
>
> Can someone tell me a little bit more about the issues with the EMC core
> and C_INCLUDE_DATAWIDTH_MATCHING?  I'm actually using u-boot on an ML403
>   board and have changed the flash to be just 16 bits wide because my
> real production board will have just one flash chip.
>
> If C_INCLUDE_DATAWIDTH_MATCHING_0 is set to 0 everything works fine and
> I can read and write the flash chip as expected 16 bits at a time.
>
> If C_INCLUDE_DATAWIDTH_MATCHING_1 is set to 1 I can no longer read/write
> as 16 bits.  I end up with bit 7 of the flash stuck.  Example, In u-boot
> I execute:
>
> => mw.w 0x68000000 0x10         (unlock)
> => mw.w 0x68000000 0x1234       (write 0x1234)
> => mw.w 0x68000000 0xff         (switch to memory array)
> => md.w 0x68000000 10           (read)
> 68000000: 12b4 ffff ffff ffff ffff ffff ffff ffff    ................
> 68000010: ffff ffff ffff ffff ffff ffff ffff ffff    ................
> =>
>
> The status right before the read would have been 0x0080 so I think that
> may have something to do with the position of the stuck bit.  I have
> updated mem_state_machine.vhd and mem_steer.vhd in
> /hw/XilinxProcessorIPLib/pcores/emc_common_v2_00_a/hdl/vhdl with the
> hacked version for 16 bits and everything looks great in simulation. I
> plan on breaking out chipscope later today, but if anyone has any
> insight I would certainly appreciate it.
>
> Thanks
>
>
>
> Errol Terblanche wrote:
> > Hi David,
> >
> > Ahh, so that is why it specifically mentions "16-bit flash works with
> JFFS2
> > filesystem". :-).
> >
> > Thanks for the info.
> >
> > Thanx,
> > E
> >
> ___________________________
> microblaze-uclinux mailing list
> microblaze-uclinux@itee.uq.edu.au
> Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
> Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-
> uclinux/
>
>
> ________________________________________________________________________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System. For more information on a proactive email security
> service working around the clock, around the globe, visit
> http://www.messagelabs.com
> ________________________________________________________________________


___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/