Re: [Gumstix-users] Multiple CS's on GPMC Interface

[Søren S. C. <li...@ss...>]

Hmm - Seems like I never got to the point writing a public answer to this.
However - Here it goes... :-)

> First of all, thank you for the detailed explanations! You
> certainly seem to know quite a bit about this - do you have references for
> where you got this information from? This way, I can look it up when i have
> doubts later
Main reference is by working with the OMAP-chips for about 6½ years now.
Secondly the TRM (spruf98c.pdf) and the data manual (omap3530.pdf) come in very handy :-)

> 1) Do you have examples in the current linux-git kernel of this cache
> manipulation taking place? Is it easily doable in the linux kernel? This
> insinuates that a single driver entity has to be responsible for cache
> manipulation for any other kernel space/user-space application that wants to
> use the GPMC peripheral (as opposed to setting up the GPMC peripheral once,
> configuring the memory space and then letting any number of bus masters, i.e
> ARM, DMA etc. operate from there on in without having to 'configure' the
> GPMC and associated memory characteristics)
I do unfortunately not have any Linux references straight in my head since I have normally been dealing with the chips in a non/limited-OS-environment. That being said, I know the functions are formalized in Linux, and I think the system is pretty stable/tested, since it's as said used in case you want do to any kind of serious data transfer to NOR-flashes. Try to search for "Linux and NOR sync burst" (or similar) on Google and see what you can find. 

> 3) I notice that in the synchronous 16-bit address/data muxed interface for
> read bursting mode, there is no conveyance of the burst length in the
> protocol, i.e the OMAP3 can de-assert the OEn as long as it wants and the
> corresponding slave device has to continually provide data till the OMAP3
> feels like taking the OEn off. Am i interpreting the protocol correctly? 
I think you are correct on this. Main point though is, that the OMAP will never do anything "clever" (like filling two successive cache lines in one burst read), so the system is (easily) deterministic.

> Is there a mechanism to convey the burst length ahead of time? This way the
> slave downstream can appropriately prepare the contents of the data to be
> fetched.
Normally you run with a fixed length, for a given memory segment in case it's set for burst mode - You therefore don't need to convey the information from time to time but only once during init. I.e. NOR flashes have a control-register in which you configure how the flash should do burst accesses, and you then afterwards have to configure the OMAP in the same way. You could i.e. use this method for your FPGA as well, or you could simply fix it at i.e. 16 or 32 words/dwords transferred at a time.

> 4) What is the nBE1, nBE0 really used for? They seem to be forced to low in
> the read transactions, but toggle in the write burst transactions? 
How have you configured the chip select for a GPMC address/data multiplexed device like a NOR chip? In that case the signals indicate the validity of the upper and lower byte being transferred on the bus from the OMAP. Since you can only do 16-bit accesses (due to a 16-bit bus) you need another way to indicate if the device on the GPMC bus only gets valid data for one byte. This is the main purpose for nBE0 and nBE1 (BE=Byte Enable). For Reads they have no meaning, since you will always read 16-bit data from the device on the GPMC bus and in case the OMAP only needs 8-bit it will just mask the other 8-bits. For further info on this please have a look at a Intel Strata Flash NOR device datasheet or similar, which normally explains this in great detail.

> 5) It looks like in the address/data muxed interface, there is 27 bits of
> effective addressing available (26 bits of address + 1 more bit due to the
> 16-bit data words coming through) - this translates to 128MB of potential
> addressable memory - is this correct?
I think you are right on this, although the TRM (spruf98c.pdf) states, that a CS can be configures for 256MB, which currently confuses me a bit. It might be that the IP block can do 256MB, but I agree, that it seems, that only address lines for 128MB is connected to the package boundary/balls. In case you  need more, remember, that you can use multiple chip-selects successive after each other in order to simulate a i.e. 512MB address room. 
As well in case you need to stall a sync-write/read, please check the capabilities of the GPMC wait0-3 pins, which can be use by the slave device to stall the OMAP in case it's not ready for delivery the requested data.

Best regards - Good luck to all
  Søren

---
SSC Solutions ApS - Denmark - www.ssc-solutions.dk