-
Notifications
You must be signed in to change notification settings - Fork 6
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
base: master
Are you sure you want to change the base?
Conversation
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" |
There was a problem hiding this comment.
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.
There was a problem hiding this 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" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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)}" |
There was a problem hiding this comment.
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)}" |
There was a problem hiding this comment.
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)}" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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? :)
Summary
This PR implements the following updates for Synopsys Yocto layer:
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:
Status
HS6x
Build commands for HS6x machine using snps-arc64-minimal distro:
Successful build and boot using nSIM.
HS5x
Build command for HS5x machine using snps-arc64-minimal distro:
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.