Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

meta-synopsys: ARCv3 support #8

Draft
wants to merge 10 commits into
base: master
Choose a base branch
from
Draft

meta-synopsys: ARCv3 support #8

wants to merge 10 commits into from

Conversation

geomatsi
Copy link

Summary

This PR implements the following updates for Synopsys Yocto layer:

  • ARC toolchain update to arc-2022.03 release
  • support for ARCv3 architecture

ARCv3 changes

Here are the lists of ARCv3 specific changes required for OE layers.

openembedded-core

ARCv3 support is implemented in patch. This patch has not yet been upstreamed.

meta-synopsys

This PR includes the following ARCv3 specific changes:

  • libffi: bbappend for ARCv3 64-bit port
  • openssl: bbappend for additional ARCv3 32-bit linker flag to make use of libatomic
  • kernel: recipe for ARCv3 port
  • glibc: recipe for ARCv3 port
  • machine: two ARCv3 machines for HS5x and HS6x processors
  • distro: custom minimalistic distro suitable for running ARCv3 images on nSIM

Status

HS6x

Build commands for HS6x machine using snps-arc64-minimal distro:

$ MACHINE=hapshs6x DISTRO=snps-arc64-minimal bitbake virtual/kernel

Successful build and boot using nSIM.

HS5x

Build command for HS5x machine using snps-arc64-minimal distro:

$ MACHINE=hapshs5x DISTRO=snps-arc64-minimal bitbake virtual/kernel

Currently build fails on libffi which lacks support for ARCv3 32-bit processors. However libffi is not actually needed for minimal boot image. So quick non-functional libffi fix (replace pop_s/push_s by pop/push instructions) allows build to successfully complete. The resulting image boots fine using nSIM.

Notes

This PR will remain in WIP state until ARCv3 triplets are finalized.

Sergey Matyukevich added 10 commits March 25, 2022 14:06
Upstream libffi does not yet support ARCv3. Meanwhile libffi support
for 64-bit ARCv3 architecture is available in Synopsys libffi fork on
github. This commit adds libffi bbappend to enable support for arc64.

Signed-off-by: Sergey Matyukevich <[email protected]>
ARCv3 32-bit CPU does not have support for 64-bit atomic operations.
Emulate missing atomic contstructs via libatomic.

Signed-off-by: Sergey Matyukevich <[email protected]>
Upstream Linux kernel does not yet support ARCv3. Add recipe for
Synopsys kernel fork on github which provides initial ARCv3 support
for both 32-bit and 64-bit architecture flavors.

Signed-off-by: Sergey Matyukevich <[email protected]>
Add perl-cross patch adding support for ARCv3.

Signed-off-by: Sergey Matyukevich <[email protected]>
Update ARC gcc version to arc-2021.03 release.
New version adds support for ARCv3.

Signed-off-by: Sergey Matyukevich <[email protected]>
Update ARC binutils version to arc-2021.03 release.
New version adds support for ARCv3.

Signed-off-by: Sergey Matyukevich <[email protected]>
Upstream glibc does not yet support ARCv3. Add recipes for Synopsys
glibc fork that provides support for the new architecture.

Signed-off-by: Sergey Matyukevich <[email protected]>
Add tune features for ARCv3. Add two ARCv3 machines: HS5x and HS6x.

Signed-off-by: Sergey Matyukevich <[email protected]>
Add custom minimalistic distro suitable for ARCv3 devices including both
HS5x and HS6x. This distro provides core-image-minimal image with busybox
mdev as a device and inirt manager. The primary purpose of this distro is
to generate small kernel ramdisks images suitable for running ARC kernels
using nSIM and QEMU emulators.

Signed-off-by: Sergey Matyukevich <[email protected]>
Updated layer is compatible with Yocto v4.0 Kirkstone release.

Signed-off-by: Sergey Matyukevich <[email protected]>
@@ -8,6 +8,6 @@ BBFILE_COLLECTIONS += "synopsys-layer"
BBFILE_PATTERN_synopsys-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_synopsys-layer = "6"

LAYERSERIES_COMPAT_synopsys-layer = " honister"
LAYERSERIES_COMPAT_synopsys-layer = " kirkstone"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cannot we just add kirkstone along with honister? I.e. is there something which makes our layer incompatible with honister?
For the record, kirkstone is going to be the next LTS - so it's good to rely on it looking forward.

Copy link
Member

@abrodkin abrodkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please find some nitpicks below.

@@ -0,0 +1,16 @@
DISTRO_NAME = "Synopsys minimal ramdisk"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering how much smaller is that image compared to core-image-minimal?
Or there're other benefits compared to aforementioned more standard "distro"?

VIRTUAL-RUNTIME_init_manager = "busybox"
VIRTUAL-RUNTIME_base-utils = "busybox"

PREFERRED_PROVIDER_virtual/kernel = "linux-arc64-dev"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW by the time of this change Linux for ARCv3 is not yet available.
So that might be another reason to not mess with our own distro ;)


PREFERRED_PROVIDER_virtual/kernel = "linux-arc64-dev"

GCCVERSION = "arc"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that all might go into conf/machine/hapshs{5|6}x.conf.
Moreover I'd do that more future proof with ?= so that when ARCv3 ports are merged upstream we may override that in the local.conf.

@@ -0,0 +1,43 @@
TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'hs58', 'arc32', 'arc64', d)}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why adding hs58 in TUNE_ARCH? Readme sys "TUNE_ARCH - The GNU canonical arch for a specific architecture". And so it looks like more appropriate would be only arc32 & arc64.

TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"

TUNEVALID[hs58] = "Enable ARCv3 64-bit"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'hs58', ' -mcpu=hs5x', '', d)}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is incorrect technically as we do have 2 separate flavors of -mcpu (hs58 & hs5x) and they are not the same: on top of hs5x, hs58 has advanced mpy9 SIMD instructions and double load/store instructions.

I.e. we need to have both tunes: hs5x & hs58. Moreover if to be more flexible and to some extent more compatible we may do what's done for ARCv2: have hs5x as a base and make hs58 tune as a superset with some more options (namely -mll64 & -msimd).

TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'hs58', ' -mcpu=hs5x', '', d)}"

TUNEVALID[hs68] = "Enable ARCv3 64-bit core"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'hs68', ' -mcpu=hs6x', '', d)}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar goes here: hs68 is hs6x + -msimd + -m128.

TUNEVALID[ll128] = "Enable 128-bit load/store operations"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'll128', ' -m128', ' -mno-128', d)}"

TUNEVALID[div_rem] = "Enable simple divider"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure really if we want to deal with so powerful new processors w/o HW division - it will compromise their purpose as a high-performance application processors then, no? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants