tree: 30eebaf3cfea2f79c0352b605a7b803c11181d1f [path history] [tgz]
  1. busybox.inc
  2. cactus.exp
  3. crash_panic.exp
  4. crash_roxlattables_unhandled_exception_at_el3.exp
  5. crash_test.exp
  6. disable_dyn_auth.inc
  7. disable_dyn_auth_tftf.exp
  8. el3-test-payload.exp
  9. hold_uart.exp
  10. ivy.exp
  11. linux-bl33.exp
  12. linux-oe-rst-bl31.exp
  13. linux-oe.exp
  14. linux-rd-busybox-aarch32.exp
  15. linux-rd-busybox.exp
  16. linux-tpm.exp
  17. linux.inc
  18. openembedded.inc
  19. README.md
  20. readonly_el1_xlat_tables.exp
  21. spm-edk2-uart0.exp
  22. spm-edk2-uart2.exp
  23. spm-linux-uart0.exp
  24. spm-optee-sp-uart1.exp
  25. spm-uart2.exp
  26. tftf-aarch32.exp
  27. tftf.exp
  28. tftf_fault.exp
  29. timeout.exp
  30. timeout_spmin_roxlattables.exp
  31. timeout_test.exp
  32. tpm-logs.exp
  33. trusted-firmware-aarch32.inc
  34. trusted-firmware-load-error.exp
  35. trusted-firmware-rst-to-bl31.inc
  36. trusted-firmware.inc
  37. tsp.exp
  38. uart-hold.inc
  39. ubsan-test-trap.exp
lava-expect/README.md

Expect Scripts

The project tracks two set of expect scripts under two different folders, expect and lava-expect, the former required for local (non-LAVA) or Internal CI (Arm CI) and the latter for Open CI (LAVA). Note that any contribution into the expect scripts must be done in both folders, otherwise expect test coverage will differ.

LAVA Expect Scripts

The lava-expect script does exactly the same as its counterpart under the expect folder. However, LAVA uses Test Interactive Actions where it expects success or failure strings. The CI would take these lava-expect scripts and converted into LAVA Test Interactive Actions, so the only task on these files is to define either successes or failures strings and probably the order of appearance.

To better understand how expect scripts translates into lava-expect, we can compare similar scripts, i.e. expect/cactus.exp vesus lava-expect/cactus.exp. Let's compare these two:

  • expect/cactus.exp
.
.
source [file join [file dirname [info script]] handle-arguments.inc]

expect_string "Booting test Secure Partition Cactus"

source [file join [file dirname [info script]] uart-hold.inc]
  • and its counterpart lava-expect/cactus.exp (note, the same filename but different folder)
.
.
expect_string+=("Booting test Secure Partition Cactus")

source $ci_root/lava-expect/uart-hold.inc

As seen, the same expect string appears in both, but in case of lava-expect/cactus.exp, which is written in bash, the variable to be used is expect_string and its expect string must be appended (+=) as an array element. Appending is important, otherwise previous expect strings would be replaced by the assigment (=).

In case we want to indicate the order of expected scripts and the pass/fail criteria, the expect string syntax is a bit more complex but with a few examples, it can be quickly understood.

For example, in an hypothetical scenario, we want to first match A, then after A, match B or C for success and match D or E for failures. This would be the lava-expect definition script (to be located under lava-expect folder)

prompt='A'
successes='B@C'
failures='D@E'
expect_string+=("${prompt};${successes};${failures}")

As you can see, prompt defines the first match, in this case A, then successes defines possible success strings, in this case B and C, separated by @ sign, and the same pattern applies for failure strings, but in this case, matching these would tell LAVA to fail the job.

For a real examples, compare similar scripts (the same filename) in both expect folders.