Re: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX
From: Christophe Leroy
Date: Thu Jan 17 2019 - 05:59:35 EST
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@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);
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