ot_otp: unify implementations
#272
Merged
Conversation
This file contains hidden or 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
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
from
32de450 to
a5cad1d
Compare
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
2 times, most recently
from
e6edb49 to
4eb19dc
Compare
loiclefort
reviewed
Oct 31, 2025
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
2 times, most recently
from
8494dad to
56b1a5e
Compare
AlexJones0
reviewed
Oct 31, 2025
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
2 times, most recently
from
b588e1b to
5e0c13a
Compare
Disable all LLVM rules as they hard-code paths from LLVM project. llvm-header-guard therefore suggests to replace header guard path with the full absolute path of the current local check out directory path! It appears that llvm-* rules are only to be used for the LLVM project itself, but they are nevertheless automatically added with the default `*` wildcard... Signed-off-by: Emmanuel Blot <[email protected]>
…erator Signed-off-by: Emmanuel Blot <[email protected]>
- move partition names to the OtOTPPartDesc array - allocate arrays of string properties and their matching byte values at runtime, - rename partition-related variables, as several new variables are added - replace statically defined constants with dynamic variables - clean up Signed-off-by: Emmanuel Blot <[email protected]>
- move partition names to the OtOTPPartDesc array - allocate arrays of string properties and their matching byte values at runtime, - rename partition-related variables, as several new variables are added - replace statically defined constants with dynamic variables - clean up Signed-off-by: Emmanuel Blot <[email protected]>
…erface. This is the second step towards unification of OtOTP* implementations. It is better to expose the OtOTPState feature as an interface, so that OtOTPState can later implement the common feature for all OtOTP Top-specialized implementation. Signed-off-by: Emmanuel Blot <[email protected]>
…TP devices Signed-off-by: Emmanuel Blot <[email protected]>
… file Signed-off-by: Emmanuel Blot <[email protected]>
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
from
5e0c13a to
fbe0c39
Compare
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
2 times, most recently
from
1aadd5c to
d7b4ee4
Compare
AlexJones0
approved these changes
Nov 3, 2025
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
from
d7b4ee4 to
64a23e2
Compare
Thanks for the reviews. |
… Darjeeling - merge and adapt common code into OtOTPEngine - keep only OTP top-specific implementation in ot_otp_eg.c and ot_otp_dj.c, which implement the OtOTPImplIf interface (specialization for Tops) - regenerate OTP partition descriptions and key seed definition with otptool.py Signed-off-by: Emmanuel Blot <[email protected]>
- use Top defined constants - simplify stack of macro calls - remove definitions from ot_otp_engine.h Signed-off-by: Emmanuel Blot <[email protected]>
…ctory This is needed to implement other OTP top-specific implementations. Signed-off-by: Emmanuel Blot <[email protected]>
…rties - secret_scrambling_keys: the exact number of such properties is created. this avoid allocated useless memory, and ensure QEMU property subsystem may report any attempt to define values for keys that do not exist - secret_scrambling_key and inv_default_data values are now tied to the partition controller, rather than to be allocated as separate arrays Signed-off-by: Emmanuel Blot <[email protected]>
Should start with OT_OTP, OtOtp, ot_otp to prevent from unexpected conflicts Signed-off-by: Emmanuel Blot <[email protected]>
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
from
64a23e2 to
b4bfe87
Compare
…TP prefix Signed-off-by: Emmanuel Blot <[email protected]>
…d data Signed-off-by: Emmanuel Blot <[email protected]>
rivos-eblot
force-pushed
the
dev/ebl/otp_unify
branch
from
b4bfe87 to
8bad622
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR generalizes OTP implementation, so that code is no longer duplicated for each top.
Most of the code is now implemented in a new component
OtOTPEngineState(ot_otp_engine.c) which contains over 4/5 of the duplicated code that used to exist inot_otp_eg.candot_otp_dj.cfiles.Those two latter files now only contain what is specific to each Top:
Some note about the interfaces/classes:
OtOTPIf(Class)interface exposes the public interface of the OTP, i.e. the API that other OpenTitan "HW" devices can use to communicate with the OTPOtOTPImplIf(Class)interface exposes the semi- private interface that a top-specific OTP implementation exposes to theOtOTPEngineStateOtOtpBeIf(Class)interface exposes the public interface of an OTP backend, which describes the characteristics of a specific backend. Note that ideally, this component should manage the QEMU OTP image file, which is not (yet) the case.OtOTPEngineState/Classimplements the whole OTP emulation. It is an abstract class whose concrete implementation is Top-specific.OtOTPEgState/ClassandOtOTPDjState/Classare two concrete implementations ofOtOTPEngineState/Class. Each implements the implements theOtOTPIfinterface which is exposed to the OTP clients, and implement theOtOTPImplIfto provide the features required by their abstract classOtOTPEngineState/Class.