From: Vicente Bergas <vicencb@gmail.com>
To: <linux-rockchip@lists.infradead.org>, <linux-spi@vger.kernel.org>,
Mark Brown <broonie@kernel.org>, Heiko Stuebner <heiko@sntech.de>
Cc: <linux-arm-kernel@lists.infradead.org>, <linux-kernel@vger.kernel.org>
Subject: [BUG] Rockchip SPI: long burst writes produce unexpected result
Date: Sat, 06 Apr 2019 19:34:32 +0200 [thread overview]
Message-ID: <21d83ed2-a8db-49cf-ba8c-c7844157d7b0@gmail.com> (raw)
Hi,
i have been experiencing issues writing to NOR-Flash SPI Memories
from two RK3399-based platforms: gru-kevin and sapphire board.
For kevin, this resulted in a bricked device because that memory
is the only boot device.
Fortunately an external programmer is available.
In order to isolate where the issue can be, several tests have been
done, after which it makes me think the issue is related to the
Rockchip SPI driver.
4KB burst reads work fine.
The issue is only observed on the write burst length.
Test user user/kernel kernel RK3399
Num space interface space SoC Status Notes
--------------------------------------------------------
1 flashrom linux_mtd MTD/RKspi RKspi Fail
2 flashrom linux_spi RKspi RKspi Fail
3 flashrom linux_spi spi_gpio GPIO OK
4 custom linux_spi spi_gpio GPIO OK 260-byte burst writes
5 custom linux_spi RKspi RKspi Fail 260-byte burst writes
6 custom linux_spi RKspi RKspi OK 1-byte burst writes
7 custom linux_spi RKspi RKspi OK 47-byte burst writes
8 custom linux_spi RKspi RKspi Fail 48-byte burst writes
3, 4) Unaccetably slow, device tree is
spi_gpio {
compatible = "spi-gpio";
#address-cells = <1>;
#size-cells = <0>;
cs-gpios = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
sck-gpios = <&gpio1 RK_PB1 GPIO_ACTIVE_HIGH>;
mosi-gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_HIGH>;
miso-gpios = <&gpio1 RK_PA7 GPIO_ACTIVE_HIGH>;
num-chipselects = <1>;
spidev@0 {
compatible = "spidev";
reg = <0>;
spi-max-frequency = <50000000>;
};
};
2, 5, 6, 7, 8) device tree is
&spi1 {
status = "okay";
spidev@0 {
compatible = "spidev";
reg = <0>;
spi-max-frequency = <50000000>;
};
};
5, 6, 7, 8) Burst writes are performed this way
enum { BURST = 48 };
struct spi_ioc_transfer msg[0x105];
unsigned i = 0;
for (unsigned j = 0; j < wcnt; j += BURST) {
msg[i++] = { .tx_buf = warr, .len = BURST<wcnt-j ? BURST : wcnt-j };
warr += BURST;
}
if (rcnt)
msg[i++] = { .rx_buf = rarr, .len = rcnt };
ioctl(fd, SPI_IOC_MESSAGE(i), msg);
1, 2, 5, 8) I have no logic analyzer to see what is happenning on the
SPI bus, but when it fails at 48-byte bursts, the contents of the memory
are like this:
Addr Expected Actual
000 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
020 FF FF FF FF FF FF FF FF FF FF FF FF F1 F2 F3 F4 FF FF FF FF FF FF FF
FF FF F1 F2 F3 F4 FF FF FF
030 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
040 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
050 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
060 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
070 FF FF FF FF FF FF FF FF FF FF FF FF E1 E2 E3 E4 FF FF FF FF FF FF E1
E2 E3 E4 FF FF FF FF FF FF
080 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
090 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
0A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
0B0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
0C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
0D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
0E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
0F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
780 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
790 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
7A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
7B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
7C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
7D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
7E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
7F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF
800 01 02 03 04 00 00 00 00 00 00 00 00 00 00 00 00 01 02 03 04 00 00 00
00 00 00 00 00 00 00 00 00
810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
820 00 00 00 00 00 00 00 00 00 00 00 00 05 06 07 08 00 00 00 00 00 00 00
00 00 05 06 07 08 00 00 00
830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
860 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
870 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Regards,
Vicenç.
next reply other threads:[~2019-04-06 17:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-06 17:34 Vicente Bergas [this message]
2019-04-06 22:23 ` [BUG] Rockchip SPI: long burst writes produce unexpected result Vicente Bergas
2019-04-07 0:38 ` Vicente Bergas
2019-04-07 0:57 ` [PATCH] spi: rockchip: Revert "set min/max speed" Vicente Bergas
2019-04-08 22:35 ` Vicente Bergas
2019-04-07 19:55 ` [BUG] Rockchip SPI: long burst writes produce unexpected result Emil Renner Berthing
2019-04-08 11:19 ` Vicente Bergas
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=21d83ed2-a8db-49cf-ba8c-c7844157d7b0@gmail.com \
--to=vicencb@gmail.com \
--cc=broonie@kernel.org \
--cc=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).