Skip to contentSkip to conversation

arch/arc: add support of ARC HS38 core

PATCH New Alexey Brodkin 3 participants 5 messages Oct 29, 2014 – Oct 30, 2014

lore
Share & tools
lore

Alexey Brodkin

author
#0 lore raw

PATCH 1/1 arch/arc: add support of ARC HS38 core

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 <[email protected]>
Cc Anton Kolesov <[email protected]>
Cc Thomas Petazzoni <[email protected]>
---
 arch/Config.in.arc       | 20 +++++++++++++++++++-
 package/uclibc/Config.in |  6 ++++++
 package/uclibc/uclibc.mk | 12 ++++++++++++
 3 files changed, 37 insertions(+), 1 deletion(-)
arch/Config.in.arc +19 -1
index fcb5d7d..1a862d7 100644
@@ -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
package/uclibc/Config.in +6 -0
index d319ae7..53ca173 100644
@@ -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"
package/uclibc/uclibc.mk +12 -0
index b2ecce3..8f990c7 100644
@@ -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)
Signature · 1 line
1.9.3
#1 lore raw

PATCH 1/1 arch/arc: add support of ARC HS38 core

Dear Alexey Brodkin,

arch/Config.in.arc line 1

Quoted 6 lines · Alexey Brodkin
arch/Config.in.arc +1 -0
index fcb5d7d..1a862d7 100644
@@ -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/.

arch/Config.in.arc line 13

Quoted 12 lines
arch/Config.in.arc +12 -0
+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?

arch/Config.in.arc line 19

Quoted 3 lines
arch/Config.in.arc +1 -0
 # 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 ?

arch/Config.in.arc config BR2_ENDIAN · line 39

Quoted 4 lines
arch/Config.in.arc +2 -1
 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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
author
#2 lore raw

PATCH 1/1 arch/arc: add support of ARC HS38 core

Hi Thomas,

Quoted 4 lines · Thomas Petazzoni

Dear Alexey Brodkin,

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

Quoted 9 lines

arch/Config.in.arc line 1

Quoted 6 lines
arch/Config.in.arc +1 -0
index fcb5d7d..1a862d7 100644
@@ -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 :(

Quoted 7 lines
Quoted 7 lines
arch/Config.in.arc +7 -0
+choice
+	prompt "Target CPU"
+	depends on BR2_arc
+	default BR2_arc700
+	help
+	    Specific CPU to use
+
Quoted 8 lines

arch/Config.in.arc line 13

Quoted 5 lines
arch/Config.in.arc +5 -0
+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.

Quoted 6 lines

arch/Config.in.arc line 19

Quoted 3 lines
arch/Config.in.arc +1 -0
 # 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.

Quoted 8 lines

arch/Config.in.arc config BR2_ENDIAN · line 39

Quoted 4 lines
arch/Config.in.arc +2 -1
 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".

Quoted 2 lines

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.

Quoted 1 line

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

#3 lore raw

PATCH 1/1 arch/arc: add support of ARC HS38 core

Dear Alexey Brodkin,

Quoted 1 line · Alexey Brodkin

Gedit doesn't do spell-checking

Go to:

Edit -> Preferences -> Plugins -> Spell Checker

Best regards,

Signature · 5 lines
Vicente Olivert Riera
Graduate Software Engineer, MIPS Processor IP
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com
#4 lore raw

PATCH 1/1 arch/arc: add support of ARC HS38 core

In reply to Alexey Brodkin

Dear Alexey Brodkin,

Quoted 10 lines · Alexey Brodkin

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.

Quoted 7 lines

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!

Quoted 16 lines
Quoted 6 lines

arch/Config.in.arc line 19

Quoted 3 lines

# Choise of atomic instructions presence
config BR2_ARC_ATOMIC_EXT

arch/Config.in.arc +1 -0
+	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.

Quoted 5 lines

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.

Quoted 8 lines
Quoted 3 lines

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?

Quoted 5 lines
Quoted 2 lines

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

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