From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753825AbbIBJso (ORCPT ); Wed, 2 Sep 2015 05:48:44 -0400 Received: from mail-io0-f172.google.com ([209.85.223.172]:34087 "EHLO mail-io0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753449AbbIBJsm (ORCPT ); Wed, 2 Sep 2015 05:48:42 -0400 MIME-Version: 1.0 In-Reply-To: <20150813172946.GD4602@e104818-lin.cambridge.arm.com> References: <1439465645-22584-1-git-send-email-suzuki.poulose@arm.com> <1439465645-22584-13-git-send-email-suzuki.poulose@arm.com> <55CCAD73.7080702@arm.com> <20150813172946.GD4602@e104818-lin.cambridge.arm.com> Date: Wed, 2 Sep 2015 11:48:41 +0200 Message-ID: Subject: Re: [PATCH 12/14] arm64: Check for selected granule support From: Ard Biesheuvel To: Catalin Marinas Cc: "Suzuki K. Poulose" , Steve Capper , "kvm@vger.kernel.org" , Marc Zyngier , Will Deacon , "linux-kernel@vger.kernel.org" , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 13 August 2015 at 19:29, Catalin Marinas wrote: > On Thu, Aug 13, 2015 at 03:45:07PM +0100, Suzuki K. Poulose wrote: >> On 13/08/15 13:28, Steve Capper wrote: >> >On 13 August 2015 at 12:34, Suzuki K. Poulose wrote: >> >> __enable_mmu: >> >>+ mrs x1, ID_AA64MMFR0_EL1 >> >>+ ubfx x2, x1, #ID_AA64MMFR0_TGran_SHIFT, 4 >> >>+ cmp x2, #ID_AA64MMFR0_TGran_ENABLED >> >>+ b.ne __no_granule_support >> >> ldr x5, =vectors >> >> msr vbar_el1, x5 >> >> msr ttbr0_el1, x25 // load TTBR0 >> >>@@ -626,3 +643,8 @@ __enable_mmu: >> >> isb >> >> br x27 >> >> ENDPROC(__enable_mmu) >> >>+ >> >>+__no_granule_support: >> >>+ wfe >> >>+ b __no_granule_support >> >>+ENDPROC(__no_granule_support) >> >>-- >> >>1.7.9.5 >> >> >> > >> >Is is possible to tell the user that the kernel has failed to boot due >> >to the kernel granule being unsupported? >> >> We don't have anything up at this time. The "looping address" is actually a clue >> to the (expert) user. Not sure we can do something, until we get something like DEBUG_LL(?) > > No. > >> Or we should let it continue and end in a panic(?). The current situation can boot a >> multi-cluster system with boot cluster having the Tgran support(which doesn't make a >> strong use case though). I will try out some options and get back to you. > > If the boot CPU does not support 16KB pages, in general there isn't much > we can do since the console printing is done after we enabled the MMU. > Even mapping the UART address requires fixmap support and the PAGE_SIZE > is hard-coded in the kernel image. The DT is also mapped at run-time. > > While in theory it's possible to fall back to a 4KB page size just > enough to load the DT and figure out the early console, I suggest we > just live with the "looping address" clue. > Couldn't we allocate some flag bits in the Image header to communicate the page size to the bootloader?