-
Notifications
You must be signed in to change notification settings - Fork 792
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[manuf] refactor FT flows to enable downstream OTP definitions
This refactors the FT provisioning Bazel build binary and test targets to enable defining downstream OTP configurations and ingesting them into FT provisioning flows. Additionally, this removes the reliance on build configurations to select which personalization extension to use, and simply builds and tests all FT provisioning flows that can be enumerated at build time. This makes it easier to run and test all flows upstream only, with: `bazel test //sw/device/silicon_creator/manuf/base:ft_provision_cw310`, or all flows upstream and downstream with: `PROV_EXTS_DIR=... bazel test //sw/device/silicon_creator/manuf/base:ft_provision_cw310`. As a result, this also simplifies the build graph by removing configuration transistions. Signed-off-by: Tim Trippel <[email protected]> (cherry picked from commit 87e0070)
- Loading branch information
1 parent
4cdfb5d
commit de283f7
Showing
11 changed files
with
161 additions
and
191 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,35 +1,55 @@ | ||
# Provisioning Flow Extensions | ||
|
||
Various components of the reference provisioning flow provided can be extended | ||
to satisfy the requirements of various SKUs. This describes the infrastructure | ||
in place that enables extending reference provisioning flows with code managed | ||
outside this repo. | ||
Provisioning an Earlgrey chip requires executing code on devivce during two core | ||
phases: | ||
1. Chip Probe (CP): when the wafer is still intact, and | ||
2. Final Test (FT): when each chip has been packaged and loaded into a socket. | ||
For the most part, the CP process is the same across all Earlgrey chips, | ||
regardless of the SKU. However, the FT process can differ based on the target | ||
SKU. | ||
|
||
## FT Provisioning Overview | ||
|
||
There are two main phases during FT provisioning: | ||
1. individualization, and | ||
2. personalization. | ||
|
||
## Customizing FT Provisioning Flows | ||
|
||
Various components of the reference FT provisioning flow can be extended to | ||
satisfy the requirements of various SKUs. Specifically, there is Bazel | ||
infrastructure, and example code, in place to demonstrate how one can define: | ||
1. downstream OTP configurations for a custom SKU, and | ||
2. downstream personalization firmware and host harness extensions for a custom SKU. | ||
|
||
Defining both start by defining an additional Bazel repo location on your system | ||
that resembles the directory this README.md is located in, and pointing Bazel | ||
at it via the `PROV_EXTS_DIR` envar. This tells Bazel to instantiate a local | ||
repo called `@provisioning_exts`. | ||
|
||
## OTP Image Definitions | ||
|
||
To define additional OTP configurations downstream, one must add OTP targets | ||
to the `EXT_EARLGREY_OTP_CFGS` and `EXT_EARLGREY_SKUS` dictionaries in their | ||
downstream `@provisioning_exts` Bazel repo. | ||
|
||
## Personalization Firmware | ||
|
||
The personalization firmware `ft_personalize.c` defines an `extern` extension | ||
function that is invoked as the final step in the personalization flow. | ||
|
||
`status_t personalize_extension(ujson_t *uj)` | ||
|
||
The example function provided in this example external Bazel repo does nothing, | ||
except print a message to the console. However, this provides a mechanism for | ||
SKU owners / customers to develop closed-source personalization FW extensions, | ||
that can easily make use of open-source code. | ||
|
||
This feature is implemented with the help of some custom Bazel repository rules. | ||
Specifically, in this directory we define a secondary Bazel | ||
repository (`@perso_exts`) that is designed to be used in | ||
conjunction with the main OpenTitan Bazel repository. Within this repository, we | ||
define a single `perso_ext` library that is linked with the reference | ||
`ft_personalize` binary. The `perso_ext` library itself just contains an | ||
implementation of the `personalize_extension(...)` function described above. | ||
However, the `perso_ext` library is linked with other libraries | ||
based on a Bazel `config_setting` that allows you to toggle which personalize | ||
extension library should be used (if you are building binaries for several SKU | ||
owners). | ||
|
||
Note, the Bazel configuration settings and example personalization extension | ||
library (`perso_ext`) provided in this | ||
repository are merely examples, as the `personalize_extension(...)` function | ||
implemented does nothing, except print a message. | ||
The personalization firmware `ft_personalize.c` defines two `extern` C functions | ||
that are invoked before and after certificates are endorsed off-device, | ||
respectively: | ||
`status_t personalize_extension_pre_cert_endorse(...)` | ||
`status_t personalize_extension_post_cert_endorse(...)` | ||
|
||
Additionally, the FT provisioning test harness provides an hook function to call | ||
during the certificate endorsement operation: | ||
`pub fn ft_ext(endorsed_cert_concat: ArrayVec<u8, 4096>) -> Result<ArrayVec<u8, 4096>>` | ||
|
||
The default functions provided in this example external Bazel repo do nothing. | ||
However, this provides a mechanism for SKU owners / customers to develop | ||
closed-source personalization FW extensions, that can make use of open-source | ||
code. | ||
|
||
To configure a SKU to use downstream hooks, on must update their SKUs | ||
configuration definition in the `EXT_EARLGREY_SKUS` dictionary in the | ||
`@provisioning_exts` repo. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
11 changes: 0 additions & 11 deletions
11
sw/device/silicon_creator/manuf/extensions/example_ft_ext_lib.rs
This file was deleted.
Oops, something went wrong.
23 changes: 0 additions & 23 deletions
23
sw/device/silicon_creator/manuf/extensions/example_personalize_ext.c
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.