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.
--
Tom
signature.asc
Description: PGP signature
