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

[Ilias Apalodimas]

On Tue, 11 Jun 2024 at 17:05, Tom Rini <trini at konsulko.com> wrote:
>
> 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.
>

So the lmb changes are scary to begin with. I think the tests
shouldn't be limited to sandbox.
Can't we plan c tests in test/dm etc that call functions and test?
IOW we could allocate EFI memory and try to overwrite it with LMB,
vice versa etc, without having to deal with the predefined areas.

Regards
/Ilias
> --
> Tom