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.
