Call for testing: spi-mem driver for Aspeed SMC controllers

[Cédric Le Goater]

On 3/3/22 10:45, Joel Stanley wrote:
> On Wed, 2 Mar 2022 at 05:45, Cédric Le Goater <clg at kaod.org> wrote:
>>
>> On 3/1/22 13:20, Joel Stanley wrote:
> 
>>> [    0.746796] spi-nor spi0.0: w25q512jv (65536 Kbytes)
>>> [    0.808104] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0641]
>>> [    0.862687] spi-nor spi0.1: w25q512jv (65536 Kbytes)
>>> [    0.923991] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0641]
>>
>>
>> On the FMC controller, could you please increase the clock to :
>>
>>          spi-max-frequency = <100000000>;
>>
>> and check the results ?
> 
> +++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
> @@ -162,7 +162,7 @@ flash at 0 {
>                  status = "okay";
>                  m25p,fast-read;
>                  label = "bmc";
> -               spi-max-frequency = <50000000>;
> +               spi-max-frequency = <100000000>;
>   #include "openbmc-flash-layout-64.dtsi"
>          };
> 
> @@ -170,6 +170,7 @@ flash at 1 {
>                  status = "okay";
>                  m25p,fast-read;
>                  label = "alt-bmc";
> +               spi-max-frequency = <100000000>;
>          };
>   };
> 
> 
> 
> # dmesg |grep spi
> [    0.746939] spi-nor spi0.0: w25q512jv (65536 Kbytes)
> [    0.904547] spi-aspeed-smc 1e620000.spi: CE0 read buswidth:2 [0x203c0741]
> [    0.959048] spi-nor spi0.1: w25q512jv (65536 Kbytes)
> [    1.116603] spi-aspeed-smc 1e620000.spi: CE1 read buswidth:2 [0x203c0741]
> [    1.130483] spi-nor spi1.0: w25q256 (32768 Kbytes)
> [    1.255015] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
> [    1.269188] spi-nor spi2.0: gd25q256 (32768 Kbytes)
> [    1.366623] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
> 
> # fdtget /sys/firmware/fdt /ahb/spi at 1e620000/flash at 0 spi-max-frequency
> 100000000
> # fdtget /sys/firmware/fdt /ahb/spi at 1e620000/flash at 0 spi-max-frequency
> 100000000
> 
> l# ./mtd-stress.sh mtd5 mtd6
> 22+0 records in
> 22+0 records out
> 23068672 bytes (23 MB, 22 MiB) copied, 2.39988 s, 9.6 MB/s
> 28deb0d7b7ac61a3a748661d17caad9b  /tmp/tmp.F0iA2sCa75
> Erasing blocks: 352/352 (100%)
> Writing data: 22528k/22528k (100%)
> Verifying data: 22528k/22528k (100%)
> 
> real    2m51.548s
> user    0m0.010s
> sys     2m46.316s
> 28deb0d7b7ac61a3a748661d17caad9b  /dev/mtd5
> 
> real    0m2.473s
> user    0m0.158s
> sys     0m2.286s
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB, 64 MiB) copied, 5.34609 s, 12.6 MB/s
> 33e2d1b6b58feaf69ae03bce376cbad3  /tmp/tmp.bCJiVeGiSh
> Erasing blocks: 1024/1024 (100%)
> Writing data: 65536k/65536k (100%)
> Verifying data: 65536k/65536k (100%)
> 
> real    7m50.545s
> user    0m0.200s
> sys     7m35.033s
> 33e2d1b6b58feaf69ae03bce376cbad3  /dev/mtd6
> 
> real    0m7.187s
> user    0m0.485s
> sys     0m6.635s
> 
> 
> Do we expect it to take the same amount of time?

There is a nice boost on the reads. Write are the same but that's expected.

> 
>>
>>> [    0.937639] spi-nor spi1.0: w25q256 (32768 Kbytes)
>>> [    1.062246] spi-aspeed-smc 1e630000.spi: CE0 read buswidth:2 [0x203c0741]
>>> [    1.076507] spi-nor spi2.0: gd25q256 (32768 Kbytes)
>>> [    1.173951] spi-aspeed-smc 1e631000.spi: CE0 read buswidth:2 [0x203c0741]
>>>
>>> ./mtd-stress.sh mtd5 mtd6 mtd7 mtd8
>>
>> A good test would be to read from /dev/mtd0 and reflash the resulting file.
>> Keep an external programmer close at hand just in case :)
> 
> I did this, while crossing my legs, arms, fingers and toes.
> 
> root at apolo:~# ./mtd-stress.sh mtd0
> 64+0 records in
> 64+0 records out
> 67108864 bytes (67 MB, 64 MiB) copied, 5.15611 s, 13.0 MB/s
> 8a439fdfec504f3e8574c4260d0389ee  /tmp/tmp.kbTNY4G8Qd
> Erasing blocks: 1024/1024 (100%)
> Writing data: 65536k/65536k (100%)
> Verifying data: 5590k/65536k (8%)File does not seem to match flash
> data. First mismatch at 0x00573000-0x00575800

ouch. we should keep the 50MHz value then.

> real    7m56.061s
> user    0m0.050s
> sys     7m54.697s
> 343335c0dc778b95afc83a95307921a7  /dev/mtd0
> 
> real    0m7.191s
> user    0m0.482s
> sys     0m6.597s
> 
> Oh no! A failure!
> 
> I ran it again and it succeeded. Both tests were with random data. I
> wrote to it a third time, this time restoring the original file, and
> it succeeded.

and did you reboot ? :)

Cheers,

C.