-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
plat-versal: add support for the Versal Net variant #6738
base: master
Are you sure you want to change the base?
Conversation
thanks @jcorbier I need to ask that the changes to support the more recent AMD/Xilinx tools maintain backwards compatibility. We should be able to query the ABI at runtime - maybe even propose whatever is needed to AMD/Xilinx https://github.com/Xilinx/embeddedsw . I'd like to understand as well the level of testing that has been done with this software (just the output of xtest, to check if you encountered any regressions (ie this is the changelog for 4.1.0 #6574 (comment) ). Thirdly is there anything that you also plan on posting to https://github.com/OP-TEE/optee_docs ? |
Thanks @ldts for your feedback.
Noted. Let me see how best we can implement that.
I don't have access to the logs right now but the current state is the same as for Versal in 4.1.0.
Yes, a working version is available here https://github.com/ProvenRun/optee_docs/tree/versal_net_port Same thing for build and manifest repositories. |
we should split the drivers (rng/nvm) into a different files (versal_net_rng, versal_net_nvm?) |
Agreed, the initial thinking for the current implementation was to avoid as much code duplication as possible between versal and versal_net but in the end it makes things much more complicated than needed. |
Hi @jcorbier any updates on this PR? |
Hi @nathan-menhorn, still working out the details of what needs to be done to properly split versal/versal-net code, including the TRNG update. I'll try and push an update to this PR by end of this week. |
@etienne-lms could you hold your comments until the patchset is updated please? There are a couple of functional changes that need addressing first
So I suggest we wait for that before we go into details (ie default configs, coding standards and so on) as some files will change quite a bit |
Indeed, I'll be pusing fixup commits in the coming hours/days. |
#define VERSAL_PM_MAJOR 0 | ||
#define VERSAL_PM_MINOR 1 | ||
#define VERSAL_PM_MAJOR 1 | ||
#define VERSAL_PM_MINOR 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deserves a specific commit IMHO.
Hi @jcorbier what's the current status of this PR? Thanks. |
Hi @jcorbier any updates on this PR? Are patches to address all the comments in the PR still estimated to come by the end of the month? Thanks. |
return do_write_efuses_value(EFUSE_WRITE_MISC1_CTRL_BITS, val); | ||
} | ||
|
||
TEE_Result versal_efuse_write_offchip_ids(uint32_t id) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this function is incorrect, there are total 8 offchip_revoke_id, and we use the api to update values for certain id, the parameters is lacking of the values going into that offchip id.
Please refer to the implementation in versal_nvm.c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @wangjudyw,
Thanks for your feedback. This implementation is a direct mapping of the API offered by the xilnvm service:
As you can see, it only expects an uint32_t for the ID to be written in the fuses (and a flag that is set by default by the do_write_efuses_value()
helper function). Could you elaborate what you mean?
Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mainly coding style issues
This pull request has been marked as a stale pull request because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this pull request will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time. |
Hi @jcorbier what's the status of this PR? Last we discussed updates were supposed to be pushed a few weeks ago? Thanks. |
@jcorbier do you plan on folding the commits as per the initial patch-set for further review? I can then have a a better look - last time I checked I found a simple regression (easy to fix). Also I was testing the Xen hypervisor with the tip of OP-TEE on the vck190 evaluation kit and I found it to be broken. I was wondering if this is a configuration (optee+xen on Versal) that you have tested? I believe probably nobody has yet (@nathan-menhorn ?) |
Hi @ldts no testing has been performed on Xen+optee yet as there haven't been any customers requests. |
@jcorbier @ldts @etienne-lms just keeping this PR alive. We should be expecting some input from @jcorbier soon. |
Yes, there a couple more things I want to fix then I'll force push a clean patchset to clean up the current fixup commits mess. |
core/drivers/versal_net_nvm.c
Outdated
@@ -994,8 +1010,16 @@ TEE_Result versal_efuse_write_revoke_ppk(enum versal_nvm_ppk_type type) | |||
return versal_efuse_write_misc(&misc_ctrl); | |||
} | |||
|
|||
/* | |||
* versal_efuse_write_revoke_id expects an efuse identifier between | |||
* 1 and 256. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcorbier 0 to 255
core/drivers/versal_net_nvm.c
Outdated
TEE_Result versal_efuse_write_revoke_id(uint32_t id) | ||
{ | ||
if ((id < VERSAL_NET_REVOKE_EFUSE_MIN) || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcorbier check should be between 0 and 255.
I'm not sure why the AMD software was implemented this way as this is very confusing and it doesn't match the OFFCHIP_REVOKE function, which expects values from 1 - 256, but this function expects values from 0 to 255
See the error handling of
https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilnvm/src/versal_net/server/xnvm_efuse.c#L615C21-L617
compared to
https://github.com/Xilinx/embeddedsw/blob/master/lib/sw_services/xilnvm/src/versal_net/server/xnvm_efuse.c#L701-L703
@@ -1012,12 +1014,12 @@ TEE_Result versal_efuse_write_revoke_ppk(enum versal_nvm_ppk_type type) | |||
|
|||
/* | |||
* versal_efuse_write_revoke_id expects an efuse identifier between | |||
* 1 and 256. | |||
* 1 and 256. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0 - 255
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcorbier please fix.
if (id < VERSAL_NET_REVOKE_EFUSE_MIN || | ||
id > VERSAL_NET_REVOKE_EFUSE_MAX) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcorbier checks needs to be between 0 and 255 for this function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jcorbier please fix.
@jcorbier @nathan-menhorn I am not seeing the separate commit that updates versal to the new PLM - I dont think this should be introduced just as part of the versal_net platform. Re: is this all that is needed or something else coming (this breaks versal last time I tested it) |
Hi @ldts we still need Versal support as customers are actively using the Versal version. If this (your link above) breaks your original port supported for the 2022.1 and 2022.2 Versal BSPs then this isn't good. |
ok. I'll wait for the commits being fold, then validate and review the partitioning/integration - @etienne-lms has already done the heavy lifting. do you know if anyone is looking into the xen support? as I said it broken but I dont think it should be much work to get it right |
Thanks @ldts. No one is looking into Xen + OP-TEE support. We don't have any customer requests and we don't have the resources to investigate this at this time. |
um, that is a pity. Over the summer I did some prototyping - integrated OP-TEE on meta-xilinx booted xen and started debugging op-tee but then had to drop it. Maybe I'll continue with it since I still have your board - need to check with my employer first if they allow me work on this on my spare time. will let you know |
Thanks @ldts. Feel free to give me an update offline through email. |
I suggest you squash the fixup commits when updating this P-R. |
``
Indeed, I'll push a cleaned up patch set. It's getting very messy. Thanks! |
thanks @jcorbier - in case I dont see the github notification (github notifications operate as a TRNG for me), you can ping me on jorge@foundries.io and I'll validate locally |
Hi @jcorbier what's the chance of getting this work finished (including the TRNG) as discussed in our last meeting as there's only about 15 days left in the year? The end customer is now almost a year behind awaiting this port. Thanks. |
@jcorbier what's the status? |
Hi @jcorbier 11 days left in the year. Could we at least get an update? Thanks. |
Hello @nathan-menhorn, things have been hectic here and the développer who was supposed to complete the last missing pieces for the port is only available starting next Monday. I'll sync up with him and let you know when we can finally finish this up. Sorry for the delay. |
Hi @jcorbier Happy New Year! Thank you for the update. Please give me an email update by the end of the week (or post here) as the end customer is still awaiting the port. Thanks. |
Hi @jcorbier what's the status of this port? Thanks. |
1 similar comment
Hi @jcorbier what's the status of this port? Thanks. |
59c4f3a
to
8e21b82
Compare
@nathan-menhorn This push is just a massive cleanup of the work on the upstreaming. I'll be pushing missing bits tomorrow before end of business day. I understand the frustration about the whole timeline. Sorry about that. |
Thanks for the update @jcorbier. Will this also include the TRNG updates? |
Yes, this will include support for TRNGv2
Le jeu. 30 janv. 2025, 23:47, nathan-menhorn ***@***.***> a
écrit :
… Thanks for the update @jcorbier <https://github.com/jcorbier>. Will this
also include the TRNG updates?
—
Reply to this email directly, view it on GitHub
<#6738 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABV5XYCSWQGD57VAEZFXNRD2NKTZXAVCNFSM6AAAAABEHSAW5WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRVG43TGNZRGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Please rebase the patches to resolve the conflicts. |
@jenswi-linaro Will do, thanks. I'll be pushing more updates today. |
Versal Net is a new SoC flavor based on the Versal architecture. This commit introduces it in versal platform code. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
Make it more generic and still provide a default IPI channel to the PMC for the other drivers. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
PLM HWRNG driver cannot provide more than 32 bytes of entropy at a time. Split bigger requests into 32 bytes chunks. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
The Versal Net variant comes with a dedicated PKI engine. This driver makes use of the engine for ECDSA P-256, P-384, and P-521 sign, verify and key generation operations. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
The original HUK driver generated the HUK using SHA-256. This commit replaces this mechanism with the more robust HKDF-SHA256. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
Add simple PTA allowing to dynamically load data in the Versal PL. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
- update crypto API IDs - update calls to the KAT subsystem Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
The XilNvm API has heavily changed between Versal and Versal Net. This commit adds support for the Net variant. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
XilSecure has been updated to pack the public exponent right after the modulus rather than at a fixed 512 bytes (RSA 4096 key size) offset. See commit below for more details: Xilinx/embeddedsw@c2dd2eb Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
Versal Net TRNG is very close to Versal but includes hardware DF. This patch adds support for this. Signed-off-by: Jeremie Corbier <jeremie.corbier@provenrun.com>
8e21b82
to
0ab9785
Compare
@nathan-menhorn Just pushed a rebased version of the port with support for TRNG v2. I'll be pushing all other repositories on Monday morning after more testing but everything is pretty close to being complete. |
This series upgrades the AMD/Xilinx port with the following: