On Fri, 2008-10-17 at 20:14 -0400, Duane Ellis wrote: > John McCarthy> I've got an ARM926EJ-S > > A bit more detail about the actual chip would be helpful. (arm926 is the > core) but who makes the chip? > Only thing I find that names "flash integration unit" is a freescale thing.
Yes, but unfortunately I can't say much more than that at present. > John McCarthy> Could anyone give me a high level description on what > would be needed to add this support and how it should be integrated into > OpenOCD? > > Hmm, generally OpenOCD sees memory as having an address and data bus. > > SPI flash - is not a traditional "bus" - it is a serial protocol. But > you say this: > > John McCarthy> The FIU on the ARM926EJ-S maps the SPI flash to the ARM > address space > John McCarthy> starting at address 0x40000000 so it reads like ordinary > memory. > > Sounds like a hardware state machine of some sort. - Quit strange. I think of it more like a flash memory controller except with SPI flash attached instead of parallel flash. At least that is true for reading, it looks like writes to the SPI flash memory region are not supported (but the UMA registers support write transactions to the SPI flash). > John McCarthy>Is this a common way to interface SPI flash to a processor? > > no - it is not a standard in way that I am familiar with - ie: on > pic32, arm, blackfin, in some ways it sounds like the "one-nand" that > has a small XIP buffer for booting - but not really. Do these devices support SPI flash as system flash? Or is SPI flash just treated like another SPI peripheral (but not a bootable flash)? > John McCarthy> [ so how do I hook it up to openocd? ] > > Good question. This FIU mode is going to be silicon vendor specific > beyond all possible ways. > > You are correct - from the stand point of the spi flash - the commands > should be mostly generic. However :-( the SPI controller is different on > every platform and every platform implementation, for example I might > connect it to SPI port 2, using GPIO 42 as the chip select - and you > might use the *SAME* arm chip as me - but use SPI port 1 - and SPICS3 as > the control signal. > > All hope is not lost - there is a way - I think - but it will seem ass > backwards to JTAG - but it would work. I was thinking of either a processor variant (since the flash controller is an integral part of SOC) or an option if this method of attaching SPI flash as system flash was somewhat generic (which it doesn't appear to be as I expected). > > ==================================== > Step #1 - Look at this Xilinx app note about programing SPI flash chips > on the PCB. > > http://www.xilinx.com/support/documentation/application_notes/xapp951.pdf > > See the schematic on page 4, see note #(3) "PROG_B" should be held LOW > during the direct programing of the SPI lash. > In effect, that holds the XILINX in RESET - we could do the same - with > either RESET or TRST. > > ==================================== > Step #2 - You probably need "flying leads" to do this > > http://toolbox.xilinx.com/docsan/xilinx5/data/docs/pac/pac0020_6.html > > See the bottom portion of the above web page. > > ==================================== > > Step 3 - Put the JTAG tap in a funny mode... > > Then I believe it is a simple matter of walking the JTAG tap through > this sequence: > > 1) make Reset=SPI-CS=high. > 2) Goto state: Shift DR - but do not shift yet. > 3) Reset=SPI-CS=Low > 4) Now shift data in Shift DR state. > TDI => data to the spi flash. > TDO => data from the spi flash. > 5) Repeat #4 until data is complete > 6) make Reset=SPI-CS=high. > 7) Return to jtag state Test Logic Reset. > > ==================================== > All it will take is somebody with the time to fiddle with it and make it > happen. > > And - we have a GENERIC SPI flash programmer :-) Unfortunately I don't believe this would work for me since I have an SPI flash controller on my SOC processor and it is the way to access the flash. Since I'm not yet familiar with the OpenOCD flash code for the ARM targets, I'm just looking for some high level pointers on how this could best be implemented from the people who understand this code much better than I do. Thanks, John McCarthy. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
