[RFC PATCH 22/31] test: lmb: run the LMB tests only on sandbox

Tom Rini trini at konsulko.com
Tue Jun 11 16:05:06 CEST 2024


On Tue, Jun 11, 2024 at 02:25:05PM +0530, Sughosh Ganu wrote:
> On Mon, 10 Jun 2024 at 23:14, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sat, Jun 08, 2024 at 12:22:31AM +0530, Sughosh Ganu wrote:
> >
> > > The LMB memory map is now persistent and global. Running the tests for
> > > the LMB module will result in the memory map getting reset, and this
> > > will have side-effects on the rest of the working of the platform. Run
> > > the LMB tests only on the sandbox platform, which is meant for running
> > > such kinds of tests.
> > >
> > > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org>
> >
> > I'm not sure about this. We can reset real hardware as often as we need,
> > too. Did you run in to problems with this test on non-sandbox?
> 
> But do we want to reset the state of the LMB memory map on real
> hardware? This was working up until now because of the local nature of
> the LMB variables. But if the LMB memory map is to be persistent,
> should we allow it to be changed for running some test? That would
> have side effects? I think running these tests on sandbox should
> suffice. I mean there isn't any aspect of the LMB module that is not
> getting tested on sandbox, right?

When running our test/ test code on hardware side effects are fine, this
isn't a POST type test that gets used in production. Do changes, reset
platform as needed just like sandbox, etc. And yes, a user running tests
that have side effects manually and then not dealing with them is user
error.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240611/a4d05ce9/attachment.sig>


More information about the U-Boot mailing list