Revert "atf-juno: update, enable OPTEE"

[mrchapp]

This reverts commit 51254c64135deb3009a5e152cac4460d2a835f21.

Juno has not been booting for a long time now [1]. Recent OE RPB jobs fail to boot [2], and even the original job [3] that proved that it worked, when resubmitted, does not work [4].

Reverting this commit gets Juno back on track.

[1] https://validation.linaro.org/results/query/+custom?entity=testjob&conditions=testjob__description__icontains__RPB%20OE%20boot%20juno%20rocko [2] https://validation.linaro.org/scheduler/job/1881609 [3] https://validation.linaro.org/scheduler/job/1654389 [4] https://validation.linaro.org/scheduler/job/1883480

Signed-off-by: Daniel Díaz daniel.diaz@linaro.org

[fboudra]

@koenkooi I believe you had Juno booted in LAVA to validate your changes and confirm that OP-TEE is enabled, right? Can you have a look?

[koenkooi]

Yes, https://validation.linaro.org/scheduler/job/1654389 had optee working

[danrue]

Since it is broken in tree, can it be reverted now and then re-introduced once fixed so that other juno users aren't blocked?

[fboudra]

@danrue the commit is 7 months old. if it was a recent commit, I would have considered it a regression and reverting is an option. IMO, we should rather spend some time to fix it and let the engineering look at the issue for the next 24h before reassess.

[vchong]

Not sure if I should 'barge in uninvited', especially since I don't even have a Juno device and limited knowledge of the recipes and yaml files, but just my humble 2 cents. This doesn't look like an op-tee issue at all. It seems like reverting the patch just brings the atf repo back an older revision (SRCREV from e83769c07bb09b7727a36389c9dd92096860637e to b762fc7481c66b64eb98b6ff694d569e66253973) that (I suspect) doesn't manifest whatever issue it is that you're having. Also, looking at the working job [3] vs the failed ones [2][4], the failed ones have a bootloader-interrupt timed out after 30 seconds, so maybe increasing bootloader-interrupt: {seconds: 30} in the yaml can be easy/quick to try? Maybe images from the newer atf SRCREV take longer to flash?

[vchong]

I'm going to hazard a guess here since some info I found appear to look like good coincidences.

[2] shows Feb 8 jobs as complete while Feb 12 as incomplete. https://firmwaresecurity.com/2018/02/09/lava-2018-2-released, dated Feb 9, says that u-boot-interrupt is now bootloader-interrupt, so perhaps https://git.linaro.org/ci/job/configs.git/tree/rpb-openembedded/lava-job-definitions/juno/template-boot.yaml#n10 should also be changed from u-boot-interrupt to bootloader-interrupt so that it's 120 seconds instead of what appears to be a default of 30 seconds if not explicitly specified?

[vchong]

Indeed when I resubmitted [4] by adding

   actions:
    bootloader-interrupt:
      seconds: 120 

to timeouts in the job definition, the job completed. xtest even passed all the tests.

https://validation.linaro.org/scheduler/job/1883628

[fboudra]

@vchong Thanks Victor for your feedback, you're always welcome to jump in :+1:

[mrchapp]

Thanks, Victor! Great catch!

It did improve on getting the builds booting. See how Morty 149 was failing: https://validation.linaro.org/scheduler/job/1882954 and how it now boots with the change in: https://validation.linaro.org/scheduler/job/1883666

This, however, did not help Rocko builds. Build 15 unchanged: https://validation.linaro.org/scheduler/job/1881609 and changed: https://validation.linaro.org/scheduler/job/1883670

Both Rocko builds still fail.

[vchong]

You're welcome! So increasing the time out to 240s didn't help [1]. Job timed out at 168s. Compared with the Morty 149 one [2], atf in [1] isn't even booting up, so it looks like a different issue, but still doesn't seem related to op-tee.

Changing recovery_image in the job definition from http://snapshots.linaro.org/reference-platform/embedded/rocko/juno/15/rpb/juno-oe-uboot.zip to http://snapshots.linaro.org/reference-platform/embedded/rocko/juno/14/rpb/juno-oe-uboot.zip didn't help either [3]. The old one (https://dominion.thruhere.net/koen/files/juno/juno-oe-uboot.zip) works [4]. http://releases.linaro.org/members/arm/platforms/18.04/juno-latest-oe-uboot.zip also works [5]. Something in the the way the components in juno-oe-uboot.zip are built has changed?

[1] https://validation.linaro.org/scheduler/job/1883712 [2] https://validation.linaro.org/scheduler/job/1883666 [3] https://validation.linaro.org/scheduler/job/1883718 [4] https://validation.linaro.org/scheduler/job/1883714 [5] https://validation.linaro.org/scheduler/job/1883715

[vchong]

It seems like builds 14 and 15 are using http://releases.linaro.org/members/arm/platforms/17.04/juno-latest-oe-uboot.zip. Made the wrong assumption that they'd be using newer ones since they're the latest snapshot builds.

The 'old' recovery image (https://dominion.thruhere.net/koen/files/juno/juno-oe-uboot.zip) actually appears to be using a newer release (http://releases.linaro.org/members/arm/platforms/17.10/juno-latest-oe-uboot.zip). http://releases.linaro.org/members/arm/platforms/18.04/juno-latest-oe-uboot.zip is obviously working as well as noted above.

So it looks like https://github.com/96boards/meta-96boards/blob/master/recipes-bsp/atf/atf-juno_git.bb#L10 and https://git.linaro.org/ci/job/configs.git/tree/optee/build/publishers.sh#n14 should be updated to 17.10 or later.

On a different note, optee/build seems like a bit out of place for publishers.sh since it doesn't seem to be doing anything op-tee related.

[mrchapp]

Thanks for following up with this, Victor! This is great info!

I can confirm that a newer juno-latest-oe-uboot.zip helps in getting to launch the kernel. This LKFT job did not work: https://lkft.validation.linaro.org/scheduler/job/293546 but this one, with the 18.04 version, does: https://lkft.validation.linaro.org/scheduler/job/295673

[mrchapp]

Submitted https://github.com/96boards/meta-96boards/pull/253 to upgrade juno-latest-oe-uboot.zip to 18.04.