Skip to contentSkip to conversation

MIPS: Loongson64: Add kexec/kdump support

PATCH In review Huacai Chen 4 participants 11 messages Dec 21, 2020 – Jan 20, 2021

Subsystems (4)
MIPS Live update kexec handover (KHO) MIPS/LOONGSON64 architecture
lore
Share & tools
lore

Huacai Chen

author maintainer
#0 lore raw

PATCH v3 1/1 MIPS: Loongson64: Add kexec/kdump support

From: Huacai Chen <[email protected]>

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 <[email protected]>
Signed-off-by Huacai Chen <[email protected]>
Signed-off-by Jinyang He <[email protected]>
Signed-off-by Youling Tang <[email protected]>

---
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(+)
arch/mips/kernel/relocate_kernel.S +28 -0
index ac870893ba2d..f649ffa0f427 100644
@@ -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
arch/mips/loongson64/reset.c +113 -0

134 lines not on this page · raw message

Signature · 7 lines
2.27.0


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Tested-by on v3 1/1
#1 lore raw
Quoted 48 lines · Huacai Chen

From: Huacai Chen <[email protected]>

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 <[email protected]>
Signed-off-by Huacai Chen <[email protected]>
Signed-off-by Jinyang He <[email protected]>
Signed-off-by Youling Tang <[email protected]>
Quoted 6 lines

---
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 <[email protected]>

Thanks, :-)
Jinyang

Quoted 176 lines
arch/mips/kernel/relocate_kernel.S +28 -0
index ac870893ba2d..f649ffa0f427 100644
@@ -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
arch/mips/loongson64/reset.c +106 -0
index 3bb8a1ed9348..c97bfdc8c922 100644
@@ -6,9 +6,14 @@
   * Copyright (C) 2009 Lemote, Inc.
   * Author: Zhangjin Wu, [email protected]
   */
+#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;

arch/mips/loongson64/reset.c static void loongson_halt(void) · line 171

Quoted 10 lines
arch/mips/loongson64/reset.c +7 -0
+	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;
  }

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

author maintainer
#2 lore raw

Hi, Thomas,

Quoted 75 lines · Jinyang He
Quoted 48 lines · Huacai Chen

From: Huacai Chen <[email protected]>

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 <[email protected]>
Signed-off-by Huacai Chen <[email protected]>
Signed-off-by Jinyang He <[email protected]>
Signed-off-by Youling Tang <[email protected]>
Quoted 6 lines

---
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
Quoted 6 lines

Result: OK!

Tested-by Jinyang He <[email protected]>

Thanks, :-)
Jinyang

Any comments?

Huacai

Quoted 172 lines
Quoted 172 lines
arch/mips/kernel/relocate_kernel.S +28 -0
index ac870893ba2d..f649ffa0f427 100644
@@ -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
arch/mips/loongson64/reset.c +101 -0
index 3bb8a1ed9348..c97bfdc8c922 100644
@@ -6,9 +6,14 @@
   * Copyright (C) 2009 Lemote, Inc.
   * Author: Zhangjin Wu, [email protected]
   */
+#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;
Quoted 16 lines
Quoted 5 lines
arch/mips/loongson64/reset.c +5 -0
+#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;

arch/mips/loongson64/reset.c static void loongson_halt(void) · line 171

Quoted 10 lines
arch/mips/loongson64/reset.c +7 -0
+     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;
  }

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

maintainer
#3 lore raw
Quoted 3 lines · Huacai Chen
Quoted 2 lines

Thanks, :-)
Jinyang

Any comments?

sure...

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +0 -0
@@ -6,6 +6,7 @@
Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +1 -0
  #include <asm/asm.h>
  #include <asm/asmmacro.h>
+#include <asm/cpu.h>
  #include <asm/regdef.h>
Quoted 8 lines

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 138

Quoted 8 lines
arch/mips/kernel/relocate_kernel.S +2 -0
  #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.

Signature · 7 lines
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#4 lore raw

Hi, Thomas,

Quoted 21 lines · Thomas Bogendoerfer
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +0 -0
@@ -6,6 +6,7 @@
Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +1 -0
   #include <asm/asm.h>
   #include <asm/asmmacro.h>
+#include <asm/cpu.h>
   #include <asm/regdef.h>
Quoted 8 lines

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 138

Quoted 8 lines
arch/mips/kernel/relocate_kernel.S +2 -0
   #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.

Quoted 2 lines

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

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

maintainer
#5 lore raw
Quoted 24 lines · Jinyang He

Hi, Thomas,

Quoted 21 lines · Thomas Bogendoerfer
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +0 -0
@@ -6,6 +6,7 @@
Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +1 -0
    #include <asm/asm.h>
    #include <asm/asmmacro.h>
+#include <asm/cpu.h>
    #include <asm/regdef.h>
Quoted 8 lines

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 138

Quoted 8 lines
arch/mips/kernel/relocate_kernel.S +0 -0
    #include <asm/mipsregs.h>
    #include <asm/stackframe.h>

@@ -133,6 +134,33 @@ LEAF(kexec_smp_wait)
    #else

       sync
   #endif

arch/mips/kernel/relocate_kernel.S +2 -0
+
+#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.

Quoted 4 lines
Quoted 2 lines

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.

Quoted 2 lines

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

Quoted 6 lines

Above all just my personal thoughts.

Thanks,
Jinyang

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

author maintainer
#6 lore raw

Hi, Jiaxun,

Quoted 55 lines · Jiaxun Yang
Quoted 27 lines · Jinyang He

Hi, Thomas,

Quoted 21 lines · Thomas Bogendoerfer
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +0 -0
@@ -6,6 +6,7 @@
Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +1 -0
   #include <asm/asm.h>
   #include <asm/asmmacro.h>
+#include <asm/cpu.h>
   #include <asm/regdef.h>
Quoted 8 lines

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 138

Quoted 8 lines
arch/mips/kernel/relocate_kernel.S +2 -0
   #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.

Quoted 2 lines

Thomas.

Quoted 12 lines

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.

Quoted 8 lines

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...

Quoted 4 lines

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

Quoted 10 lines

- Jiaxun

Quoted 6 lines

Above all just my personal thoughts.

Thanks,
Jinyang

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

maintainer
#7 lore raw
Quoted 53 lines · Huacai Chen

Hi, Jiaxun,

Quoted 50 lines · Jiaxun Yang
Quoted 26 lines · Jinyang He

Hi, Thomas,

Quoted 21 lines · Thomas Bogendoerfer
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +0 -0
@@ -6,6 +6,7 @@
Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +1 -0
    #include <asm/asm.h>
    #include <asm/asmmacro.h>
+#include <asm/cpu.h>
    #include <asm/regdef.h>
Quoted 8 lines

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 138

Quoted 8 lines
arch/mips/kernel/relocate_kernel.S +2 -0
    #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.

Quoted 2 lines

Thomas.

Quoted 12 lines

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.

Quoted 7 lines

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...

Quoted 7 lines
Quoted 4 lines

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

Quoted 9 lines

Huacai

Quoted 7 lines

- Jiaxun

Quoted 5 lines

Above all just my personal thoughts.

Thanks,
Jinyang

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

author maintainer
#8 lore raw

Hi, Jiaxun,

Quoted 63 lines · Jiaxun Yang
Quoted 53 lines · Huacai Chen

Hi, Jiaxun,

Quoted 50 lines · Jiaxun Yang
Quoted 26 lines · Jinyang He

Hi, Thomas,

Quoted 21 lines · Thomas Bogendoerfer
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +0 -0
@@ -6,6 +6,7 @@
Quoted 12 lines
Quoted 4 lines
Quoted 4 lines
arch/mips/kernel/relocate_kernel.S +1 -0
    #include <asm/asm.h>
    #include <asm/asmmacro.h>
+#include <asm/cpu.h>
    #include <asm/regdef.h>
Quoted 8 lines

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 138

Quoted 8 lines
arch/mips/kernel/relocate_kernel.S +2 -0
    #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.

Quoted 2 lines

Thomas.

Quoted 12 lines

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.

Quoted 7 lines

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...

Quoted 7 lines
Quoted 4 lines

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.

Quoted 7 lines

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

Quoted 15 lines

Thanks.

- Jiaxun

Quoted 9 lines

Huacai

Quoted 7 lines

- Jiaxun

Quoted 5 lines

Above all just my personal thoughts.

Thanks,
Jinyang

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

maintainer
#9 lore raw
In reply to Jinyang He
Quoted 12 lines · Jinyang He

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.

Quoted 8 lines

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 <[email protected]>
Date: Tue, 19 Jan 2021 21:58:55 +0100
Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials

Signed-off-by Thomas Bogendoerfer <[email protected]>
---
 .../include/asm/mach-cavium-octeon/kernel-entry-init.h   | 8 ++++++++
 arch/mips/kernel/relocate_kernel.S                       | 9 ++++-----
 2 files changed, 12 insertions(+), 5 deletions(-)
arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h +8 -0
index c38b38ce5a3d..b071a7353ee1 100644
@@ -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 */
arch/mips/kernel/relocate_kernel.S +4 -5
index ac870893ba2d..f3c908abdbb8 100644
@@ -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
Signature · 11 lines
2.29.2


-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#10 lore raw
Quoted 25 lines · Thomas Bogendoerfer
Quoted 12 lines · Jinyang He

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.

Quoted 8 lines

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.

Quoted 5 lines

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

Quoted 46 lines

From 81d3e1e24a0dae48f310b8d819d625f88139ef9b Mon Sep 17 00:00:00 2001
From: Thomas Bogendoerfer <[email protected]>
Date: Tue, 19 Jan 2021 21:58:55 +0100
Subject: [PATCH] MIPS: Use macro for kexec_smp_wait specials

Signed-off-by Thomas Bogendoerfer <[email protected]>
---
  .../include/asm/mach-cavium-octeon/kernel-entry-init.h   | 8 ++++++++
  arch/mips/kernel/relocate_kernel.S                       | 9 ++++-----
  2 files changed, 12 insertions(+), 5 deletions(-)
arch/mips/include/asm/mach-cavium-octeon/kernel-entry-init.h +8 -0
index c38b38ce5a3d..b071a7353ee1 100644
@@ -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 */
arch/mips/kernel/relocate_kernel.S +2 -0
index ac870893ba2d..f3c908abdbb8 100644
@@ -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

arch/mips/kernel/relocate_kernel.S LEAF(kexec_smp_wait) · line 134

Quoted 10 lines
arch/mips/kernel/relocate_kernel.S +2 -5
-#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

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec