Hi, see few comments inline [OD].

________________________________ From: Chenxu Wang irakatz51@gmail.com Sent: 14 December 2022 20:27 To: Olivier Deprez Olivier.Deprez@arm.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: Re: [TF-A] Question about using rme for smmuv3

Thanks Olivier!

Now I change my TF-A to v2.8 (but no change in boot cmd), and then I can get the value of SMMU_ROOT_IDR0/SMMU_ROOT_IIDR by modifying the smmu file. But I still have some questions:

1. it looks like the mapping of DEVICE0 is "device memory, MT_SECURE". But based on the manual, the smmu root page is only accessible with Root privilege (MT_ROOT). So I wonder how the inserted codes in smmu_v3.c can get these values with MT_SECURE.

[OD] Yes this is a valid question. smmuv3_init called from bl31_early_platform_setup2 is done with MMU off, I appreciate transactions issued from EL3 are marked root with mmu off, and hence the smmu root page read access succeeds. When called from bl31_main, MMU is on, and as you mentioned MMU attributes are secure access, so the same read operation doesn't reach the SMMU peripheral. I'd have expected some GPF to be reported though.

Also, when I insert in bl31_main.c, it returns 0x0. But if I split the MAP_DEVICE0 and map the smmu region with MT_ROOT, I can get the same value as in smmu_v3.c

[OD] Yes this confirms the description above.

2. On FVP Does this smmu only controls PCIe? If so, who will control the other peripherals? Here I consider a DMA-330, it seems that it has no corresponding smmu on Arm FVP (I know other board, such as Juno, has a DMA SMMU).

[OD] AFAIK on FVP the only peripheral upstream to the SMMU is the SMMUv3TestEngine. I don't believe PCIe is involved.

Can you help me with these?

Sincerely, WANG Chenxu

Olivier Deprez Olivier.Deprez@arm.com 于2022年12月14日周三 17:41写道：

Hi,

See few comments [OD]

Regards, Olivier.

---

From: Chenxu Wang via TF-A tf-a@lists.trustedfirmware.org Sent: 13 December 2022 19:42 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Question about using rme for smmuv3

Hi all,

I test the SMMUv3 on FVP_Base_RevC-2xAEMvA_11.20_15, and my TF-A is the branch "arm_cca_v0.3".

[OD] you should consider using master, from now as I appreciate this branch might have aged a bit.

When I boot my FVP, I set the following commands: -C pci.pci_smmuv3.mmu.SMMU_ROOT_IDR0=3 \ -C pci.pci_smmuv3.mmu.SMMU_ROOT_IIDR=0x43B \ -C pci.pci_smmuv3.mmu.root_register_page_offset=0x20000 \ -C cluster0.rme_support_level=2 \ -C cluster1.rme_support_level=2 \

[OD] Note for running TF-A's SMMU test cases, we use a number of other options (but omitting those options may not be the exact reason for the problem you observe) -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 \ -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B \ -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 \ -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 \ -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0475 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 \ -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 \

Based on the FVP manual, the SMMU base is 0x2b40_0000, and I think the SMMU Root Control Page should be 0x2b42_0000. Thus, I add the mapping to this region in plat_arm_mmap[], as: MAP_REGION_FLAT(0x2b420000,(0x2b430000-0x2b420000),MT_MEMORY | MT_RW |MT_ROOT)

[OD] I believe the region shall be mapped as device memory. Depending on which TF-A component you use, it may already be mapped as part of the generic peripherals region e.g. for BL31: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo... https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo... https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo...

Then I try to access the SMMU_ROOT_IDR0 register in TF-A. Based on the manual, its offset is 0x0, so I read 0x2b42_0000. However, it returns 0x0, which is not what I configured in the boot commands (I think it should be 0x3).

[OD] I tried by inserting in BL31:

diff --git a/drivers/arm/smmu/smmu_v3.c b/drivers/arm/smmu/smmu_v3.c index 6c6f978d4..42ebbc79e 100644 --- a/drivers/arm/smmu/smmu_v3.c +++ b/drivers/arm/smmu/smmu_v3.c @@ -87,6 +87,14 @@ int __init smmuv3_init(uintptr_t smmu_base) SMMU_ROOT_IDR0_ROOT_IMPL) == 0U) { WARN("Skip SMMU GPC configuration.\n"); } else {

•                   NOTICE("SMMU_ROOT_IDR0: %lx %x\n",
  

•                           smmu_base + SMMU_ROOT_IDR0,
  

•                           mmio_read_32(smmu_base + SMMU_ROOT_IDR0));
  

•                   NOTICE("SMMU_ROOT_IIDR: %lx %x\n",
  

•                           smmu_base + SMMU_ROOT_IIDR,
  

•                           mmio_read_32(smmu_base + SMMU_ROOT_IIDR));
  
  

and this gives as simulation output: NOTICE: SMMU_ROOT_IDR0: 2b420000 3 NOTICE: SMMU_ROOT_IIDR: 2b420008 43b

Can someone tell me the reason for this?

Sincerely, WANG Chenxu -- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org