On Thu, Feb 06, 2025 at 08:31:02AM -0600, Tom Rini wrote: > On Thu, Feb 06, 2025 at 06:14:09PM +0530, Love Kumar wrote: > > 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. > > OK, please send a patch enabling it in u-boot-test-hooks. > > > > > 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? > > I was unclear, sorry. In the case of sifive_unleashed-spi-nor_qemu, > which is in CI and u-boot-test-hooks, if I enable the test here then the > test will overwrite U-Boot in the (simulated) SPI flash. Can the test be > configured to know it only has a certain region of space available to > use? > > > > > > > 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? > > Again, sorry for being unclear. I don't know where exactly the problem > is, but I see this same problem on multiple flash chips. The above is > easy to replicate in that it's in QEMU. The same problem also happens on > my TI K3 platforms with s28hs512t for example.
Have you had a chance to look in to this more? Thanks! -- Tom
signature.asc
Description: PGP signature
