Messages in this thread | | | Subject | Re: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX | From | Christophe Leroy <> | Date | Wed, 16 Jan 2019 14:34:53 +0100 |
| |
Le 16/01/2019 à 14:16, Jonathan Neuschäfer a écrit : > On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote: >> Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit : >>> Thinning the kernel down a bit actually makes it boot again. Ooops...! >>> Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to >>> fail the hash table allocation, but there may have been other factors >>> involved (I'm not sure exactly). Sorry for the confusion! >> >> Ok, that must be the reason. Thanks for testing. >> >> What about the following modification which maps a second 256Mb BAT, does it >> helps ? >> >> >> >> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S >> index c2f564690778..ea574596de37 100644 >> --- a/arch/powerpc/kernel/head_32.S >> +++ b/arch/powerpc/kernel/head_32.S >> @@ -1160,6 +1160,14 @@ initial_bats: >> mtspr SPRN_DBAT0U,r11 /* bit in upper BAT register */ >> mtspr SPRN_IBAT0L,r8 >> mtspr SPRN_IBAT0U,r11 >> +#ifdef CONFIG_WII >> + addis r11,r11,0x10000000@h >> + addis r8,r8,0x10000000@h >> + mtspr SPRN_DBAT2L,r8 >> + mtspr SPRN_DBAT2U,r11 >> + mtspr SPRN_IBAT2L,r8 >> + mtspr SPRN_IBAT2U,r11 >> +#endif >> isync >> blr >> >> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c >> index 3f4193201ee7..a334fd5210a8 100644 >> --- a/arch/powerpc/mm/ppc_mmu_32.c >> +++ b/arch/powerpc/mm/ppc_mmu_32.c >> @@ -259,6 +259,8 @@ void setup_initial_memory_limit(phys_addr_t >> first_memblock_base, >> /* 601 can only access 16MB at the moment */ >> if (PVR_VER(mfspr(SPRN_PVR)) == 1) >> memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000)); >> + else if (IS_ENABLED(CONFIG_WII)) >> + memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000)); >> else /* Anything else has 256M mapped */ >> memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000)); >> } > > I haven't tested it, but this patch won't be enough, because we're only > looking at the first memblock, and the additional memory in the Wii > (MEM2) is the second memblock. >
Yes right.
Would the following work instead ?
memblock_set_current_limit(0x20000000);
Christophe
| |