From: Gregory CLEMENT <gregory.clement@bootlin.com>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>, linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, tsbogend@alpha.franken.de,
vladimir.kondratiev@intel.com,
Jiaxun Yang <jiaxun.yang@flygoat.com>
Subject: Re: [PATCH v2 05/10] MIPS: Refactor mips_cps_core_entry implementation
Date: Wed, 08 Nov 2023 17:30:46 +0100 [thread overview]
Message-ID: <87o7g46wcp.fsf@BL-laptop> (raw)
In-Reply-To: <20231027221106.405666-6-jiaxun.yang@flygoat.com>
Hello Jiaxun,
> Now the exception vector for CPS systems are allocated on-fly
> with memblock as well.
>
> It will try to allocate from KSEG1 first, and then try to allocate
> in low 4G if possible.
>
> The main reset vector is now generated by uasm, to avoid tons
> of patches to the code. Other vectors are copied to the location
> later.
>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
> +
> +static int __init setup_cps_vecs(void)
> +{
[...]
> +
> + /* We want to ensure cache is clean before writing uncached mem */
> + blast_dcache_range(TO_CAC(cps_vec_pa), TO_CAC(cps_vec_pa) +
> BEV_VEC_SIZE);
In my case this call failed because when setup_cps_vecs is called, the
cache information are not initialized yet!
As a workaround I moved the cpu_cache_init() call before
plat_smp_setup() in the /arch/mips/kernel/setup.c file.
Obviously it is not the right thing to do, but it shows that the cache
related function are called too early. For example, in
blast_dcache_range, the value returned by cpu_dcache_line_size was 0
instead of 64, because the value cpu_data[0].dcache.linesz was not set
yet.
So I wonder who it managed to work in your setup. What is the machine
running in QEMU ?
Does it use someting like the following line ?
#define cpu_dcache_line_size() 32
> + bc_wback_inv(TO_CAC(cps_vec_pa), BEV_VEC_SIZE);
> + __sync();
> +
> + cps_vec = (void *)TO_UNCAC(cps_vec_pa);
> + mips_cps_build_core_entry(cps_vec);
> +
> + memcpy(cps_vec + 0x200, &excep_tlbfill, 0x80);
> + memcpy(cps_vec + 0x280, &excep_xtlbfill, 0x80);
> + memcpy(cps_vec + 0x300, &excep_cache, 0x80);
> + memcpy(cps_vec + 0x380, &excep_genex, 0x80);
> + memcpy(cps_vec + 0x400, &excep_intex, 0x80);
> + memcpy(cps_vec + 0x480, &excep_ejtag, 0x80);
> +
> + /* Make sure no prefetched data in cache */
> + blast_inv_dcache_range(TO_CAC(cps_vec_pa), TO_CAC(cps_vec_pa) + BEV_VEC_SIZE);
> + bc_inv(TO_CAC(cps_vec_pa), BEV_VEC_SIZE);
> + __sync();
> +
> + return 0;
> +}
[...]
> /* If we have an FPU, enroll ourselves in the FPU-full mask */
> @@ -110,10 +241,14 @@ static void __init cps_prepare_cpus(unsigned int max_cpus)
> {
> unsigned ncores, core_vpes, c, cca;
> bool cca_unsuitable, cores_limited;
> - u32 *entry_code;
>
> mips_mt_set_cpuoptions();
>
> + if (!core_entry_reg) {
> + pr_err("core_entry address unsuitable, disabling smp-cps\n");
> + goto err_out;
> + }
> +
> /* Detect whether the CCA is unsuited to multi-core SMP */
> cca = read_c0_config() & CONF_CM_CMASK;
> switch (cca) {
> @@ -145,20 +280,6 @@ static void __init cps_prepare_cpus(unsigned int max_cpus)
> (cca_unsuitable && cpu_has_dc_aliases) ? " & " : "",
> cpu_has_dc_aliases ? "dcache aliasing" : "");
>
> - /*
> - * Patch the start of mips_cps_core_entry to provide:
> - *
> - * s0 = kseg0 CCA
> - */
> - entry_code = (u32 *)&mips_cps_core_entry;
> - uasm_i_addiu(&entry_code, 16, 0, cca);
> - UASM_i_LA(&entry_code, 17, (long)mips_gcr_base);
> - BUG_ON((void *)entry_code > (void *)&mips_cps_core_entry_patch_end);
> - blast_dcache_range((unsigned long)&mips_cps_core_entry,
> - (unsigned long)entry_code);
> - bc_wback_inv((unsigned long)&mips_cps_core_entry,
> - (void *)entry_code - (void *)&mips_cps_core_entry);
> - __sync();
The original code here was called later during boot from
kernel_init_freeable() which is called by kernel_init() after all the
calls in start_kernel. That's why there were no issue before the move.
Gregory
>
> /* Allocate core boot configuration structs */
> ncores = mips_cps_numcores(0);
> @@ -213,7 +334,7 @@ static void boot_core(unsigned int core, unsigned int vpe_id)
> mips_cm_lock_other(0, core, 0, CM_GCR_Cx_OTHER_BLOCK_LOCAL);
>
> /* Set its reset vector */
> - write_gcr_co_reset_base(CKSEG1ADDR((unsigned long)mips_cps_core_entry));
> + write_gcr_co_reset_base(core_entry_reg);
>
> /* Ensure its coherency is disabled */
> write_gcr_co_coherence(0);
> @@ -290,7 +411,6 @@ static int cps_boot_secondary(int cpu, struct task_struct *idle)
> unsigned vpe_id = cpu_vpe_id(&cpu_data[cpu]);
> struct core_boot_config *core_cfg = &mips_cps_core_bootcfg[core];
> struct vpe_boot_config *vpe_cfg = &core_cfg->vpe_config[vpe_id];
> - unsigned long core_entry;
> unsigned int remote;
> int err;
>
--
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com
next prev parent reply other threads:[~2023-11-08 16:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 22:10 [PATCH v2 00/10] MIPS: Fix kernel in XKPHYS Jiaxun Yang
2023-10-27 22:10 ` [PATCH v2 01/10] MIPS: Export higher/highest relocation functions in uasm Jiaxun Yang
2023-10-27 22:10 ` [PATCH v2 02/10] MIPS: spaces: Define a couple of handy macros Jiaxun Yang
2023-12-21 15:42 ` Thomas Bogendoerfer
2023-10-27 22:10 ` [PATCH v2 03/10] MIPS: genex: Fix except_vec_vi for kernel in XKPHYS Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 04/10] MIPS: Fix set_uncached_handler for ebase " Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 05/10] MIPS: Refactor mips_cps_core_entry implementation Jiaxun Yang
2023-10-28 7:22 ` kernel test robot
2023-11-08 16:30 ` Gregory CLEMENT [this message]
2023-11-09 13:12 ` Jiaxun Yang
2023-12-22 12:18 ` Thomas Bogendoerfer
2023-12-22 12:40 ` Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 06/10] MIPS: Allow kernel base to be set from Kconfig for all platforms Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 07/10] MIPS: traps: Handle CPU with non standard vint offset Jiaxun Yang
2023-12-22 12:19 ` Thomas Bogendoerfer
2023-12-22 12:47 ` Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 08/10] MIPS: Avoid unnecessary reservation of exception space Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 09/10] MIPS: traps: Enhance memblock ebase allocation process Jiaxun Yang
2023-10-27 22:11 ` [PATCH v2 10/10] MIPS: Get rid of CONFIG_NO_EXCEPT_FILL Jiaxun Yang
2023-11-08 16:12 ` [PATCH v2 00/10] MIPS: Fix kernel in XKPHYS Gregory CLEMENT
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o7g46wcp.fsf@BL-laptop \
--to=gregory.clement@bootlin.com \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=tsbogend@alpha.franken.de \
--cc=vladimir.kondratiev@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox