[PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX
Christophe Leroy
christophe.leroy at c-s.fr
Thu Jan 17 21:14:54 AEDT 2019
Le 17/01/2019 à 00:48, Jonathan Neuschäfer a écrit :
> On Wed, Jan 16, 2019 at 02:34:53PM +0100, Christophe Leroy wrote:
>> 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 at h
>>>> + addis r8,r8,0x10000000 at 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);
>
> With the config at https://gist.githubusercontent.com/neuschaefer/12ccc87ff8aeff543fad558e8742cd2b/raw/d49d321709cac364779e6893bbd91ff5a80bcb03/config
> it still doesn't boot, but with a different error:
>
> top of MEM2 @ 13F00000
>
> zImage starting: loaded at 0x01000000 (sp: 0x0178afa0)
> Allocating 0x166b2c8 bytes for kernel...
> Decompressing (0x00000000 <- 0x01011000:0x01788799)...
> Done! Decompressed 0xf421f4 bytes
>
> Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
> Finalizing device tree... flat tree at 0x178b7a0
> [ 0.000000] printk: bootconsole [udbg0] enabled
> [ 0.000000] __memblock_find_range_top_down(1000:20000000, 100000:100000, ffffffff, 0)
> [ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
> [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at d3e00000)
> [ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
> [ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13e00000
> [ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
> [ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13dff000
> [ 0.000000] BUG: Unable to handle kernel data access at 0xc106a434
> [ 0.000000] Faulting instruction address: 0xc0071bf4
> [ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 0.000000] BE PREEMPT
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00038-gc34b70d591b6-dirty #1337
> [ 0.000000] NIP: c0071bf4 LR: c00727d8 CTR: 00000000
> [ 0.000000] REGS: c0f1fd30 TRAP: 0300 Not tainted (5.0.0-rc1-wii-00038-gc34b70d591b6-dirty)
> [ 0.000000] MSR: 00001032 <ME,IR,DR,RI> CR: 44002842 XER: 00000000
> [ 0.000000] DAR: c106a434 DSISR: 40000000
> [ 0.000000] GPR00: c0074a98 c0f1fde0 c0ead4a0 c0ead4a0 c0ead9c8 00000008 00000000 00000000
> [ 0.000000] GPR08: 00000003 c106a418 00000258 00000001 24000444 fb43ef5b c0f30000 7561f327
> [ 0.000000] GPR16: c0f40000 691cfd11 38afe359 f161e513 00000000 c0ead9c8 00000001 00000000
> [ 0.000000] GPR24: 00000000 c0f46288 00000000 c0ead4a0 c0ead9c8 00000008 c0ead4a0 00000100
> [ 0.000000] NIP [c0071bf4] mark_lock+0x64/0x858
> [ 0.000000] LR [c00727d8] __lock_acquire+0x334/0x1a40
> [ 0.000000] Call Trace:
> [ 0.000000] [c0f1fe20] [00000006] 0x6
> [ 0.000000] [c0f1fed0] [c0074a98] lock_acquire+0x110/0x20c
> [ 0.000000] [c0f1ff10] [c085e8cc] _raw_spin_lock+0x44/0x60
> [ 0.000000] [c0f1ff30] [c007f220] vprintk_emit+0xa0/0x328
> [ 0.000000] [c0f1ff70] [c007fc48] printk+0x5c/0x84
> [ 0.000000] [c0f1ffb0] [c0c00854] start_kernel+0x64/0x460
> [ 0.000000] [c0f1fff0] [00003438] 0x3438
> [ 0.000000] Instruction dump:
> [ 0.000000] 41820170 55086cfe 550a083c 7d4a4214 554a1838 3d20c0f4 7d4a4214 39296288
> [ 0.000000] 554a1838 3d290012 7d295214 39293f38 <8129001c> 7fe94839 41820028 3bc00001
> [ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x6c with crng_init=0
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> [ 0.000000]
> [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
>
> Not sure what's wrong. It does work with wii_defconfig, though.
> I think for now I'm happy without this patch, as it doesn't seem to be
> really necessary.
That's strange, 0xc106a434 is within the first block, should not be a
problem, should it ?
According to DSISR, the fault is due to: Set if the translation of an
attempted access is not found in the primary or secondary hash table entry
group (HTEG), or in the range of a DBAT register (page fault condition)
Ok, won't spend more time on that for now, 24Mbytes should be OK for
early init in most cases.
Christophe
>
>
> Jonathan
>
More information about the Linuxppc-dev
mailing list