Automate the creation and execution of the UX capsule

[BeataZdunczyk]

Brief summary

Use UX capsule to convey message to the user that the update is in progress. Because update takes significantly more time than normal boot, impatient user may think that the boot process is stuck and try to force a platform reboot, which in turn may end up with non-working platform.

[krystian-hebel]

Some initial notes:

• UX capsule holds the number of GOP mode, hence it should be created on platform that is updated. In case of desktops (like MSI) it may also mean that the same GPU and monitor must be used to get the same mode numbering.
• If the resolution of mode saved in UX capsule doesn't match the bitmap resolution:
  • Bitmap larger than video - error, UX not shown but other capsule(s) are applied.
  • Bitmap smaller than video - bitmap is aligned to top left corner, boot logo in the background is not cleared.
  • FMP capsules may have drivers that in theory could craft the bitmap with proper size. Those drivers are started after UX capsules, at that point it would be easier to access GOP directly.
• Color of progress bar is specified by PCD, its position depends on size and offset of boot logo (20% of logo height below the lowest non-black pixel of logo).
  • These calculations are done on the first invocation of DisplayUpdateProgress(), so it may be possible to overwrite the logo in driver included in the capsule, unless another FMP capsule is processed earlier.

[JanPrusinowski]

I'm not sure of how exactly this function might work? Is it only testing for boot logo?

@krystian Hebel how an example test might look like? Is the logo supposed to be changed during the capsule update - and only then? Or is it supposed to change? Or reset to the default one? How to create/add such logo to the capsule?

UX capsule holds the number of GOP mode, hence it should be created on platform that is updated. In case of desktops (like MSI) it may also mean that the same GPU and monitor must be used to get the same mode numbering.

Does this mean that the capsules are to be created on the DUT now? This will complicate things - downloading coreboot setting, correct branch, editing settings of version etc. Cant those settings be somehow extracted from DUTand applied in creating a capsule locally (since we already have a script for preparing local capsules) and if so how it can be done?

These calculations are done on the first invocation of DisplayUpdateProgress(), so it may be possible to overwrite the logo in driver included in the capsule, unless another FMP capsule is processed earlier.

Is there a way to queue 2 or more capsule updates and then reboot? Or how to interpret this?

[krystian-hebel]

@JanPrusinowski you don't have to worry about those notes, they apply to the implementation of the capsule driver and including it in capsule. Those steps are not needed for testing. Preparation of capsule for testing will look identical to previous tests, except there will be 2 embedded drivers in all capsules, after the implementation is merged.

Tests must check that the update screen looks like this:

Previously the length of the progress bar was equal to the width of the logo (rounded up to 100px), now it should be consistent regardless of how small the logo was.

[JanPrusinowski]

Will this be run only on MSI or on all platforms? Is this screen displayed over serial (or a similar one - I guess some sort of text based display)? I'm wondering if it could be done by some sort of screen compare tool in Robot Framework.
Should there be created a negative path tests too? With for example too big logo?
Or is it just supposed to be one case with small logo? If so then it can be observed while running capsule update suite... Or should it be completly seprate test?

[krystian-hebel]

It will be run on all platforms with graphic output. It isn't displayed on the serial, neither is the progress (at least not for release builds).

Should there be created a negative path tests too? With for example too big logo? Or is it just supposed to be one case with small logo?

Too big logo would be a valid test for logo customization functionality rather than capsule updates. I think it should work fine for capsules, but some other parts of firmware may break because of that.

it can be observed while running capsule update suite... Or should it be completly seprate test?

This would be fine, as long as it is actually checked. I don't know if this can be somehow enforced by RF, e.g. by waiting for user confirmation before performing the update, and then getting the manual input.

[krystian-hebel]

This would be fine, as long as it is actually checked. I don't know if this can be somehow enforced by RF, e.g. by waiting for user confirmation before performing the update, and then getting the manual input.

https://robotframework.org/robotframework/latest/libraries/Dialogs.html this seems to provide what's needed.

[krystian-hebel]

This was implemented in coreboot and edk2. PR with test cases was also implemented and merged. The test is semi-automatic, it requires manual look at the update screen to confirm if the progress bar is displayed as it should be. A log from passing execution: log.zip

Without these changes, the location and size of progress bar would depend on the size and position of logo, for example:

Apart from different size, it would be possible to make the progress bar appear outside of screen with big enough logo. As the logo is configurable by users, we decided to display a simple text information in its place to avoid this problem, and to put user's mind at ease.

This is how the update screen now looks like:

It also scales relative to the screen size, contrary to the logo which always had the same dimensions in pixels.