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
Field Applications Engineer
Nu Horizons Electronics Corp.
2070 Ringwood Avenue
San Jose, CA
(408)434-0800 - office
(415)846-5837 - cell
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Greg Miller
Sent: Thursday, July 07, 2005
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
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.
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
=> 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.
Errol Terblanche wrote:
> Hi David,
> Ahh, so that is why it specifically mentions "16-bit flash works with
> filesystem". :-).
> Thanks for the info.
microblaze-uclinux mailing list
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