From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8E782C433EF for ; Tue, 25 Jan 2022 13:34:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HB3p8SWZv+JEe+g2uCG0yTmMEbxwbKog7JqGbKLR0xk=; b=WrZbhqveWJJyy2 abqgBvoze4DxpeX9dynzaHtWcbsmxzgJcfIoGHclAsjc+1eEXikwXij5tXO5Rq3+o8xtfwTztbup1 xQZ4hDAuGsG9DXeXWzesCupKkVg8x0ZUklzU/McIdcNuuEkAs6BJqvQs2sx6MZCidc1SBRwopa7QN ZUgZ+Aady9ap0Y3FCRD0Vql7ZthzFpfHojMrNhFtNnhn3xM5gcLbNElqmT39OqUcZsjvslFvcyXIv /8XH9xPkiJTRae+9djhaZnYJwFHMWxCFOnXCrjnwVFtIK7gAVtX/q6s8DbteeVtR/hMQkHXXf5oJc NdibvDcz8bBcnUUjQaqw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCLwS-007w9h-Sg; Tue, 25 Jan 2022 13:33:00 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCLwP-007w8j-7P for linux-arm-kernel@lists.infradead.org; Tue, 25 Jan 2022 13:32:59 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1111FD6E; Tue, 25 Jan 2022 05:32:55 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.1.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E46873F7D8; Tue, 25 Jan 2022 05:32:53 -0800 (PST) Date: Tue, 25 Jan 2022 13:32:48 +0000 From: Mark Rutland To: Andre Przywara Cc: linux-arm-kernel@lists.infradead.org, Jaxson.Han@arm.com, robin.murphy@arm.com, vladimir.murzin@arm.com, Wei.Chen@arm.com Subject: Re: [bootwrapper PATCH v2 06/13] aarch64: initialize SCTLR_ELx for the boot-wrapper Message-ID: References: <20220114105653.3003399-1-mark.rutland@arm.com> <20220114105653.3003399-7-mark.rutland@arm.com> <20220114181247.7b366f45@donnerap.cambridge.arm.com> <20220117121557.GA87485@C02TD0UTHF1T.local> <20220117130554.GB87485@C02TD0UTHF1T.local> <20220118123741.5f367d1f@donnerap.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220118123741.5f367d1f@donnerap.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220125_053257_383662_7F678980 X-CRM114-Status: GOOD ( 43.35 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jan 18, 2022 at 12:37:41PM +0000, Andre Przywara wrote: > On Mon, 17 Jan 2022 13:05:54 +0000 > Mark Rutland wrote: > > Hi Mark, > > > On Mon, Jan 17, 2022 at 12:15:57PM +0000, Mark Rutland wrote: > > > On Fri, Jan 14, 2022 at 06:12:47PM +0000, Andre Przywara wrote: > > > > On Fri, 14 Jan 2022 10:56:46 +0000 > > > > Mark Rutland wrote: > > > > > > > > Hi Mark, > > > > > > Hi Andre, > > > > > > > + > > > > > +#define SCTLR_EL1_RES1 (BIT(29) | BIT(28) | BIT(23) | BIT(22) | \ > > > > > + BIT(11) | BIT(8) | BIT(7) | BIT(4)) > > > > > > > -#define SCTLR_EL1_RES1 (3 << 28 | 3 << 22 | 1 << 11) > > > > > > > > > > #ifdef KERNEL_32 > > > > > /* 32-bit kernel decompressor uses CP15 barriers */ > > > > > #define SCTLR_EL1_KERNEL (SCTLR_EL1_RES1 | SCTLR_EL1_CP15BEN) > > > > > > > > So I wonder if this actually works? The ARMv7 version of SCTLR > > > > differs in some bits from both the ARMv8 AArch32 version and more > > > > importantly the AArch64 version. > > > > > > I had troubles the other day running the > > > > arm32 Linux kernel decompressor with some ARMv8 SCTLR_EL1 reset value. The > > > > decompressor code does only read-modify-write of SCTLR (probably to > > > > cover multiple architecture revisions), so some bits might stay wrong. In > > > > particular I think having bits 28 and 29 set caused problems. > > > > By looking at the ARMv7 ARM and with experimentation I came up > > > > with 0x00c00878 as a safe and working value. > > > > Having re-read all of this, I believe you're right; I'll rework the > > AArch32-kernel SCTLR_EL1_KERNEL to not use the AArch64 bit definitions, > > and I'll add some commentary explaining that we're writing to the AArch32 > > format. > > > > > > Shall we have a separate reset value for 32bit? > > > > Assuming you meant to alter the SCTLR_ELx_KERNEL definition, yes. > > > > The idea of splitting the SCTLR_ELx_RESET and SCTLR_ELx_KERNEL > > definitions was that the former would be whatever the boot-wrapper > > needed to run at ELx, and the latter was whatever we must initialize for > > the kernel to run at ELx, so I don't want to put the AArch32 kernel bits > > into SCTLR_EL1_RESET. > > > > My only remaining concern is exactly what we must initialize. If there's > > any documentation we can refer to, that'd be great, otherwise I'll dig > > through your prior suggestion. > > I don't know of any recommendation what to initialise, though the ARMv7 > ARM speaks a bit about reset values. > So the SCTLR_KERNEL value we use in arch/aarch32/include/asm/cpu.h seems > to work (although it's not perfect), but we should use the same in the > KERNEL_32 case in arch/aarch64/include/asm/cpu.h. Ok; for now I'm going to copy the SCTLR_KERNEL definition as-is from the aarch32 header, and add a comment that we should restructure things to share a single definition in future. The rest of the reply is mostly for future reference. > Going through the SCTLR description in the ARMv8 *and* ARMv7 ARM again, > I think a safe and sane init value would be to set bits > [23,22,18,16,11,5,4,3] to one. This differs slightly from the value I told > you above, which I think was what I observed on an Cortex-A7 when dumping > SCTLR in the decompressor code. Having delved through the ARM ARM, those bits look right to me. Below is expanded detail for each bit to save having to delve into the ARM ARM again. Looking at the latest ARM ARM (ARM DDI 0487G.b), section G8.2.126 "SCTLR, System Control Register" starting on page G8-6810: * Bit 25 / EE RES0/RES1 in depending on implemented endianness support. Currently the boot-wrapper doesn't handle missin support for either BE or LE, so I'm going to ignore this for now and just assume LE is present (so 0 is a legitimate value). * Bit 23 / SPAN RES1 where FEAT_PAN is not implemented. * Bit 22 RES1 always. * Bit 18 / nTWE Not RESx, but warm-resets to 1. * Bit 16 / nTWI Not RESx, but warm-resets to 1. * Bit 11 RES1 always. * Bit 5 / CP15BEN Not RESx, but warm-resets to 1. * Bit 4 / LSMAOE RES1 where FEAT_LSMAOC is not implemented. Warm-resets to 1 where FEAT_LSMAOC is implemented. * Bit 3 / nTLSMD RES1 where FEAT_LSMAOC is not implemented. Warm-resets to 1 where FEAT_LSMAOC is implemented. ... with all other bits being UNKNOWN, RES0, or warm-rest to 0. > I became aware of the issue when I tried to start an ARM kernel on a > Cortex-A53 board, with U-Boot dropping from AArch64-EL2 to AArch32-EL1. > SCTLR_EL1 there got initialised according to the ARMv8 ARM (bits > [29,28,23,22,20,11] set), but this made the kernel decompressor hang as > soon as the MMU got enabled. I *think* I bisected it down to bits 28 and > 29, which are RES1 in AArch64, but enable TEX remap and the Access Flag in > v7, and both reset to 0 there. I haven't tried that on the model with the > boot-wrapper, but I guess we see the same problem there. > > In any case it seems to be already broken, so a fix or discussion doesn't > need to block this series. Sure; I think I'll save the AArch32 cleanup for a follow-up and go for a simple change to jsut avoid making it worse in this patch. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel