From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=40.107.5.43; helo=eur03-ve1-obe.outbound.protection.outlook.com; envelope-from=supreeth.venkatesh@arm.com; receiver=edk2-devel@lists.01.org Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50043.outbound.protection.outlook.com [40.107.5.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 8381F22742A81 for ; Wed, 11 Apr 2018 08:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RWSupvDSHacf8h9ImrZ3saSNf7LlVAsHLLU0p+RRLpk=; b=CakgWzZbT8eU6Ri1uNaytZxKL8Bt6M44lhLo7BxiZKNrCPTqPNq0mC/MieOM28zpXv2gSwQhypKm+/0OnfjPhhSKjD4T//HoT7+7Egmrnj7DCVbb3IhQU5rGYQFbl8wdYulnRF5V0unUvMxF3nSvFzo/I2nikcQ27oCTax5KMR4= Received: from AM4PR0802MB2306.eurprd08.prod.outlook.com (10.172.218.15) by AM4PR0802MB2241.eurprd08.prod.outlook.com (10.172.217.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.675.10; Wed, 11 Apr 2018 15:34:30 +0000 Received: from AM4PR0802MB2306.eurprd08.prod.outlook.com ([fe80::b0b8:5932:74e7:ef8a]) by AM4PR0802MB2306.eurprd08.prod.outlook.com ([fe80::b0b8:5932:74e7:ef8a%4]) with mapi id 15.20.0675.009; Wed, 11 Apr 2018 15:34:30 +0000 From: Supreeth Venkatesh To: Laszlo Ersek , Steve Capper , "edk2-devel@lists.01.org" CC: Ard Biesheuvel , Leif Lindholm , Nariman Poushin Thread-Topic: [edk2] Boot failure for ArmVExpress-FVP-AArch64, CpuArch protocol does not appear to be registered Thread-Index: AQHT0YAbLD35yzwEE06toRiKImsFiKP7fXoAgAAxCeA= Date: Wed, 11 Apr 2018 15:34:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Supreeth.Venkatesh@arm.com; x-originating-ip: [217.140.111.135] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0802MB2241; 7:JuldLv/eSni27io9dokXh9lizQDXdekqGHb2fsJXX0Jd5Sgyn4KvFWJprHzU+5WGq+TrGt1RpklUZdZauHbCpKSgb7tzHkpn7L3InJZ8JnG70zv8eQQS1PtPr3WJBfcxoQ8lKV4Sd7lHtJ6cxwKlpY4JZwYirSNT4FouMRbfSRsHWmfvSxTg12HWqkxRjvtgo+b5LHUGfFMWQi3Msr6tfeeDUevUhNtyCWohWkdFcRaKA9gJZkVw7NQhHV/Nk8AK x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603328)(7153060)(7193020); SRVR:AM4PR0802MB2241; x-ms-traffictypediagnostic: AM4PR0802MB2241: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(15185016700835)(788757137089)(162533806227266); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231221)(944501327)(52105095)(3002001)(10201501046)(6055026)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR0802MB2241; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0802MB2241; x-forefront-prvs: 0639027A9E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(39860400002)(39380400002)(376002)(13464003)(31014005)(199004)(377424004)(189003)(40434004)(5890100001)(11346002)(72206003)(6306002)(486006)(6246003)(478600001)(9686003)(2501003)(14454004)(8936002)(6436002)(55016002)(5250100002)(6116002)(25786009)(3846002)(575784001)(102836004)(86362001)(6506007)(81166006)(229853002)(53546011)(2906002)(81156014)(5660300001)(53936002)(446003)(68736007)(476003)(4326008)(966005)(99286004)(54906003)(7696005)(316002)(66066001)(59450400001)(305945005)(74316002)(7736002)(2900100001)(110136005)(8676002)(26005)(3660700001)(105586002)(186003)(33656002)(76176011)(97736004)(3280700002)(106356001)(87944003)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0802MB2241; H:AM4PR0802MB2306.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 4dYwEPULodRfFoJyfvGVVrsVGRg9+BDDkzBIvuf28rAnZGJ7Y9Hkg8F6CWABTuC+96dlkPWknutZF4bUFemwk/w5aJLGG7ZtjE/rYTrlXL5dg/Qn3gqFsIyZbJj9ROdV3qBcdwS/aTwLyPArNzV0gf68pPlwzGPCu0It4XekTKjqbSEUGlN2Rflc939m/pldho1VYxQ2P0H9770ZJNU3zzmZVBxV1UJtcQ5QnwNJoQBVTFHq15im7hWQ4hsTjc0pFHcntDzOe2/3gou8AH50gtJaeDudKPQYnvA+DIZDaoWO4kqsjFL258QMIdGoFLtAwdvslt/bUqF8nPTMASwkCpBOYpKkYgVBqVmexsCjoO3QttRBqKl7DWdzarf0+xoTx6o6HnFwhYQw4i7oTQxXK0/fhFoMEEMMqSdfvPgQNw8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 5ec83f7b-f5a8-4360-fd66-08d59fc1b812 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ec83f7b-f5a8-4360-fd66-08d59fc1b812 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2018 15:34:30.7612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0802MB2241 Subject: Re: Boot failure for ArmVExpress-FVP-AArch64, CpuArch protocol does not appear to be registered X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2018 15:34:39 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Laszlo/Steve, I ran into the same problem on ArmVExpress-FVP-AArch64 while running manage= ment mode. I have fixed this problem in this patch by reordering driver load order her= e: https://lists.01.org/pipermail/edk2-devel/2018-April/023550.html Not sure whether Leif/Ard/Laszlo agree with this. Thanks, Supreeth -----Original Message----- From: edk2-devel On Behalf Of Laszlo Erse= k Sent: Wednesday, April 11, 2018 7:26 AM To: Steve Capper ; edk2-devel@lists.01.org Cc: Ard Biesheuvel ; Leif Lindholm ; Nariman Poushin Subject: Re: [edk2] Boot failure for ArmVExpress-FVP-AArch64, CpuArch proto= col does not appear to be registered Hi Steve, On 04/11/18 12:30, Steve Capper wrote: > Hello, > I am trying to debug a boot problem for a recent build of EDK2 in an > Arm FVP model. > > I built EDK2 from the following branches: > Edk2: a146c532c754106431b063fec9985a838afd82be > Edk2-platforms: e74f53df8b18e4aed0c9df0942ce0c30f78a68e2 > > Toolchain: Debian Stretch latest (though I have also tried Linaro=19s > GCC 5 latest). > > Build command: > GCC5_AARCH64_PREFIX=3Daarch64-linux-gnu- build -a AARCH64 -t GCC5 -b > DEBUG -p Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc > > The boot log can be found in the attached file. I *think* this is due > to the Cpu Arch protocol not actually being ready when > CoreConvertSpace is called by the SetMemoryAttributes from the > NorFlash code. > > I have found that this code path fails: > https://github.com/tianocore/edk2/blob/a146c532c754106431b063fec9985a8 > 38afd82be/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L893 > > The only modification I have made is to edk2-platforms to get more > debug output (PcdDebugPrintErrorLevel). > > Unfortunately, I'm not sure how to fix this? This is a bit of a problem. The gDS->SetMemorySpaceAttributes() DXE service is allowed to fail if the C= PU architectural protocol has not been installed yet. This is documented in= the Platform Init spec (although riddled by a few typos -- EFI_NOT_AVAILAB= LE_YET is documented under the preceding GetMemorySpaceDescriptor() section, and not in the correct SetMemorySpaceAttributes() section). The usual solution for DXE drivers is to add an explicit dependency on gEfi= CpuArchProtocolGuid to the DEPEX section in the INF file. You can see an ex= ample in commit f9a8be423cdd ("ArmVirtualizationPkg/PciHostBridgeDxe: MMIO aperture must not be uncached= ", 2015-02-23). And that's where the issue is. If you check the [Depex] section in "ArmPlat= formPkg/Drivers/NorFlashDxe/NorFlashDxe.inf", you find > [Depex] > # > # NorFlashDxe must be loaded before VariableRuntimeDxe in case empty fl= ash needs populating with default values > # > BEFORE gVariableRuntimeDxeFileGuid Why is BEFORE technically an issue here? Because, it cannot be combined wit= h other depex opcodes. From the PI spec: > If this opcode is present in a dependency expression, it must be the > first and only opcode in the expression. If is appears in any other > location in the dependency expression, then the dependency expression > is evaluated to FALSE. So we can't simply combine the existent BEFORE depex with "AND gEfiCpuArchP= rotocolGuid", like you see in the commit f9a8be423cdd example above. Now, more to the point, a "BEFORE" depex is *always* a hack. From the PI spec: > This opcode tells the DXE Dispatcher that the DXE driver that is > associated with this dependency expression must be dispatched just > before the DXE driver with the file name specified by GUID. This means > that as soon as the dependency expression for the DXE driver specified > by GUID evaluates to TRUE, then this DXE driver must be placed in the > dispatch queue just before the DXE driver with the file name specified > by GUID. Sometimes there's really no way around such a hack, to express an inter-mod= ule dependency, but even then, there is a better way to implement it. Namel= y, - a custom protocol GUID can be invented, - the pre-requisite module can install a NULL protocol interface with that GUID, - and - either the protocol GUID can be added directly to the [depex] section of the dependent module (if the latter module is under the platform's control), - or the platform DSC file can hook a NULL-class library instance into the dependent module, such that the lib instance makes the dependent module *inherit* a [depex] on the protocol GUID. In other words, if we want to order the dispatch of a platform-independent = module (that lives in another Package), due to platform-specific circumstan= ces, behind another module that our platform owns, then we can change our p= latform DSC to "imbue" the module with a dependency on a custom protocol GU= ID. We can then install that NULL protocol in our own module. Under this sc= heme the usual dependency resolution will order things the right way, and a= ll the depex-es remain composable with other GUIDs. OK -- so *should* we rewrite this BEFORE depex, like described above? I don= 't think so. In my opinion, the *idea* of this dependency is wrong. The BEFORE depex was introduced in commit 6acb379fbcf8 ("ArmPlatformPkg/CTA9x4: Remove Variable Storage FD file from FDF", 2011-03= -31), and the idea there was to replace the build-time pre-formatting of th= e flash variable store with runtime formatting. You might ask why this repl= acement needed an explicit ordering hint between drivers (i.e. why any DEPE= Xes had to be touched at all). Here's why: - For *writing* non-volatile UEFI variables, a platform-independent protocol dependency chain already exists. At the least abstract level, we have the FVB (firmware volume block) protocol service, e.g. NorFlashDxe. At the next level, we have the platform-independent FTW (fault tolerant write) driver. Finally, at the top (the most abstract level), we have the non-volatile variable write service / driver. - However, for *reading* non-volatile UEFI variables, no such dependency chain exists. The variable driver (the top level from the previous bullet) will just go ahead and read various headers from the flash chip. If those headers are not correctly formatted, the variable driver blows up and the platform will not boot. To solve this issue, platform FDF files usually pre-format a variable store template at build-time, which will at once satisfy the "read-side startup" of the variable driver. Unfortunately, this requires FDF files to contain various ugly hexdumps, an= d people are tempted to replace those with runtime formatting of the varsto= re headers. In turn though, they have to employ hacks for ordering the vari= able driver behind their runtime formatting. Hence the BEFORE depex. :( So, what can we do? Given that NorFlashDxe is used by several platforms, th= e ugly BEFORE depex should be removed. Once BEFORE is removed, you can simp= ly add "gEfiCpuArchProtocolGuid", and then the current issue will be solved= . But, what shall take the place of BEFORE? Using ArmVirtQemu as an example platform, the answer is "nothing", because = ArmVirtQemu already pre-formats the varstore template -- please see "ArmVir= tPkg/VarStore.fdf.inc". For all other platforms that don't do this -- and I= don't see "Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf" doing it = --, there are two choices: - build a varstore template in *all* of the platform FDF files where the platform DSC file includes the NorFlashDxe driver -- in this case, the BEFORE needs no replacement, it can simply be dropped, - or implement the custom NULL protocol trick that I described above. Platforms that don't actually *depend* on this trick, such as ArmVirtQemu, will simply ignore the new protocol instance in the protocol database. For the second option, there are several examples under OvmfPkg and ArmVirt= Pkg. One is: - "MdeModulePkg/Include/Guid/PlatformHasAcpi.h" defines the custom "gEdkiiPlatformHasAcpiGuid". - "ArmVirtPkg/ArmVirtQemu.dsc" includes the "ArmVirtPkg/PlatformHasAcpiDtDxe" platform driver, which installs a NULL protocol interface with the above custom GUID under certain circumstances. - "EmbeddedPkg/Library/PlatformHasAcpiLib" is a library instance that does nothing; it just has an empty constructor function, and a dependency on the GUID. - "ArmVirtPkg/ArmVirt.dsc.inc" hooks the library into "MdeModulePkg/Universal/Acpi/AcpiTableDxe", imbuing the latter with a dependency on the protocol GUID. As a result, "MdeModulePkg/Universal/Acpi/AcpiTableDxe" will not be dispatc= hed until (and, unless!) "ArmVirtPkg/PlatformHasAcpiDtDxe" installs the GUID. If the GUID is never installed, then "MdeModulePkg/Unive= rsal/Acpi/AcpiTableDxe" will never be dispatched. Summary: (1) introduce a custom GUID for "NorFlashDxe has formatted the variable store headers for the variable driver to read"; (2) install the GUID in NorFlashDxe once it's done verifying and/or formatting the headers; (3) introduce a custom library instance with an empty constructor function, and a DEPEX on the GUID; (4) hook the library instance into "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf" in all the platform DSC files where the platform build does not pre-format a varstore template in the FDF file; (5) replace the BEFORE depex with gEfiCpuArchProtocolGuid. Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you.