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