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 357E9C433F5 for ; Thu, 3 Feb 2022 21:21:38 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bur0Ki3WqPwk2hYL0OWx/iA0S88HTgcZdJGXM2zPWn0=; b=ts0EtoNB5aWBKz zQEChs+j7NZxcO7FGcNBdj4vsCzNBS62ib9t2kCasPr31pTij2baHadsnCSzBsYiVFMAZAkoLtTck wgrZLkqPtwAyaLyICnIQD4XB/bq6dL2EbTcO8CqAzC+XVFbqgiW7YhQjcBF/ex4ZHDIeUQq6VkaG3 vqRDXwEiWuiMIjtNwnzHxGvJyCKAiJReruj8tTsjyJU3lFbrD8Gn/sUpAXfgM3teQ/JMC695KdJW1 Ts8KwfJ06NsFavYLNv7/PU1EXOWYjGx8gwaOoZZBhpKwAq5pAjvjcXu7niRFloALHWXu76Ty5zXs4 LborjRVYu17y6lAHppTw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFjWY-002vBQ-BD; Thu, 03 Feb 2022 21:20:14 +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 1nFjWS-002vA5-58 for linux-arm-kernel@lists.infradead.org; Thu, 03 Feb 2022 21:20:10 +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 738431435; Thu, 3 Feb 2022 13:20:05 -0800 (PST) Received: from [10.57.68.47] (unknown [10.57.68.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 383463F774; Thu, 3 Feb 2022 13:20:04 -0800 (PST) Message-ID: <93a920bb-ee5b-fd72-ddb9-5c4bfb1729cc@arm.com> Date: Thu, 3 Feb 2022 21:20:00 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: Big endian modifications Content-Language: en-GB To: Mark Rutland , Rory Bolt Cc: "linux-arm-kernel@lists.infradead.org" , ardb@kernel.org, maz@kernel.org, will@kernel.org, catalin.marinas@arm.com References: From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220203_132008_364357_02DD1D6A X-CRM114-Status: GOOD ( 41.32 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-02-03 20:10, Mark Rutland wrote: > Hi, > > On Thu, Feb 03, 2022 at 06:48:43PM +0000, Rory Bolt wrote: >> Hello, >> >> I have been modifying GRUB on Das U-boot to allow it to boot aarch64_be big >> endian kernels on the RockPro64 board. Since the RockPro64 has a PCIe (albeit >> 2.0) slot, it provides a low cost/reasonable performance (vs QEMU) system to >> test our devices, drivers and software stack on a big endian system. I am in >> the process of publishing the required changes to GRUB, however there are two >> minor changes made to the kernel itself. > > Kernel patches need to be submitted in a particular format, with a commit > title, commit message, and DCO (Signed-off-by) lines. Please see: > > https://docs.kernel.org/process/submitting-patches.html > > https://docs.kernel.org/process/development-process.html > > It's also worthwhile looking at the MAINTAINERS file to Cc relevant people. For > example, Catalin and Will are the maintainers of the arm64 port, and Ard, Marc, > and I have made various changes to this code. > >> Arguably the modification to head.S could be moved to grub itself, however it >> is in the defensive spirit of not assuming the boot loader has set up >> everything correctly and is very similar to the startup of NetBSD which >> contains similar code in its startup. > > Hmm... big-endian boot *should* already work. The kernel configures its > endianness in init_kernel_el(), and from testing a BE v5.17-rc2 kernel just now > with a FVP Base model and the boot-wrapper (which would leave the CPU in a > little-endian state when jumping to the kernel) things seem to work. > > Which kernel version are you testing with, and how *exactly* is the kernel > being entered? > > Is it being entered directly by the protocol defined at: > > https://docs.kernel.org/arm64/booting.html > > ... or some other way (e.g. via the EFI application entry point?). > >> The second change to Kconfig allows a EFI/PE/COFF header to be added to a big >> endian kernel (although unfortunately it also adds a useless big endian >> efistub to the kernel too). With the following two changes the modified GRUB >> can boot either big endian or little endian Arm64 images. > > This implies that grub is trying to enter the EFI entry point, and a bunch of > things aren't going to work thereafter. > > What have you changed on the GRUB side? Because I don't understand why it would > *need* changes, if the PE/COFF header and EFI stub handled being entered in LE, > then switching to BE. That and it should be possible to boot a BE kernel > without neding a PE/COFF header, so something doesn't add up. AFAIK arm64 GRUB only supports calling Linux as an EFI application. >> Please consider the following two modifications for inclusion: > > As above, we can't take this as-is, but if you've found a regression I'm more > than happy to try to get that fixed. If we *really* need to be able to boot > BE kernels from EFI, there might be things that we can do, but I don't think we > can just remove the CONFIG_EFI dependency on !CPU_BIG_ENDIAN -- the runtime > bits *certainly* won't work, at minimum the stub needs to be built LE, etc. > > Also, have you considered running your kernel under KVM, with devices assigned > to it? That might be significantly easier than having a BE kernel that handles > EFI. Sadly that's not an option on RockPro64 since there's no suitable IOMMU. The number of affordable AArch64 platforms actually capable of device assignment is still disappointingly close to none :( Robin. > > Thanks, > Mark. > >> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S >> index 6a98f1a38c29..40a18d767d15 100644 >> --- a/arch/arm64/kernel/head.S >> +++ b/arch/arm64/kernel/head.S >> @@ -89,6 +89,24 @@ >> * x24 __primary_switch() .. relocate_kernel() current RELR displacement >> */ >> SYM_CODE_START(primary_entry) >> +#ifdef CONFIG_CPU_BIG_ENDIAN >> + mrs x21, CurrentEL >> + lsr x21, x21, #2 >> + cmp x21, #0x2 >> + b.lo 1f >> + >> + mrs x21, sctlr_el2 >> + orr x21, x21, #SCTLR_ELx_EE /* set: Big Endian */ >> + msr sctlr_el2, x21 >> + isb >> + >> +1: >> + mrs x21, sctlr_el1 >> + orr x21, x21, #(SCTLR_ELx_EE | SCTLR_EL1_E0E) /* set: Big Endian */ >> + msr sctlr_el1, x21 >> + isb >> + >> +#endif >> bl preserve_boot_args >> bl init_kernel_el // w0=cpu_boot_mode >> adrp x23, __PHYS_OFFSET >> >> >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index c4207cf9bb17..a9ccbeb75ea7 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -1997,7 +1997,7 @@ config EFI_STUB >> >> config EFI >> bool "UEFI runtime support" >> - depends on OF && !CPU_BIG_ENDIAN >> + depends on OF >> depends on KERNEL_MODE_NEON >> select ARCH_SUPPORTS_ACPI >> select LIBFDT >> >> Rory Bolt >> >> KIOXIA America, Inc. | formerly Toshiba Memory America, Inc. >> >> >> >> >> >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-kernel@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel