[Buildroot] [PATCH] arch/arc: add support of ARC HS38 core

[Buildroot] [PATCH] arch/arc: add support of ARC HS38 core

[Alexey Brodkin]

Synopsys has recently announced its new ARC HS38 core that is capable of running
Linux - http://www.synopsys.com/dw/ipdir.php?ds=arc-hs38-processor

ARC HS38 is based on ARCv2 ISA and requires special settings of gcc and libc.
Also in case of HS38 atomic extensions (LLOCK/SCOND instructions) are built-in
by default, so enabling atomic extensions in Buildroot as well.

This commit adds support of the core in buildroot.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>

Cc: Anton Kolesov <anton.kolesov@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
 arch/Config.in.arc       | 20 +++++++++++++++++++-
 package/uclibc/Config.in |  6 ++++++
 package/uclibc/uclibc.mk | 12 ++++++++++++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/arch/Config.in.arc b/arch/Config.in.arc
index fcb5d7d..1a862d7 100644
--- a/arch/Config.in.arc
+++ b/arch/Config.in.arc
@@ -1,5 +1,22 @@
+# Choise of CPU
+choice
+	prompt "Target CPU"
+	depends on BR2_arc
+	default BR2_arc700
+	help
+	    Specific CPU to use
+
+config BR2_arc700
+	bool "ARC 700"
+
+config BR2_archs
+	bool "ARC HS"
+
+endchoice
+
 # Choise of atomic instructions presence
 config BR2_ARC_ATOMIC_EXT
+	default y if BR2_archs
 	bool "Atomic extension (LLOCK/SCOND instructions)"
 
 config BR2_ARCH_HAS_ATOMICS
@@ -18,4 +35,5 @@ config BR2_ENDIAN
 	default "BIG"	 if BR2_arceb
 
 config BR2_GCC_TARGET_CPU
-	default "arc700"
+	default "arc700" if BR2_arc700
+	default "archs"	 if BR2_archs
diff --git a/package/uclibc/Config.in b/package/uclibc/Config.in
index d319ae7..53ca173 100644
--- a/package/uclibc/Config.in
+++ b/package/uclibc/Config.in
@@ -194,6 +194,12 @@ config BR2_UCLIBC_TARGET_ARCH
 	default i386	   if BR2_i386
 	default x86_64	   if BR2_x86_64
 
+config BR2_UCLIBC_ARC_TYPE
+	string
+	depends on BR2_UCLIBC_TARGET_ARCH = "arc"
+	default ARC_CPU_700	if BR2_arc700
+	default ARC_CPU_HS	if BR2_archs
+
 config BR2_UCLIBC_ARM_BX
 	bool
 	depends on BR2_UCLIBC_TARGET_ARCH = "arm"
diff --git a/package/uclibc/uclibc.mk b/package/uclibc/uclibc.mk
index b2ecce3..8f990c7 100644
--- a/package/uclibc/uclibc.mk
+++ b/package/uclibc/uclibc.mk
@@ -57,6 +57,17 @@ UCLIBC_LOCALES = $(foreach locale,$(GENERATE_LOCALE),\
 endif
 
 #
+# ARC definitions
+#
+
+ifeq ($(UCLIBC_TARGET_ARCH),arc)
+UCLIBC_ARC_TYPE = CONFIG_$(call qstrip,$(BR2_UCLIBC_ARC_TYPE))
+define UCLIBC_ARC_TYPE_CONFIG
+	$(call KCONFIG_ENABLE_OPT,$(UCLIBC_ARC_TYPE),$(@D)/.config)
+endef
+endif # arc
+
+#
 # ARM definitions
 #
 
@@ -410,6 +421,7 @@ define UCLIBC_KCONFIG_FIXUP_CMDS
 	$(call KCONFIG_SET_OPT,DEVEL_PREFIX,"/usr",$(@D)/.config)
 	$(call KCONFIG_SET_OPT,SHARED_LIB_LOADER_PREFIX,"/lib",$(@D)/.config)
 	$(UCLIBC_MMU_CONFIG)
+	$(UCLIBC_ARC_TYPE_CONFIG)
 	$(UCLIBC_ARM_ABI_CONFIG)
 	$(UCLIBC_ARM_BX_CONFIG)
 	$(UCLIBC_MIPS_ABI_CONFIG)
-- 
1.9.3

[Buildroot] [PATCH] arch/arc: add support of ARC HS38 core

[Thomas Petazzoni]

Dear Alexey Brodkin,

On Wed, 29 Oct 2014 15:25:17 +0300, Alexey Brodkin wrote:

> diff --git a/arch/Config.in.arc b/arch/Config.in.arc
> index fcb5d7d..1a862d7 100644
> --- a/arch/Config.in.arc
> +++ b/arch/Config.in.arc
> @@ -1,5 +1,22 @@
> +# Choise of CPU

I don't think this comment is very useful, so you can get rid of it.
And anyway, s/Choise/Choice/.

> +choice
> +	prompt "Target CPU"
> +	depends on BR2_arc
> +	default BR2_arc700
> +	help
> +	    Specific CPU to use
> +
> +config BR2_arc700
> +	bool "ARC 700"
> +
> +config BR2_archs
> +	bool "ARC HS"

The commit log says that the core is called HS38, but now it's just
"HS". Can you clarify?

>  # Choise of atomic instructions presence
>  config BR2_ARC_ATOMIC_EXT
> +	default y if BR2_archs

Why? Are atomic instructions *always* available on HS38, or are they
also optional like on ARC700 ?

>  config BR2_GCC_TARGET_CPU
> -	default "arc700"
> +	default "arc700" if BR2_arc700
> +	default "archs"	 if BR2_archs

So from gcc's point of view, the processor is called archs, but from a
marketing point of view it's HS38. What happens if tomorrow Synopsys
creates a different CPU core called HS100 ?

Is this processor already supported by the current binutils/gcc/uClibc
versions used for the ARC architecture in Buildroot?

The rest of the patch looks good to me.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] arch/arc: add support of ARC HS38 core

[Alexey Brodkin]

Hi Thomas,

On Wed, 2014-10-29 at 22:18 +0100, Thomas Petazzoni wrote:
> Dear Alexey Brodkin,
> 
> On Wed, 29 Oct 2014 15:25:17 +0300, Alexey Brodkin wrote:
> 
> > diff --git a/arch/Config.in.arc b/arch/Config.in.arc
> > index fcb5d7d..1a862d7 100644
> > --- a/arch/Config.in.arc
> > +++ b/arch/Config.in.arc
> > @@ -1,5 +1,22 @@
> > +# Choise of CPU
> 
> I don't think this comment is very useful, so you can get rid of it.
> And anyway, s/Choise/Choice/.

Ok, makes sense and right - Gedit doesn't do spell-checking so I made
this mistake and it went into the wild :(

> > +choice
> > +	prompt "Target CPU"
> > +	depends on BR2_arc
> > +	default BR2_arc700
> > +	help
> > +	    Specific CPU to use
> > +
> > +config BR2_arc700
> > +	bool "ARC 700"
> > +
> > +config BR2_archs
> > +	bool "ARC HS"
> 
> The commit log says that the core is called HS38, but now it's just
> "HS". Can you clarify?

Ok, here's an explanation.
ARC has currently 4 families of CPU cores.
2 of those families may have MMU, they are:
 1) ARC700 series (ARC750D and ARC770D have MMU while others like
ARC705, ARC725 have no MMU)
 2) ARC HS series (HS38 has MMU while HS34 and HS36 are MMU-less models)

But since Buildroot is used for building tools and packages for
Linux-driven systems I don't even mention other HS family members.

Also what's important that ARC700 and ARC HS families implement
different ISAs and that's why I had to add another type of CPU -
different settings of gcc and uclibc are required for ARC700 and HS.

Probably what I need to do is to list explicitly all relevant CPU
modifications that could be used for Linux. then we'll have ARC750D,
ARC770D and ARC HS38. In this case there will be no confusions.

> >  # Choise of atomic instructions presence
> >  config BR2_ARC_ATOMIC_EXT
> > +	default y if BR2_archs
> 
> Why? Are atomic instructions *always* available on HS38, or are they
> also optional like on ARC700 ?

Well with ARC things a bit more complex compared to other architectures.
Because we provide a LEGO-like IP - user may select each and every tiny
detail he wants or doesn't want.

And all those "names" mentioned above like ARC770D, ARC HS are only
names of "templates" - sets of components and features that are most
likely will be used. But nobody can stop user to down-configure
anything.

So in case of HS38 by default atomic options are enabled - that's why I
enabled them in Buildroot for ARC HS by default. But since there's a
probability one customer decides to down-configure atomic instructions
(even though we don't recommend to do it) we need to have an ability to
build software without atomic ops.

> >  config BR2_GCC_TARGET_CPU
> > -	default "arc700"
> > +	default "arc700" if BR2_arc700
> > +	default "archs"	 if BR2_archs
> 
> So from gcc's point of view, the processor is called archs, but from a
> marketing point of view it's HS38. What happens if tomorrow Synopsys
> creates a different CPU core called HS100 ?

See above. We need to have arc700 and archs to distinguish 2 different
ISAs and ABIs. Still as I commented above I'll add selection of a
particular CPU so for example we may pass fine-tuning options to gcc
like "-mtune=ARCxxx".

> Is this processor already supported by the current binutils/gcc/uClibc
> versions used for the ARC architecture in Buildroot?

Right, arc-2014.08 tools (gcc, binutils, uClibc) already support ARC HS.
Moreover uClibc has ARC HS support even in upstream master branch.

> The rest of the patch looks good to me.

I'll do a respin with fixed comments and more fine-grained ARC CPU
selection shortly.

-Alexey

[Buildroot] [PATCH] arch/arc: add support of ARC HS38 core

[Vicente Olivert Riera]

Dear Alexey Brodkin,

On 10/30/2014 11:05 AM, Alexey Brodkin wrote:
> Gedit doesn't do spell-checking

Go to:

Edit -> Preferences -> Plugins -> Spell Checker

Best regards,
-- 
Vicente Olivert Riera
Graduate Software Engineer, MIPS Processor IP
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com

[Buildroot] [PATCH] arch/arc: add support of ARC HS38 core

[Thomas Petazzoni]

Dear Alexey Brodkin,

On Thu, 30 Oct 2014 11:05:24 +0000, Alexey Brodkin wrote:

> Ok, here's an explanation.
> ARC has currently 4 families of CPU cores.
> 2 of those families may have MMU, they are:
>  1) ARC700 series (ARC750D and ARC770D have MMU while others like
> ARC705, ARC725 have no MMU)
>  2) ARC HS series (HS38 has MMU while HS34 and HS36 are MMU-less models)
> 
> But since Buildroot is used for building tools and packages for
> Linux-driven systems I don't even mention other HS family members.
> 
> Also what's important that ARC700 and ARC HS families implement
> different ISAs and that's why I had to add another type of CPU -
> different settings of gcc and uclibc are required for ARC700 and HS.
> 
> Probably what I need to do is to list explicitly all relevant CPU
> modifications that could be used for Linux. then we'll have ARC750D,
> ARC770D and ARC HS38. In this case there will be no confusions.

Thanks for the explanation!

> > >  # Choise of atomic instructions presence
> > >  config BR2_ARC_ATOMIC_EXT
> > > +	default y if BR2_archs
> > 
> > Why? Are atomic instructions *always* available on HS38, or are they
> > also optional like on ARC700 ?
> 
> Well with ARC things a bit more complex compared to other architectures.
> Because we provide a LEGO-like IP - user may select each and every tiny
> detail he wants or doesn't want.
> 
> And all those "names" mentioned above like ARC770D, ARC HS are only
> names of "templates" - sets of components and features that are most
> likely will be used. But nobody can stop user to down-configure
> anything.
> 
> So in case of HS38 by default atomic options are enabled - that's why I
> enabled them in Buildroot for ARC HS by default. But since there's a
> probability one customer decides to down-configure atomic instructions
> (even though we don't recommend to do it) we need to have an ability to
> build software without atomic ops.

Ok, that explains why you decided to make it 'default y' for some CPU,
but still keep it an option.


> > So from gcc's point of view, the processor is called archs, but from a
> > marketing point of view it's HS38. What happens if tomorrow Synopsys
> > creates a different CPU core called HS100 ?
> 
> See above. We need to have arc700 and archs to distinguish 2 different
> ISAs and ABIs. Still as I commented above I'll add selection of a
> particular CPU so for example we may pass fine-tuning options to gcc
> like "-mtune=ARCxxx".

Hum: beware, we are removing the support for -mtune in Buildroot. Since
Buildroot targets only one system, -mtune is normally not useful and
-mcpu should be used instead. On some architecture, -march indicates
the ISA, while -mcpu indicates the specific CPU. Maybe ARC should do
the same?

> > Is this processor already supported by the current binutils/gcc/uClibc
> > versions used for the ARC architecture in Buildroot?
> 
> Right, arc-2014.08 tools (gcc, binutils, uClibc) already support ARC HS.
> Moreover uClibc has ARC HS support even in upstream master branch.

Great!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com