[yocto] Cannot use any TEST_TARGET besides simpleremote or qemu

[Paulo Neves]

Hello Paul,

I find this functionality very useful for test benches of embedded
systems. Now that you said it was broken i started pruning code and
have 3 ways we can and save the current functionality:
1 In the testimage.bbclass, pass the td variable to
OERuntimeTestContextExecutor.getTarget(). Also greatly simplifying
argument passing.
2 In the testimage.bbclass add the td variable to the kwargs so that
controllers can access the datastore at __init__ time.
3 Have the user set a variable with a list of variables (!) that
should available in kwargs.

I will give it a try by simply passing td. This way we give all the
information that controllers might need to work. As td is retrieved by
the json file generated at the image creation time the external test
(bitbakeless) functionality should be unaffected.

Let me know if you have different opinions.

Paulo Neves

On Thu, Aug 2, 2018 at 10:35 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> Hi Paulo,
>
> On Thursday, 2 August 2018 12:11:37 AM BST Paulo Neves wrote:
>> I am trying to create my own test controller. After copy pasting and
>> adapting the skeleton from BeagleBoneTarget to
>> $MYLAYER/lib/oeqa/controllers I set the appropriate TEST_TARGET.
>>
>> When I run the testimage task I always have errors like in [1]. The
>> actual keyword that is unexpected changes from invocation to
>> invocation. There was a similar error previously reported in this
>> mailing list but the presented solution was to actually stop using the
>> TEST_TARGET variable, which is not applicable.
>>
>> I have tried setting TEST_TARGET to any of the proposed options in the
>> manual [2] and the same unhelping error shows. I know that some of
>> that these controller targets, are not appropriate for my target
>> (odroid [cortex-arm15]), but the errors seems to not be related to any
>> functionality or these boards.
>>
>> I have analyzed and cannot really understand also how all the example
>> targets classes have a constructor which takes the d variable, while
>> the context.py call has some more variables including a dictionary,
>> kwargs, which does not actually have the d variable.
>
> I discovered this as well:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=12842
>
> This code got broken during the refactoring a while ago, and I think the
> person doing the work considered it to be legacy functionality and was going
> to remove it. Personally I'd like to see it stay and get fixed up, but the
> issue is having the time to fix it and maintain it - if you do by any chance
> then that would be great.
>
> At the moment I believe "simpleremote" does still work, it's just the actual
> classes that are broken, but I didn't give it extensive testing.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
>