Hello,
Is there a way to run newly written tests (on the fly) without closing and rerunning the FVP executable with the new binary each time?
Thank you
Dear all,
This is a test email. Please ignore it and sorry for the inconvenience.
Kind regards,
John
--
<https://www.arm.com/>
John Tsichritzis | Graduate Software Engineer
Email : john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com>
110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom
Hello Alamy,
> There is a Makefile dependency problem regarding the "tests_list.h" as it mentioned in
> https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/docs/change-log.rst
>
> I have a fix to that (in one way) but not perfect:
> https://github.com/AlamyLiu/tf-a-tests/commit/33929aca35c7ad65e9acde7126059…
Thanks for your patch! I see that you've pushed it to Github, could you
please post it to the official Gerrit review server instead? We conduct
code reviews on https://review.trustedfirmware.org/ The contribution
guidelines are highlighted in the following document:
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/contributing.rst
> I think the root cause is that
>
> * It uses `eval` in Makefile to `do` the job that should be done by `make`.
> * Makefile should have only the `rules` (none), not the action (verb - eval) for compiling.
>
> Using `eval` to compile the code hide the information to `make`.
> Let `make` know the rules & dependency so the problem could be solved cleanly.
I agree with you. The build system would need to be re-designed for
better clarity and ease of maintenance.
The build system of TF-A Tests is inherited from TF-A, which
unfortunately had these issues already. We are planning to rework the
TF-A build system in the future (see
https://lists.trustedfirmware.org/pipermail/tf-a/2018-December/000000.html).
When that work is complete, I'm hoping we'll be able to import it in
TF-A Tests as well.
Regards,
Sandrine
Hi developers,
There is a Makefile dependency problem regarding the "tests_list.h" as it mentioned in
https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/docs/change-log.rst
I have a fix to that (in one way) but not perfect:
https://github.com/AlamyLiu/tf-a-tests/commit/33929aca35c7ad65e9acde7126059…
I think the root cause is that
* It uses `eval` in Makefile to `do` the job that should be done by `make`.
* Makefile should have only the `rules` (none), not the action (verb - eval) for compiling.
Using `eval` to compile the code hide the information to `make`.
Let `make` know the rules & dependency so the problem could be solved cleanly.
P.S.:
The workaround is `make -j1`. Which has self-described the dependency problem.
Regards,
Alamy
Hi,
I'm currently investigating ways to improve the output of the TF-A
Tests. This email serves as a proposal. Feedback is welcome.
Attached are 2 text files:
- old-output.txt
Shows an extract of how the UART output looks like today.
- new-output.txt
Shows an extract of how I propose we present this information in the future.
With this, I hope to improve:
1) Conciseness.
- Duplicated test results are removed.
Tests results are reported as we go along, like they are today but in a
more concise way. The final summary no longer repeats individual tests
results but instead indicates the success or failure of the entire test
suite. (A test suite is marked as passed if all of its tests have either
passed or have been skipped.) as well as the total number of
skipped/passed/... tests (see at line 57).
- The unnecessary CPU ID headers are removed.
Most of the lines no longer indicate which CPU printed them. This will
always be the primary CPU so this information seems useless.
Messages printed by tests continue to print the CPU ID as before.
However, instead of printing the CPU MPIDR (e.g. [CPU 0x0001]), the CPU
linear index (as returned by the platform_get_core_pos() function) is
displayed. It is shorter, while providing the same information.
Messages printed by tests are prefixed by T: (see an example at line 28)
to make them stand out among the other framework messages.
2) More human-friendly.
3) Reasonably script-friendly.
E.g.: The final string at line 77 is only there for our Continuous
Integration tools to identify the end of the test session.
Regards,
Sandrine Bailleux
