| Message ID | 20201221120220.3186744-1-chenhuacai@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [V3] MIPS: Loongson64: Add kexec/kdump support | expand |
On 12/21/2020 08:02 PM, Huacai Chen wrote: > From: Huacai Chen <chenhc@lemote.com> > > Add kexec/kdump support for Loongson64 by: > 1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(), > loongson_kexec_shutdown() and loongson_crash_shutdown(); > 2, Provide Loongson-specific assembly code in kexec_smp_wait(); > > To start Loongson64, The boot CPU needs 3 parameters: > fw_arg0: the number of arguments in cmdline (i.e., argc). > fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty" > (i.e., argv). > fw_arg2: environment (i.e., envp, additional boot parameters from LEFI). > > Non-boot CPUs do not need one parameter as the IPI mailbox base address. > They query their own IPI mailbox to get PC, SP and GP in a loopi, until > the boot CPU brings them up. > > loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump > cmdline comes from kexec's "append" option string. This structure will > be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image > ->control_code_page and the cmdline need to be in a safe memory region > (memory allocated by the old kernel may be corrupted by the new kernel). > In order to maintain compatibility for the old firmware, the low 2MB is > reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_ > ADDR be here. LEFI parameters may be corrupted at runtime, so backup it > at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown() > /loongson_crash_shutdown(). > > loongson_kexec_shutdown(): Wake up all present CPUs and let them go to > reboot_code_buffer. Pass the kexec parameters to kexec_args. > > loongson_crash_shutdown(): Pass the kdump parameters to kexec_args. > > The assembly part in kexec_smp_wait provide a routine as BIOS does, in > order to keep secondary CPUs in a querying loop. > > The layout of low 2MB memory in our design: > 0x80000000, the first MB, the first 64K, Exception vectors > 0x80010000, the first MB, the second 64K, STR (suspend) data > 0x80020000, the first MB, the third and fourth 64K, UEFI HOB > 0x80040000, the first MB, the fifth 64K, RT-Thread for SMC > 0x80100000, the second MB, the first 64K, KEXEC code > 0x80108000, the second MB, the second 64K, KEXEC data > > Cc: Eric Biederman <ebiederm@xmission.com> > Signed-off-by: Huacai Chen <chenhuacai@kernel.org> > Signed-off-by: Jinyang He <hejinyang@loongson.cn> > Signed-off-by: Youling Tang <tangyouling@loongson.cn> > --- > V3: Some minor improvements suggested by Jinyang He. > > arch/mips/kernel/relocate_kernel.S | 28 +++++++ > arch/mips/loongson64/reset.c | 113 +++++++++++++++++++++++++++++ > 2 files changed, 141 insertions(+) kexec-tools v2.0.21 3A3000/7A1000 3A4000/7A1000 Test kexec: # kexec -l vmlinux --append="<cmdline>" # kexec -e Result: OK! Test kdump: We need a capture kernel to dump the panic kernel. To build the capture kernel: make loongson3_defconfig and set CONFIG_PROC_VMCORE=y , CONFIG_CRASH_DUMP=y and CONFIG_PHYSICAL_START=0xffffffff84000000 # kexec -p vmlinux(capture) --append="<cmdline>" # echo c > /proc/sysrq-trigger Result: OK! Tested-by: Jinyang He <hejinyang@loongson.cn> Thanks, :-) Jinyang > diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S > index ac870893ba2d..f649ffa0f427 100644 > --- a/arch/mips/kernel/relocate_kernel.S > +++ b/arch/mips/kernel/relocate_kernel.S > @@ -6,6 +6,7 @@ > > #include <asm/asm.h> > #include <asm/asmmacro.h> > +#include <asm/cpu.h> > #include <asm/regdef.h> > #include <asm/mipsregs.h> > #include <asm/stackframe.h> > @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) > #else > sync > #endif > + > +#ifdef CONFIG_CPU_LOONGSON64 > + /* s0:prid s1:initfn */ > + /* a0:base t1:cpuid t2:node t9:count */ > + mfc0 t1, CP0_EBASE > + andi t1, MIPS_EBASE_CPUNUM > + dins a0, t1, 8, 2 /* insert core id*/ > + dext t2, t1, 2, 2 > + dins a0, t2, 44, 2 /* insert node id */ > + mfc0 s0, CP0_PRID > + andi s0, s0, (PRID_IMP_MASK | PRID_REV_MASK) > + beq s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f > + beq s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f > + b 2f /* Loongson-3A1000/3A2000/3A3000/3A4000 */ > +1: dins a0, t2, 14, 2 /* Loongson-3B1000/3B1500 need bit 15~14 */ > +2: li t9, 0x100 /* wait for init loop */ > +3: addiu t9, -1 /* limit mailbox access */ > + bnez t9, 3b > + lw s1, 0x20(a0) /* check PC as an indicator */ > + beqz s1, 2b > + ld s1, 0x20(a0) /* get PC via mailbox reg0 */ > + ld sp, 0x28(a0) /* get SP via mailbox reg1 */ > + ld gp, 0x30(a0) /* get GP via mailbox reg2 */ > + ld a1, 0x38(a0) > + jr s1 /* jump to initial PC */ > +#endif > + > j s1 > END(kexec_smp_wait) > #endif > diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c > index 3bb8a1ed9348..c97bfdc8c922 100644 > --- a/arch/mips/loongson64/reset.c > +++ b/arch/mips/loongson64/reset.c > @@ -6,9 +6,14 @@ > * Copyright (C) 2009 Lemote, Inc. > * Author: Zhangjin Wu, wuzhangjin@gmail.com > */ > +#include <linux/cpu.h> > +#include <linux/delay.h> > #include <linux/init.h> > +#include <linux/kexec.h> > #include <linux/pm.h> > +#include <linux/slab.h> > > +#include <asm/bootinfo.h> > #include <asm/idle.h> > #include <asm/reboot.h> > > @@ -47,12 +52,120 @@ static void loongson_halt(void) > } > } > > +#ifdef CONFIG_KEXEC > + > +/* 0X80000000~0X80200000 is safe */ > +#define MAX_ARGS 64 > +#define KEXEC_CTRL_CODE 0xFFFFFFFF80100000UL > +#define KEXEC_ARGV_ADDR 0xFFFFFFFF80108000UL > +#define KEXEC_ARGV_SIZE COMMAND_LINE_SIZE > +#define KEXEC_ENVP_SIZE 4800 > + > +static int kexec_argc; > +static int kdump_argc; > +static void *kexec_argv; > +static void *kdump_argv; > +static void *kexec_envp; > + > +static int loongson_kexec_prepare(struct kimage *image) > +{ > + int i, argc = 0; > + unsigned int *argv; > + char *str, *ptr, *bootloader = "kexec"; > + > + /* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */ > + if (image->type == KEXEC_TYPE_DEFAULT) > + argv = (unsigned int *)kexec_argv; > + else > + argv = (unsigned int *)kdump_argv; > + > + argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2); > + > + for (i = 0; i < image->nr_segments; i++) { > + if (!strncmp(bootloader, (char *)image->segment[i].buf, > + strlen(bootloader))) { > + /* > + * convert command line string to array > + * of parameters (as bootloader does). > + */ > + int offt; > + str = (char *)argv + KEXEC_ARGV_SIZE/2; > + memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2); > + ptr = strchr(str, ' '); > + > + while (ptr && (argc < MAX_ARGS)) { > + *ptr = '\0'; > + if (ptr[1] != ' ') { > + offt = (int)(ptr - str + 1); > + argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt; > + argc++; > + } > + ptr = strchr(ptr + 1, ' '); > + } > + break; > + } > + } > + > + if (image->type == KEXEC_TYPE_DEFAULT) > + kexec_argc = argc; > + else > + kdump_argc = argc; > + > + /* kexec/kdump need a safe page to save reboot_code_buffer */ > + image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE); > + > + return 0; > +} > + > +static void loongson_kexec_shutdown(void) > +{ > +#ifdef CONFIG_SMP > + int cpu; > + > + /* All CPUs go to reboot_code_buffer */ > + for_each_possible_cpu(cpu) > + if (!cpu_online(cpu)) > + cpu_device_up(get_cpu_device(cpu)); > +#endif > + kexec_args[0] = kexec_argc; > + kexec_args[1] = fw_arg1; > + kexec_args[2] = fw_arg2; > + secondary_kexec_args[0] = TO_UNCAC(0x3ff01000); > + memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE); > + memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE); > +} > + > +static void loongson_crash_shutdown(struct pt_regs *regs) > +{ > + default_machine_crash_shutdown(regs); > + kexec_args[0] = kdump_argc; > + kexec_args[1] = fw_arg1; > + kexec_args[2] = fw_arg2; > + secondary_kexec_args[0] = TO_UNCAC(0x3ff01000); > + memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE); > + memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE); > +} > + > +#endif > + > static int __init mips_reboot_setup(void) > { > _machine_restart = loongson_restart; > _machine_halt = loongson_halt; > pm_power_off = loongson_poweroff; > > +#ifdef CONFIG_KEXEC > + kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL); > + kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL); > + kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL); > + fw_arg1 = KEXEC_ARGV_ADDR; > + memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE); > + > + _machine_kexec_prepare = loongson_kexec_prepare; > + _machine_kexec_shutdown = loongson_kexec_shutdown; > + _machine_crash_shutdown = loongson_crash_shutdown; > +#endif > + > return 0; > } >
Hi, Thomas, On Tue, Dec 22, 2020 at 2:41 PM Jinyang He <hejinyang@loongson.cn> wrote: > > On 12/21/2020 08:02 PM, Huacai Chen wrote: > > > From: Huacai Chen <chenhc@lemote.com> > > > > Add kexec/kdump support for Loongson64 by: > > 1, Provide Loongson-specific kexec functions: loongson_kexec_prepare(), > > loongson_kexec_shutdown() and loongson_crash_shutdown(); > > 2, Provide Loongson-specific assembly code in kexec_smp_wait(); > > > > To start Loongson64, The boot CPU needs 3 parameters: > > fw_arg0: the number of arguments in cmdline (i.e., argc). > > fw_arg1: structure holds cmdline such as "root=/dev/sda1 console=tty" > > (i.e., argv). > > fw_arg2: environment (i.e., envp, additional boot parameters from LEFI). > > > > Non-boot CPUs do not need one parameter as the IPI mailbox base address. > > They query their own IPI mailbox to get PC, SP and GP in a loopi, until > > the boot CPU brings them up. > > > > loongson_kexec_prepare(): Setup cmdline for kexec/kdump. The kexec/kdump > > cmdline comes from kexec's "append" option string. This structure will > > be parsed in fw_init_cmdline() of arch/mips/fw/lib/cmdline.c. Both image > > ->control_code_page and the cmdline need to be in a safe memory region > > (memory allocated by the old kernel may be corrupted by the new kernel). > > In order to maintain compatibility for the old firmware, the low 2MB is > > reserverd and safe for Loongson. So let KEXEC_CTRL_CODE and KEXEC_ARGV_ > > ADDR be here. LEFI parameters may be corrupted at runtime, so backup it > > at mips_reboot_setup(), and then restore it at loongson_kexec_shutdown() > > /loongson_crash_shutdown(). > > > > loongson_kexec_shutdown(): Wake up all present CPUs and let them go to > > reboot_code_buffer. Pass the kexec parameters to kexec_args. > > > > loongson_crash_shutdown(): Pass the kdump parameters to kexec_args. > > > > The assembly part in kexec_smp_wait provide a routine as BIOS does, in > > order to keep secondary CPUs in a querying loop. > > > > The layout of low 2MB memory in our design: > > 0x80000000, the first MB, the first 64K, Exception vectors > > 0x80010000, the first MB, the second 64K, STR (suspend) data > > 0x80020000, the first MB, the third and fourth 64K, UEFI HOB > > 0x80040000, the first MB, the fifth 64K, RT-Thread for SMC > > 0x80100000, the second MB, the first 64K, KEXEC code > > 0x80108000, the second MB, the second 64K, KEXEC data > > > > Cc: Eric Biederman <ebiederm@xmission.com> > > Signed-off-by: Huacai Chen <chenhuacai@kernel.org> > > Signed-off-by: Jinyang He <hejinyang@loongson.cn> > > Signed-off-by: Youling Tang <tangyouling@loongson.cn> > > --- > > V3: Some minor improvements suggested by Jinyang He. > > > > arch/mips/kernel/relocate_kernel.S | 28 +++++++ > > arch/mips/loongson64/reset.c | 113 +++++++++++++++++++++++++++++ > > 2 files changed, 141 insertions(+) > kexec-tools v2.0.21 > 3A3000/7A1000 3A4000/7A1000 > > Test kexec: > > # kexec -l vmlinux --append="<cmdline>" > # kexec -e > > Result: OK! > > Test kdump: We need a capture kernel to dump the panic kernel. > To build the capture kernel: > make loongson3_defconfig and set CONFIG_PROC_VMCORE=y , CONFIG_CRASH_DUMP=y > and CONFIG_PHYSICAL_START=0xffffffff84000000 > > # kexec -p vmlinux(capture) --append="<cmdline>" > # echo c > /proc/sysrq-trigger > > Result: OK! > > Tested-by: Jinyang He <hejinyang@loongson.cn> > > Thanks, :-) > Jinyang Any comments? Huacai > > > diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S > > index ac870893ba2d..f649ffa0f427 100644 > > --- a/arch/mips/kernel/relocate_kernel.S > > +++ b/arch/mips/kernel/relocate_kernel.S > > @@ -6,6 +6,7 @@ > > > > #include <asm/asm.h> > > #include <asm/asmmacro.h> > > +#include <asm/cpu.h> > > #include <asm/regdef.h> > > #include <asm/mipsregs.h> > > #include <asm/stackframe.h> > > @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) > > #else > > sync > > #endif > > + > > +#ifdef CONFIG_CPU_LOONGSON64 > > + /* s0:prid s1:initfn */ > > + /* a0:base t1:cpuid t2:node t9:count */ > > + mfc0 t1, CP0_EBASE > > + andi t1, MIPS_EBASE_CPUNUM > > + dins a0, t1, 8, 2 /* insert core id*/ > > + dext t2, t1, 2, 2 > > + dins a0, t2, 44, 2 /* insert node id */ > > + mfc0 s0, CP0_PRID > > + andi s0, s0, (PRID_IMP_MASK | PRID_REV_MASK) > > + beq s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f > > + beq s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f > > + b 2f /* Loongson-3A1000/3A2000/3A3000/3A4000 */ > > +1: dins a0, t2, 14, 2 /* Loongson-3B1000/3B1500 need bit 15~14 */ > > +2: li t9, 0x100 /* wait for init loop */ > > +3: addiu t9, -1 /* limit mailbox access */ > > + bnez t9, 3b > > + lw s1, 0x20(a0) /* check PC as an indicator */ > > + beqz s1, 2b > > + ld s1, 0x20(a0) /* get PC via mailbox reg0 */ > > + ld sp, 0x28(a0) /* get SP via mailbox reg1 */ > > + ld gp, 0x30(a0) /* get GP via mailbox reg2 */ > > + ld a1, 0x38(a0) > > + jr s1 /* jump to initial PC */ > > +#endif > > + > > j s1 > > END(kexec_smp_wait) > > #endif > > diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c > > index 3bb8a1ed9348..c97bfdc8c922 100644 > > --- a/arch/mips/loongson64/reset.c > > +++ b/arch/mips/loongson64/reset.c > > @@ -6,9 +6,14 @@ > > * Copyright (C) 2009 Lemote, Inc. > > * Author: Zhangjin Wu, wuzhangjin@gmail.com > > */ > > +#include <linux/cpu.h> > > +#include <linux/delay.h> > > #include <linux/init.h> > > +#include <linux/kexec.h> > > #include <linux/pm.h> > > +#include <linux/slab.h> > > > > +#include <asm/bootinfo.h> > > #include <asm/idle.h> > > #include <asm/reboot.h> > > > > @@ -47,12 +52,120 @@ static void loongson_halt(void) > > } > > } > > > > +#ifdef CONFIG_KEXEC > > + > > +/* 0X80000000~0X80200000 is safe */ > > +#define MAX_ARGS 64 > > +#define KEXEC_CTRL_CODE 0xFFFFFFFF80100000UL > > +#define KEXEC_ARGV_ADDR 0xFFFFFFFF80108000UL > > +#define KEXEC_ARGV_SIZE COMMAND_LINE_SIZE > > +#define KEXEC_ENVP_SIZE 4800 > > + > > +static int kexec_argc; > > +static int kdump_argc; > > +static void *kexec_argv; > > +static void *kdump_argv; > > +static void *kexec_envp; > > + > > +static int loongson_kexec_prepare(struct kimage *image) > > +{ > > + int i, argc = 0; > > + unsigned int *argv; > > + char *str, *ptr, *bootloader = "kexec"; > > + > > + /* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */ > > + if (image->type == KEXEC_TYPE_DEFAULT) > > + argv = (unsigned int *)kexec_argv; > > + else > > + argv = (unsigned int *)kdump_argv; > > + > > + argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2); > > + > > + for (i = 0; i < image->nr_segments; i++) { > > + if (!strncmp(bootloader, (char *)image->segment[i].buf, > > + strlen(bootloader))) { > > + /* > > + * convert command line string to array > > + * of parameters (as bootloader does). > > + */ > > + int offt; > > + str = (char *)argv + KEXEC_ARGV_SIZE/2; > > + memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2); > > + ptr = strchr(str, ' '); > > + > > + while (ptr && (argc < MAX_ARGS)) { > > + *ptr = '\0'; > > + if (ptr[1] != ' ') { > > + offt = (int)(ptr - str + 1); > > + argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt; > > + argc++; > > + } > > + ptr = strchr(ptr + 1, ' '); > > + } > > + break; > > + } > > + } > > + > > + if (image->type == KEXEC_TYPE_DEFAULT) > > + kexec_argc = argc; > > + else > > + kdump_argc = argc; > > + > > + /* kexec/kdump need a safe page to save reboot_code_buffer */ > > + image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE); > > + > > + return 0; > > +} > > + > > +static void loongson_kexec_shutdown(void) > > +{ > > +#ifdef CONFIG_SMP > > + int cpu; > > + > > + /* All CPUs go to reboot_code_buffer */ > > + for_each_possible_cpu(cpu) > > + if (!cpu_online(cpu)) > > + cpu_device_up(get_cpu_device(cpu)); > > +#endif > > + kexec_args[0] = kexec_argc; > > + kexec_args[1] = fw_arg1; > > + kexec_args[2] = fw_arg2; > > + secondary_kexec_args[0] = TO_UNCAC(0x3ff01000); > > + memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE); > > + memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE); > > +} > > + > > +static void loongson_crash_shutdown(struct pt_regs *regs) > > +{ > > + default_machine_crash_shutdown(regs); > > + kexec_args[0] = kdump_argc; > > + kexec_args[1] = fw_arg1; > > + kexec_args[2] = fw_arg2; > > + secondary_kexec_args[0] = TO_UNCAC(0x3ff01000); > > + memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE); > > + memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE); > > +} > > + > > +#endif > > + > > static int __init mips_reboot_setup(void) > > { > > _machine_restart = loongson_restart; > > _machine_halt = loongson_halt; > > pm_power_off = loongson_poweroff; > > > > +#ifdef CONFIG_KEXEC > > + kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL); > > + kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL); > > + kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL); > > + fw_arg1 = KEXEC_ARGV_ADDR; > > + memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE); > > + > > + _machine_kexec_prepare = loongson_kexec_prepare; > > + _machine_kexec_shutdown = loongson_kexec_shutdown; > > + _machine_crash_shutdown = loongson_crash_shutdown; > > +#endif > > + > > return 0; > > } > > >
On Thu, Dec 31, 2020 at 09:23:33AM +0800, Huacai Chen wrote: > > Thanks, :-) > > Jinyang > Any comments? sure... > > > --- a/arch/mips/kernel/relocate_kernel.S > > > +++ b/arch/mips/kernel/relocate_kernel.S > > > @@ -6,6 +6,7 @@ > > > > > > #include <asm/asm.h> > > > #include <asm/asmmacro.h> > > > +#include <asm/cpu.h> > > > #include <asm/regdef.h> > > > #include <asm/mipsregs.h> > > > #include <asm/stackframe.h> > > > @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) > > > #else > > > sync > > > #endif > > > + > > > +#ifdef CONFIG_CPU_LOONGSON64 Is there a reason why you can't use the already existing infrastructure the way cavium-octeon is doing it ? If you can't please explain why so we can find a way to extend it. But having some sort of poking loongson registers in generic MIPS code is a non starter. Thomas.
Hi, Thomas, On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote: >>>> --- a/arch/mips/kernel/relocate_kernel.S >>>> +++ b/arch/mips/kernel/relocate_kernel.S >>>> @@ -6,6 +6,7 @@ >>>> >>>> #include <asm/asm.h> >>>> #include <asm/asmmacro.h> >>>> +#include <asm/cpu.h> >>>> #include <asm/regdef.h> >>>> #include <asm/mipsregs.h> >>>> #include <asm/stackframe.h> >>>> @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) >>>> #else >>>> sync >>>> #endif >>>> + >>>> +#ifdef CONFIG_CPU_LOONGSON64 > Is there a reason why you can't use the already existing infrastructure > the way cavium-octeon is doing it ? If you can't please explain why > so we can find a way to extend it. But having some sort of poking > loongson registers in generic MIPS code is a non starter. > > Thomas. > Unlike the cavium-octeon platform, the Loongson64 platform needs some changes. Before the kernel starts, (before entering the kernel_entry), each CPU has its own state (the SMP system). For Loongson64, only the boot CPU will enter the kernel_entry, and other CPUs will query their mailbox value in a loop. This is what the BIOS does for the CPU. Here is different from cavium-octeon. All CPUs will enter the kernel_entry on cavium-octeon platform. Then the kernel_entry_setup, the co-CPUs will enter the query loop. I saw the kernel_entry_setup of other platforms, such as ip27, malta, and generic. They are not like cavium-octeon and the co-CPUs entering the loop may be earlier than entering kernel_entry. So I have reason to guess that most SMP system platform CPUs are similar to Loongson64. relocate_kernel.S is like BIOS doing s omething for the CPU. It allows the boot CPU to start from the new kernel_entry and makes the co-CPUs enter a loop. The already existing infrastructure may be more suitable for non-smp platforms. Although we can do something with plat_smp_ops.kexec_nonboot_cpu, more new problems will arise in that case. The kexec process actually runs on a copy of relocate_kernel.S, which will bring a lot of problems... Above all just my personal thoughts. Thanks, Jinyang
在 2021/1/8 下午6:07, Jinyang He 写道: > Hi, Thomas, > > On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote: >>>>> --- a/arch/mips/kernel/relocate_kernel.S >>>>> +++ b/arch/mips/kernel/relocate_kernel.S >>>>> @@ -6,6 +6,7 @@ >>>>> >>>>> #include <asm/asm.h> >>>>> #include <asm/asmmacro.h> >>>>> +#include <asm/cpu.h> >>>>> #include <asm/regdef.h> >>>>> #include <asm/mipsregs.h> >>>>> #include <asm/stackframe.h> >>>>> @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) >>>>> #else >>>>> sync >>>>> #endif >>>>> + >>>>> +#ifdef CONFIG_CPU_LOONGSON64 >> Is there a reason why you can't use the already existing infrastructure >> the way cavium-octeon is doing it ? If you can't please explain why >> so we can find a way to extend it. But having some sort of poking >> loongson registers in generic MIPS code is a non starter. >> >> Thomas. >> > > Unlike the cavium-octeon platform, the Loongson64 platform needs some > changes. Before the kernel starts, (before entering the kernel_entry), > each CPU has its own state (the SMP system). For Loongson64, only the > boot CPU will enter the kernel_entry, and other CPUs will query their > mailbox value in a loop. This is what the BIOS does for the CPU. Here > is different from cavium-octeon. All CPUs will enter the kernel_entry > on cavium-octeon platform. Then the kernel_entry_setup, the co-CPUs > will enter the query loop. I saw the kernel_entry_setup of other > platforms, such as ip27, malta, and generic. They are not like > cavium-octeon and the co-CPUs entering the loop may be earlier than > entering kernel_entry. So I have reason to guess that most SMP system > platform CPUs are similar to Loongson64. Hi Jingyang, As I commented before you may reuse play_dead logic in Loongson's smp.c. > > relocate_kernel.S is like BIOS doing s omething for the CPU. It allows > the boot CPU to start from the new kernel_entry and makes the co-CPUs > enter a loop. The already existing infrastructure may be more suitable > for non-smp platforms. Although we can do something with > plat_smp_ops.kexec_nonboot_cpu, more new problems will arise in that > case. The kexec process actually runs on a copy of relocate_kernel.S, > which will bring a lot of problems... It won't be a problem as you can keep all data on-stack without external reference. Thanks. - Jiaxun > > Above all just my personal thoughts. > > Thanks, > Jinyang >
Hi, Jiaxun, On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote: > > 在 2021/1/8 下午6:07, Jinyang He 写道: > > Hi, Thomas, > > > > On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote: > >>>>> --- a/arch/mips/kernel/relocate_kernel.S > >>>>> +++ b/arch/mips/kernel/relocate_kernel.S > >>>>> @@ -6,6 +6,7 @@ > >>>>> > >>>>> #include <asm/asm.h> > >>>>> #include <asm/asmmacro.h> > >>>>> +#include <asm/cpu.h> > >>>>> #include <asm/regdef.h> > >>>>> #include <asm/mipsregs.h> > >>>>> #include <asm/stackframe.h> > >>>>> @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) > >>>>> #else > >>>>> sync > >>>>> #endif > >>>>> + > >>>>> +#ifdef CONFIG_CPU_LOONGSON64 > >> Is there a reason why you can't use the already existing infrastructure > >> the way cavium-octeon is doing it ? If you can't please explain why > >> so we can find a way to extend it. But having some sort of poking > >> loongson registers in generic MIPS code is a non starter. > >> > >> Thomas. > >> > > > > Unlike the cavium-octeon platform, the Loongson64 platform needs some > > changes. Before the kernel starts, (before entering the kernel_entry), > > each CPU has its own state (the SMP system). For Loongson64, only the > > boot CPU will enter the kernel_entry, and other CPUs will query their > > mailbox value in a loop. This is what the BIOS does for the CPU. Here > > is different from cavium-octeon. All CPUs will enter the kernel_entry > > on cavium-octeon platform. Then the kernel_entry_setup, the co-CPUs > > will enter the query loop. I saw the kernel_entry_setup of other > > platforms, such as ip27, malta, and generic. They are not like > > cavium-octeon and the co-CPUs entering the loop may be earlier than > > entering kernel_entry. So I have reason to guess that most SMP system > > platform CPUs are similar to Loongson64. > > Hi Jingyang, > > As I commented before you may reuse play_dead logic in Loongson's smp.c. > > > > > relocate_kernel.S is like BIOS doing s omething for the CPU. It allows > > the boot CPU to start from the new kernel_entry and makes the co-CPUs > > enter a loop. The already existing infrastructure may be more suitable > > for non-smp platforms. Although we can do something with > > plat_smp_ops.kexec_nonboot_cpu, more new problems will arise in that > > case. The kexec process actually runs on a copy of relocate_kernel.S, > > which will bring a lot of problems... > > It won't be a problem as you can keep all data on-stack without external > reference. > > Thanks. As I said before, only the control page is safe during kexec, so we cannot reuse smp.c. If BIOS provides play_dead(), that is also a safe region, but currently there is no runtime service from BIOS. Huacai > > - Jiaxun > > > > > Above all just my personal thoughts. > > > > Thanks, > > Jinyang > > >
在 2021/1/9 上午9:36, Huacai Chen 写道: > Hi, Jiaxun, > > On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote: >> 在 2021/1/8 下午6:07, Jinyang He 写道: >>> Hi, Thomas, >>> >>> On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote: >>>>>>> --- a/arch/mips/kernel/relocate_kernel.S >>>>>>> +++ b/arch/mips/kernel/relocate_kernel.S >>>>>>> @@ -6,6 +6,7 @@ >>>>>>> >>>>>>> #include <asm/asm.h> >>>>>>> #include <asm/asmmacro.h> >>>>>>> +#include <asm/cpu.h> >>>>>>> #include <asm/regdef.h> >>>>>>> #include <asm/mipsregs.h> >>>>>>> #include <asm/stackframe.h> >>>>>>> @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) >>>>>>> #else >>>>>>> sync >>>>>>> #endif >>>>>>> + >>>>>>> +#ifdef CONFIG_CPU_LOONGSON64 >>>> Is there a reason why you can't use the already existing infrastructure >>>> the way cavium-octeon is doing it ? If you can't please explain why >>>> so we can find a way to extend it. But having some sort of poking >>>> loongson registers in generic MIPS code is a non starter. >>>> >>>> Thomas. >>>> >>> Unlike the cavium-octeon platform, the Loongson64 platform needs some >>> changes. Before the kernel starts, (before entering the kernel_entry), >>> each CPU has its own state (the SMP system). For Loongson64, only the >>> boot CPU will enter the kernel_entry, and other CPUs will query their >>> mailbox value in a loop. This is what the BIOS does for the CPU. Here >>> is different from cavium-octeon. All CPUs will enter the kernel_entry >>> on cavium-octeon platform. Then the kernel_entry_setup, the co-CPUs >>> will enter the query loop. I saw the kernel_entry_setup of other >>> platforms, such as ip27, malta, and generic. They are not like >>> cavium-octeon and the co-CPUs entering the loop may be earlier than >>> entering kernel_entry. So I have reason to guess that most SMP system >>> platform CPUs are similar to Loongson64. >> Hi Jingyang, >> >> As I commented before you may reuse play_dead logic in Loongson's smp.c. >> >>> relocate_kernel.S is like BIOS doing s omething for the CPU. It allows >>> the boot CPU to start from the new kernel_entry and makes the co-CPUs >>> enter a loop. The already existing infrastructure may be more suitable >>> for non-smp platforms. Although we can do something with >>> plat_smp_ops.kexec_nonboot_cpu, more new problems will arise in that >>> case. The kexec process actually runs on a copy of relocate_kernel.S, >>> which will bring a lot of problems... >> It won't be a problem as you can keep all data on-stack without external >> reference. >> >> Thanks. > As I said before, only the control page is safe during kexec, so we > cannot reuse smp.c. If BIOS provides play_dead(), that is also a safe > region, but currently there is no runtime service from BIOS. Sorry, ignored the overlap case :-( Jumping to 0xbfc00000 to use firmware boot vector seems a little bit overkill. But we'd better delivery it into platform folder, just like kernel-entry-init.h Thanks. - Jiaxun > > Huacai >> - Jiaxun >> >>> Above all just my personal thoughts. >>> >>> Thanks, >>> Jinyang >>>
Hi, Jiaxun, On Sat, Jan 9, 2021 at 3:38 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote: > > 在 2021/1/9 上午9:36, Huacai Chen 写道: > > Hi, Jiaxun, > > > > On Fri, Jan 8, 2021 at 6:15 PM Jiaxun Yang <jiaxun.yang@flygoat.com> wrote: > >> 在 2021/1/8 下午6:07, Jinyang He 写道: > >>> Hi, Thomas, > >>> > >>> On 01/08/2021 01:26 AM, Thomas Bogendoerfer wrote: > >>>>>>> --- a/arch/mips/kernel/relocate_kernel.S > >>>>>>> +++ b/arch/mips/kernel/relocate_kernel.S > >>>>>>> @@ -6,6 +6,7 @@ > >>>>>>> > >>>>>>> #include <asm/asm.h> > >>>>>>> #include <asm/asmmacro.h> > >>>>>>> +#include <asm/cpu.h> > >>>>>>> #include <asm/regdef.h> > >>>>>>> #include <asm/mipsregs.h> > >>>>>>> #include <asm/stackframe.h> > >>>>>>> @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) > >>>>>>> #else > >>>>>>> sync > >>>>>>> #endif > >>>>>>> + > >>>>>>> +#ifdef CONFIG_CPU_LOONGSON64 > >>>> Is there a reason why you can't use the already existing infrastructure > >>>> the way cavium-octeon is doing it ? If you can't please explain why > >>>> so we can find a way to extend it. But having some sort of poking > >>>> loongson registers in generic MIPS code is a non starter. > >>>> > >>>> Thomas. > >>>> > >>> Unlike the cavium-octeon platform, the Loongson64 platform needs some > >>> changes. Before the kernel starts, (before entering the kernel_entry), > >>> each CPU has its own state (the SMP system). For Loongson64, only the > >>> boot CPU will enter the kernel_entry, and other CPUs will query their > >>> mailbox value in a loop. This is what the BIOS does for the CPU. Here > >>> is different from cavium-octeon. All CPUs will enter the kernel_entry > >>> on cavium-octeon platform. Then the kernel_entry_setup, the co-CPUs > >>> will enter the query loop. I saw the kernel_entry_setup of other > >>> platforms, such as ip27, malta, and generic. They are not like > >>> cavium-octeon and the co-CPUs entering the loop may be earlier than > >>> entering kernel_entry. So I have reason to guess that most SMP system > >>> platform CPUs are similar to Loongson64. > >> Hi Jingyang, > >> > >> As I commented before you may reuse play_dead logic in Loongson's smp.c. > >> > >>> relocate_kernel.S is like BIOS doing s omething for the CPU. It allows > >>> the boot CPU to start from the new kernel_entry and makes the co-CPUs > >>> enter a loop. The already existing infrastructure may be more suitable > >>> for non-smp platforms. Although we can do something with > >>> plat_smp_ops.kexec_nonboot_cpu, more new problems will arise in that > >>> case. The kexec process actually runs on a copy of relocate_kernel.S, > >>> which will bring a lot of problems... > >> It won't be a problem as you can keep all data on-stack without external > >> reference. > >> > >> Thanks. > > As I said before, only the control page is safe during kexec, so we > > cannot reuse smp.c. If BIOS provides play_dead(), that is also a safe > > region, but currently there is no runtime service from BIOS. > > Sorry, ignored the overlap case :-( > > Jumping to 0xbfc00000 to use firmware boot vector seems a little bit > overkill. > > But we'd better delivery it into platform folder, just like > kernel-entry-init.h Even if we move something to kernel-entry-init.h, we still need to modify arch/mips/kernel/relocate_kernel.S. Huacai > > Thanks. > > - Jiaxun > > > > > Huacai > >> - Jiaxun > >> > >>> Above all just my personal thoughts. > >>> > >>> Thanks, > >>> Jinyang > >>> >
On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote: > Unlike the cavium-octeon platform, the Loongson64 platform needs some > changes. Before the kernel starts, (before entering the kernel_entry), each > CPU has its own state (the SMP system). For Loongson64, only the boot CPU > will enter the kernel_entry, and other CPUs will query their mailbox value > in a loop. This is what the BIOS does for the CPU. Here is different from > cavium-octeon. All CPUs will enter the kernel_entry on cavium-octeon > platform. Then the kernel_entry_setup, the co-CPUs will enter the query > loop. I saw the kernel_entry_setup of other platforms, such as ip27, malta, > and generic. They are not like cavium-octeon and the co-CPUs entering the > loop may be earlier than entering kernel_entry. So I have reason to guess > that most SMP system platform CPUs are similar to Loongson64. > > relocate_kernel.S is like BIOS doing s omething for the CPU. It allows the > boot CPU to start from the new kernel_entry and makes the co-CPUs enter a > loop. The already existing infrastructure may be more suitable for non-smp > platforms. Although we can do something with plat_smp_ops.kexec_nonboot_cpu, > more new problems will arise in that case. The kexec process actually runs > on a copy of relocate_kernel.S, which will bring a lot of problems... > > Above all just my personal thoughts. thank you for describing current state. So it looks like kexec and SMP is probably only working for Octeon and maybe some MIPS VPE based SMP systems, but not with "real" cores. How about the patch below as preparation for your loongson64 kexec patch ? You only need to put write a kexec_smp_wait_final macro and the rest of your patch stays the same... Thomas. From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001 From: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Date: Tue, 19 Jan 2021 21:58:55 +0100 Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> --- .../include/asm/mach-cavium-octeon/kernel-entry-init.h | 8 ++++++++ arch/mips/kernel/relocate_kernel.S | 9 ++++----- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h index c38b38ce5a3d..b071a7353ee1 100644 --- a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h +++ b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h @@ -157,4 +157,12 @@ .macro smp_slave_setup .endm +#define USE_KEXEC_SMP_WAIT_FINAL + .macro kexec_smp_wait_final + .set push + .set noreorder + synci 0($0) + .set pop + .endm + #endif /* __ASM_MACH_CAVIUM_OCTEON_KERNEL_ENTRY_H */ diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S index ac870893ba2d..f3c908abdbb8 100644 --- a/arch/mips/kernel/relocate_kernel.S +++ b/arch/mips/kernel/relocate_kernel.S @@ -11,6 +11,8 @@ #include <asm/stackframe.h> #include <asm/addrspace.h> +#include <kernel-entry-init.h> + LEAF(relocate_new_kernel) PTR_L a0, arg0 PTR_L a1, arg1 @@ -125,11 +127,8 @@ LEAF(kexec_smp_wait) 1: LONG_L s0, (t0) bne s0, zero,1b -#ifdef CONFIG_CPU_CAVIUM_OCTEON - .set push - .set noreorder - synci 0($0) - .set pop +#ifdef USE_KEXEC_SMP_WAIT_FINAL + kexec_smp_wait_final #else sync #endif
On 01/20/2021 05:08 AM, Thomas Bogendoerfer wrote: > On Fri, Jan 08, 2021 at 06:07:39PM +0800, Jinyang He wrote: >> Unlike the cavium-octeon platform, the Loongson64 platform needs some >> changes. Before the kernel starts, (before entering the kernel_entry), each >> CPU has its own state (the SMP system). For Loongson64, only the boot CPU >> will enter the kernel_entry, and other CPUs will query their mailbox value >> in a loop. This is what the BIOS does for the CPU. Here is different from >> cavium-octeon. All CPUs will enter the kernel_entry on cavium-octeon >> platform. Then the kernel_entry_setup, the co-CPUs will enter the query >> loop. I saw the kernel_entry_setup of other platforms, such as ip27, malta, >> and generic. They are not like cavium-octeon and the co-CPUs entering the >> loop may be earlier than entering kernel_entry. So I have reason to guess >> that most SMP system platform CPUs are similar to Loongson64. >> >> relocate_kernel.S is like BIOS doing s omething for the CPU. It allows the >> boot CPU to start from the new kernel_entry and makes the co-CPUs enter a >> loop. The already existing infrastructure may be more suitable for non-smp >> platforms. Although we can do something with plat_smp_ops.kexec_nonboot_cpu, >> more new problems will arise in that case. The kexec process actually runs >> on a copy of relocate_kernel.S, which will bring a lot of problems... >> >> Above all just my personal thoughts. > thank you for describing current state. So it looks like kexec and SMP > is probably only working for Octeon and maybe some MIPS VPE based SMP > systems, but not with "real" cores. > > How about the patch below as preparation for your loongson64 kexec patch ? > You only need to put write a kexec_smp_wait_final macro and the rest of > your patch stays the same... > > Thomas. Thank you for this patch. By applying your patch and the revised Huacai's patch, kexec works well on the Loongson-3A4000. I compared the assembly code, too. It's the same as the previous patch doing. I think it's correct. Huacai, how do you think about it? Thanks, :-) Jinyang > > From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001 > From: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > Date: Tue, 19 Jan 2021 21:58:55 +0100 > Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials > > Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> > --- > .../include/asm/mach-cavium-octeon/kernel-entry-init.h | 8 ++++++++ > arch/mips/kernel/relocate_kernel.S | 9 ++++----- > 2 files changed, 12 insertions(+), 5 deletions(-) > > diff --git a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h > index c38b38ce5a3d..b071a7353ee1 100644 > --- a/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h > +++ b/arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h > @@ -157,4 +157,12 @@ > .macro smp_slave_setup > .endm > > +#define USE_KEXEC_SMP_WAIT_FINAL > + .macro kexec_smp_wait_final > + .set push > + .set noreorder > + synci 0($0) > + .set pop > + .endm > + > #endif /* __ASM_MACH_CAVIUM_OCTEON_KERNEL_ENTRY_H */ > diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S > index ac870893ba2d..f3c908abdbb8 100644 > --- a/arch/mips/kernel/relocate_kernel.S > +++ b/arch/mips/kernel/relocate_kernel.S > @@ -11,6 +11,8 @@ > #include <asm/stackframe.h> > #include <asm/addrspace.h> > > +#include <kernel-entry-init.h> > + > LEAF(relocate_new_kernel) > PTR_L a0, arg0 > PTR_L a1, arg1 > @@ -125,11 +127,8 @@ LEAF(kexec_smp_wait) > 1: LONG_L s0, (t0) > bne s0, zero,1b > > -#ifdef CONFIG_CPU_CAVIUM_OCTEON > - .set push > - .set noreorder > - synci 0($0) > - .set pop > +#ifdef USE_KEXEC_SMP_WAIT_FINAL > + kexec_smp_wait_final > #else > sync > #endif
diff --git a/arch/mips/kernel/relocate_kernel.S b/arch/mips/kernel/relocate_kernel.S index ac870893ba2d..f649ffa0f427 100644 --- a/arch/mips/kernel/relocate_kernel.S +++ b/arch/mips/kernel/relocate_kernel.S @@ -6,6 +6,7 @@ #include <asm/asm.h> #include <asm/asmmacro.h> +#include <asm/cpu.h> #include <asm/regdef.h> #include <asm/mipsregs.h> #include <asm/stackframe.h> @@ -133,6 +134,33 @@ LEAF(kexec_smp_wait) #else sync #endif + +#ifdef CONFIG_CPU_LOONGSON64 + /* s0:prid s1:initfn */ + /* a0:base t1:cpuid t2:node t9:count */ + mfc0 t1, CP0_EBASE + andi t1, MIPS_EBASE_CPUNUM + dins a0, t1, 8, 2 /* insert core id*/ + dext t2, t1, 2, 2 + dins a0, t2, 44, 2 /* insert node id */ + mfc0 s0, CP0_PRID + andi s0, s0, (PRID_IMP_MASK | PRID_REV_MASK) + beq s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R1), 1f + beq s0, (PRID_IMP_LOONGSON_64C | PRID_REV_LOONGSON3B_R2), 1f + b 2f /* Loongson-3A1000/3A2000/3A3000/3A4000 */ +1: dins a0, t2, 14, 2 /* Loongson-3B1000/3B1500 need bit 15~14 */ +2: li t9, 0x100 /* wait for init loop */ +3: addiu t9, -1 /* limit mailbox access */ + bnez t9, 3b + lw s1, 0x20(a0) /* check PC as an indicator */ + beqz s1, 2b + ld s1, 0x20(a0) /* get PC via mailbox reg0 */ + ld sp, 0x28(a0) /* get SP via mailbox reg1 */ + ld gp, 0x30(a0) /* get GP via mailbox reg2 */ + ld a1, 0x38(a0) + jr s1 /* jump to initial PC */ +#endif + j s1 END(kexec_smp_wait) #endif diff --git a/arch/mips/loongson64/reset.c b/arch/mips/loongson64/reset.c index 3bb8a1ed9348..c97bfdc8c922 100644 --- a/arch/mips/loongson64/reset.c +++ b/arch/mips/loongson64/reset.c @@ -6,9 +6,14 @@ * Copyright (C) 2009 Lemote, Inc. * Author: Zhangjin Wu, wuzhangjin@gmail.com */ +#include <linux/cpu.h> +#include <linux/delay.h> #include <linux/init.h> +#include <linux/kexec.h> #include <linux/pm.h> +#include <linux/slab.h> +#include <asm/bootinfo.h> #include <asm/idle.h> #include <asm/reboot.h> @@ -47,12 +52,120 @@ static void loongson_halt(void) } } +#ifdef CONFIG_KEXEC + +/* 0X80000000~0X80200000 is safe */ +#define MAX_ARGS 64 +#define KEXEC_CTRL_CODE 0xFFFFFFFF80100000UL +#define KEXEC_ARGV_ADDR 0xFFFFFFFF80108000UL +#define KEXEC_ARGV_SIZE COMMAND_LINE_SIZE +#define KEXEC_ENVP_SIZE 4800 + +static int kexec_argc; +static int kdump_argc; +static void *kexec_argv; +static void *kdump_argv; +static void *kexec_envp; + +static int loongson_kexec_prepare(struct kimage *image) +{ + int i, argc = 0; + unsigned int *argv; + char *str, *ptr, *bootloader = "kexec"; + + /* argv at offset 0, argv[] at offset KEXEC_ARGV_SIZE/2 */ + if (image->type == KEXEC_TYPE_DEFAULT) + argv = (unsigned int *)kexec_argv; + else + argv = (unsigned int *)kdump_argv; + + argv[argc++] = (unsigned int)(KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2); + + for (i = 0; i < image->nr_segments; i++) { + if (!strncmp(bootloader, (char *)image->segment[i].buf, + strlen(bootloader))) { + /* + * convert command line string to array + * of parameters (as bootloader does). + */ + int offt; + str = (char *)argv + KEXEC_ARGV_SIZE/2; + memcpy(str, image->segment[i].buf, KEXEC_ARGV_SIZE/2); + ptr = strchr(str, ' '); + + while (ptr && (argc < MAX_ARGS)) { + *ptr = '\0'; + if (ptr[1] != ' ') { + offt = (int)(ptr - str + 1); + argv[argc] = KEXEC_ARGV_ADDR + KEXEC_ARGV_SIZE/2 + offt; + argc++; + } + ptr = strchr(ptr + 1, ' '); + } + break; + } + } + + if (image->type == KEXEC_TYPE_DEFAULT) + kexec_argc = argc; + else + kdump_argc = argc; + + /* kexec/kdump need a safe page to save reboot_code_buffer */ + image->control_code_page = virt_to_page((void *)KEXEC_CTRL_CODE); + + return 0; +} + +static void loongson_kexec_shutdown(void) +{ +#ifdef CONFIG_SMP + int cpu; + + /* All CPUs go to reboot_code_buffer */ + for_each_possible_cpu(cpu) + if (!cpu_online(cpu)) + cpu_device_up(get_cpu_device(cpu)); +#endif + kexec_args[0] = kexec_argc; + kexec_args[1] = fw_arg1; + kexec_args[2] = fw_arg2; + secondary_kexec_args[0] = TO_UNCAC(0x3ff01000); + memcpy((void *)fw_arg1, kexec_argv, KEXEC_ARGV_SIZE); + memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE); +} + +static void loongson_crash_shutdown(struct pt_regs *regs) +{ + default_machine_crash_shutdown(regs); + kexec_args[0] = kdump_argc; + kexec_args[1] = fw_arg1; + kexec_args[2] = fw_arg2; + secondary_kexec_args[0] = TO_UNCAC(0x3ff01000); + memcpy((void *)fw_arg1, kdump_argv, KEXEC_ARGV_SIZE); + memcpy((void *)fw_arg2, kexec_envp, KEXEC_ENVP_SIZE); +} + +#endif + static int __init mips_reboot_setup(void) { _machine_restart = loongson_restart; _machine_halt = loongson_halt; pm_power_off = loongson_poweroff; +#ifdef CONFIG_KEXEC + kexec_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL); + kdump_argv = kmalloc(KEXEC_ARGV_SIZE, GFP_KERNEL); + kexec_envp = kmalloc(KEXEC_ENVP_SIZE, GFP_KERNEL); + fw_arg1 = KEXEC_ARGV_ADDR; + memcpy(kexec_envp, (void *)fw_arg2, KEXEC_ENVP_SIZE); + + _machine_kexec_prepare = loongson_kexec_prepare; + _machine_kexec_shutdown = loongson_kexec_shutdown; + _machine_crash_shutdown = loongson_crash_shutdown; +#endif + return 0; }