> Subject: Re: [PATCH V5 5/5] configs: imx8qm: add configuration files
>
> On 27.09.20 03:13, Peng Fan wrote:
> >> Subject: Re: [PATCH V5 5/5] configs: imx8qm: add configuration files
> >>
> >> On 25.09.20 09:55, Jan Kiszka wrote:
> >>> On 25.09.20 09:30, Peng Fan wrote:
> >>>>> Subject: Re: [PATCH V5 5/5] configs: imx8qm: add configuration
> >>>>> files
> >>>>>
> >>>>> On 22.09.20 08:45, Alice Guo wrote:
> >>>>>> + .platform_info = {
> >>>>>> + /*
> >>>>>> + * .pci_mmconfig_base is fixed; if you change it,
> >>>>>> + * update the value in mach.h
> >>>>>> + * (PCI_CFG_BASE) and regenerate the inmate
> >> library
> >>>>>> + */
> >>>>>> + .pci_mmconfig_base = 0xfd700000,
> >>>>>> + .pci_mmconfig_end_bus = 0x0,
> >>>>>> + .pci_is_virtual = 1,
> >>>>>> + .pci_domain = 0,
> >>>>>> +
> >>>>>> + .iommu_units = {
> >>>>>> + {
> >>>>>> + .type =
> >> JAILHOUSE_IOMMU_ARM_MMU500,
> >>>>>> + .base = 0x51400000,
> >>>>>> + .size = 0x40000,
> >>>>>> + .arm_mmu500.sid_mask = 0x7f80,
> >>>>>
> >>>>> How is the sid_mask of a platform retrieved? Can this be derived
> >>>>> from information in a normal device tree?
> >>>>
> >>>> This could be get from device tree, to i.MX8QM, iommus = <&smmu
> >>>> 0x12
> >>>> 0x7f80>;
> >>>> 0x12 is sid, 0x7f80 is sid mask.
> >>>>
> >>>> Sid mask is use to get the extract the exact sid from SOC internal
> >>>> BUS, You could think as below:
> >>>> Bus signal & 0x7f80 = 0x12
> >>>>
> >>>
> >>> Understood - but there seems to be nothing like this on zynqmp, so I
> >>> tried both 0 and ~0, so far without any sids assigned to the cell. I
> >>> would have expected that something breaks then, MMC e.g. There is no
> >>> error reporting in the SMMU code so, thus I will simply see stuck
> >>> DMA requests?
> >>>
> >>> I guess I need to study that SoC to understand what can be expected
> >>> there, i.e. which devices are under SMMU regime. Unfortunately, I do
> >>> not have the MX8QM running here yet to check your setup.
> >>>
> >>
> >> I do understand now how the 14-bit IDs on the zynqmp look like and
> >> that they cover all units, including the SD interfaces that I'm
> >> currently using for mmc and wifi. But leaving those stream IDs out
> generates no apparent error.
> >>
> >> The SMMU seems to initialize fine (I've already cleaned up the output):
> >>
> >> [...]
> >> Initializing unit: ARM SMMU
> >> ARM MMU500 at 0xfd800000 with:
> >> stream matching with 48 SMR groups
> >> 16 context banks (0 stage 2 only)
> >> supported page sizes: 0x61311000
> >> stage-2: 40-bit IPA -> 48-bit PA
> >> Initializing unit: PVU IOMMU
> >> Initializing unit: PCI
> >> Adding virtual PCI device 00:00.0 to cell "Ultra96"
> >> Adding virtual PCI device 00:01.0 to cell "Ultra96"
> >> Page pool usage after late setup: mem 63/991, remap 37/131072
> >> Activating hypervisor
> >>
> >> But that's it. DMA is still happily flowing. What could that mean?
> >> What do you get on the imx8qm when dropping the sids from the root cell?
> >
> > I am not sure how zynqmp use SMMU and how their bus signal looks like.
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> xilinx.com%2Fsupport%2Fdocumentation%2Fuser_guides%2Fug1085-zynq-ult
> rascale-trm.pdf&data=02%7C01%7Cpeng.fan%40nxp.com%7C7d10728c
> 715d4d712a0908d862d2bebb%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C1%7C637368004563253765&sdata=kD0%2BEz%2Bavbv6YUM0hvx
> kcSoDGqZarTmIngdHLVbehcg%3D&reserved=0,
> Figure 1-1: There are 6 Translation Buffer Units (TBUs), managed by the
> Translation Control Unit. Those TBUs seems to intercept all interesting DMA
> transfers, including the SDIOs I was testing.
>
> >
> > To i.MX8QM, if the IP DMA has SID, but without SMMU context
> > programmed, the smmu will bypass the translation per the configuration
> > is bypass in smmu driver, so if dropping the sids from the root cell, it
> > will
> work well, no error.
> > Same to inmate cell.
>
> If I take your configs/arm64/imx8qm.c, remove SID 0x13 e.g., will DMA
> requests from that source be blocked with the current setup?
No.
And if I remove
> all SIDs, will nothing work? That would be my expectation. If that is not the
> case, we have an issue. How to isolate a device from a cell or the complete
> system then?
Ok, then we need to think of change s2cr_init_val to default FAULT or translate.
>
> >
> > You could try to not bypass SMMU transition in smmu driver, then the
> > system might not work well.
>
> Where is this bypass controlled? In the SMMU settings? Or is that
> platform-specific?
S2CR_TYPE_BYPASS, smmu settings currently.
Thanks,
Peng.
>
> Jan
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jailhouse-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/AM5PR0402MB2756949C49DAC709F669D7F388350%40AM5PR0402MB2756.eurprd04.prod.outlook.com.
