Forum Discussion
New ContributorMailbox Client IP - SEND_CERTIFICATE command through FPGA fabric
Hi colleagues,
under Agilex3C (A3CY135BM16A) Non-HPS with Quartus 26.1 (latest SDM, latest IPs)
how one can send compact certificates to SDM through the internal FPGA fabric?
I tried it with Mailbox Client (1024/1024 FIFO depth, AXI accelerator path disabled) + SPI slave/JTAG Avalon Master, all other SDM commands (incl. the complicated ones like SPI programming with larger payloads) are working fine except this one.
The error I get back all the time is 0xF00000FF (which appears as 0x3FF in SDM level1 log), so generic error, no explanation.
When I load the same certificate over JTAG (external JTAG not via JTAG Avalon bridge to Mailbox Client), then it is working fine (so signature and certificate content is right).
I tried both burning fuse or just loading virtual fuse with/without test bit. All gives back this same answer if it has been sent over FPGA Fabric SDM mailbox.
Does anyone know any example project for this?
(I tried to make it work based on ATF-A mailbox driver's VAB certificate loading command implementation (which theoretically should accept other certificates too). I believe this is something supposed to work without HPS. (otherwise you should leave JTAG enabled in your system).
Links:
arm-trusted-firmware/plat/altera/soc/common/include/socfpga_mailbox.h at socfpga_v2.14.0 · altera-fpga/arm-trusted-firmware
arm-trusted-firmware/plat/altera/soc/common/soc/socfpga_mailbox.c at socfpga_v2.14.0 · altera-fpga/arm-trusted-firmware
Thanks,
Peter
7 Replies
dpcsu_eOne more question:
If this is an SDM behavior to reject it, is it considered a bug by altera and will it be fixed in later SDM firmware versions in later quartus revisions?
if yes by when?
and what is the ticket id so we can doublecheck when it was fixed (in quartus release notes).Thanks,
Peter
Farabi_AlteraRegular Contributor
Hello Peter,
PDF attached. This is not a bug. This is more to SDM mailbox limitation. There is no fix plan for this limitation.
regards,
Farabi
- dpcsu_e
Hi Farabi,
where did you attach the PDF?
Thanks,
Peter
- dpcsu_e
Hello Farabi,
thank you for the hints!
One question: are you an Altera employee so your answers I can assume as official answers or shall I wait more for them too?
If I understand your suggestions correctly all the 3 related to:
1) enable AXI, use 32bit word indirect transfers and align this external memory to 8 bytes, etc...I checked the Avalon bus parameters it there it seems it is not supporting indirect transfers with this IP.
And AXI is used only for the acceleration engine, which (I believe) has no role in loading compact certificates.
I would find it strange that SDM implement such sophisticated security features and would restrict me to use it only in HPS versions. That does not make any sense to me, anti rollback protection is needed with normal fpga images, what if someone implement ad absurdum a nios processor or such?! or just simply wants their normal fpga logic to be properly protected. The whole point in Agilex3C -Z version is having config authentication/encryption, therefore anti-rollback is a crucial feature.Thanks,
Peter - Farabi_Altera
Hello Peter,
Do you have further question?
regards,
Farabi - Farabi_Altera
Hello,
The SDM rejected the certificate due to source/format/transfer constraints, not cryptographic validity.
SInce the JTAG external is working, your certificate(signature) is valid.
This specific SDM command is probably not accepted from the internal FPGA fabric mailbox path on Agilex 3C non-HPS.
Recommendation:
1- Use indirect transfer mode(buffered writes)
2- Check if the data written is 32-bit words
3- Ensure payload base address aligned to 8bytes, and length is multiple of 4bytes. Pad with zero if needed.
If you need this to work in non-HPS system, the supported path may be limited to external JTAG.
I would currently assume there is no supported example because this command is likely not supported from the internal FPGA fabric mailbox path on Agilex 3C non-HPS device.
regards,
Farabi
