All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Retanubun <RichardRetanubun@RuggedCom.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [mpc8xxx_spi] help with using mpc8xxxx_spi and M25P40 spi flash
Date: Fri, 16 Oct 2009 17:33:15 -0400	[thread overview]
Message-ID: <4AD8E69B.4060706@RuggedCom.com> (raw)

Hello guys,

This is a derivative of my previous post for adapting mpc8xxx_spi to work with mpc8360e spi in cpu-mode.

I'm seeing something funny with using the 'sf probe' command, but not the sspi command.

Using 'sspi' command, I got a good response:

=> sspi 0 32 9f
spi_xfer: tx 9f000000 [32 of 32] bits
spi_xfer: ... 9f000000 written
[0] iR 0 ev 3 <-- [tm] isRead spi->event
[0] spi_xfer: rx 1fffa270 = ff202013
spi_xfer: transfer ended. Value=ff202013
*** spi_xfer: exit
FF202013
=>


When using 'sf probe', only the first tx data got transmitted (verified with scope):

sf probe 0:0
spi_xfer: tx 9fffd600 [8 of 8] bits
spi_xfer: ... 9fffd600 written
[0] iR 0 ev 3 <-- [tm] isRead spi->event
[0] spi_xfer: rx 00000000 = ffff0001
spi_xfer: transfer ended. Value=ffff0001
*** spi_xfer: exit
spi_xfer: tx 000102ff [32 of 40] bits
spi_xfer: ... 000102ff written <-- Never got sent out!
[0] iR 0 ev 1 <-- [tm] isRead spi->event
[1] iR 0 ev 1 <-- [tm] isRead spi->event
[2] iR 0 ev 1 <-- [tm] isRead spi->event
...
[1000] iR 0 ev 1
*** spi_xfer: Time out during SPI transfer
spi_xfer: transfer ended. Value=00000000
spi_xfer: tx 03ffffff [8 of 8] bits
spi_xfer: ... 03ffffff written <-- Never got sent out!
[0] spi_xfer: rx 1f5b4da8 = 13000000
spi_xfer: transfer ended. Value=13000000
*** spi_xfer: exit
SF: Got idcode 13 00 00 00 00
Failed to initialize SPI flash@0:0
=>

On the oscilloscope, even though "spi_xfer: ... 000102ff written" is shown,
I only see the first byte (9f) being sent and the clock stops there, explaining the debug printout during getting
rx data that shows the rx buffer never got any data

I have tried replacing the spi->tx = tmpdout statement (and all register access) with out_be##(&spi->tx, tmpdout)
in case the compiler is optimizing things out, but this makes no difference.

but if this is true, won't the MPC8349EMDS see this problem also?

What am I missing here?

Modified driver is attached.

Thanks for all the help!

- Richard


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpc8xxx_spi.c
Type: text/x-csrc
Size: 8218 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091016/82df6c28/attachment.c 

                 reply	other threads:[~2009-10-16 21:33 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AD8E69B.4060706@RuggedCom.com \
    --to=richardretanubun@ruggedcom.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.