[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [microblaze-uclinux] CFI Flash on 8bit bus?
Remember with DATAWITH = 1 and hack, the bootloader much be changed to compensate. I ave not tried this with uBoot, and I suspect the code needs to be changed.
Try the bootloader I wrote (or Davids) in our designs.
Michael Libeskind <mbl@lucent.com> wrote:
So far for me,
HACK + C_INCLUDE_DATAWIDTH_MATCHING = '1' = stuck flash bit 7
HACK + C_INCLUDE_DATAWIDTH_MATCHING = '0' = working OK (with the known
limitation that SW can not do a 32 bit read)
I've been digging through the simulation and with chipscope for most of
this afternoon and haven't found the problem yet. I'll keep you posted.
David Banas wrote:
> Greg,
>
>
>
> Thanks for the correction. What happens if you use the hack and set
> C_INCLUDE_DATAWIDTH_MATCHING to “0”?
>
>
>
> 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:37 PM
> *To:* microblaze-uclinux@itee.uq.edu.au
> *Subject:* RE: [microblaze-uclinux] CFI Flash on 8bit bus?
>
>
>
> No, you must use the hack and keep DATA_WITCH_MATCHING=1.
>
> */David Banas /* wrote:
>
> 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 c! ase, 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
>&g!
t; 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 b!
een
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/
>
>
> ________________________________________________________________________
> 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>
________________________________________________________________________
>
--
Michael Libeskind
mbl@lucent.com
732-949-7657
___________________________
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/