From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web08.13241.1664902703584278729 for ; Tue, 04 Oct 2022 09:58:23 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=CSs1Ozhn; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: athierry@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664902702; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uiUDXRCiqcy9Se3EV78V9ePlAA8FicqvDeTUKMjTVEA=; b=CSs1OzhnXX+nrtOo5WM7Xd83WBGpO6iQIFHC4dmebEhFEdnS1Tfs7CykZ1RDuS/4/pwHVp /1nPas0ldlvDXJwHdKFgX3I4RcqepCV21F1B9SooG0NGfHy7cq3I4FzecJry2/bH262eYW 05Q0BAkRBpppAZ3vNcqMvBsVZSo+ffc= Received: from mail-oo1-f71.google.com (mail-oo1-f71.google.com [209.85.161.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-63-0zQvG_BDM0eljEjfURRV3Q-1; Tue, 04 Oct 2022 12:58:21 -0400 X-MC-Unique: 0zQvG_BDM0eljEjfURRV3Q-1 Received: by mail-oo1-f71.google.com with SMTP id e9-20020a4a9b49000000b00475ea4651fcso7822080ook.17 for ; Tue, 04 Oct 2022 09:58:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=uiUDXRCiqcy9Se3EV78V9ePlAA8FicqvDeTUKMjTVEA=; b=QpqIS8jeIfHzF31UnL05SLQWSpbBQ5+UcDiY6ecqVo4DUcpzjPhUiXsd0xh/+9Orfh QP4w6j5xYFu4vBt1DOdziiaaYdv1F4+XzumByk+LWJFOA1cVsCCjivMu35Gl6R+q7Qi2 qAv740QEyQqnEueiLAo8b90vHZyksIYTLSyGg1nV0oJ+TMJ3XI78+sQ1GS41QL/Q4DKd 6b9bccB6DhdrKa4M8fuGAuptKeis/d5JEQzpH0jiTmuPfQ0BWR2/H+JwauuiSUwbKbr9 QoAcenR/UgB00nzySAepiCrnSIFEY48GyyLIsd3cnhstZNz83MEh6frGzV1AOXI+yqei 49eQ== X-Gm-Message-State: ACrzQf3E+91rqe+f37tsUDQg5i7CqOQ1JSZRi5fZg8OI0970reBjuLMh vCA0/Py4PK8ObqWRRo2QNW8rjyjc4LXAKATiDGHtowL9dv54dtuQELIToSJDFbzghfsJ0NYCyVl ajRGe2vRuP5zzAw== X-Received: by 2002:a05:6870:2381:b0:12c:8a51:47c6 with SMTP id e1-20020a056870238100b0012c8a5147c6mr399567oap.12.1664902701047; Tue, 04 Oct 2022 09:58:21 -0700 (PDT) X-Google-Smtp-Source: AMsMyM40BO144C8fstkJ2n8YajGFMSCrNEa1O6ix4chL9VHBO3S0dv5Q/MvRcWIYH2ix2zyuwDExBQ== X-Received: by 2002:a05:6870:2381:b0:12c:8a51:47c6 with SMTP id e1-20020a056870238100b0012c8a5147c6mr399556oap.12.1664902700842; Tue, 04 Oct 2022 09:58:20 -0700 (PDT) Return-Path: Received: from fedora (modemcable149.19-202-24.mc.videotron.ca. [24.202.19.149]) by smtp.gmail.com with ESMTPSA id d1-20020a056871040100b0010e73e252b8sm3899739oag.6.2022.10.04.09.58.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Oct 2022 09:58:20 -0700 (PDT) Date: Tue, 4 Oct 2022 12:58:18 -0400 From: "Adrien Thierry" To: Jeremy Linton Cc: Ard Biesheuvel , Leif Lindholm , devel@edk2.groups.io Subject: Re: [edk2-platforms PATCH 0/2] Platform/RaspberryPi: SyncPcie() fixes Message-ID: References: <20220929195335.61495-1-athierry@redhat.com> <8594b186-d1b6-052c-7bcc-6e0d81ddc313@arm.com> MIME-Version: 1.0 In-Reply-To: <8594b186-d1b6-052c-7bcc-6e0d81ddc313@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jeremy, > That is unfortunate. Which revision/how much RAM? Can you paste the > before/after kernel/pci output like: My RPi4 is a 8GB revision d03114. Here's the pci output before applying your ranges tweak: [ 3.697773] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges: [ 3.706020] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff] [ 3.716271] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x063fffffff -> 0x00c0000000 [ 3.726229] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x00bfffffff -> 0x0000000000 [ 3.737357] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00 [ 3.743891] pci_bus 0000:00: root bus resource [bus 00-ff] [ 3.749530] pci_bus 0000:00: root bus resource [mem 0x600000000-0x63fffffff] (bus address [0xc0000000-0xffffffff]) And after: [ 3.781758] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges: [ 3.789907] brcm-pcie fd500000.pcie: No bus range found for /scb/pcie@7d500000, using [bus 00-ff] [ 3.800230] brcm-pcie fd500000.pcie: MEM 0x0600000000..0x0603ffffff -> 0x00f8000000 [ 3.809721] brcm-pcie fd500000.pcie: IB MEM 0x0000000000..0x00bfffffff -> 0x0000000000 [ 3.828359] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00 [ 3.835812] pci_bus 0000:00: root bus resource [bus 00-ff] [ 3.845651] pci_bus 0000:00: root bus resource [mem 0x600000000-0x603ffffff] (bus address [0xf8000000-0xfbffffff]) I tested with the latest binaries and DT from https://github.com/raspberrypi/firmware (master), same issue with the USB. Here's the firmware version I'm running (got that from Raspbian), are you using a different/more recent one? $ vcgencmd version Aug 26 2022 14:03:16 Copyright (c) 2012 Broadcom version 102f1e848393c2112206fadffaaf86db04e98326 (clean) (release) (start) > So the first patch makes sense, but I think it should probably be > checking both DT property names (pci0,0 and pci1,0) since we probably > want maximum compatibility with differing DT's the user might swap in, > and the upstream linux change which changes the node from 1,0 to 0,0 is > from august of last year, so not old at all.. Sounds good, I can submit a v2 handling both variants > The second one, I'm less sure about, since the primary thing your > changing (AFAIK) is whether the XHCI BIOS handoff is being checked, and > since EDK2 supports the hand-off and Linux doesn't throw the XHCI bios > failure message I think we actually want to leave that in place. If you > have debugging turned on, the XHCI/LegacyBios ownership control is the > message you see during exit boot services that says > "XhciClearBiosOwnership: called to clear BIOS ownership". I suspect the > kernel patch is yet another case of "UBOOT and/or the pi foundation > firmware is broken so we fixed the kernel" > > Do you see a difference with/without the second patch? Thanks for explaining this. I can't see a difference with/without the second patch. AFAICT the hand-off check seems to execute without issue on Linux. It makes sense to me to drop this second patch since the hand-off is supported by EDK2. Adrien