Hi Andy, On Mon, 8 Feb 2021 at 04:34, Andy Shevchenko <andriy.shevche...@linux.intel.com> wrote: > > On Sun, Feb 07, 2021 at 07:37:55AM -0700, Simon Glass wrote: > > On Fri, 5 Feb 2021 at 13:46, Andy Shevchenko > > <andriy.shevche...@linux.intel.com> wrote: > > > On Fri, Feb 05, 2021 at 09:17:27PM +0200, Andy Shevchenko wrote: > > > > On Fri, Feb 05, 2021 at 08:15:25PM +0200, Andy Shevchenko wrote: > > > > > On Fri, Feb 05, 2021 at 07:34:49PM +0200, Andy Shevchenko wrote: > > > > > > On Thu, Feb 04, 2021 at 08:17:24PM -0700, Simon Glass wrote: > > > > > > > > > > ... > > > > > > > > > > > Btw, you have an issue there, i.e. if test case failed, all > > > > > > percentage after it > > > > > > goes red, which is wrong. > > > > > > > > > > One more thing, is it known bug that either in the original code, or > > > > > in your > > > > > new branch the following test case is 100% failed? > > > > > > > > > > /* Non-existent in DTB */ > > > > > ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr(dev)); > > > > > > > > > > Can you fix this sooner than later, please? > > > > > > > > Actually it seems this very patch makes the issue visible (I suppose > > > > something > > > > with test case names). > > > > > > Okay, actually there *is* a problem with the test suite, i.e. you may not > > > run > > > some test cases twice during the same session. > > > > If this is related to the squashfs tests? I have disabled them for now > > in my local tree. > > I don't think it's related to the certain test case, it's a test suite design > issue and how some of the test cases have been written. So, if you run u-boot > application and manually run `ut dm` in there, > - first time: Failures: 0 > - second time: Failures: 9 > - third and next time: Failures: 12 > > Means that 12 test cases are written badly.
OK I see. It did not use to be possible to pass all tests without running through pytest, which does some setup. You still need to create a 'spi.bin' file for the SPI tests to pass. I'm not sure what prevents multiple runs without quitting U-Boot, but I suspect it is just some state hanging around, as we don't reset everything. For example, sandbox provides control of what happens when a sysreset is performed, and perhaps that is not reset to initial values correct by state_reset_for_test().. Regards, Simon
