Assuming that the testing firmware will
alwyays trust production keys, and
that testing firmware will always be
available, contrary to signed
production firmware.
With that, the TEST_KEYS variants handling
can be removed.
We can use for the tests:
CUP002: test base, any capsule
- we cant test if base is a test variant,
but test should always be available, so
it should be always used as base
CUP150: any base, test capsule
- we can check if capsule is test/prod
CUP151: any base, prod capsule
- same as CUP150
CUP001 and every other test: any base, any capsule
So we can assume that for V2 capsules
only a test variant will be used for base.
When that will be possible we can add a check
for whether RC0 is test or prod
and conditionally skip CUP002
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
If the Skip condition for CUP002 is not triggered, then
- option a) `CAPSULE_FW_FILE` contains test keys, so `CAPSULE_UPDATE_RC0_FW_FILE` must best test too, so BASE_FW_FILE is a testing firmware
- option b) Test RC0 and capsule were provided, and the `BASE_FW_FILE` is set to a testing firmware.
Either way the testing firmware is already flashed.
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Sometimes the logs file is read as empty.
After such issue happened ive checked manually
and it was not empty at all.
It must be some kind of a synchronization issue
which should be fixed by a quick remount of the
/boot FS.
Additionally the BOM bytes from UTF-8 encoding seem to break the Telnet
library and the file contents are interpreted as empty despite the
library reading the contents. Removing them using SED should help with
that.
recv b'\xbb\xbfCapsuleMax -
CapsuleFFFF\r\r\n\x1b[?2004hroot@3mdeb:/home/ubuntu#
but ${output} = ""
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
As of the time of writing the tests, the test base firmware
only accepts testing keys. If it will also accept
the production keys in the future, this flash step
could be removed and there won't be a need to create
a production RC0.
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Instead of setting the option in setup menu and repeating the
process after every flash, modify the base binary
and reuse it in the suite later.
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
This way the tests won't break in a criptic way when Flashing the
firmware or capsule update fails to restore the bootorder.
This does not cause additional power cycle as before and after
the capsule updates the tests enter an OS.
Signed-off-by: Filip Gołaś <filip.golas@3mdeb.com>
Wiktor MowinskiandFilip Gołaś