[PATCH v2 2/2] platform: generic: eswin: Add eic770x_hsm and fix warm reset issues

[Min Lin]

> -----Original Messages-----
> From: "Bo Gan" <ganboing at gmail.com>
> Send time:Friday, 05/06/2026 15:57:08
> To: opensbi at lists.infradead.org
> Cc: nick.hu at sifive.com, linmin at eswincomputing.com, gaohan at iscas.ac.cn, me at ziyao.cc
> Subject: [PATCH v2 2/2] platform: generic: eswin: Add eic770x_hsm and fix warm reset issues
> 
> During warm reset, my EIC770X/Hifive Premier P550 can sometimes
> encounter memory corruption issue crashing Linux boot. Currently the
> issue is mitigated by having a sbi_printf before writing to the reset
> register. I analyzed the issue further since then. From the SoC
> datasheet[1], it's recommended to implement power-down flow as:
> 
>   a. Designate a primary core, and let it broadcast requests to other
>      cores to execute a CEASE insn. Primary core also notifies an
>      "Externel Agent" to start monitoring.
>   b. Primary core waits for other cores to CEASE before it CEASEs.
>   c. "External Agent" waits for primary core to CEASE before resets
>      the Core Complex.
> 
> It's possible that EIC770X can trigger undefined behavior if the core
> complex is reset while the harts are actively running. The sbi_printf
> in the reset handler effectively hides the problem by delaying the
> reset -- by the time sbi_printf finishes, all other harts will have
> already landed in the loop in sbi_hsm_hart_wait(), which parks the hart.
> Without the sbi_printf, I confirmed that other harts haven't reached
> sbi_hsm_hart_wait yet before current hart resets the SoC. (by debugging)
> 
> To safely reset, and inspired by the datasheet, the warm reset logic
> in eic770x.c now use the current hart as both primary core and the
> "External Agent", and other harts as secondary cores. It leverages
> the HSM framework and a new eic770x_hsm device to CEASE other harts,
> and wait for them to CEASE before resets the SoC. with the sbi_printf
> before reset removed, and this logic in place, stress test shows that
> the memory corruption issue no longer occurs.
> 
> The new eic770x_hsm device is only used for the reset-CEASE logic at
> the moment, and may be extended to a fully functional HSM device in
> the future.
> 
> [1] https://github.com/eswincomputing/EIC7700X-SoC-Technical-Reference-Manual
> 
> Fixes: e5797e0688c1 ("platform: generic: eswin: add EIC7700")
> Signed-off-by: Bo Gan <ganboing at gmail.com>
> ---
>  platform/generic/eswin/eic770x.c         | 118 +++++++++++++++++++++--
>  platform/generic/eswin/hfp.c             |   4 +-
>  platform/generic/include/eswin/eic770x.h |  20 +++-
>  3 files changed, 126 insertions(+), 16 deletions(-)
> 
> diff --git a/platform/generic/eswin/eic770x.c b/platform/generic/eswin/eic770x.c
> index 7330df9f..b5c128c6 100644
> --- a/platform/generic/eswin/eic770x.c
> +++ b/platform/generic/eswin/eic770x.c
> @@ -10,14 +10,109 @@
>  #include <sbi/sbi_console.h>
>  #include <sbi/sbi_system.h>
>  #include <sbi/sbi_math.h>
> +#include <sbi/sbi_hsm.h>
> +#include <sbi/sbi_ipi.h>
>  #include <sbi/sbi_hart_pmp.h>
>  #include <sbi/sbi_hart_protection.h>
> +#include <sbi_utils/hsm/fdt_hsm_sifive_inst.h>
>  #include <eswin/eic770x.h>
>  #include <eswin/hfp.h>

[snip...]

>  
>  /* Memory Ports */
>  #define EIC770X_MEMPORT_BASE	0x0080000000UL // 2G
> @@ -98,4 +105,7 @@ struct eic770x_board_override {
>  		divisor > 2 ? divisor : 2; 		\
>  	})
>  
> +/* Reset definitions */
> +#define EIC770X_SYSRST_VAL	0x1AC0FFE6UL
> +
>  #endif
> -- 
> 2.34.1

I had discussions with the SiFive hardware team. When resetting individual
CPU cores, it is indeed necessary to follow the power-down sequence 
recommended in the SoC datasheet. However, writing 0x1AC0FFE6 to the 
EIC770X_SYSCRG_SYSRST register resets the entire chip — including 
CPU cores, DDR controller, NoC, etc. 
Therefore, the issue described here should not occur.

In our local environment, we removed the sbi_printf function before reset, 
but failed to reproduce the problem that Bo Gan encountered.

That said, regardless of this, I believe we should still follow the power-down
sequence described in the datasheet to ensure a safe reset.

This patch series looks good to me.

Regards,
Lin Min