lkml.org 
[lkml]   [2020]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
Date
It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf8000000. This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require that the start address of physical memory is
> a multiple of 128 MiB, precluding booting Linux on platforms where this
> requirement is not fulfilled.
>
> Fix this limitation by obtaining the start address from the DTB instead,
> if available (either explicitly passed, or appended to the kernel).
> Fall back to the traditional method when needed.
>
> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> i.e. not at a multiple of 128 MiB.
>
> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Dmitry Osipenko <digetx@gmail.com>
> ---

[...]

Apparently reading physical memory layout from DTB breaks crashdump
kernels. A crashdump kernel is loaded into a region of memory, that is
reserved in the original (i.e. to be crashed) kernel. The reserved
region is large enough for the crashdump kernel to run completely inside
it and don't modify anything outside it, just read and dump the remains
of the crashed kernel. Using the information from DTB makes the
decompressor place the kernel outside of the dedicated region.

The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
it is decompressed to 0x00008000 (see r4 reported before jumping from
within __enter_kernel). If I were to suggest something, there need to be
one more bit of information passed in the DTB telling the decompressor
to use the old masking technique to determain kernel address. It would
be set in the DTB loaded along with the crashdump kernel.

Despite the fact the kernel is able to start and get quite far it simply
panics (for a reason unknown to me at the moment).

Kind regards,
ŁS

--8<---------------cut here---------------start------------->8---
[ 42.358349] kexec_file:__do_sys_kexec_file_load:435: kexec_file: Loading segment 0: buf=0xf1871bcb bufsz=0x52c870 mem=0x18eb8000 memsz=0x52d000
[ 42.374615] kexec_file:__do_sys_kexec_file_load:435: kexec_file: Loading segment 1: buf=0x012365f6 bufsz=0x5abf mem=0x193f6000 memsz=0x6000
root@target:~# sync && echo c > /proc/sysrq-trigger
[ 62.206252] sysrq: Trigger a crash
[ 62.209711] Kernel panic - not syncing: sysrq triggered crash
[ 62.215548] CPU: 0 PID: 1236 Comm: bash Kdump: loaded Tainted: G W 5.7.0-rc6-00011-gad3fbe6a883e #174
[ 62.226225] Hardware name: BCM2711
[ 62.229676] Backtrace:
[ 62.232178] [<c010bfa4>] (dump_backtrace) from [<c010c334>] (show_stack+0x20/0x24)
[ 62.239863] r7:00000008 r6:c0b4a48d r5:00000000 r4:c0eb7b18
[ 62.245617] [<c010c314>] (show_stack) from [<c03e475c>] (dump_stack+0x20/0x28)
[ 62.252954] [<c03e473c>] (dump_stack) from [<c011e368>] (panic+0xf4/0x320)
[ 62.259941] [<c011e274>] (panic) from [<c044bb60>] (sysrq_handle_crash+0x1c/0x20)
[ 62.267536] r3:c044bb44 r2:c57e1c21 r1:60000093 r0:c0b4a48d
[ 62.273278] r7:00000008
[ 62.275853] [<c044bb44>] (sysrq_handle_crash) from [<c044c198>] (__handle_sysrq+0xa0/0x150)
[ 62.284334] [<c044c0f8>] (__handle_sysrq) from [<c044c620>] (write_sysrq_trigger+0x68/0x78)
[ 62.292814] r10:00000002 r9:e9123f50 r8:00000002 r7:012f2408 r6:e9112cc0 r5:c044c5b8
[ 62.300757] r4:00000002
[ 62.303335] [<c044c5b8>] (write_sysrq_trigger) from [<c02a7ad4>] (proc_reg_write+0x98/0xa8)
[ 62.311808] r5:c044c5b8 r4:eb655700
[ 62.315443] [<c02a7a3c>] (proc_reg_write) from [<c023b080>] (__vfs_write+0x48/0xf4)
[ 62.323216] r9:012f2408 r8:c02a7a3c r7:00000002 r6:e9112cc0 r5:e9123f50 r4:c0e04248
[ 62.331077] [<c023b038>] (__vfs_write) from [<c023c900>] (vfs_write+0xa8/0xcc)
[ 62.338407] r8:e9123f50 r7:012f2408 r6:00000002 r5:00000000 r4:e9112cc0
[ 62.345211] [<c023c858>] (vfs_write) from [<c023cae0>] (ksys_write+0x78/0xc4)
[ 62.352454] r9:012f2408 r8:e9123f5c r7:c0e04248 r6:e9123f50 r5:012f2408 r4:e9112cc0
[ 62.360316] [<c023ca68>] (ksys_write) from [<c023cb44>] (sys_write+0x18/0x1c)
[ 62.367559] r10:00000004 r9:e9122000 r8:c0100264 r7:00000004 r6:b6edcd90 r5:012f2408
[ 62.375504] r4:00000002
[ 62.378080] [<c023cb2c>] (sys_write) from [<c0100060>] (ret_fast_syscall+0x0/0x54)
[ 62.385759] Exception stack(0xe9123fa8 to 0xe9123ff0)
[ 62.390889] 3fa0: 00000002 012f2408 00000001 012f2408 00000002 00000000
[ 62.399190] 3fc0: 00000002 012f2408 b6edcd90 00000004 012f2408 00000002 00000000 00118fd8
[ 62.407488] 3fe0: 0000006c be82b7e8 b6df7010 b6e546e4
[ 62.412647] Loading crashdump kernel...
[ 62.416628] Bye!
Uncompressing Linux... done, booting the kernel.
r2:0x193F6000
r4:0x00008000
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.7.0-rc6-00011-gad3fbe6a883e (l.stelmach@AMDC1062) (gcc version 8.3.0 (Debian 8.3.0-2), GNU ld (GNU Binutils for Debian) 2.31.1) #174 Tue May 19
09:37:10 CEST 2020
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B
[ 0.000000] earlycon: uart8250 at MMIO32 0xfe215040 (options '')
[ 0.000000] printk: bootconsole [uart8250] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Reserved memory: created CMA memory pool at 0x04000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address d93f6000
[ 0.000000] pgd = (ptrval)
[ 0.000000] [d93f6000] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00011-gad3fbe6a883e #174
[ 0.000000] Hardware name: BCM2711
[ 0.000000] PC is at fdt32_ld+0xc/0x18
[ 0.000000] LR is at fdt_check_header+0x14/0x15c
[ 0.000000] pc : [<c03e4b10>] lr : [<c03e4c24>] psr: a00000d3
[ 0.000000] sp : c0e01ed8 ip : c0e01ee8 fp : c0e01ee4
[ 0.000000] r10: c3ffff40 r9 : c0e2e4f4 r8 : 00000000
[ 0.000000] r7 : c0f5b35c r6 : d93f6000 r5 : c0e085d0 r4 : c0d25510
[ 0.000000] r3 : d93f6000 r2 : c0f5b35c r1 : 00000000 r0 : d93f6000
[ 0.000000] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 0.000000] Control: 10c5383d Table: 00004059 DAC: 00000051
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc0e01ed8 to 0xc0e02000)
[ 0.000000] 1ec0: c0e01f04 c0e01ee8
[ 0.000000] 1ee0: c03e4c24 c03e4b10 c0d25510 c0e085d0 d93f6000 c0f5b35c c0e01f2c c0e01f08
[ 0.000000] 1f00: c05f7d94 c03e4c1c c0d25510 c0e085d0 07ffffff 00000000 c0f4c580 c0e2e4f4
[ 0.000000] 1f20: c0e01f4c c0e01f30 c0d26a54 c05f7ccc 00000000 c0e01f40 c0123458 c0d2ff08
[ 0.000000] 1f40: c0e01fa4 c0e01f50 c0d03c18 c0d26a28 ffffffff 10c5383d c0d0d244 c0e04248
[ 0.000000] 1f60: c0b11587 c09000e7 c0e01f94 c0e01f78 c01580e4 00000000 c0e01f9c c0d00330
[ 0.000000] 1f80: c0e04248 c0e04240 ffffffff 193f6000 c0eb77fc 10c53c7d c0e01ff4 c0e01fa8
[ 0.000000] 1fa0: c0d00b5c c0d035a4 00000000 00000000 00000000 00000000 00000000 c0d31a30
[ 0.000000] 1fc0: 00000000 00000000 00000000 c0d00330 00000051 10c03c7d ffffffff 193f6000
[ 0.000000] 1fe0: 410fd083 10c53c7d 00000000 c0e01ff8 00000000 c0d00b08 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c03e4b04>] (fdt32_ld) from [<c03e4c24>] (fdt_check_header+0x14/0x15c)
[ 0.000000] [<c03e4c10>] (fdt_check_header) from [<c05f7d94>] (__unflatten_device_tree+0xd4/0x284)
[ 0.000000] r7:c0f5b35c r6:d93f6000 r5:c0e085d0 r4:c0d25510
[ 0.000000] [<c05f7cc0>] (__unflatten_device_tree) from [<c0d26a54>] (unflatten_device_tree+0x38/0x54)
[ 0.000000] r9:c0e2e4f4 r8:c0f4c580 r7:00000000 r6:07ffffff r5:c0e085d0 r4:c0d25510
[ 0.000000] [<c0d26a1c>] (unflatten_device_tree) from [<c0d03c18>] (setup_arch+0x680/0xabc)
[ 0.000000] r4:c0d2ff08
[ 0.000000] [<c0d03598>] (setup_arch) from [<c0d00b5c>] (start_kernel+0x60/0x500)
[ 0.000000] r10:10c53c7d r9:c0eb77fc r8:193f6000 r7:ffffffff r6:c0e04240 r5:c0e04248
[ 0.000000] r4:c0d00330
[ 0.000000] [<c0d00afc>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:10c53c7d r9:410fd083 r8:193f6000 r7:ffffffff r6:10c03c7d r5:00000051
[ 0.000000] r4:c0d00330
[ 0.000000] Code: c03e49d0 e1a0c00d e92dd800 e24cb004 (e5900000)
[ 0.000000] random: get_random_bytes called from init_oops_id+0x30/0x4c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
--8<---------------cut here---------------end--------------->8---


--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2020-05-19 10:54    [W:0.566 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site