From: Xavier Drudis Ferran <xdrudis@tinet.cat>
To: u-boot@lists.denx.de
Cc: Jagan Teki <jagan@amarulasolutions.com>
Subject: [PATCH v3 4/4] spi: spi-mem: Allow address 0 for SPI mem operations
Date: Wed, 20 Jul 2022 17:43:35 +0200 [thread overview]
Message-ID: <20220720154335.GH2049@begut> (raw)
In-Reply-To: <20220720153610.GD2049@begut>
Trying to boot my Rock Pi 4B from its XTX SPI NOR Flash failed when my
custom compiled TF-A had a load address of 0.
The same TF-A booted correctly from MMC.
Add a local variable to spi_mem_exec_op() to determine operation
direction, instead of testing rx_buf or tx_buf for null value, so that
a buffer at RAM address 0 is accepted.
This commit also cuts short a debug dump of the image loaded to show
only the first 0x1000 and the last 0x100 bytes, and not swamping the
serial log. When adding the #define DEBUG to the .c file one can
change these limits at the same time if they don't fit.
Changed since v2:
- no changes
Changed since v1:
- no changes
Signed-off-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Cc: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/spi/spi-mem.c | 34 ++++++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 9c1ede1b61..4dc90addb3 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -21,6 +21,8 @@
#include <spi.h>
#include <spi-mem.h>
#include <dm/device_compat.h>
+#define DEBUG_DUMP_START_LENGTH 0x1000
+#define DEBUG_DUMP_END_LENGTH 0x100
#endif
#ifndef __UBOOT__
@@ -373,12 +375,21 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
if (msg.actual_length != totalxferlen)
return -EIO;
#else
+ enum spi_mem_data_dir dir = SPI_MEM_NO_DATA;
if (op->data.nbytes) {
- if (op->data.dir == SPI_MEM_DATA_IN)
+ dir = op->data.dir;
+ if (dir == SPI_MEM_DATA_IN) {
rx_buf = op->data.buf.in;
- else
+ } else {
tx_buf = op->data.buf.out;
+ /**
+ * keep old behaviour, to assume SPI_MEM_DATA_OUT
+ * if ever data.nbytes!=0 but data.dir==SPI_MEM_NO_DATA
+ * (hopefully never)
+ */
+ dir = SPI_MEM_DATA_OUT;
+ }
}
op_len = op->cmd.nbytes + op->addr.nbytes + op->dummy.nbytes;
@@ -410,7 +421,7 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
/* 1st transfer: opcode + address + dummy cycles */
flag = SPI_XFER_BEGIN;
/* Make sure to set END bit if no tx or rx data messages follow */
- if (!tx_buf && !rx_buf)
+ if (dir == SPI_MEM_NO_DATA)
flag |= SPI_XFER_END;
ret = spi_xfer(slave, op_len * 8, op_buf, NULL, flag);
@@ -418,7 +429,7 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
return ret;
/* 2nd transfer: rx or tx data path */
- if (tx_buf || rx_buf) {
+ if (dir != SPI_MEM_NO_DATA) {
ret = spi_xfer(slave, op->data.nbytes * 8, tx_buf,
rx_buf, SPI_XFER_END);
if (ret)
@@ -430,10 +441,17 @@ int spi_mem_exec_op(struct spi_slave *slave, const struct spi_mem_op *op)
for (i = 0; i < pos; i++)
debug("%02x ", op_buf[i]);
debug("| [%dB %s] ",
- tx_buf || rx_buf ? op->data.nbytes : 0,
- tx_buf || rx_buf ? (tx_buf ? "out" : "in") : "-");
- for (i = 0; i < op->data.nbytes; i++)
- debug("%02x ", tx_buf ? tx_buf[i] : rx_buf[i]);
+ op->data.nbytes,
+ dir == SPI_MEM_DATA_IN ? "in" : (dir == SPI_MEM_DATA_OUT ? "out" : "-"));
+ for (i = 0; i < op->data.nbytes && i < DEBUG_DUMP_START_LENGTH ; i++)
+ debug("%02x ", dir == SPI_MEM_DATA_OUT ? tx_buf[i] : rx_buf[i]);
+ if (op->data.nbytes > DEBUG_DUMP_END_LENGTH && op->data.nbytes > DEBUG_DUMP_START_LENGTH &&
+ i < op->data.nbytes - DEBUG_DUMP_END_LENGTH) {
+ debug(" ... ");
+ i = op->data.nbytes - DEBUG_DUMP_END_LENGTH;
+ }
+ for (; i < op->data.nbytes ; i++)
+ debug("%02x ", dir == SPI_MEM_DATA_OUT ? tx_buf[i] : rx_buf[i]);
debug("[ret %d]\n", ret);
if (ret < 0)
--
2.20.1
prev parent reply other threads:[~2022-07-20 15:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 15:36 [PATCH v3 0/4] mtd: spi: spi-nor: rk3399: rock-pi-4: u-boot/next Support SPI NOR Flash in Rock Pi 4 (XTX xt25f32b) Xavier Drudis Ferran
2022-07-20 15:39 ` [PATCH v3 1/4] mtd: spi: spi-nor: Add Rock pi 4b new flash chip Xavier Drudis Ferran
2022-07-20 15:41 ` [PATCH v3 2/4] rockchip: rk-3399: rock-pi-4: dts: Add XTX SPI NOR 4MiB Flash chip in Rock Pi 4 boards from rev 1.4 on Xavier Drudis Ferran
2022-08-27 4:02 ` Kever Yang
2022-07-20 15:42 ` [PATCH v3 3/4] spi-nor: Adapt soft reset to XTX25F32B in Rock Pi 4 rev 1.4 Xavier Drudis Ferran
2022-07-26 7:13 ` Pratyush Yadav
2022-07-26 8:27 ` Xavier Drudis Ferran
2022-07-26 9:09 ` Pratyush Yadav
2022-07-26 11:19 ` [SPAM] " Xavier Drudis Ferran
2022-09-01 12:17 ` Kever Yang
2022-07-20 15:43 ` Xavier Drudis Ferran [this message]
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=20220720154335.GH2049@begut \
--to=xdrudis@tinet.cat \
--cc=jagan@amarulasolutions.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