Forum Discussion

dpcsu_e's avatar
dpcsu_e
Icon for New Contributor rankNew Contributor
16 days ago

Mailbox 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

Platform

3 Replies

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    7 days ago

    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

     

  • Farabi's avatar
    Farabi
    Icon for Regular Contributor rankRegular Contributor
    4 days ago

    Hello Peter, 

     

    Do you have further question? 

     

    regards,
    Farabi

  • dpcsu_e's avatar
    dpcsu_e
    Icon for New Contributor rankNew Contributor
    3 days ago

    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