| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <0168f45b-e624-4da0-878e-655f0f731e13@gmail.com>
Date: Sun, 07 Apr 2019 00:23:33 +0200
From: Vicente Bergas <vicencb@...il.com>
To: Emil Renner Berthing <kernel@...il.dk>,
Heiko Stuebner <heiko@...ech.de>,
Mark Brown <broonie@...nel.org>
Cc: <linux-rockchip@...ts.infradead.org>, <linux-spi@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [BUG] Rockchip SPI: long burst writes produce unexpected result
Hi again,
just found the first offending commit:
commit eff0275e5253604429aedc42b008c5fcaa6cc597
Date: Wed Oct 31 11:57:06 2018 +0100
spi: rockchip: simplify use_dma logic
We only need to know if we're using dma when setting
up the transfer, so just use a local variable for
that.
It was mainlined in Linux v5.0.
This is the result of a binary search among this list of commits:
04290192f7ebe892828f69ac57c4684e25da378d
65498c6ae2414a1425aa6c4231e79e2998afec05
01b59ce5dac856323a0c13c1d51d99a819f32efe
74b7efa82b11914c21e30d987ed61d3daa57ff21
420b82f842941a32adf309ca1b193adfc77616b0
eff0275e5253604429aedc42b008c5fcaa6cc597
d790c342e689ea77a5cf72d5b993299911ee5276
eee06a9ee2cd5deaddc5f77ce8f6118c8b82b2a0
fc1ad8ee33480bdf0493b54907b74538bf9b75b8
ce386100d99976442093ff57b5b24a9562c6cc27
fab3e4871f623c8f86e8a0e00749f1480ffa08db
2410d6a3c3070e205169a1a741aa78898e30a642
31bcb57be12fd815a9051f07d64334809b8cb472
30688e4e670d21126aa596df4523940e2f8d24de
a3c174021ce780f5d2e9b2105e2cb4903a37226d
d9071b7e9fc474e474e3b865428a8d30d88daaf4
f340b920511a666b02d371e88801d3817ea7a880
058f7c509e84abd36f988d4e16432366bd793d8f
dcfc861d24ec19f0d0d3d55bb016646794571fbb
dd8fd2cbc73f8650f651da71fc61a6e4f30c1566
Regards,
Vicenç.
On Saturday, April 6, 2019 7:34:32 PM CEST, Vicente Bergas wrote:
> 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ç.
>
>
>
Powered by blists - more mailing lists