T1040: Problem with PCIe4 during secure boot

KSin · ‎03-30-2021

Hello,

There is an SSD disc connected over PCIe 4 on our T1040 board. I think, all the PCIe busses are configured correctly, because if we build the u-boot for non-secure mode, everything works correctly.

But if we try to build and run the u-boot in secure boot mode, the initialization ends with a memory trap. During debug, we have found that the memory trap is caused by reading from address 0xB0000000 (readl function) in ahci_host_init function in ahci.c module.

I try also to check the LAW and TLBCAM configurations but I did not found any significant difference which can have an impact on the PCIe.

Can you help me?

Both the u-boot (non-secure also secure) logs are attached and both the logs are containing the lists of law_table and tlb_table.

Regards,

Karel Sin

KSin · ‎04-19-2021

Hello,

I just solved my problem, so let me make some summary of solution for somebody who probably has a similar one.

Problem:

I tried to configure the SATA SSD connected over PCIe – SATA bridge to the PCIe 4 in the u-boot. Everything worked fine if I build the u-boot for non-secure boot mode, but if I tried to build the u-boot for secure boot mode, the disk was not found, and the u-boot ends with memory trap caused by reading from address 0xB0000000 (0xB0000000 is configured address of PCIe 4) in ahci_host_init function.

Solution:

The memory tap was solved adding the LAW configuration for the PCIes:

SET_LAW(CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_PCIE_1),

SET_LAW(CONFIG_SYS_PCIE2_MEM_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_PCIE_2),

SET_LAW(CONFIG_SYS_PCIE3_MEM_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_PCIE_3),

SET_LAW(CONFIG_SYS_PCIE4_MEM_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_PCIE_4),

into the law_table[] defined in law.c file. (I am not sure, why it is necessary to do especially for secure boot configuration only.)

After this, the memory trap gone, but the disk was still not found even I added the PCIe LIODNs into the sec_config_pamu_table function (defined in pamu_table.c file).

Now I was known, that the communication was blocked by the PAMU (because if I bypass the PAMU by setting the bit BYP1 in DCFG_CCSR_PAMUBYPENR register), the disk was found.

So, I configured the PAMU interrupt to list out the PAMU status registers in case of access violation and found followed:

UDAD_UDAD = 0: NO Unauthorized Device Access Detected

AVS1_AV = 1: Access violation detected for LIODN (AVS1_LIODN): 388 (0x184)

AVS1_PDV = 0; No access violation while the PAMU enable (PE) bit is not set

AVS1_GCV = 0; No access violation during PAMU gate closed

AVS1_LAV = 010: LIODN access violation-Secondary PAACE index not within SPAACT

AVS1_WAV = 000: No window access violation

AVS1_APV = 0000: No access permission violation

AVS1_OTV = 00: No operation type violation

AVS2_OIV = 0: NO Operation Index Violation

Access Violation Address: address, in I/O address space, of the operation that encountered the error condition (AVAH, AVAL) [Hex]. 00000000 7FB03000

It means, the LIODN of PCIe4 was not added in the secondary PAACE table even it was added in the primary one.

Checking the code of the PAMU driver, I was found, that both, primary and secondary tables are defined with static size which is defined in fsl_pamu.h file as:

#define NUM_PPAACT_ENTRIES 512

#define NUM_SPAACT_ENTRIES 256

The size of 256 entries for secondary PAACE table was too small, and increasing this number solves the problem.

Regards,

Karel

View solution in original post

KSin · ‎04-19-2021