Re: [PATCH 12/14] arm64: Check for selected granule support

From: Catalin Marinas
Date: Thu Aug 13 2015 - 13:29:59 EST

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 <suzuki.poulose@xxxxxxx> wrote:
> >> __enable_mmu:
> >>+ mrs x1, ID_AA64MMFR0_EL1
> >>+ ubfx x2, x1, #ID_AA64MMFR0_TGran_SHIFT, 4
> >>+ cmp x2, #ID_AA64MMFR0_TGran_ENABLED
> >>+ __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)
> >>--
> >>
> >>
> >
> >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(?)


> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at