plat-versal: add support for the Versal Net variant #6738

jcorbier · 2024-03-05T17:30:10Z

This series upgrades the AMD/Xilinx port with the following:

Add support for a new SoC in the Versal family
Add a hardware crypto accelerator driver for this specific SoC
Fixes for more recent versions of the Xilinx software environment (PLM APIs have changed in 2023)

ldts · 2024-03-06T10:25:47Z

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 ?

jcorbier · 2024-03-06T10:38:16Z

Thanks @ldts for your feedback.

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 .

Noted. Let me see how best we can implement that.

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) ).

I don't have access to the logs right now but the current state is the same as for Versal in 4.1.0.

Thirdly is there anything that you also plan on posting to https://github.com/OP-TEE/optee_docs ?

Yes, a working version is available here https://github.com/ProvenRun/optee_docs/tree/versal_net_port
It needs some additional work before I create a pull request for it though.

Same thing for build and manifest repositories.

ldts · 2024-03-08T11:06:39Z

we should split the drivers (rng/nvm) into a different files (versal_net_rng, versal_net_nvm?)

jcorbier · 2024-03-08T13:39:45Z

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.

nathan-menhorn · 2024-03-12T15:08:46Z

Hi @jcorbier any updates on this PR?

jcorbier · 2024-03-12T15:47:37Z

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.

core/arch/arm/plat-versal/conf.mk

core/pta/versal/fpga_pta.c

core/drivers/versal_mbox.c

core/drivers/crypto/versal/ecc.c

core/drivers/crypto/versal/ecc_mbox.c

core/drivers/versal_mbox.c

ldts · 2024-03-31T19:17:50Z

@etienne-lms could you hold your comments until the patchset is updated please?

There are a couple of functional changes that need addressing first

ABI runtime detection (not only to support the older toolchain but also to be covered for changes in the future)
use different files for Versal net instead of conditional macros (since some drivers are radically different).

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

jcorbier · 2024-04-02T14:12:21Z

@etienne-lms could you hold your comments until the patchset is updated please?

Indeed, I'll be pusing fixup commits in the coming hours/days.

core/drivers/crypto/versal/ecc.c

core/drivers/crypto/versal/ecc_mbox.c

core/pta/versal/fpga_pta.c

core/drivers/versal_net_nvm.c

etienne-lms · 2024-04-03T08:01:03Z

core/drivers/versal_pm.c

-#define VERSAL_PM_MAJOR		0
-#define VERSAL_PM_MINOR		1
+#define VERSAL_PM_MAJOR		1
+#define VERSAL_PM_MINOR		0


Deserves a specific commit IMHO.

core/drivers/crypto/versal/authenc.c

nathan-menhorn · 2024-05-07T21:54:57Z

Hi @jcorbier what's the current status of this PR? Thanks.

nathan-menhorn · 2024-05-23T20:49:32Z

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.

wangjudyw · 2024-06-27T03:02:11Z

core/drivers/versal_net_nvm.c

+	return do_write_efuses_value(EFUSE_WRITE_MISC1_CTRL_BITS, val);
+}
+
+TEE_Result versal_efuse_write_offchip_ids(uint32_t id)


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

Hi @wangjudyw,

Thanks for your feedback. This implementation is a direct mapping of the API offered by the xilnvm service:

https://github.com/Xilinx/embeddedsw/blob/86a272bd9cd412bf1e5214f6098aefff301e58f0/lib/sw_services/xilnvm/src/versal_net/server/xnvm_efuse_cdohandler.c#L229

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!

etienne-lms

mainly coding style issues

core/drivers/crypto/versal/ecc.c

core/drivers/crypto/versal/ecc_mbox.c

core/drivers/versal_mbox.c

core/drivers/versal_net_nvm.c

core/drivers/versal_trng.c

lib/libutee/include/pta_versal_fpga.h

github-actions · 2024-07-29T01:43:11Z

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.

nathan-menhorn · 2024-07-29T13:54:56Z

Hi @jcorbier what's the status of this PR? Last we discussed updates were supposed to be pushed a few weeks ago? Thanks.

core/arch/arm/plat-versal/conf.mk

core/drivers/crypto/versal/authenc.c

core/drivers/crypto/versal/ecc.c

core/drivers/crypto/versal/ecc_mbox.c

core/drivers/versal_puf.c

core/include/drivers/versal_mbox.h

core/include/drivers/versal_trng.h

core/pta/versal/fpga_pta.c

ldts · 2024-08-22T13:00:14Z

@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 ?)

nathan-menhorn · 2024-08-26T03:00:24Z

Hi @ldts no testing has been performed on Xen+optee yet as there haven't been any customers requests.

nathan-menhorn · 2024-09-11T14:30:30Z

@jcorbier @ldts @etienne-lms just keeping this PR alive. We should be expecting some input from @jcorbier soon.

jcorbier · 2024-09-18T15:35:54Z

@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).

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.

nathan-menhorn · 2024-09-18T19:01:09Z

core/drivers/versal_net_nvm.c

@@ -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. 


@jcorbier 0 to 255

nathan-menhorn · 2024-09-18T19:03:27Z

core/drivers/versal_net_nvm.c

 TEE_Result versal_efuse_write_revoke_id(uint32_t id)
 {
+	if ((id < VERSAL_NET_REVOKE_EFUSE_MIN) ||


@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

nathan-menhorn · 2024-09-19T14:39:58Z

core/drivers/versal_net_nvm.c

@@ -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.


@jcorbier please fix.

nathan-menhorn · 2024-09-19T14:40:36Z

core/drivers/versal_net_nvm.c

+	if (id < VERSAL_NET_REVOKE_EFUSE_MIN ||
+	    id > VERSAL_NET_REVOKE_EFUSE_MAX)


@jcorbier checks needs to be between 0 and 255 for this function.

@jcorbier please fix.

ldts · 2024-09-23T06:31:46Z

@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.
having said that, if we want to drop the support for the previous toolchain (@nathan-menhorn?) then I suppose we could.

Re: is this all that is needed or something else coming (this breaks versal last time I tested it)
9267cb6

nathan-menhorn · 2024-09-27T03:27:53Z

@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. having said that, if we want to drop the support for the previous toolchain (@nathan-menhorn?) then I suppose we could.

Re: is this all that is needed or something else coming (this breaks versal last time I tested it) 9267cb6

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.

ldts · 2024-09-27T06:54:41Z

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

nathan-menhorn · 2024-09-30T15:37:33Z

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.

ldts · 2024-09-30T19:18:19Z

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

nathan-menhorn · 2024-10-01T02:11:11Z

Thanks @ldts. Feel free to give me an update offline through email.

jcorbier · 2025-01-30T22:53:02Z

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: ***@***.***>

jenswi-linaro · 2025-01-31T08:48:06Z

Please rebase the patches to resolve the conflicts.

jcorbier · 2025-01-31T09:13:26Z

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 <[email protected]>

jcorbier · 2025-01-31T16:05:54Z

@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.

etienne-lms

For commit "drivers: versal: fix RSA driver": add tag Fixes: cef8ce12fcab ("crypto: versal: RSA driver")

etienne-lms · 2025-01-31T09:06:28Z

core/drivers/versal_mbox.c

 	.rmt = IPI_ID_PMC,
-	.lcl = IPI_ID_3,
+	.lcl = IPI_ID_5,


(commit "plat-versal: add support for Versal Net variant")
Changes versal-generic config. Is that right?
That said, these field of ipi are initialized from versal_mbox_init() so is this change really needed?

etienne-lms · 2025-01-31T09:16:56Z

core/drivers/versal_mbox.c

+#define IPI_REG_BASE(I) (versal_ipi_table[I].ipi_reg_base)
+#define IPI_BIT_MASK(I) (versal_ipi_table[I].ipi_bit_mask)
+#define IPI_BUF_BASE(I) (versal_ipi_table[I].ipi_buf_base)
+#define IPI_REMOTE_OFFSET(I) (versal_ipi_table[I].ipi_remote_offset)


Prefer lower case of arguments: s/I/i/

etienne-lms · 2025-01-31T09:19:48Z

core/drivers/versal_mbox.c

@@ -302,99 +427,113 @@ TEE_Result versal_mbox_alloc(size_t len, const void *init,
 	return TEE_SUCCESS;
 }

-TEE_Result versal_mbox_notify(struct versal_ipi_cmd *cmd,
+TEE_Result versal_mbox_free(struct versal_mbox_mem *mem)


All callers of versal_mbox_free() do not check the return value.
I think the best way would be to have the function returning void, allow mem == NULL, maybe add and assertion on mem != NULL` to address unexpected case when building in debug mode.

etienne-lms · 2025-02-03T07:34:25Z

core/drivers/versal_trng.c

+#define SEC_MODULE_SHIFT 8
+#define SEC_MODULE_ID 5
+
+#define CRYPTO_API_ID(__x) ((SEC_MODULE_ID << SEC_MODULE_SHIFT) | (__x))


Prefer `(SHIFT_U32(SEC_MODULE_ID, SEC_MODULE_SHIFT) | (__x))

etienne-lms · 2025-02-03T07:45:34Z

core/pta/versal/fpga_pta.c

+	if (!buf)
+		return TEE_ERROR_OUT_OF_MEMORY;
+
+	memcpy(buf, params[0].memref.buffer, bufsize);


This will copy more bytes that those provided in params[0].memref.buffer. Is this expected? Should the buffer by padded this 0s instead?

Indeed, fixed.

etienne-lms · 2025-02-03T07:51:28Z

core/arch/arm/plat-versal/conf.mk

@@ -113,6 +117,7 @@ CFG_VERSAL_SHA3_384 ?= y
 CFG_VERSAL_PUF ?= y

 # Enable Hardware Unique Key driver
+CFG_VERSAL_DUMMY_DNA ?= n


Maybe force n also if CFG_INSECURE is disabled.

etienne-lms · 2025-02-03T07:53:47Z

core/drivers/versal_net_nvm.c

+#define EFUSE_CACHE_PLM_IV_RANGE0_OFFSET		0x1DC
+#define EFUSE_CACHE_DATA_PARTITION_IV_RANGE0_OFFSET	0x1E8
+#define EFUSE_CACHE_USER0_OFFSET			0x240
+#define EFUSE_CACHE_PUF_SYN0_OFFSET			0x300


Prefer macro definitions at top of the source file.

etienne-lms · 2025-02-03T07:55:38Z

core/drivers/versal_net_nvm.c

+	reg_pair_from_64(virt_to_phys(p.buf), &b, &a);
+
+	cmd.data[0] = NVM_API_ID(id);
+	cmd.data[1] = (type << 16) | EFUSE_ENV_DIS_FLAG;


SHIFT_U32()

etienne-lms · 2025-02-03T07:57:20Z

core/drivers/versal_net_nvm.c

+					      keys->aes_key, EFUSE_AES_KEY_LEN);
+		if (res2) {
+			DMSG("Error programming AES key (0x%" PRIx32 ")", res2);
+			res = TEE_ERROR_GENERIC;


Still attempt to program other fuses if this failed? Maybe return straight?

We might have weird scenarios where one key has already been burnt and locked and the other ones not yet and we don't want the other writes to fail.

etienne-lms · 2025-02-03T08:01:02Z

core/drivers/versal_trng.c

+#if defined(CFG_VERSAL_RNG_DRV_V2)
+	if (trng->cfg.version == TRNG_V2)
+		trng_clrset32(trng->cfg.addr, TRNG_CTRL_3, TRNG_CTRL_3_DLEN_MASK,
+			TRNG_CTRL_3_DLEN_DEFVAL);


indentation

Make it more generic and still provide a default IPI channel to the PMC for the other drivers. Signed-off-by: Jeremie Corbier <[email protected]>

jcorbier · 2025-02-03T16:03:30Z

@etienne-lms Thanks for the review once more. I'll be taking that into account in another round of commits.

nathan-menhorn

Comments on TRNG self-check

nathan-menhorn · 2025-02-06T00:17:16Z

core/drivers/versal_trng.c

@@ -963,6 +991,10 @@ static TEE_Result trng_kat_test(struct versal_trng *trng)
 	if (!trng)
 		return TEE_ERROR_GENERIC;

+	/* Self-tests are performed in HW */
+	if (trng->cfg.version == TRNG_V2)
+		return TEE_SUCCESS;


All the self tests are still needed.

See https://github.com/Xilinx/embeddedsw/blob/xilinx_v2024.2/XilinxProcessorIPLib/drivers/trngpsx/src/xtrngpsx_tests.c#L211

Linkage into the PKI: https://github.com/Xilinx/embeddedsw/blob/xilinx_v2024.2/lib/sw_services/xilpki/src/xilpki.c#L602

ldts · 2025-02-07T08:01:20Z

@jcorbier the commit "versal rework mailbox driver" should be split into multiple commits indicating what is being addressed and what new functionality is being added (ie, I think the timeout feature while waiting for an acknowledgement deserves one)

ldts · 2025-02-07T08:12:28Z

@jcorbier it would have been cleaner to keep separate ecc and kpi drivers instead of splitting ecc - more over since ecc.c has a conditional macro for kpi. would it be too much work to keep them separate? It would be great if you could do that please.

ldts · 2025-02-07T08:16:47Z

@jcorbier could you keep the foundries.io copyright in versal_trng.h? AFAICS is a verbatim copy/paste from versal_trng.c?

ldts

Replacing the HUK is going to break systems using RPMB if they take this upgrade.

Could you make HKDF derivation a configuration option please disabled by default?

ldts

WRT to the RSA driver "fix", the code was correct for 2022.1. I think the title will confuse projects that regularly cherry-pick security fixes.

This commit should be named update to 2022.2 or something similar instead (not tagged at as a a generic fix for the RSA driver)

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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

Add simple PTA allowing to dynamically load data in the Versal PL. Signed-off-by: Jeremie Corbier <[email protected]>

- update crypto API IDs - update calls to the KAT subsystem Signed-off-by: Jeremie Corbier <[email protected]>

The XilNvm API has heavily changed between Versal and Versal Net. This commit adds support for the Net variant. Signed-off-by: Jeremie Corbier <[email protected]>

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 Fixes: cef8ce1 ("crypto: versal: RSA driver") Signed-off-by: Jeremie Corbier <[email protected]>

Versal Net TRNG is very close to Versal but includes hardware DF. This patch adds support for this. Signed-off-by: Jeremie Corbier <[email protected]>

nathan-menhorn · 2025-02-10T18:22:18Z

Hi @etienne-lms @jenswi-linaro just curious what else you need to get this merged into main. Thanks.

jenswi-linaro · 2025-02-11T07:42:44Z

@nathan-menhorn have you addressed all the comments from @ldts?
This is a rather large pull request, more than 4000 LOC to review so it's extra important to be clear about what's updated so we don't need to check the same thing repeatedly. Overlooking comments or questions will cause further delays. If you don't agree with something be clear about that so it can be discussed.

nathan-menhorn · 2025-02-11T16:23:36Z

Hi @jenswi-linaro although @ldts provided excellent feedback, the Versal OP-TEE port is no longer maintained and only works with 2022.1 and 2022.2 AMD bsps. Additionally, the customer has been awaiting this OP-TEE OS port for over 2 years so this upstream effort will need to be prioritized over requests from @ldts.

cc: @jcorbier

ldts · 2025-02-12T08:27:07Z

Hi @jenswi-linaro although @ldts provided excellent feedback, the Versal OP-TEE port is no longer maintained and only works with 2022.1 and 2022.2 AMD bsps. Additionally, the customer has been awaiting this OP-TEE OS port for over 2 years so this upstream effort will need to be prioritized over requests from @ldts.

cc: @jcorbier

The first thing I suggested on this pull request was separating the commit that updates the Versal port to a more recent PLM.

If I recall correctly, this primarily involved ABI detection and a minor protocol adjustment in one of the drivers due to changes in the PLM call identifiers. Updating the current Versal support to a recent BSP—if still relevant—shouldn’t be a major effort, likely just a few days of work.

I’m not entirely satisfied with how this port has been structured, and it’s unfortunate that addressing the syntactic review—though necessary—has taken so long. As a result, we’ve run out of time to ensure a clear separation between Versal and Versal Net.

That said, we are where we are, so moving forward: from your comment, it sounds like the current upstream Versal port is now obsolete (no users). If that’s the case, it may be time to consider dropping it entirely. @nathan-menhorn, do you know who will be maintaining Versal Net? Perhaps that team could also take over maintainership of Versal and its drivers and handle the necessary cleanup?

jenswi-linaro · 2025-02-12T08:32:17Z

Additionally, the customer has been awaiting this OP-TEE OS port for over 2 years

This is all the more reason to be keen to answer on review feedback from someone who knows the code. Upstreaming takes time, especially when it's in large chunks like this. @ldts has spent time to review this PR and his requests are in line with what you should expect when upstreaming.

etienne-lms reviewed Mar 20, 2024

View reviewed changes

etienne-lms reviewed Apr 3, 2024

View reviewed changes

wangjudyw reviewed Jun 27, 2024

View reviewed changes

etienne-lms reviewed Jun 27, 2024

View reviewed changes

github-actions bot added the Stale label Jul 29, 2024

github-actions bot removed the Stale label Jul 30, 2024

etienne-lms reviewed Aug 21, 2024

View reviewed changes

nathan-menhorn reviewed Sep 19, 2024

View reviewed changes

plat-versal: add support for Versal Net variant

d7d4604

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 <[email protected]>

jcorbier force-pushed the versal_net_port_upstreaming branch from 8e21b82 to 0ab9785 Compare January 31, 2025 16:04

etienne-lms reviewed Feb 3, 2025

View reviewed changes

drivers: versal: rework mbox driver

5418d26

Make it more generic and still provide a default IPI channel to the PMC for the other drivers. Signed-off-by: Jeremie Corbier <[email protected]>

jcorbier force-pushed the versal_net_port_upstreaming branch from 0ab9785 to 9835f1f Compare February 3, 2025 16:03

nathan-menhorn reviewed Feb 6, 2025

View reviewed changes

ldts suggested changes Feb 7, 2025

View reviewed changes

jcorbier added 8 commits February 7, 2025 18:25

drivers: versal: use PLM for generic RNG operations

7a66bd9

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 <[email protected]>

drivers: versal: PKI engine driver for Versal Net

a70520c

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 <[email protected]>

drivers: versal: use HKDF to derive the HUK

405eef2

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 <[email protected]>

core: pta: add Versal FPGA PTA

80dda35

Add simple PTA allowing to dynamically load data in the Versal PL. Signed-off-by: Jeremie Corbier <[email protected]>

drivers: versal: update to support more recent versions of the PLM

d4de26b

- update crypto API IDs - update calls to the KAT subsystem Signed-off-by: Jeremie Corbier <[email protected]>

drivers: versal: NVM driver for Versal Net

6aa8a44

The XilNvm API has heavily changed between Versal and Versal Net. This commit adds support for the Net variant. Signed-off-by: Jeremie Corbier <[email protected]>

drivers: versal: add support for new TRNG IP

2ee731c

Versal Net TRNG is very close to Versal but includes hardware DF. This patch adds support for this. Signed-off-by: Jeremie Corbier <[email protected]>

jcorbier force-pushed the versal_net_port_upstreaming branch from 9835f1f to 2ee731c Compare February 7, 2025 17:45

		if (id < VERSAL_NET_REVOKE_EFUSE_MIN \|\|
		id > VERSAL_NET_REVOKE_EFUSE_MAX)

plat-versal: add support for the Versal Net variant #6738

Are you sure you want to change the base?

plat-versal: add support for the Versal Net variant #6738

Conversation

jcorbier commented Mar 5, 2024

ldts commented Mar 6, 2024 • edited Loading

jcorbier commented Mar 6, 2024

ldts commented Mar 8, 2024

jcorbier commented Mar 8, 2024

nathan-menhorn commented Mar 12, 2024

jcorbier commented Mar 12, 2024

ldts commented Mar 31, 2024

jcorbier commented Apr 2, 2024

Choose a reason for hiding this comment

nathan-menhorn commented May 7, 2024

nathan-menhorn commented May 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

etienne-lms left a comment

Choose a reason for hiding this comment

github-actions bot commented Jul 29, 2024

nathan-menhorn commented Jul 29, 2024

ldts commented Aug 22, 2024 • edited Loading

nathan-menhorn commented Aug 26, 2024

nathan-menhorn commented Sep 11, 2024

jcorbier commented Sep 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ldts commented Sep 23, 2024 • edited Loading

nathan-menhorn commented Sep 27, 2024

ldts commented Sep 27, 2024

nathan-menhorn commented Sep 30, 2024

ldts commented Sep 30, 2024

nathan-menhorn commented Oct 1, 2024

jcorbier commented Jan 30, 2025 via email

jenswi-linaro commented Jan 31, 2025

jcorbier commented Jan 31, 2025

jcorbier commented Jan 31, 2025

etienne-lms left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jcorbier commented Feb 3, 2025

nathan-menhorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ldts commented Feb 7, 2025 • edited Loading

ldts commented Feb 7, 2025 • edited Loading

ldts commented Feb 7, 2025

ldts left a comment • edited Loading

Choose a reason for hiding this comment

ldts left a comment • edited Loading

Choose a reason for hiding this comment

nathan-menhorn commented Feb 10, 2025

jenswi-linaro commented Feb 11, 2025

nathan-menhorn commented Feb 11, 2025

ldts commented Feb 12, 2025

jenswi-linaro commented Feb 12, 2025

ldts commented Mar 6, 2024 •

edited

Loading

ldts commented Aug 22, 2024 •

edited

Loading

ldts commented Sep 23, 2024 •

edited

Loading

ldts commented Feb 7, 2025 •

edited

Loading

ldts commented Feb 7, 2025 •

edited

Loading

ldts left a comment •

edited

Loading

ldts left a comment •

edited

Loading