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. 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 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).
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