Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Trustedfirmware.org Project Migration Information Update #681
As mentioned in my original Trustedfirmware.org Project Migration Information post (#655) I promised updates concerning the migration to hosting this project on https://www.trustedfirmware.org. We are planning and working towards a phased approach to the migration:
1st Phase: Migrate Repository, Patch Review, Wiki, Issues
2nd Phase: Migrate Continuous Integration (CI) Build Capability
3rd Phase: Migrate CI Fixed Virtual Platforms (FVP) Test Capability
4th Phase: Migrate CI Hardware Test Capability
Any questions please let us at Arm know and we will try to clarify.
Hi @DamianVesk ,
I am unsure what you mean by having "an early preview" of these tests. Are you asking whether some of the end-to-end boot tests results will be visible before the end of the 3rd phase? At this stage, I'm afraid I don't have enough visibility to give a definitive answer.
I can certainly describe what these end-to-end boot tests consist in today, though, if that's what you are interested in.
The scripts that drive these boot tests first download various binary dependencies to assemble a complete software stack. Typically U-boot, a Linux kernel image, a RAMdisk or an OpenEmbedded root filesystem. All of these are coming from the Linaro release advertised in the TF-A User Guide.
Then we deploy this software stack on the target. When testing on a Fixed Virtual Platform (FVP), this is just a matter of pointing it to the location of the images on the host machine. For testing on real hardware (i.e. the Arm Juno development platform in our case) we rely on LAVA to abstract the flashing of the images and other details of interfacing with the board.
Then we start booting this software stack. Different pieces of software print messages on different UARTs. We monitor their output using some expect scripts. We look for specific string patterns like BL1: Booting BL2 or Linux version x.y to track the progress, until we see the Linux shell prompt.
If the expect scripts see all the strings we were expecting then the boot test is a pass. Otherwise, if some specific string never arrives, the scripts time out and the boot test is a fail.
Yes, that was the intention of my question exactly. Thank you for the detailed answer, it's a very good description of what to expect from the tests in the future. I'll keep an eye for updates, if there's a mailing list I can subscribe for the development of this feature please let me know.
P.S. Great work on the TFTF test suite development! The tests are very insightful when it comes to dealing with the TF-A on the base FVP.
Hi @DamianVesk ,
You're welcome. By the way, do note that we already do this level of testing today. It's just that the details and tests results are unfortunately not visible externally. I thought I would clarify, because you mentioned "expect from the tests in the future". The 3rd phase of this migration work is about moving this existing test infrastructure from Arm internal servers to trustedfirmware.org public ones, which in turn will give visibility to everyone.
There is no mailing list dedicated to the trustedfirmware.org migration work but we do have TF-A and TF-A Tests mailing lists, see https://www.trustedfirmware.org/contact/.
I am very glad to know that is useful to you. The TF-A Tests project has already migrated to trustedfirmware.org so if you want to contribute, feel free to submit patches to review.trustedfirmware.org already. The contribution guidelines are outlined here.
This was referenced
Apr 5, 2019
A 2nd update on the 1st Phase: Migrate Repository, Patch Review, Wiki, Issues migration.