<snip> > > On Thu, 2019-08-01 at 07:48 +0800, Gavin Hu wrote: > > Arm N1 SDP is an infrastructure segment development platform based on > > armv8.2-a Neoverse N1 CPU. For more information, refer to: > > https://community.arm.com/developer/tools-software/oss-platforms/w/ > > docs/440/neoverse-n1-sdp > > > > Signed-off-by: Gavin Hu <gavin...@arm.com> > > Reviewed-by: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com> > > Reviewed-by: Steve Capper <steve.cap...@arm.com> > > --- > > config/arm/meson.build | 9 ++++++- > > config/defconfig_arm64-neoversen1-linux-gcc | 1 + > > config/defconfig_arm64-neoversen1-linuxapp-gcc | 15 ++++++++++++ > > mk/machine/neoversen1/rte.vars.mk | 34 > > ++++++++++++++++++++++++++ > > 4 files changed, 58 insertions(+), 1 deletion(-) create mode 120000 > > config/defconfig_arm64-neoversen1-linux-gcc > > create mode 100644 config/defconfig_arm64-neoversen1-linuxapp-gcc > > create mode 100644 mk/machine/neoversen1/rte.vars.mk > > > > diff --git a/config/arm/meson.build b/config/arm/meson.build index > > 979018e..995d321 100644 > > --- a/config/arm/meson.build > > +++ b/config/arm/meson.build > > @@ -63,6 +63,12 @@ flags_armada = [ > > ['RTE_MAX_LCORE', 16]] > > > > flags_default_extra = [] > > +flags_neoversen1_extra = [ > > +['RTE_MACHINE', '"neoversen1"'], > What does RTE_MACHINE stand for? Not sure, what it stands for. I cannot find a consistent assignment for it. Some time it takes 'armv8' (in the case of BlueField), 'dpaa', 'dpaa2', 'thunderx' etc (architecture, SoC, micro-architecture). I also cannot find an instance of its usage.
> > Neoverse N1 is a CPU core, not a platform, not a SoC architecture etc. > Many different SoC's can be designed using the N1 core. > Some will be small with few cores and no NUMA, others might be large with > many cores and multi-socket (NUMA) support. > The N1SDP (N1 System Development Platform) is using such a small SoC > (specially designed for the N1DSP, it is not going to show up in other > platforms). The configuration below matches N1SDP but will most likely not > match other future N1-based SoC's. What do we do when other quite > different "machines" using the Neoverse N1 core shows up? Is it OK to > qualitatively change these configurations later? All other implementations of N1 based SoCs should have their own implementor ID and variant. Hence they should not clash with these configurations. IIRC, BlueField had the same implementation ID as Arm (0x41), so ' flags_arm' was modified to reflect BlueField configuration. Hopefully, this will be corrected in the future. > > > +['RTE_MAX_NUMA_NODES', 1], > > +['RTE_MAX_LCORE', 4], > > +['RTE_EAL_NUMA_AWARE_HUGEPAGES', false], > ['RTE_LIBRTE_VHOST_NUMA', > > +false]] > > flags_thunderx_extra = [ > > ['RTE_MACHINE', '"thunderx"'], > > ['RTE_USE_C11_MEM_MODEL', false]] > > @@ -87,7 +93,8 @@ machine_args_generic = [ ['0xd07', > > ['-mcpu=cortex-a57']], ['0xd08', ['-mcpu=cortex-a72']], ['0xd09', > > ['-mcpu=cortex-a73']], -['0xd0a', ['-mcpu=cortex-a75']]] > > +['0xd0a', ['-mcpu=cortex-a75']], > > +['0xd0c', ['-march=armv8.2-a+crc+crypto', '-mcpu=neoverse-n1'], > > flags_neoversen1_extra]] > > > > machine_args_cavium = [ > > ['default', ['-march=armv8-a+crc+crypto','-mcpu=thunderx']], > > diff --git a/config/defconfig_arm64-neoversen1-linux-gcc > > b/config/defconfig_arm64-neoversen1-linux-gcc > > new file mode 120000 > > index 0000000..47c96a4 > > --- /dev/null > > +++ b/config/defconfig_arm64-neoversen1-linux-gcc > > @@ -0,0 +1 @@ > > +defconfig_arm64-neoversen1-linuxapp-gcc > > \ No newline at end of file > ! > > > diff --git a/config/defconfig_arm64-neoversen1-linuxapp-gcc > > b/config/defconfig_arm64-neoversen1-linuxapp-gcc > > new file mode 100644 > > index 0000000..39b9e1f > > --- /dev/null > > +++ b/config/defconfig_arm64-neoversen1-linuxapp-gcc > > > > > @@ -0,0 +1,15 @@ > > +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2019 Arm Ltd. > > +# > > + > > +#include "defconfig_arm64-armv8a-linux-gcc" > > + > > +CONFIG_RTE_MACHINE="neoversen1" > This should probably be "n1sdp" as this is the name of the platform that > matches the below configuration. A clear definition of RTE_MACHINE is required. Jerin? > > > +CONFIG_RTE_ARCH_ARM_TUNE="neoverse-n1" > > +CONFIG_RTE_MAX_LCORE=4 > > +CONFIG_RTE_MAX_NUMA_NODES=1 > > +CONFIG_RTE_CACHE_LINE_SIZE=64 > > + > > +# Doesn't support NUMA > > +CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES=n > > +CONFIG_RTE_LIBRTE_VHOST_NUMA=n > > diff --git a/mk/machine/neoversen1/rte.vars.mk > > b/mk/machine/neoversen1/rte.vars.mk > > new file mode 100644 > > index 0000000..6d69de0 > > --- /dev/null > > +++ b/mk/machine/neoversen1/rte.vars.mk > > @@ -0,0 +1,34 @@ > > +# SPDX-License-Identifier: BSD-3-Clause # Copyright(c) 2019 Arm Ltd # > > + > > +# > > +# machine: > > +# > > +# - can define ARCH variable (overridden by cmdline value) > > +# - can define CROSS variable (overridden by cmdline value) > > +# - define MACHINE_CFLAGS variable (overridden by cmdline value) > > +# - define MACHINE_LDFLAGS variable (overridden by cmdline value) > > +# - define MACHINE_ASFLAGS variable (overridden by cmdline value) > > +# - can define CPU_CFLAGS variable (overridden by cmdline value) that > > +# overrides the one defined in arch. > > +# - can define CPU_LDFLAGS variable (overridden by cmdline value) that > > +# overrides the one defined in arch. > > +# - can define CPU_ASFLAGS variable (overridden by cmdline value) that > > +# overrides the one defined in arch. > > +# - may override any previously defined variable > > +# > > + > > +# ARCH = > > +# CROSS = > > +# MACHINE_CFLAGS = > > +# MACHINE_LDFLAGS = > > +# MACHINE_ASFLAGS = > > +# CPU_CFLAGS = > > +# CPU_LDFLAGS = > > +# CPU_ASFLAGS = > > + > > +include $(RTE_SDK)/mk/rte.helper.mk > > + > > +MACHINE_CFLAGS += $(call rte_cc_has_argument, > > +-march=armv8.2-a+crc+crypto) MACHINE_CFLAGS += $(call > > +rte_cc_has_argument, -mcpu=neoverse-n1) > > > > > -- > Ola Liljedahl, Networking System Architect, Arm Phone +46706866373, Skype > ola.liljedahl
