cross-distro April 2017

cross-distro@lists.linaro.org

4 participants
2 discussions

by dann frazier

hey, I'm investigating enabling AArch32/Virt edk2 builds in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857858 I wanted to see if we can reach a consensus on what the pathname for these images should be, as these paths for other architectures have become hardcoded in upstream projects like OpenStack Nova and libvirt. These project currently expect to find the AArch64 images at: /usr/share/AAVMF/AAVMF_{CODE,VARS}.fd And, similarly, the x86-64 images at: /usr/share/ovmf/OVMF_{CODE,VARS}.fd I'm unaware of anyone shipping 32-bit x86 images. I propose: /usr/share/AAVMF/AAVMF32_{CODE,VARS}.fd -dann

6 years, 10 months

Fwd: [RFC PATCH] acpi/pci: mcfg: add quirk for Marvell Armada8k

by Ard Biesheuvel

Hello all, Please refer to the patch and the ACPI/arm64 maintainer's reply below if you are interested in understanding why the SolidRun MacchiatoBin board (an arm64 board based on the Marvell Armada 8040 SoC) cannot be fully supported in ACPI mode in the upstream kernel. The change itself is trivial, but it violates a policy regarding standards compliance when it comes to implementing the PCIe root complex. However, this is a very useful board when it comes to development involving secure and non-secure firmware, given that all the code it runs is open (ARM Trusted Firmware, U-Boot, UEFI). So perhaps it may be worth considering taking this as a downstream patch in the distros? -- Ard. Forwarded conversation Subject: [RFC PATCH] acpi/pci: mcfg: add quirk for Marvell Armada8k ------------------------ From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: 27 April 2017 at 14:17 To: leif.lindholm(a)linaro.org, graeme.gregory(a)linaro.org Cc: agraf(a)suse.de, mw(a)semihalf.com, yehuday(a)marvell.com, linaro-acpi(a)lists.linaro.org, lorenzo.pieralisi(a)arm.com, Ard Biesheuvel <ard.biesheuvel(a)linaro.org> This implements a quirk for the Marvell Armada80x0 running in ACPI mode, in which case the config space configuration is not 100% ECAM compatible. The issue with this SoC is that it only consists of a host bridge, and all type 0 configuration cycles are forwarded to the peer (i.e., the device in the slot), which will therefore appear at all device slots on bus 0. This can be fixed by reducing the IATU window size for bus 0, but due to CX_ATU_MIN_REGION_SIZE == 64KB (which is a synthesis-time configuration parameter of the IP block) the window producing type 0 config cycles will always produce two copies of the peer device. So add a quirk that specifies a config space accessor override, and override config space accesses to devices on bus 0 other than device 0. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- drivers/acpi/pci_mcfg.c | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/drivers/acpi/pci_mcfg.c b/drivers/acpi/pci_mcfg.c index 2944353253ed..7d68b3208043 100644 --- a/drivers/acpi/pci_mcfg.c +++ b/drivers/acpi/pci_mcfg.c @@ -49,6 +49,40 @@ struct mcfg_fixup { NULL, IORESOURCE_BUS) #define MCFG_BUS_ANY MCFG_BUS_RANGE(0x0, 0xff) +/* + * The Armada 8k uses Synopsys PCIe IP, which /can/ be configured at + * synthesis time to be ECAM compatible, by reducing the IATU minimum + * window size to 32 KB. This way, we can reduce the window that produces + * type 0 config cycles to only cover b/d 0/0, which will make the peer + * only appear once on bus 0. The rest of the ECAM region can be enabled + * to generate type 1 config cycles in an ECAM compliant manner, which + * makes the rest of the hierarchy accessible if the peer is a true + * bridge. + * + * Note that in this configuration, there is only a host bridge that + * translates memory accesses to PCI bus cycles, and given that there + * is only a single peer, there is no reason to model a pseudobridge + * on bus 0 and make the peer appear on bus 1. (This is how the various + * DT drivers for snps,dw-pcie compatible controllers are implemented.) + */ +static void __iomem *armada8k_pcie_ecam_map_bus(struct pci_bus *bus, + unsigned int devfn, + int where) +{ + if (bus->number == 0 && PCI_SLOT(devfn) > 0) + return NULL; + return pci_ecam_map_bus(bus, devfn, where); +} + +static struct pci_ecam_ops armada8k_pcie_ecam_ops = { + .bus_shift = 20, + .pci_ops = { + .map_bus = armada8k_pcie_ecam_map_bus, + .read = pci_generic_config_read, + .write = pci_generic_config_write, + } +}; + static struct mcfg_fixup mcfg_quirks[] = { /* { OEM_ID, OEM_TABLE_ID, REV, SEGMENT, BUS_RANGE, ops, cfgres }, */ @@ -133,6 +167,8 @@ static struct mcfg_fixup mcfg_quirks[] = { XGENE_V2_ECAM_MCFG(4, 0), XGENE_V2_ECAM_MCFG(4, 1), XGENE_V2_ECAM_MCFG(4, 2), + + { "MVEBU ", "ARMADA8K", 0, 0, MCFG_BUS_ANY, &armada8k_pcie_ecam_ops }, }; static char mcfg_oem_id[ACPI_OEM_ID_SIZE]; -- 2.9.3 ---------- From: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> Date: 28 April 2017 at 17:14 To: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Cc: leif.lindholm(a)linaro.org, graeme.gregory(a)linaro.org, agraf(a)suse.de, mw(a)semihalf.com, yehuday(a)marvell.com, linaro-acpi(a)lists.linaro.org On Thu, Apr 27, 2017 at 02:17:32PM +0100, Ard Biesheuvel wrote: > This implements a quirk for the Marvell Armada80x0 running in ACPI mode, > in which case the config space configuration is not 100% ECAM compatible. Too bad, I am not keen on merging any more ECAM quirks, we have been very clear about this and it is in our best interest to keep this code out of tree - we will bootstrap ACPI PCI systems on ECAM HW/FW compliant systems, that's it (I understand it is painful but it is necessary). Thanks, Lorenzo

7 years, 1 month

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro April 2017