On 13 August 2015 at 19:29, Catalin Marinas <catalin.marinas@xxxxxxx> 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 <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 >> >>+ 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? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
