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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox