diff options
author | Tom Rini <trini@konsulko.com> | 2020-10-29 16:10:24 +0300 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2020-10-29 16:10:24 +0300 |
commit | eca57cafa521345b2fc71616ae47245598dad53d (patch) | |
tree | 04bb2c22f4defdcfdb251cb31363276a8e7e34a7 /arch/arm/cpu/armv8 | |
parent | 81a659e10a10020cfb03abd4794103194add1f3a (diff) | |
parent | 78a8bca5e4971e4be0c3ba438f7386462507ad6a (diff) | |
download | u-boot-eca57cafa521345b2fc71616ae47245598dad53d.tar.xz |
Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq
- Bug fixes and updates on vid, ls1088a lx2160a and other layerscape
platforms.
- Add optee_rpmb support for LX2 & Kontron sl28 support
Diffstat (limited to 'arch/arm/cpu/armv8')
-rw-r--r-- | arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 16 | ||||
-rw-r--r-- | arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra | 67 | ||||
-rw-r--r-- | arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 41 |
3 files changed, 115 insertions, 9 deletions
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c index e610528544..596b88d3e2 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c @@ -1147,15 +1147,15 @@ int arch_early_init_r(void) * EC*_PMUX(rgmii) bits in RCW. * e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from * serdes bits and as RGMII via EC1_PMUX/EC2_PMUX bits - * Now if a dpmac is enabled by serdes bits then it takes precedence - * over EC*_PMUX bits. i.e. in LX2160A if we select serdes protocol - * that configures dpmac17 as SGMII and set the EC1_PMUX as RGMII, - * then the dpmac is SGMII and not RGMII. + * Now if a dpmac is enabled as RGMII through ECx_PMUX then it takes + * precedence over SerDes protocol. i.e. in LX2160A if we select serdes + * protocol that configures dpmac17 as SGMII and set the EC1_PMUX as + * RGMII, then the dpmac is RGMII and not SGMII. * - * Therefore, move the fsl_rgmii_init after fsl_serdes_init. in - * fsl_rgmii_init function of SOC, we will check if the dpmac is enabled - * or not? if it is (fsl_serdes_init has already enabled the dpmac), - * then don't enable it. + * Therefore, even thought fsl_rgmii_init is after fsl_serdes_init + * function of SOC, the dpmac will be enabled as RGMII even if it was + * also enabled before as SGMII. If ECx_PMUX is not configured for + * RGMII, DPMAC will remain configured as SGMII from fsl_serdes_init(). */ fsl_rgmii_init(); #endif diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra new file mode 100644 index 0000000000..43db4d8e94 --- /dev/null +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.pci_iommu_extra @@ -0,0 +1,67 @@ +# +# Copyright 2020 NXP +# +# SPDX-License-Identifier: GPL-2.0+ +# + +Specifying extra IOMMU mappings for PCI controllers + +This feature can be enabled through the PCI_IOMMU_EXTRA_MAPPINGS Kconfig option. + +The "pci_iommu_extra" env var or "pci-iommu-extra" device tree property (to be +used for example in more static scenarios such as hardwired PCI endpoints that +get initialized later in the system setup) allows two things: + - for a SRIOV capable PCI EP identified by its B.D.F specify the maximum number + of VFs that will ever be created for it + - for hot-plug case, specify the B.D.F with which the device will show up on + the PCI bus + +The env var consists of a list of <bdf>,<action> pairs for a certain pci bus +identified by its controller's base register address, as defined in the "reg" +property in the device tree. + +pci_iommu_extra = pci@<addr1>,<bdf>,<action>,<bdf>,<action>, + pci@<addr2>,<bdf>,<action>,<bdf>,<action>,... + +where: + <addr> is the base register address of the pci controller for which the + subsequent <bdf>,<action> pairs apply + <bdf> identifies to which B.D.F the action applies to + <action> can be: + - "vfs=<number>" to specify that for the PCI EP identified previously by + the <bdf> to include mappings for <number> of VFs. + The variant "noari_vfs=<number>" is available to disable taking ARI into + account. + - "hp" to specify that on this <bdf> there will be a hot-plugged device so + it needs a mapping +The device tree property must be placed under the correct pci controller node +and only the bdf and action pairs need to be specified, like this: + +pci-iommu-extra = "<bdf>,<action>,<bdf>,<action>,..."; + +Note: the env var has priority over the device tree property. + +For example, given this configuration on bus 6: + +=> pci 6 +Scanning PCI devices on bus 6 +BusDevFun VendorId DeviceId Device Class Sub-Class +_____________________________________________________________ +06.00.00 0x8086 0x1572 Network controller 0x00 +06.00.01 0x8086 0x1572 Network controller 0x00 + +The following u-boot env var will create iommu mappings for 3 VFs for each PF: + +=> setenv pci_iommu_extra pci@0x3800000,6.0.0,vfs=3,6.0.1,vfs=3 + +For the device tree case, this would be specified like this: + +pci-iommu-extra = "6.0.0,vfs=3,6.0.1,vfs=3"; + +To add an iommu mapping for a hot-plugged device, please see following example: + +=> setenv pci_iommu_extra pci@0x3800000,2.16.0,hp + +For the device tree case, this would be specified like this: + +pci-iommu-extra = "2.16.0,hp"; diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c index 7400b2cf29..6d3391db3b 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c @@ -437,13 +437,52 @@ __weak void fdt_fixup_ecam(void *blob) } #endif +/* + * If it is a non-E part the crypto is disabled on the following SoCs: + * - LS1043A + * - LS1088A + * - LS2080A + * - LS2088A + * and their personalities. + * + * On all other SoCs just the export-controlled ciphers are disabled, that + * means that the following is still working: + * - hashing (using MDHA - message digest hash accelerator) + * - random number generation (using RNG4) + * - cyclic redundancy checking (using CRCA) + * - runtime integrity checker (RTIC) + * + * The linux driver will figure out what is available and what is not. + * Therefore, we just remove the crypto node on the SoCs which have no crypto + * support at all. + */ +static bool crypto_is_disabled(unsigned int svr) +{ + if (IS_E_PROCESSOR(svr)) + return false; + + if (IS_SVR_DEV(svr, SVR_DEV(SVR_LS1043A))) + return true; + + if (IS_SVR_DEV(svr, SVR_DEV(SVR_LS1088A))) + return true; + + if (IS_SVR_DEV(svr, SVR_DEV(SVR_LS2080A))) + return true; + + if (IS_SVR_DEV(svr, SVR_DEV(SVR_LS2088A))) + return true; + + return false; +} + void ft_cpu_setup(void *blob, struct bd_info *bd) { struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR); unsigned int svr = gur_in32(&gur->svr); /* delete crypto node if not on an E-processor */ - if (!IS_E_PROCESSOR(svr)) + if (crypto_is_disabled(svr)) fdt_fixup_crypto_node(blob, 0); #if CONFIG_SYS_FSL_SEC_COMPAT >= 4 else { |