| Message ID | 8835330baa77d88e0267b0b1215b78c991e6d17a.1543517818.git.christophe.leroy@c-s.fr (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | powerpc/32s: Use BATs for STRICT_KERNEL_RWX | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | next/apply_patch Successfully applied |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 79 lines checked |
Hi, On Thu, Nov 29, 2018 at 07:00:16PM +0000, Christophe Leroy wrote: > This patch reworks mmu_mapin_ram() to be more generic and map as much > blocks as possible. It now supports blocks not starting at address 0. > > It scans DBATs array to find free ones instead of forcing the use of > BAT2 and BAT3. > > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> > --- I've just tested this series on my Wii, and starting from this patch (03/13), it hangs at the following lines of output: [ 0.000000] printk: bootconsole [udbg0] enabled [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval)) Before this patch it looks like this and boots to userspace: [ 0.000000] printk: bootconsole [udbg0] enabled [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval)) [ 0.000000] Linux version 4.20.0-rc5-wii-00022-gfbb911b84755 (jn@longitude) (gcc version 8.2.0 (Debian 8.2.0-9)) #1337 PREEMPT Mon Dec 3 21:49:02 CET 2018 ug_udbg_init: early -> final usbgecko_udbg: ready [ 0.000000] Using wii machine description ... I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works somewhere in the middle, but probably not. (And in case you're wondering about the 22 in the version string: Those are mostly patches that give me a serial console.) I'm not sure what is going on, because I haven't looked closely at the patches or tried to debug the problem. If you have some debugging tips, I can try them. Jonathan Neuschäfer
Hi, On 12/03/2018 09:55 PM, Jonathan Neuschäfer wrote: > Hi, > > On Thu, Nov 29, 2018 at 07:00:16PM +0000, Christophe Leroy wrote: >> This patch reworks mmu_mapin_ram() to be more generic and map as much >> blocks as possible. It now supports blocks not starting at address 0. >> >> It scans DBATs array to find free ones instead of forcing the use of >> BAT2 and BAT3. >> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >> --- > > I've just tested this series on my Wii, and starting from this patch > (03/13), it hangs at the following lines of output: > > [ 0.000000] printk: bootconsole [udbg0] enabled > [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval)) > > Before this patch it looks like this and boots to userspace: > > [ 0.000000] printk: bootconsole [udbg0] enabled > [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval)) > [ 0.000000] Linux version 4.20.0-rc5-wii-00022-gfbb911b84755 (jn@longitude) (gcc version 8.2.0 (Debian 8.2.0-9)) #1337 PREEMPT Mon Dec 3 21:49:02 CET 2018 > ug_udbg_init: early -> final > usbgecko_udbg: ready > [ 0.000000] Using wii machine description Can you tell/provide the .config and dts used ? You seem to have 319MB RAM wherease arch/powerpc/boot/dts/wii.dts only has 88MB Memory: memory { device_type = "memory"; reg = <0x00000000 0x01800000 /* MEM1 24MB 1T-SRAM */ 0x10000000 0x04000000>; /* MEM2 64MB GDDR3 */ }; Christophe > ... > > I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works > somewhere in the middle, but probably not. > > (And in case you're wondering about the 22 in the version string: Those > are mostly patches that give me a serial console.) > > I'm not sure what is going on, because I haven't looked closely at the > patches or tried to debug the problem. If you have some debugging tips, > I can try them. > > > Jonathan Neuschäfer >
Hi Again, Le 13/12/2018 à 13:16, Christophe Leroy a écrit : > Hi, > > On 12/03/2018 09:55 PM, Jonathan Neuschäfer wrote: >> Hi, >> >> On Thu, Nov 29, 2018 at 07:00:16PM +0000, Christophe Leroy wrote: >>> This patch reworks mmu_mapin_ram() to be more generic and map as much >>> blocks as possible. It now supports blocks not starting at address 0. >>> >>> It scans DBATs array to find free ones instead of forcing the use of >>> BAT2 and BAT3. >>> >>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >>> --- >> >> I've just tested this series on my Wii, and starting from this patch >> (03/13), it hangs at the following lines of output: >> >> [ 0.000000] printk: bootconsole [udbg0] enabled >> [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at >> (ptrval)) >> >> Before this patch it looks like this and boots to userspace: >> >> [ 0.000000] printk: bootconsole [udbg0] enabled >> [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at >> (ptrval)) >> [ 0.000000] Linux version 4.20.0-rc5-wii-00022-gfbb911b84755 >> (jn@longitude) (gcc version 8.2.0 (Debian 8.2.0-9)) #1337 PREEMPT Mon >> Dec 3 21:49:02 CET 2018 >> ug_udbg_init: early -> final >> usbgecko_udbg: ready >> [ 0.000000] Using wii machine description > > Can you tell/provide the .config and dts used ? > > You seem to have 319MB RAM wherease arch/powerpc/boot/dts/wii.dts only > has 88MB Memory: > > memory { > device_type = "memory"; > reg = <0x00000000 0x01800000 /* MEM1 24MB 1T-SRAM */ > 0x10000000 0x04000000>; /* MEM2 64MB GDDR3 */ > }; Putting the same description in my mpc832x board DTS and doing a few hacks to get the WII functions called, I get the following: [ 0.000000] Top of RAM: 0x14000000, Total RAM: 0x5800000 [ 0.000000] Memory hole size: 232MB [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x0000000013ffffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000017fffff] [ 0.000000] node 0: [mem 0x0000000010000000-0x0000000013ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000013ffffff] [ 0.000000] On node 0 totalpages: 22528 [ 0.000000] DMA zone: 640 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 22528 pages, LIFO batch:3 [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 21888 [ 0.000000] Kernel command line: loglevel=7 ip=192.168.2.5:192.168.2.2::255.0 [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Memory: 77060K/90112K available (6548K kernel code, 1156K rwdata, [ 0.000000] Kernel virtual memory layout: [ 0.000000] * 0xfffdf000..0xfffff000 : fixmap [ 0.000000] * 0xfdffd000..0xfe000000 : early ioremap [ 0.000000] * 0xd5000000..0xfdffd000 : vmalloc & ioremap root@vgoippro:~# cat /sys/kernel/debug/powerpc/block_address_translation ---[ Instruction Block Address Translation ]--- 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC coherent 1: - 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC coherent 3: - 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel EXEC coherent 5: - 6: - 7: - ---[ Data Block Address Translation ]--- 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW coherent 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW coherent 3: - 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel RW coherent 5: - 6: - 7: - Could you please provide the dmesg and /sys/kernel/debug/powerpc/block_address_translation from before this patch, so that we can compare and identify the differences if any ? Thanks Christophe > > Christophe > >> ... >> >> I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works >> somewhere in the middle, but probably not. >> >> (And in case you're wondering about the 22 in the version string: Those >> are mostly patches that give me a serial console.) >> >> I'm not sure what is going on, because I haven't looked closely at the >> patches or tried to debug the problem. If you have some debugging tips, >> I can try them. >> >> >> Jonathan Neuschäfer >>
Hi, thanks for your reply. On Thu, Dec 13, 2018 at 03:51:32PM +0100, Christophe Leroy wrote: > Hi Again, > > Le 13/12/2018 à 13:16, Christophe Leroy a écrit : [...] > > Can you tell/provide the .config and dts used ? I'm using wii.dts and almost the wii_defconfig from my tree (save- defconfig result is attached), which is 4.20-rc5 plus a few patches: https://github.com/neuschaefer/linux wii-4.20-rc5 (w/o your patches) https://github.com/neuschaefer/linux wii-4.20-rc5-ppcbat (w/ your patches 1-3) > > You seem to have 319MB RAM wherease arch/powerpc/boot/dts/wii.dts only > > has 88MB Memory: > > > > memory { > > device_type = "memory"; > > reg = <0x00000000 0x01800000 /* MEM1 24MB 1T-SRAM */ > > 0x10000000 0x04000000>; /* MEM2 64MB GDDR3 */ > > }; This is, I think, because something marks all the address space from 0 to the end of MEM2 as RAM, and then cuts out a hole in the middle. I'm not sure about the exact mechanism. Unfortunately this hole has to be treated carefully because it contains MMIO devices. > Putting the same description in my mpc832x board DTS and doing a few hacks > to get the WII functions called, I get the following: > > [ 0.000000] Top of RAM: 0x14000000, Total RAM: 0x5800000 > [ 0.000000] Memory hole size: 232MB > [ 0.000000] Zone ranges: > [ 0.000000] DMA [mem 0x0000000000000000-0x0000000013ffffff] > [ 0.000000] Normal empty > [ 0.000000] Movable zone start for each node > [ 0.000000] Early memory node ranges > [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000017fffff] > [ 0.000000] node 0: [mem 0x0000000010000000-0x0000000013ffffff] > [ 0.000000] Initmem setup node 0 [mem > 0x0000000000000000-0x0000000013ffffff] > [ 0.000000] On node 0 totalpages: 22528 > [ 0.000000] DMA zone: 640 pages used for memmap > [ 0.000000] DMA zone: 0 pages reserved > [ 0.000000] DMA zone: 22528 pages, LIFO batch:3 > [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 > [ 0.000000] pcpu-alloc: [0] 0 > [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 21888 > [ 0.000000] Kernel command line: loglevel=7 > ip=192.168.2.5:192.168.2.2::255.0 > [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 > bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) > [ 0.000000] Memory: 77060K/90112K available (6548K kernel code, 1156K > rwdata, > [ 0.000000] Kernel virtual memory layout: > [ 0.000000] * 0xfffdf000..0xfffff000 : fixmap > [ 0.000000] * 0xfdffd000..0xfe000000 : early ioremap > [ 0.000000] * 0xd5000000..0xfdffd000 : vmalloc & ioremap > > > > > root@vgoippro:~# cat /sys/kernel/debug/powerpc/block_address_translation > ---[ Instruction Block Address Translation ]--- > 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC coherent > 1: - > 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC coherent > 3: - > 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel EXEC coherent > 5: - > 6: - > 7: - > > ---[ Data Block Address Translation ]--- > 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW coherent > 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded > 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW coherent > 3: - > 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel RW coherent > 5: - > 6: - > 7: - > > > Could you please provide the dmesg and > /sys/kernel/debug/powerpc/block_address_translation from before this patch, > so that we can compare and identify the differences if any ? After applying the patch that adds this debugfs file and enabling CONFIG_PPC_PTDUMP, I get this: # cat /sys/kernel/debug/powerpc/block_address_translation ---[ Instruction Block Address Translation ]--- 0: - 1: - 2: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC 3: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC 5: - 6: - 7: - ---[ Data Block Address Translation ]--- 0: - 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded 2: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW 3: 0xc1000000-0xc17fffff 0x01000000 Kernel RW 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW 5: - 6: - 7: - dmesg is attached. I added some tracing to the setbat function: diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c index f6f575bae3bc..4da3dc54fe46 100644 --- a/arch/powerpc/mm/ppc_mmu_32.c +++ b/arch/powerpc/mm/ppc_mmu_32.c @@ -120,6 +120,9 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys, struct ppc_bat *bat = BATS[index]; unsigned long flags = pgprot_val(prot); + pr_info("setbat(%u, %px, %px, %px, %lx)\n", + index, (void *)virt, (void *)phys, (void *)size, flags); + if ((flags & _PAGE_NO_CACHE) || (cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0)) flags &= ~_PAGE_COHERENT; And here's what I got: Before your patches (circa v4.20-rc5): [ 0.000000] setbat(2, c0000000, 00000000, 01000000, 591) [ 0.000000] setbat(3, c1000000, 01000000, 00800000, 591) [ 0.000000] setbat(4, d0000000, 10000000, 02000000, 591) With patches 1-3: [ 0.000000] setbat(0, c0000000, 00000000, 01000000, 311) [ 0.000000] setbat(2, c1000000, 01000000, 00800000, 311) [ 0.000000] setbat(4, d0000000, 10000000, 02000000, 791) According to arch/powerpc/include/asm/book3s/32/hash.h, - 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT - 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT - 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT Changing the flags back to 0x591 in setbat doesn't result in a booting system. > > > I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works > > > somewhere in the middle, but probably not. (I get the same results if I also merge powerpc/next, btw) I hope this helps somewhat, Jonathan Neuschäfer [ 0.000000] printk: bootconsole [udbg0] enabled [ 0.000000] Total memory = 319MB; using 1024kB for hash table (at (ptrval)) [ 0.000000] Linux version 4.20.0-rc5-wii-00021-g15eb67569a3d (jn@longitude) (gcc version 8.2.0 (Debian 8.2.0-9)) #1337 PREEMPT Sun Dec 16 02:37:19 CET 2018 [ 0.000000] Using wii machine description [ 0.000000] ----------------------------------------------------- [ 0.000000] Hash_size = 0x100000 [ 0.000000] phys_mem_size = 0x5700000 [ 0.000000] dcache_bsize = 0x20 [ 0.000000] icache_bsize = 0x20 [ 0.000000] cpu_features = 0x000000000401a008 [ 0.000000] possible = 0x000000002f7ff049 [ 0.000000] always = 0x0000000000000000 [ 0.000000] cpu_user_features = 0x8c000001 0x00000000 [ 0.000000] mmu_features = 0x00010001 [ 0.000000] Hash = 0x(ptrval) [ 0.000000] Hash_mask = 0x3fff [ 0.000000] ----------------------------------------------------- [ 0.000000] wii: hw_ctrl at 0x0d800100 mapped to 0x(ptrval) [ 0.000000] wii: hw_gpio at 0x0d8000c0 mapped to 0x(ptrval) [ 0.000000] Top of RAM: 0x13f00000, Total RAM: 0x5700000 [ 0.000000] Memory hole size: 232MB [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000000000000-0x0000000013efffff] [ 0.000000] Normal empty [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000017fffff] [ 0.000000] node 0: [mem 0x0000000010000000-0x0000000013efffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000013efffff] [ 0.000000] On node 0 totalpages: 22272 [ 0.000000] DMA zone: 638 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 22272 pages, LIFO batch:3 [ 0.000000] random: get_random_u32 called from start_kernel+0x84/0x438 with crng_init=0 [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 21634 [ 0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait console=usbgecko1 [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Memory: 73016K/89088K available (7084K kernel code, 512K rwdata, 1796K rodata, 2724K init, 158K bss, 16072K reserved, 0K cma-reserved) [ 0.000000] Kernel virtual memory layout: [ 0.000000] * 0xfffdf000..0xfffff000 : fixmap [ 0.000000] * 0xfde00000..0xfe000000 : consistent mem [ 0.000000] * 0xfddfe000..0xfde00000 : early ioremap [ 0.000000] * 0xd4000000..0xfddfe000 : vmalloc & ioremap [ 0.000000] rcu: Preemptible hierarchical RCU implementation. [ 0.000000] Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. [ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 [ 0.000000] flipper-pic: controller at 0x0c003000 mapped to 0x(ptrval) [ 0.000000] hlwd-pic: controller at 0x0d800030 mapped to 0x(ptrval) [ 0.000000] time_init: decrementer frequency = 60.750000 MHz [ 0.000000] time_init: processor frequency = 729.000000 MHz [ 0.000012] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0x1c0588ffb6, max_idle_ns: 881590404504 ns [ 0.004906] clocksource: timebase mult[83afef2] shift[23] registered [ 0.007920] clockevent: decrementer mult[f8d4fdf] shift[32] cpu[0] [ 0.011235] Console: colour dummy device 80x25 [ 0.013381] pid_max: default: 32768 minimum: 301 [ 0.015704] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.018862] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.023818] rcu: Hierarchical SRCU implementation. [ 0.026863] devtmpfs: initialized [ 0.057205] DMA-API: preallocated 65536 debug entries [ 0.059600] DMA-API: debugging enabled by kernel config [ 0.062146] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.066813] futex hash table entries: 256 (order: 0, 7168 bytes) [ 0.070472] NET: Registered protocol family 16 [ 0.074531] exi: Nintendo GameCube/Wii EXternal Interface (EXI) driver - version 4.0i [ 0.079457] exi: about to add [exi0:0] id=0xfffffffe (external card) [ 0.082855] exi: add completed [ 0.084329] exi: about to add [exi0:1] id=0xfffff308 Wii Mask ROM/RTC/SRAM/UART [ 0.088140] exi: add completed [ 0.129762] SCSI subsystem initialized [ 0.131853] Advanced Linux Sound Architecture Driver Initialized. [ 0.138423] Bluetooth: Core ver 2.22 [ 0.140835] NET: Registered protocol family 31 [ 0.142944] Bluetooth: HCI device and connection manager initialized [ 0.146378] Bluetooth: HCI socket layer initialized [ 0.148693] Bluetooth: L2CAP socket layer initialized [ 0.151303] Bluetooth: SCO socket layer initialized [ 0.153707] clocksource: Switched to clocksource timebase [ 0.236624] NET: Registered protocol family 2 [ 0.239818] tcp_listen_portaddr_hash hash table entries: 256 (order: 0, 6144 bytes) [ 0.243850] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [ 0.247389] TCP bind hash table entries: 1024 (order: 2, 20480 bytes) [ 0.250658] TCP: Hash tables configured (established 1024 bind 1024) [ 0.253850] UDP hash table entries: 256 (order: 1, 12288 bytes) [ 0.256758] UDP-Lite hash table entries: 256 (order: 1, 12288 bytes) [ 0.260147] NET: Registered protocol family 1 [ 0.262867] RPC: Registered named UNIX socket transport module. [ 0.265675] RPC: Registered udp transport module. [ 0.267974] RPC: Registered tcp transport module. [ 0.270219] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.584441] Initialise system trusted keyrings [ 0.588214] workingset: timestamp_bits=30 max_order=15 bucket_order=0 [ 0.682925] Key type asymmetric registered [ 0.684871] Asymmetric key parser 'x509' registered [ 0.687476] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 0.691178] io scheduler noop registered [ 0.693039] io scheduler deadline registered [ 0.695278] io scheduler cfq registered (default) [ 0.697511] io scheduler mq-deadline registered [ 0.699746] io scheduler kyber registered [ 0.755731] usbgecko: Console and TTY driver for the USB Gecko adapter - version 0.1i [ 0.760106] usbgecko: USB Gecko detected in memcard slot-A [ 1.341534] printk: console [usbgecko0] enabled [ 1.346940] Generic non-volatile memory driver v1.1 [ 1.354626] brd: module loaded [ 1.372181] loop: module loaded [ 1.376667] Broadcom 43xx driver loaded [ Features: NS ] [ 1.383138] i2c /dev entries driver [ 1.388232] sdhci: Secure Digital Host Controller Interface driver [ 1.395102] sdhci: Copyright(c) Pierre Ossman [ 1.399557] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.405551] mmc0 bounce up to 128 segments into one, max segment size 65536 bytes [ 1.437737] mmc0: SDHCI controller on d070000.sd [d070000.sd] using DMA [ 1.444910] mmc1 bounce up to 128 segments into one, max segment size 65536 bytes [ 1.477741] mmc1: SDHCI controller on d080000.sdio [d080000.sdio] using DMA [ 1.488556] NET: Registered protocol family 17 [ 1.500457] Bluetooth: RFCOMM socket layer initialized [ 1.506001] Bluetooth: RFCOMM ver 1.11 [ 1.510150] mmc0: new high speed SDHC card at address 1234 [ 1.515730] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 1.523394] mmcblk0: mmc0:1234 SA32G 28.9 GiB [ 1.527978] Bluetooth: BNEP filters: multicast [ 1.533692] Bluetooth: BNEP socket layer initialized [ 1.539240] Bluetooth: HIDP (Human Interface Emulation) ver 1.2 [ 1.545434] mmcblk0: p1 [ 1.548923] Bluetooth: HIDP socket layer initialized [ 1.555729] drmem: No dynamic reconfiguration memory found [ 1.563332] Loading compiled-in X.509 certificates [ 1.568179] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 1.575175] input: gpio-keys as /devices/platform/gpio-keys/input/input0 [ 1.583075] hctosys: unable to open rtc device (rtc0) [ 1.588566] mmc1: queuing unknown CIS tuple 0x80 (5 bytes) [ 1.594391] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 1.603328] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 1.614717] mmc1: queuing unknown CIS tuple 0x80 (5 bytes) [ 1.624477] random: fast init done [ 1.632755] mmc1: queuing unknown CIS tuple 0x80 (10 bytes) [ 1.643310] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 1.650089] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 1.655619] ALSA device list: [ 1.658623] No soundcards found. [ 1.662253] mmc1: queuing unknown CIS tuple 0x80 (2 bytes) [ 1.674115] mmc1: queuing unknown CIS tuple 0x80 (5 bytes) [ 1.680759] Freeing unused kernel memory: 2724K [ 1.685600] mmc1: queuing unknown CIS tuple 0x80 (4 bytes) [ 1.691121] This architecture does not have kernel memory protection. [ 1.697611] mmc1: new SDIO card at address 0001 [ 1.702178] Run /init as init process [ 1.706477] b43-sdio mmc1:0001:1: Chip ID 14e4:4318 [ 1.716390] ssb: Found chip with id 0x4710, rev 0x00 and package 0x00 [ 1.736283] ssb: WARNING: Multiple ChipCommon found [ 1.750060] b43-phy0: Broadcom 4710 WLAN found (core revision 9) [ 1.768026] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 1.785099] cfg80211: failed to load regulatory.db [ 1.794322] b43-phy0: Found PHY: Analog 3, Type 2 (G), Revision 7 [ 1.806215] b43-phy0: Found Radio: Manuf 0x17F, ID 0x2050, Revision 8, Version 0 [ 1.878936] b43-sdio mmc1:0001:1: Sonics Silicon Backplane found on SDIO device mmc1:0001:1 [ 1.907732] udevd[615]: starting version 3.2.5 [ 1.921820] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 1.937066] random: udevd: uninitialized urandom read (16 bytes read) [ 1.945644] random: udevd: uninitialized urandom read (16 bytes read) [ 1.952679] random: udevd: uninitialized urandom read (16 bytes read) [ 1.974388] udevd[616]: starting eudev-3.2.5 [ 3.055809] random: dd: uninitialized urandom read (512 bytes read) CONFIG_LOCALVERSION="-wii" CONFIG_SYSVIPC=y CONFIG_PREEMPT=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=14 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="/home/jn/dev/linux/gc-linux/buildroot/images/rootfs.cpio" CONFIG_EXPERT=y # CONFIG_ELF_CORE is not set CONFIG_PERF_EVENTS=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_SLAB=y # CONFIG_PPC_CHRP is not set # CONFIG_PPC_PMAC is not set CONFIG_EMBEDDED6xx=y CONFIG_WII=y # CONFIG_PPC_OF_BOOT_TRAMPOLINE is not set CONFIG_KEXEC=y # CONFIG_SECCOMP is not set CONFIG_ADVANCED_OPTIONS=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_BINFMT_MISC=m CONFIG_NET=y CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_RARP=y # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_DIAG is not set # CONFIG_IPV6 is not set CONFIG_BT=y CONFIG_BT_RFCOMM=y CONFIG_BT_BNEP=y CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_HIDP=y CONFIG_CFG80211=y CONFIG_MAC80211=y CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y # CONFIG_STANDALONE is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=2 CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_NETDEVICES=y # CONFIG_ETHERNET is not set CONFIG_B43=y CONFIG_B43_BUSES_SSB=y CONFIG_B43_SDIO=y # CONFIG_B43_PHY_LP is not set CONFIG_B43_DEBUG=y CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_JOYDEV=y CONFIG_INPUT_EVDEV=y # CONFIG_KEYBOARD_ATKBD is not set CONFIG_KEYBOARD_GPIO=y # CONFIG_MOUSE_PS2 is not set CONFIG_INPUT_JOYSTICK=y CONFIG_INPUT_MISC=y CONFIG_INPUT_UINPUT=y # CONFIG_SERIO_I8042 is not set # CONFIG_SERIO_SERPORT is not set CONFIG_LEGACY_PTY_COUNT=64 CONFIG_SERIAL_USBGECKO=y # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_GPIO=y CONFIG_GPIOLIB=y CONFIG_GPIO_SYSFS=y CONFIG_GPIO_HLWD=y CONFIG_POWER_RESET=y CONFIG_POWER_RESET_GPIO=y # CONFIG_HWMON is not set CONFIG_FB=y # CONFIG_VGA_CONSOLE is not set CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_SOUND=y CONFIG_SND=y CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=y CONFIG_SND_PCM_OSS=y # CONFIG_SND_VERBOSE_PROCFS is not set CONFIG_SND_SEQUENCER=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_HID_APPLE=m CONFIG_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_OF_HLWD=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_PANIC=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_GENERIC=y CONFIG_EXT2_FS=y CONFIG_EXT4_FS=y CONFIG_FUSE_FS=m CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_PROC_KCORE=y # CONFIG_PROC_PAGE_MONITOR is not set CONFIG_TMPFS=y CONFIG_NFS_FS=y CONFIG_ROOT_NFS=y CONFIG_CIFS=m CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_ISO8859_1=y # CONFIG_CRYPTO_HW is not set CONFIG_CRC_CCITT=y CONFIG_PRINTK_TIME=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_LATENCYTOP=y CONFIG_SCHED_TRACER=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_DMA_API_DEBUG=y CONFIG_PPC_EARLY_DEBUG=y CONFIG_PPC_PTDUMP=y
Le 17/12/2018 à 02:28, Jonathan Neuschäfer a écrit : > Hi, thanks for your reply. > > On Thu, Dec 13, 2018 at 03:51:32PM +0100, Christophe Leroy wrote: >> Hi Again, >> >> Le 13/12/2018 à 13:16, Christophe Leroy a écrit : > [...] >>> Can you tell/provide the .config and dts used ? > > I'm using wii.dts and almost the wii_defconfig from my tree (save- > defconfig result is attached), which is 4.20-rc5 plus a few patches: > > https://github.com/neuschaefer/linux wii-4.20-rc5 (w/o your patches) > https://github.com/neuschaefer/linux wii-4.20-rc5-ppcbat (w/ your patches 1-3) > >>> You seem to have 319MB RAM wherease arch/powerpc/boot/dts/wii.dts only >>> has 88MB Memory: >>> >>> memory { >>> device_type = "memory"; >>> reg = <0x00000000 0x01800000 /* MEM1 24MB 1T-SRAM */ >>> 0x10000000 0x04000000>; /* MEM2 64MB GDDR3 */ >>> }; > > This is, I think, because something marks all the address space from 0 > to the end of MEM2 as RAM, and then cuts out a hole in the middle. I'm > not sure about the exact mechanism. > > Unfortunately this hole has to be treated carefully because it contains > MMIO devices. > >> Putting the same description in my mpc832x board DTS and doing a few hacks >> to get the WII functions called, I get the following: >> >> [ 0.000000] Top of RAM: 0x14000000, Total RAM: 0x5800000 >> [ 0.000000] Memory hole size: 232MB >> [ 0.000000] Zone ranges: >> [ 0.000000] DMA [mem 0x0000000000000000-0x0000000013ffffff] >> [ 0.000000] Normal empty >> [ 0.000000] Movable zone start for each node >> [ 0.000000] Early memory node ranges >> [ 0.000000] node 0: [mem 0x0000000000000000-0x00000000017fffff] >> [ 0.000000] node 0: [mem 0x0000000010000000-0x0000000013ffffff] >> [ 0.000000] Initmem setup node 0 [mem >> 0x0000000000000000-0x0000000013ffffff] >> [ 0.000000] On node 0 totalpages: 22528 >> [ 0.000000] DMA zone: 640 pages used for memmap >> [ 0.000000] DMA zone: 0 pages reserved >> [ 0.000000] DMA zone: 22528 pages, LIFO batch:3 >> [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 >> [ 0.000000] pcpu-alloc: [0] 0 >> [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 21888 >> [ 0.000000] Kernel command line: loglevel=7 >> ip=192.168.2.5:192.168.2.2::255.0 >> [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 >> bytes) >> [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) >> [ 0.000000] Memory: 77060K/90112K available (6548K kernel code, 1156K >> rwdata, >> [ 0.000000] Kernel virtual memory layout: >> [ 0.000000] * 0xfffdf000..0xfffff000 : fixmap >> [ 0.000000] * 0xfdffd000..0xfe000000 : early ioremap >> [ 0.000000] * 0xd5000000..0xfdffd000 : vmalloc & ioremap >> >> >> >> >> root@vgoippro:~# cat /sys/kernel/debug/powerpc/block_address_translation >> ---[ Instruction Block Address Translation ]--- >> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC coherent >> 1: - >> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC coherent >> 3: - >> 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel EXEC coherent >> 5: - >> 6: - >> 7: - >> >> ---[ Data Block Address Translation ]--- >> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW coherent >> 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded >> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW coherent >> 3: - >> 4: 0xd0000000-0xd3ffffff 0x10000000 Kernel RW coherent >> 5: - >> 6: - >> 7: - >> >> >> Could you please provide the dmesg and >> /sys/kernel/debug/powerpc/block_address_translation from before this patch, >> so that we can compare and identify the differences if any ? > > After applying the patch that adds this debugfs file and enabling > CONFIG_PPC_PTDUMP, I get this: > > # cat /sys/kernel/debug/powerpc/block_address_translation > ---[ Instruction Block Address Translation ]--- > 0: - > 1: - > 2: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC > 3: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC > 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC > 5: - > 6: - > 7: - > > ---[ Data Block Address Translation ]--- > 0: - > 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded > 2: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW > 3: 0xc1000000-0xc17fffff 0x01000000 Kernel RW > 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW > 5: - > 6: - > 7: - > > dmesg is attached. > > > I added some tracing to the setbat function: > > diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c > index f6f575bae3bc..4da3dc54fe46 100644 > --- a/arch/powerpc/mm/ppc_mmu_32.c > +++ b/arch/powerpc/mm/ppc_mmu_32.c > @@ -120,6 +120,9 @@ void __init setbat(int index, unsigned long virt, phys_addr_t phys, > struct ppc_bat *bat = BATS[index]; > unsigned long flags = pgprot_val(prot); > > + pr_info("setbat(%u, %px, %px, %px, %lx)\n", > + index, (void *)virt, (void *)phys, (void *)size, flags); > + > if ((flags & _PAGE_NO_CACHE) || > (cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0)) > flags &= ~_PAGE_COHERENT; > > > And here's what I got: > > Before your patches (circa v4.20-rc5): > [ 0.000000] setbat(2, c0000000, 00000000, 01000000, 591) > [ 0.000000] setbat(3, c1000000, 01000000, 00800000, 591) > [ 0.000000] setbat(4, d0000000, 10000000, 02000000, 591) Ok, I have not tested against raw v4.20-rc5. I always powerpc/merge branch as the reference. Maybe I should try that. > > With patches 1-3: > [ 0.000000] setbat(0, c0000000, 00000000, 01000000, 311) > [ 0.000000] setbat(2, c1000000, 01000000, 00800000, 311) > [ 0.000000] setbat(4, d0000000, 10000000, 02000000, 791) What we see is that BAT0 is not used in the origin. I have always wondered the reason, maybe there is something odd behind and BAT0 shall no ne used. Could you try and modify find_free_bat() so that it starts at b = 1 instead of b = 0 ? > > According to arch/powerpc/include/asm/book3s/32/hash.h, > - 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT > - 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT > - 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT > Yes, patch 1 added _PAGE_EXEC which explains this 0x200. Do you confirm it still works well with only patch 1 ? And patch 3 uses PAGE_KERNEL_TEXT instead of PAGE_KERNEL_X, hence the lack of _PAGE_RW, which should not be necessary. > Changing the flags back to 0x591 in setbat doesn't result in a booting > system. > > >>>> I've tested at patch 1, 2, 3, 4, and 13, so I don't know if it works >>>> somewhere in the middle, but probably not. > > (I get the same results if I also merge powerpc/next, btw) Ok, then no need for me to test with raw 4.20 rc 5. Christophe > > > I hope this helps somewhat, > Jonathan Neuschäfer >
On Mon, Dec 17, 2018 at 10:29:18AM +0100, Christophe Leroy wrote: > > With patches 1-3: > > [ 0.000000] setbat(0, c0000000, 00000000, 01000000, 311) > > [ 0.000000] setbat(2, c1000000, 01000000, 00800000, 311) > > [ 0.000000] setbat(4, d0000000, 10000000, 02000000, 791) > > What we see is that BAT0 is not used in the origin. I have always wondered > the reason, maybe there is something odd behind and BAT0 shall no ne used. > > Could you try and modify find_free_bat() so that it starts at b = 1 instead > of b = 0 ? In this case, setbat is called with index 2, 3, and 4, but the Wii still doesn't boot. > > According to arch/powerpc/include/asm/book3s/32/hash.h, > > - 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT > > - 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT > > - 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT > > > > Yes, patch 1 added _PAGE_EXEC which explains this 0x200. > Do you confirm it still works well with only patch 1 ? Patch 1 alone boots to userspace. Jonathan
On 12/18/2018 03:05 AM, Jonathan Neuschäfer wrote: > On Mon, Dec 17, 2018 at 10:29:18AM +0100, Christophe Leroy wrote: >>> With patches 1-3: >>> [ 0.000000] setbat(0, c0000000, 00000000, 01000000, 311) >>> [ 0.000000] setbat(2, c1000000, 01000000, 00800000, 311) >>> [ 0.000000] setbat(4, d0000000, 10000000, 02000000, 791) >> >> What we see is that BAT0 is not used in the origin. I have always wondered >> the reason, maybe there is something odd behind and BAT0 shall no ne used. >> >> Could you try and modify find_free_bat() so that it starts at b = 1 instead >> of b = 0 ? > > In this case, setbat is called with index 2, 3, and 4, but the Wii still > doesn't boot. > >>> According to arch/powerpc/include/asm/book3s/32/hash.h, >>> - 0x591 = _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT >>> - 0x311 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_COHERENT | _PAGE_PRESENT >>> - 0x791 = _PAGE_RW | _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | _PAGE_PRESENT >>> >> >> Yes, patch 1 added _PAGE_EXEC which explains this 0x200. >> Do you confirm it still works well with only patch 1 ? > > Patch 1 alone boots to userspace. > Ok, thanks for testing. The only difference I see then are the flags. Everything else is seems identical. I know you tried already, but would you mind trying once more with the following change ? diff --git b/arch/powerpc/mm/ppc_mmu_32.c a/arch/powerpc/mm/ppc_mmu_32.c index 61c10ee00ba2..628fba266663 100644 --- b/arch/powerpc/mm/ppc_mmu_32.c +++ a/arch/powerpc/mm/ppc_mmu_32.c @@ -119,7 +119,7 @@ unsigned long __init mmu_mapin_ram(unsigned long base, unsigned long top) if (size < 128 << 10) break; - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); base += size; } I think we may have some code trying to modify the kernel text without using code patching functions. Thanks, Christophe > > Jonathan >
On Tue, Dec 18, 2018 at 09:18:42AM +0000, Christophe Leroy wrote: > The only difference I see then are the flags. Everything else is seems > identical. > > I know you tried already, but would you mind trying once more with the > following change ? > [...] > - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); > + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); Good call, with this workaround on top of patches 1-3, it boots again: # mount -t debugfs d /sys/kernel/debug # cat /sys/kernel/debug/powerpc/block_address_translation ---[ Instruction Block Address Translation ]--- 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC 1: - 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC 3: - 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC 5: - 6: - 7: - ---[ Data Block Address Translation ]--- 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW 3: - 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW 5: - 6: - 7: - > I think we may have some code trying to modify the kernel text without using > code patching functions. Is there any faster way than to sprinkle some printks in setup_kernel and try to find the guilty piece of code this way? Jonathan
Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit : > On Tue, Dec 18, 2018 at 09:18:42AM +0000, Christophe Leroy wrote: >> The only difference I see then are the flags. Everything else is seems >> identical. >> >> I know you tried already, but would you mind trying once more with the >> following change ? >> > [...] >> - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); >> + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); > > Good call, with this workaround on top of patches 1-3, it boots again: > > # mount -t debugfs d /sys/kernel/debug > # cat /sys/kernel/debug/powerpc/block_address_translation > ---[ Instruction Block Address Translation ]--- > 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC > 1: - > 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC > 3: - > 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC > 5: - > 6: - > 7: - > > ---[ Data Block Address Translation ]--- > 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW > 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded > 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW > 3: - > 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW > 5: - > 6: - > 7: - > >> I think we may have some code trying to modify the kernel text without using >> code patching functions. > > Is there any faster way than to sprinkle some printks in setup_kernel > and try to find the guilty piece of code this way? Can you start with the serie https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ? Christophe > > > Jonathan >
Le 18/12/2018 à 15:15, Christophe Leroy a écrit : > > > Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit : >> On Tue, Dec 18, 2018 at 09:18:42AM +0000, Christophe Leroy wrote: >>> The only difference I see then are the flags. Everything else is seems >>> identical. >>> >>> I know you tried already, but would you mind trying once more with the >>> following change ? >>> >> [...] >>> - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); >>> + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); >> >> Good call, with this workaround on top of patches 1-3, it boots again: >> >> # mount -t debugfs d /sys/kernel/debug >> # cat /sys/kernel/debug/powerpc/block_address_translation >> ---[ Instruction Block Address Translation ]--- >> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC >> 1: - >> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC >> 3: - >> 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC >> 5: - >> 6: - >> 7: - >> >> ---[ Data Block Address Translation ]--- >> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW >> 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded >> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW >> 3: - >> 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW >> 5: - >> 6: - >> 7: - >> >>> I think we may have some code trying to modify the kernel text >>> without using >>> code patching functions. >> >> Is there any faster way than to sprinkle some printks in setup_kernel >> and try to find the guilty piece of code this way? > > Can you start with the serie > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ? Ok, the thing I was thinking about was the MMU_init_hw() but it is called before mapin_ram() so it should not be a problem. Not sure that serie improves anything at all here. So there must be something else, pretty early (before the system is able to properly handle and display an Oops for write to RO area.) Does anybody have an idea of what it can be ? Christophe > > Christophe > >> >> >> Jonathan >>
Le 18/12/2018 à 15:55, Christophe Leroy a écrit : > > > Le 18/12/2018 à 15:15, Christophe Leroy a écrit : >> >> >> Le 18/12/2018 à 15:07, Jonathan Neuschäfer a écrit : >>> On Tue, Dec 18, 2018 at 09:18:42AM +0000, Christophe Leroy wrote: >>>> The only difference I see then are the flags. Everything else is seems >>>> identical. >>>> >>>> I know you tried already, but would you mind trying once more with the >>>> following change ? >>>> >>> [...] >>>> - setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); >>>> + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_X); >>> >>> Good call, with this workaround on top of patches 1-3, it boots again: >>> >>> # mount -t debugfs d /sys/kernel/debug >>> # cat /sys/kernel/debug/powerpc/block_address_translation >>> ---[ Instruction Block Address Translation ]--- >>> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel EXEC >>> 1: - >>> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel EXEC >>> 3: - >>> 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel EXEC >>> 5: - >>> 6: - >>> 7: - >>> >>> ---[ Data Block Address Translation ]--- >>> 0: 0xc0000000-0xc0ffffff 0x00000000 Kernel RW >>> 1: 0xfffe0000-0xffffffff 0x0d000000 Kernel RW no cache guarded >>> 2: 0xc1000000-0xc17fffff 0x01000000 Kernel RW >>> 3: - >>> 4: 0xd0000000-0xd1ffffff 0x10000000 Kernel RW >>> 5: - >>> 6: - >>> 7: - >>> >>>> I think we may have some code trying to modify the kernel text >>>> without using >>>> code patching functions. >>> >>> Is there any faster way than to sprinkle some printks in setup_kernel >>> and try to find the guilty piece of code this way? >> >> Can you start with the serie >> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=75072 ? > > Ok, the thing I was thinking about was the MMU_init_hw() but it is > called before mapin_ram() so it should not be a problem. Not sure that > serie improves anything at all here. > > So there must be something else, pretty early (before the system is able > to properly handle and display an Oops for write to RO area.) > > Does anybody have an idea of what it can be ? Stupid of me. In fact at the time being, BATS cover both RO and RW data areas, so it can definitly not be mapped with PAGE_KERNEL_ROX. In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is PAGE_KERNEL_X on my side. That's the reason why I missed it. With this change being done to patch 3, does the overall serie works for you ? Thanks Christophe > > Christophe > >> >> Christophe >> >>> >>> >>> Jonathan >>>
On Tue, Dec 18, 2018 at 04:04:42PM +0100, Christophe Leroy wrote: > Stupid of me. In fact at the time being, BATS cover both RO and RW data > areas, so it can definitly not be mapped with PAGE_KERNEL_ROX. > > In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is > PAGE_KERNEL_X on my side. That's the reason why I missed it. > > With this change being done to patch 3, does the overall serie works for you ? Yes, with the PAGE_KERNEL_X change, the whole series boots on the Wii. Jonathan
Le 18/12/2018 à 18:04, Jonathan Neuschäfer a écrit : > On Tue, Dec 18, 2018 at 04:04:42PM +0100, Christophe Leroy wrote: >> Stupid of me. In fact at the time being, BATS cover both RO and RW data >> areas, so it can definitly not be mapped with PAGE_KERNEL_ROX. >> >> In fact, as I have CONFIG_BDI_SWITCH in my setup, PAGE_KERNEL_TEXT is >> PAGE_KERNEL_X on my side. That's the reason why I missed it. >> >> With this change being done to patch 3, does the overall serie works for you ? > > Yes, with the PAGE_KERNEL_X change, the whole series boots on the Wii. That's great, many thanks for testing. Christophe > > > Jonathan >
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c index 3a29e88308b0..61c10ee00ba2 100644 --- a/arch/powerpc/mm/ppc_mmu_32.c +++ b/arch/powerpc/mm/ppc_mmu_32.c @@ -72,39 +72,58 @@ unsigned long p_block_mapped(phys_addr_t pa) return 0; } +static int find_free_bat(void) +{ + int b; + + if (cpu_has_feature(CPU_FTR_601)) { + for (b = 0; b < 4; b++) { + struct ppc_bat *bat = BATS[b]; + + if (!(bat[0].batl & 0x40)) + return b; + } + } else { + int n = mmu_has_feature(MMU_FTR_USE_HIGH_BATS) ? 8 : 4; + + for (b = 0; b < n; b++) { + struct ppc_bat *bat = BATS[b]; + + if (!(bat[1].batu & 3)) + return b; + } + } + return -1; +} + +static unsigned int block_size(unsigned long base, unsigned long top) +{ + unsigned int max_size = (cpu_has_feature(CPU_FTR_601) ? 8 : 256) << 20; + unsigned int base_shift = (fls(base) - 1) & 31; + unsigned int block_shift = (fls(top - base) - 1) & 31; + + return min3(max_size, 1U << base_shift, 1U << block_shift); +} + unsigned long __init mmu_mapin_ram(unsigned long base, unsigned long top) { - unsigned long tot, bl, done; - unsigned long max_size = (256<<20); + int idx; if (__map_without_bats) { printk(KERN_DEBUG "RAM mapped without BATs\n"); return 0; } - /* Set up BAT2 and if necessary BAT3 to cover RAM. */ + while ((idx = find_free_bat()) != -1 && base != top) { + unsigned int size = block_size(base, top); - /* Make sure we don't map a block larger than the - smallest alignment of the physical address. */ - tot = top; - for (bl = 128<<10; bl < max_size; bl <<= 1) { - if (bl * 2 > tot) + if (size < 128 << 10) break; + setbat(idx, PAGE_OFFSET + base, base, size, PAGE_KERNEL_TEXT); + base += size; } - setbat(2, PAGE_OFFSET, 0, bl, PAGE_KERNEL_X); - done = (unsigned long)bat_addrs[2].limit - PAGE_OFFSET + 1; - if ((done < tot) && !bat_addrs[3].limit) { - /* use BAT3 to cover a bit more */ - tot -= done; - for (bl = 128<<10; bl < max_size; bl <<= 1) - if (bl * 2 > tot) - break; - setbat(3, PAGE_OFFSET+done, done, bl, PAGE_KERNEL_X); - done = (unsigned long)bat_addrs[3].limit - PAGE_OFFSET + 1; - } - - return done; + return base; } /*
This patch reworks mmu_mapin_ram() to be more generic and map as much blocks as possible. It now supports blocks not starting at address 0. It scans DBATs array to find free ones instead of forcing the use of BAT2 and BAT3. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> --- arch/powerpc/mm/ppc_mmu_32.c | 61 +++++++++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 21 deletions(-)