On Thursday, July 07, 2011 23:39:14 Jonathan Stroud wrote:
> > the jedec spec (which all the spi flashes ive worked with support)
> > supports 8bit transfers to get the idcode out, and from there you know
> > exactly what manufacturer it is and its device id. and all the spi
> > flashes ive used work in 8bit mode. this is also how the u-boot spi
> > flash driver operates, as well as the linux kernel spi flash driver.
> >
> > then for addresses, the first three bytes after the command are simply
> > the addresses:
> > static void spi_flash_addr(u32 addr, u8 *cmd)
> > {
> >
> > /* cmd[0] is actual command */
> > cmd[1] = addr >> 16;
> > cmd[2] = addr >> 8;
> > cmd[3] = addr >> 0;
> >
> > }
> >
> > keeping the overrides on these is fine, but the default should match
> > this behavior (maybe it does already and i just didnt read the code
> > close enough?).
>
> I just remembered that I have a bunch of jedec compliant SPI flashes, they
> just aren't currently accessible over JTAG. I can rework a board to put
> that flash in the place of the one that is JTAGable. Then I can go ahead
> and try to implement this the right way.ive got plenty of boards with diff jedec flashes that work with u-boot/linux, so it's easy for me to test. > I figure the best way will be > for detectflash to automatically detect the flash and set the address size > appropriately. Otherwise, you will pass all the required information via > command line parameters. How does that sound? for now, let's keep the spi bus the same. leave the defaults of 8bit transfers with 0 addr shifting as that's how most spi flashes operate. we can ponder flash/bus interaction reworking later across all of them. and that way we at least have working code as a base. so, let's focus on the spi flash driver and moving the size/etc... assumptions out of the core code and into a data structure. do we have to worry about how fast we drive the SPI pins ? the read command you've defaulted to is the "slow" one iirc and cannot operate over a certain speed. > Yeah, I realized that. But I did this over a year ago, and at the time it > was pretty easy to manage. At some point I gave up on this code ever > getting merged and moved on and checked it into another svn server. Now, > I am too lazy to switch. <sad face> -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
