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>
Wiktor MowinskiandFilip Gołaś
Michał IwanickiandDanil Klimuk