Enabling test/py/tests/test_spi.py more?

[Love Kumar]

Hi Tom,

On 01/02/25 4:28 am, Tom Rini wrote:
> On Fri, Jan 31, 2025 at 02:00:07PM -0600, Tom Rini wrote:
>> Hey,
>>
>> Can you please confirm that this test currently functions on your
>> platforms? And then can we please enable it in
>> https://source.denx.de/u-boot/u-boot-test-hooks as both a functional
>> example, and testing of the SPI framework?
>>
Yes, this test works fine on our boards and it can be enabled it in 
u-boot-test-hooks as well.

>> I'm asking in part because I've attempted to enable it on two TI K3
>> platforms (am62x_evm_a53 and am64x_evm_a53) and the write twice test
>> fails there and while I can repeat the failure on the command line, I
>> can't make the same concept fail at the CLI (including 0xff'ing out
>> memory before reading back to the same location). I've also tried
>> enabling it for sifive_unleashed via QEMU but that in turn seems to fail
>> differently, and possibly because we're destroying all of the SPI
>> contents and need to expand the test to include a region to ignore? I'm
>> not entirely sure, I'm still debugging that one.

You mean to say some regions in SPI are protected and test should ignore it?

> 
> As an easy'ish for-example, if you rename
> py/travis-ci/u_boot_boardenv_evb-ast2500_qemu.py to
> py/travis-ci/u_boot_boardenv_evb_ast2500_qemu.py and add:
> 
> env__spi_device_test = {
>      'bus': 0,
>      'chip_select': 0,
>      'mode': 0,
>      'part_name': 'mx25l25635e',
>      'timeout': 10000,
>      'iteration': 5,
> }
> 
> So that the test will run, it fails with:
> AssertionError: assert 'f753d4e0' in 'crc32 for 822000c8 ... 83212327 ==> bf3e333c'
> ------------------------------------ Captured stdout call -------------------------------------
> => sf probe 0:0 0 0
> SF: Detected mx25l25635e with page size 256 Bytes, erase size 64 KiB, total 32 MiB
> => => crc32 0x82200000 0x10
> crc32 for 82200000 ... 8220000f ==> ecbb4b55
> => => sf erase 0x0 0x10000
> SF: 65536 bytes @ 0x0 Erased: OK
> => => sf write 0x82200000 0x0 0x10
> device 0 offset 0x0, size 0x10
> SF: 16 bytes @ 0x0 Written: OK
> => => sf read 0x82200054 0x0 0x10
> device 0 offset 0x0, size 0x10
> SF: 16 bytes @ 0x0 Read: OK
> => => crc32 0x82200054 0x10
> crc32 for 82200054 ... 82200063 ==> ecbb4b55
> => => crc32 0x82200000 0x1012260
> crc32 for 82200000 ... 8321225f ==> f753d4e0
> => => sf erase 0x0 0x1020000
> SF: 16908288 bytes @ 0x0 Erased: OK
> => => sf write 0x82200000 0x0 0x1012260
> device 0 offset 0x0, size 0x1012260
> SF: 16851552 bytes @ 0x0 Written: OK
> => => sf read 0x822000c8 0x0 0x1012260
> device 0 offset 0x0, size 0x1012260
> SF: 16851552 bytes @ 0x0 Read: OK
> => => crc32 0x822000c8 0x1012260
> crc32 for 822000c8 ... 83212327 ==> bf3e333c
> =>

I haven't tried with mx25l25635e part but on other macronix part 
(mx66u1g45g) - it was working on ZynqMP. Need to figure out if it is a 
flash specific issue or any thing else?

Regards,
Love Kumar

> 
> And that is also how the TI K3 platforms fail. However, evb-ast2600 is
> fine, with:
> env__spi_device_test = {
>      'bus': 0,
>      'chip_select': 0,
>      'mode': 0,
>      'part_name': 'mx25u51245g',
>      'timeout': 10000,
>      'iteration': 5,
> }
> 
> And note that evb-ast2600 is a 64MB flash while evb-ast2500 is a 32MB
> flash.
>