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.

jenswi-linaro · 2025-03-24T09:19:11Z

I'm sorry, I missed there was an update in this pull request. Sometimes when only pushing changes to a pull request, github doesn't send updates. So the best is to add a comment after pushing changes to a PR to avoid unnecessary delays.

@ldts had a few questions:

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?

Do we need to choose between Versal and Versal Net to move forward here, or can both variants co-exist without breakage? Who decides to remove Versal if that's needed?

ldts · 2025-03-24T09:43:45Z

@jenswi-linaro I believe this decision is ultimately up to @nathan-menhorn.

I'm willing to step down as a Versal platform and crypto/driver maintainer to support the proposed strategy moving forward. I don't want to be a blocker for either Versal2 or Versal-Net. My only request is that the license remains in place, as I understand AMD intends to reuse all of the code.

jenswi-linaro · 2025-03-24T12:29:33Z

Thank you @ldts, I fully support your request for the license.

nathan-menhorn · 2025-03-24T16:53:23Z

@jenswi-linaro I believe this decision is ultimately up to @nathan-menhorn.

I'm willing to step down as a Versal platform and crypto/driver maintainer to support the proposed strategy moving forward. I don't want to be a blocker for either Versal2 or Versal-Net. My only request is that the license remains in place, as I understand AMD intends to reuse all of the code.

@ldts @jenswi-linaro I agree that the license needs to remain in place as the code is heavily reused.

@jcorbier could you please provide an update with the license request? Thanks.

nathan-menhorn · 2025-03-24T16:55:15Z

I'm sorry, I missed there was an update in this pull request. Sometimes when only pushing changes to a pull request, github doesn't send updates. So the best is to add a comment after pushing changes to a PR to avoid unnecessary delays.

@ldts had a few questions:

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?

Do we need to choose between Versal and Versal Net to move forward here, or can both variants co-exist without breakage? Who decides to remove Versal if that's needed?

Hi @jenswi-linaro both variants can exist without breakage. I've done basic testing on my end and both variants compile as expected for the various boards. Plans for Versal NET maintenance are currently TBD, the main goal is to support the end customer by first getting this port upstreamed.

jenswi-linaro · 2025-03-25T10:04:44Z

Hi @jenswi-linaro both variants can exist without breakage. I've done basic testing on my end and both variants compile as expected for the various boards. Plans for Versal NET maintenance are currently TBD, the main goal is to support the end customer by first getting this port upstreamed.

Thanks for testing. @nathan-menhorn, if @ldts is stepping down, can you be an interim maintainer for versal while future maintenance is sorted out?

nathan-menhorn · 2025-03-25T14:57:07Z

@jenswi-linaro I believe this decision is ultimately up to @nathan-menhorn.
I'm willing to step down as a Versal platform and crypto/driver maintainer to support the proposed strategy moving forward. I don't want to be a blocker for either Versal2 or Versal-Net. My only request is that the license remains in place, as I understand AMD intends to reuse all of the code.

@ldts @jenswi-linaro I agree that the license needs to remain in place as the code is heavily reused.

@jcorbier could you please provide an update with the license request? Thanks.

Just a minor correction on the license. I am checking with AMD legal on this. Thanks.

nathan-menhorn

Hi @jcorbier the TRNG KAT test is not passing.

nathan-menhorn · 2025-04-03T14:44:27Z

core/drivers/versal_trng.c

-	.cfg.base = TRNG_BASE,
-	.cfg.len = TRNG_SIZE,
-};
+static TEE_Result trng_kat_test_v2(struct versal_trng *trng)


@jcorbier This code is not passing as expected on hardware causing OP-TEE to fail booting. Please recheck this on your board as the generated output does not match the expected output. Thanks.

I added some debug prints to see the KAT output and here are the results:

D/TC:00 0 do_init_calls:19 service_initcall level 2 check_ta_store()
D/TC:00 0 check_ta_store:449 TA store: "early TA"
D/TC:00 0 check_ta_store:449 TA store: "Secure Storage TA"
D/TC:00 0 check_ta_store:449 TA store: "REE"
D/TC:00 0 do_init_calls:19 service_initcall level 2 early_ta_init()
D/TC:00 0 early_ta_init:56 Early TA f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c size 48116 (compressed, uncompressed 109288)
D/TC:00 0 do_init_calls:19 service_initcall level 2 verify_pseudo_tas_conformance()
D/TC:00 0 do_init_calls:19 service_initcall level 3 tee_fs_init_key_manager()
I/TC: Using Development HUK
D/TC:00 0 boot_mem_release_tmp_alloc:324 Releasing 8192 bytes from va 0x223fe000
D/TC:00 0 do_init_calls:19 driver_initcall level 1 ecc_init()
E/TC:00 0 trng_kat_test_v2:1152 PRINTING TRNG KAT VECTOR
E/TC:00 0 trng_kat_test_v2:1155 D8
E/TC:00 0 trng_kat_test_v2:1155 F1
E/TC:00 0 trng_kat_test_v2:1155 6E
E/TC:00 0 trng_kat_test_v2:1155 04
E/TC:00 0 trng_kat_test_v2:1155 46
E/TC:00 0 trng_kat_test_v2:1155 8E
E/TC:00 0 trng_kat_test_v2:1155 6B
E/TC:00 0 trng_kat_test_v2:1155 73
E/TC:00 0 trng_kat_test_v2:1155 E6
E/TC:00 0 trng_kat_test_v2:1155 92
E/TC:00 0 trng_kat_test_v2:1155 BD
E/TC:00 0 trng_kat_test_v2:1155 3D
E/TC:00 0 trng_kat_test_v2:1155 A6
E/TC:00 0 trng_kat_test_v2:1155 28
E/TC:00 0 trng_kat_test_v2:1155 9C
E/TC:00 0 trng_kat_test_v2:1155 37
E/TC:00 0 trng_kat_test_v2:1155 5B
E/TC:00 0 trng_kat_test_v2:1155 9E
E/TC:00 0 trng_kat_test_v2:1155 6C
E/TC:00 0 trng_kat_test_v2:1155 3C
E/TC:00 0 trng_kat_test_v2:1155 89
E/TC:00 0 trng_kat_test_v2:1155 8D
E/TC:00 0 trng_kat_test_v2:1155 81
E/TC:00 0 trng_kat_test_v2:1155 9E
E/TC:00 0 trng_kat_test_v2:1155 D7
E/TC:00 0 trng_kat_test_v2:1155 E3
E/TC:00 0 trng_kat_test_v2:1155 89
E/TC:00 0 trng_kat_test_v2:1155 61
E/TC:00 0 trng_kat_test_v2:1155 6A
E/TC:00 0 trng_kat_test_v2:1155 58
E/TC:00 0 trng_kat_test_v2:1155 65
E/TC:00 0 trng_kat_test_v2:1155 09
E/TC:00 0 trng_kat_test_v2:1157
E/TC:00 0 trng_kat_test_v2:1158 K.A.T mismatch
E/TC:00 0 versal_trng_hw_init:1216 KAT Failed
E/TC:00 0 Panic at core/drivers/versal_trng.c:1217 <versal_trng_hw_init>
E/TC:00 0 TEE load address @ 0x22200000
E/TC:00 0 Call stack:
E/TC:00 0 0x222081d4
E/TC:00 0 0x22225cbc
E/TC:00 0 0x2221c89c
E/TC:00 0 0x222227cc
E/TC:00 0 0x22223180
E/TC:00 0 0x222219d4
E/TC:00 0 0x222277bc
E/TC:00 0 0x22207ee8

Hi @nathan-menhorn, thanks for the logs. It might be a merge issue caused by us not testing on the final hardware, sorry about that. Let me check.

nathan-menhorn · 2025-04-11T17:15:07Z

Hi @ldts could you please clearly specific which files are missing the license you mention and the specific license text you are looking to include. Thanks.

nathan-menhorn · 2025-04-11T17:15:19Z

@jcorbier any updates on the TRNG?

ldts · 2025-04-14T07:16:24Z

Hi @ldts could you please clearly specific which files are missing the license you mention and the specific license text you are looking to include. Thanks.

hi @nathan-menhorn I checked and I think it is all good now. Maybe I was confused with the versal2 PRs.

nathan-menhorn · 2025-04-14T20:11:22Z

Thanks @ldts for confirming.

nathan-menhorn · 2025-04-14T20:12:16Z

@jcorbier any updates on the TRNG? This is slipping schedules for our CAVP testing and slipping schedules for the end customer. Thanks.

jcorbier · 2025-04-15T06:48:57Z

@jcorbier any updates on the TRNG? This is slipping schedules for our CAVP testing and slipping schedules for the end customer. Thanks.

Hi @nathan-menhorn, working on it. Debugging is taking a bit more time than expected. We hope we'll have pushed an update here by tomorrow morning your time.

ldts · 2025-04-16T11:29:43Z

@jcorbier can you check if this is required for Versal?
74c6ad9

I suspect it will be.

jcorbier · 2025-04-16T15:16:24Z

@jcorbier can you check if this is required for Versal? 74c6ad9

I suspect it will be.

Indeed. Thanks for pointing this out.

nathan-menhorn · 2025-05-05T16:31:18Z

Hi @jcorbier any updates?

nathan-menhorn · 2025-05-05T16:36:18Z

Hi @jcorbier any updates on the TRNG KAT?

nathan-menhorn · 2025-05-12T19:21:27Z

@jcorbier any updates on the TRNG? This is slipping schedules for our CAVP testing and slipping schedules for the end customer. Thanks.

Hi @nathan-menhorn, working on it. Debugging is taking a bit more time than expected. We hope we'll have pushed an update here by tomorrow morning your time.

Hi @jcorbier From your comment last month, we were supposed to get updates in a day or so and it's now May and the customer is even further behind. Any updates on getting this fixed?

nathan-menhorn · 2025-05-19T16:38:57Z

@jcorbier

nathan-menhorn · 2025-05-21T17:30:30Z

@jcorbier

nathan-menhorn · 2025-05-22T16:32:34Z

@jcorbier

nathan-menhorn · 2025-06-02T21:35:53Z

@jcorbier

nathan-menhorn · 2025-06-10T20:04:13Z

@jcorbier

github-actions · 2025-07-11T02:26:03Z

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.

jcorbier · 2025-07-11T05:49:00Z

Pull request still being worked on in the background. More pushes to come in an estimated couple weeks

huynhdanvo · 2025-07-22T14:41:30Z

Hi @nathan-menhorn , I was able to produce the same issue with trng_kat_test_v2() panic issue. It seems to me that the hw is disabled.

I/TC: TRNG_OSC_EN after manual enable: 0x00000001
I/TC: TRNG_CTRL = 0x00000000
I/TC: Initial CTRL: 0x00000000
I/TC: CTRL after write: 0x00000000
I/TC: Dump before TRNG KAT
I/TC: ---- TRNG Register Dump ----
I/TC: TRNG_CTRL       : 0x00000000
I/TC: TRNG_STATUS     : 0x00000000
I/TC: TRNG_OSC_EN     : 0x00000001
I/TC: TRNG_CORE_OUTPUT: 0x00000000
I/TC: CFG_VERSAL_RNG_DRV_V2: 1
I/TC: TRNG_CTRL2       : 0x00000000
I/TC: TRNG_CTRL3       : 0x00000000
I/TC: TRNG_CTRL4       : 0x00000000
I/TC: -----------------------------

Could you please assist me on how to setup the right clock to enable the hw on my device?

Thanks,
Dan

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

nathan-menhorn suggested changes Apr 3, 2025

View reviewed changes

jockebech mentioned this pull request Jun 12, 2025

Add Versal Net Documentation OP-TEE/optee_docs#261

Open

github-actions bot added the Stale label Jul 11, 2025

jenswi-linaro removed the Stale label Jul 11, 2025

		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

Uh oh!

Conversation

jcorbier commented Mar 5, 2024

Uh oh!

ldts commented Mar 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jcorbier commented Mar 6, 2024

Uh oh!

ldts commented Mar 8, 2024

Uh oh!

jcorbier commented Mar 8, 2024

Uh oh!

nathan-menhorn commented Mar 12, 2024

Uh oh!

jcorbier commented Mar 12, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ldts commented Mar 31, 2024

Uh oh!

jcorbier commented Apr 2, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nathan-menhorn commented May 7, 2024

Uh oh!

nathan-menhorn commented May 23, 2024

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

etienne-lms left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Jul 29, 2024

Uh oh!

nathan-menhorn commented Jul 29, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ldts commented Mar 6, 2024 •

edited

Loading

ldts commented Aug 22, 2024 •

edited

Loading

ldts commented Sep 23, 2024 •

edited

Loading

ldts commented Mar 24, 2025 •

edited

Loading