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

Greg,

Can you explain this part, specifically?

>Also, you must keep the DATA_WIDTH_MATCHING turned on with the hack to use JFFS2.

Is it the case that the Linux driver for the EMC peripheral does not correctly watch for / react to the “Byte Enable” lines of the OPB bus and that, therefore, ALL reads must be 32-bits wide?

Thanks,

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

From: owner-microblaze-uclinux@itee.uq.edu.au [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of Greg Miller
Sent: Thursday, July 07, 2005 12:46 PM
To: microblaze-uclinux@itee.uq.edu.au
Subject: Re: [microblaze-uclinux] CFI Flash on 8bit bus?

The problem is with the EMC controller and doing double writes. Reads are OK. The hack is that you modify the HDL to make it such that when doing reads it's still 32-bit and a write is the width of the flash. The 8-bits can be modified as the 16-bit version was. See the lx25 board release. Chipscope is a grea way to see and troubleshoot these issues.

When writing a boot loader you must modify the code to compinsate. Inside uCLinux it must be a 32-bit multiple read and a single write to the bit-width in order for the JFFS filesystem to work. When building the kernel make sure to set the bit-width of the flash if Linux does not see the flash properly.

Also, you must keep the DATA_WIDTH_MATCHING turned on with the hack to use JFFS2. If you are not going to use JFFS2 or similar file system in uCLinux, non of this matters, just keep DATA_WITCH_MATCHING = 0.

Greg Miller

Michael Libeskind <mbl@lucent.com> wrote:

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
________________________________________________________________________