In target/arm/cpu64.c, CPU init function for A64FX is there, add this
CPU to the sbsa-ref board.

Signed-off-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
---
 hw/arm/sbsa-ref.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 4bb444684f..a7d27b2e55 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -146,6 +146,7 @@ static const char * const valid_cpus[] = {
     ARM_CPU_TYPE_NAME("cortex-a57"),
     ARM_CPU_TYPE_NAME("cortex-a72"),
     ARM_CPU_TYPE_NAME("cortex-a76"),
+    ARM_CPU_TYPE_NAME("a64fx"),
     ARM_CPU_TYPE_NAME("neoverse-n1"),
     ARM_CPU_TYPE_NAME("max"),
 };
-- 
2.25.1

On Fri, 20 May 2022 at 09:46, Itaru Kitayama <itaru.kitayama@gmail.com> wrote:
>
> In target/arm/cpu64.c, CPU init function for A64FX is there, add this
> CPU to the sbsa-ref board.

(cc'ing the sbsa-ref maintainers)

This isn't an objection, but I would like to know what the
sbsa-ref maintainers' view is on what CPUs the board type
is supposed to handle. Is this like the virt board, where we
add basically any CPU type that might possibly work? Or is
it more like a piece of 'real' hardware, where there are only
one or two CPU types that that hardware might have shipped with,
and the firmware/software stack might not be built to cope with
anything more ?

If we can answer the general question, then specific
patches like this one will be easy to review.

> Signed-off-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
> ---
>  hw/arm/sbsa-ref.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
> index 4bb444684f..a7d27b2e55 100644
> --- a/hw/arm/sbsa-ref.c
> +++ b/hw/arm/sbsa-ref.c
> @@ -146,6 +146,7 @@ static const char * const valid_cpus[] = {
>      ARM_CPU_TYPE_NAME("cortex-a57"),
>      ARM_CPU_TYPE_NAME("cortex-a72"),
>      ARM_CPU_TYPE_NAME("cortex-a76"),
> +    ARM_CPU_TYPE_NAME("a64fx"),
>      ARM_CPU_TYPE_NAME("neoverse-n1"),
>      ARM_CPU_TYPE_NAME("max"),
>  };
> --
> 2.25.1

thanks
-- PMM

Doesn’t ‘max’ support being there mean we are supposed to support various
types of CPUs on the SBSA board?

On Fri, May 20, 2022 at 18:00 Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Fri, 20 May 2022 at 09:46, Itaru Kitayama <itaru.kitayama@gmail.com>
> wrote:
> >
> > In target/arm/cpu64.c, CPU init function for A64FX is there, add this
> > CPU to the sbsa-ref board.
>
> (cc'ing the sbsa-ref maintainers)
>
> This isn't an objection, but I would like to know what the
> sbsa-ref maintainers' view is on what CPUs the board type
> is supposed to handle. Is this like the virt board, where we
> add basically any CPU type that might possibly work? Or is
> it more like a piece of 'real' hardware, where there are only
> one or two CPU types that that hardware might have shipped with,
> and the firmware/software stack might not be built to cope with
> anything more ?
>
> If we can answer the general question, then specific
> patches like this one will be easy to review.
>
> > Signed-off-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>
> > ---
> >  hw/arm/sbsa-ref.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
> > index 4bb444684f..a7d27b2e55 100644
> > --- a/hw/arm/sbsa-ref.c
> > +++ b/hw/arm/sbsa-ref.c
> > @@ -146,6 +146,7 @@ static const char * const valid_cpus[] = {
> >      ARM_CPU_TYPE_NAME("cortex-a57"),
> >      ARM_CPU_TYPE_NAME("cortex-a72"),
> >      ARM_CPU_TYPE_NAME("cortex-a76"),
> > +    ARM_CPU_TYPE_NAME("a64fx"),
> >      ARM_CPU_TYPE_NAME("neoverse-n1"),
> >      ARM_CPU_TYPE_NAME("max"),
> >  };
> > --
> > 2.25.1
>
> thanks
> -- PMM
>