ARC support in Buildroot
Hello Alexey, Hello ARC maintainers,
I am reaching out to you to understand the interest that you have (or no longer have) with the ARC support in Buildroot.
Indeed, we haven't seen any updates from ARC people in a long time. Our toolchain components for ARC are stuck at arc-2020.09, which is quite old as I've noticed you have release much newer versions of gcc/binutils/gdb. Also, some of that ARC support has been upstreamed I guess.
Is there still some interest at Synopsys in maintaining the ARC support in Buildroot? If not, we would probably want to get rid of the support for this CPU architecture.
Side question, is there an emulated platform that is freely available we could use to do runtime testing of ARC? I very quickly looked at the 4 defconfigs we have, but none of them seem to be related to a freely available emulated platform. And in fact, only one of the defconfigs seem to have a readme.txt to indicate how to use it.
Thanks in advance for your feedback!
Best regards,
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Thomas,
Quoted 9 lines
I am reaching out to you to understand the interest that you have (or no longer have) with the ARC support in Buildroot.
Indeed, we haven't seen any updates from ARC people in a long time. Our toolchain components for ARC are stuck at arc-2020.09, which is quite old as I've noticed you have release much newer versions of gcc/binutils/gdb. Also, some of that ARC support has been upstreamed I guess.
Quoted 3 lines
Is there still some interest at Synopsys in maintaining the ARC support in Buildroot? If not, we would probably want to get rid of the support for this CPU architecture.
We do have an interest in ARC cores support in Buildroot and in fact we and our customers actively use it.
And the reason you were not seeing our contributions is two-fold.
From one point of view ARCompact & ARCv2 support is so good
in the upstream components that barely anything needs to be done for them. Possibly I'm missing something but the only report I keep getting with ARC-related problems it's glibc build failure for ARC700 - that problem was discussed some time ago and I sill have that action-item to fix it.
On the other hand, we were busy working on ARCv3 ISA support, see [1] & [2]. Of which the latter is a family of 64-bit processors!
And so, while it was all work-in-progress we kept all the work in our fork [3], including changes related to ARCompact & ARCv2 processors.
That said, we do plan to upstream our ARCv3 support in all the projects as usual, and Buildroot will be one of the first projects seeing these changes.
In that sense, I'd like to keep ARC architecture in Buildroot.
Quoted 5 lines
Side question, is there an emulated platform that is freely available we could use to do runtime testing of ARC? I very quickly looked at the 4 defconfigs we have, but none of them seem to be related to a freely available emulated platform. And in fact, only one of the defconfigs seem to have a readme.txt to indicate how to use it.
Great question! We do have now QEMU port for ARC and similarly to other components it was not yet upstreamed as we wanted to have ARCv3 supported there well enough, which is achieved now. If of any interest it could be found here [4]. We're still polishing it, but it's definitely usable. As a matter of fact for a couple of years now QEMU is an essential part of Zephyr SDK [5] and used for per-PR upstream verification of Zephyr RTOS. And since Linux along with Zephyr RTOS are the key payloads for QEMU, it's only essential to run Buildroot-built images in QEMU for ARC.
Now, why you didn't see any QEMU-related defconfigs in the Buildroot, it's because we intentionally introduced a "virt" platform in QEMU which fully matches our reference FPGA platform (HAPS) and proprietary simulator (DesignWare nSIM). That said "snps_archs38_haps_defconfig" will equally well work on HAPS, nSIM & QEMU ;)
That said, I hope my comments make sense and improve your perception of ARC support in Buildroot and kinda gives a feeling of our interest in the project. Let me know, though, if there's anything you feel we really need to improve and what might be useful for the Buildroot from our side.
[1] https://www.synopsys.com/dw/ipdir.php?ds=arc-HS5x-processors
[2] https://www.synopsys.com/dw/ipdir.php?ds=arc-HS6x-processors
[3] https://github.com/foss-for-synopsys-dwc-arc-processors/buildroot
[4] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu
[5] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu
Regards,
Alexey
P.S. That's too bad that due to some bureaucracy nonsense I was not able
to meet you and other folks in Prague last month, even though I had all booked and planned. But I hope to see all of you on the next event like ELCE.
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Hello Alexey,
Thanks for your feedback! See below.
Quoted 10 lines · On Wed, 2 Aug 2023 21:20:28 +0000 Alexey Brodkin <[email protected]>…
We do have an interest in ARC cores support in Buildroot and in fact we and our customers actively use it.
And the reason you were not seeing our contributions is two-fold.
From one point of view ARCompact & ARCv2 support is so good
in the upstream components that barely anything needs to be done for them. Possibly I'm missing something but the only report I keep getting with ARC-related problems it's glibc build failure for ARC700 - that problem was discussed some time ago and I sill have that action-item to fix it.
Well, if the support in upstream GCC/binutils/GDB is so good, why do we still have ARC-specific version that are now outdated?
config BR2_GCC_VERSION_ARC (based on gcc 10.x)
config BR2_BINUTILS_VERSION_ARC (based on binutils 2.34! super old) arc-2020.09-release-gdb for GDB
Can we drop those special versions and assume what's in upstream GCC/binutils/GDB is good enough?
Quoted 2 lines
On the other hand, we were busy working on ARCv3 ISA support, see [1] & [2]. Of which the latter is a family of 64-bit processors!
Very nice!
Quoted 2 lines
And so, while it was all work-in-progress we kept all the work in our fork [3], including changes related to ARCompact & ARCv2 processors.
Would be good to see things being upstreamed of course :)
Quoted 2 lines
That said, we do plan to upstream our ARCv3 support in all the projects as usual, and Buildroot will be one of the first projects seeing these changes.
OK.
Quoted 9 lines
Great question! We do have now QEMU port for ARC and similarly to other components it was not yet upstreamed as we wanted to have ARCv3 supported there well enough, which is achieved now. If of any interest it could be found here [4]. We're still polishing it, but it's definitely usable. As a matter of fact for a couple of years now QEMU is an essential part of Zephyr SDK [5] and used for per-PR upstream verification of Zephyr RTOS. And since Linux along with Zephyr RTOS are the key payloads for QEMU, it's only essential to run Buildroot-built images in QEMU for ARC.
Quoted 5 lines
Now, why you didn't see any QEMU-related defconfigs in the Buildroot, it's because we intentionally introduced a "virt" platform in QEMU which fully matches our reference FPGA platform (HAPS) and proprietary simulator (DesignWare nSIM). That said "
snps_archs38_haps_defconfig" will equally well work on HAPS, nSIM & QEMU ;)
I think then it would be good to add a readme.txt in Buildroot about the snps_archs38_haps_defconfig configuration.
Currently, we have 4 ARC configurations:
snps_arc700_axs101_defconfig -> no readme.txt
snps_archs38_axs103_defconfig -> no readme.txt snps_archs38_haps_defconfig -> no readme.txt snps_archs38_hsdk_defconfig -> has board/synopsys/hsdk/readme.txt but it points to https://embarc.org/platforms.html which is a dead linke
Quoted 4 lines
That said, I hope my comments make sense and improve your perception of ARC support in Buildroot and kinda gives a feeling of our interest in the project. Let me know, though, if there's anything you feel we really need to improve and what might be useful for the Buildroot from our side.
See above :-)
I think the action points are:
(1) Drop ARC-specific versions of GCC/binutils/GDB if you confirm it's OK
(2) Add readme.txt about the different defconfigs so we understand which platform they target, and where it can be found, if freely available.
(3) Perhaps make it possible to build the ARC-specific qemu, so that we can out of the box have a qemu that we can use to boot test one ARC platform. Then we can enable that in our Gitlab CI
Quoted 4 lines
P.S. That's too bad that due to some bureaucracy nonsense I was not able
to meet you and other folks in Prague last month, even though I had all booked and planned. But I hope to see all of you on the next event like ELCE.
Yeah, definitely. Next year ELC will be in the US, there will be no ELC in Europe. There is Embedded Recipes in September in Paris, then FOSDEM in Brussels in February.
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Thomas,
Quoted 17 lines
Quoted 10 lines · On Wed, 2 Aug 2023 21:20:28 +0000 Alexey Brodkin <[email protected]>…
We do have an interest in ARC cores support in Buildroot and in fact we and our customers actively use it.
And the reason you were not seeing our contributions is two-fold.
From one point of view ARCompact & ARCv2 support is so good
in the upstream components that barely anything needs to be done for them. Possibly I'm missing something but the only report I keep getting with ARC-related problems it's glibc build failure for ARC700 - that problem was discussed some time ago and I sill have that action-item to fix it.Well, if the support in upstream GCC/binutils/GDB is so good, why do we still have ARC-specific version that are now outdated?
Quoted 6 lines
config
BR2_GCC_VERSION_ARC(based on gcc 10.x)
configBR2_BINUTILS_VERSION_ARC(based on binutils 2.34! super old) arc-2020.09-release-gdb for GDBCan we drop those special versions and assume what's in upstream GCC/binutils/GDB is good enough?
Well, we'll just update it to say 2023.03 [1] or maybe even 2023.09 later in the fall :)
And the reason is that ARCv3 support. As I mentioned ARCompact/ARCv2 is well supported in upstream GCC/Binutils/GDB etc and all the fixes go right to the upstream repos as we have our own maintainers who take care of that.
So, in theory it should be OK to remove "arc-xxxx.yy" toolchains from Buildroot. But since we were a bit late with ARCv3 changes for GCC 13, those will only land in GCC 14 which is going to happen sometime in 2024, I guess.
Thus, we'll need to have "arc-xxxx.yy" anyway with sources from our GitHub forks, primarily to support ARCv3 stuff. Thus, I didn't want to introduce that turbulence with removal of ARC toolchain and then adding it back next week.
I hope it explains the situation.
Quoted 4 lines
Quoted 2 lines
And so, while it was all work-in-progress we kept all the work in our fork [3], including changes related to ARCompact & ARCv2 processors.
Would be good to see things being upstreamed of course :)
As usual, we're working on that. But you know it better than me - it takes time.
Quoted 9 lines
Quoted 9 lines
Great question! We do have now QEMU port for ARC and similarly to other components it was not yet upstreamed as we wanted to have ARCv3 supported there well enough, which is achieved now. If of any interest it could be found here [4]. We're still polishing it, but it's definitely usable. As a matter of fact for a couple of years now QEMU is an essential part of Zephyr SDK [5] and used for per-PR upstream verification of Zephyr RTOS. And since Linux along with Zephyr RTOS are the key payloads for QEMU, it's only essential to run Buildroot-built images in QEMU for ARC.
Quoted 8 lines
Quoted 5 lines
Now, why you didn't see any QEMU-related defconfigs in the Buildroot, it's because we intentionally introduced a "virt" platform in QEMU which fully matches our reference FPGA platform (HAPS) and proprietary simulator (DesignWare nSIM). That said "
snps_archs38_haps_defconfig" will equally well work on HAPS, nSIM & QEMU ;)I think then it would be good to add a readme.txt in Buildroot about the
snps_archs38_haps_defconfigconfiguration.
Clear, we'll clean-up that mess and will add readmes for all the relevant platforms.
Quoted 3 lines
I think the action points are:
(1) Drop ARC-specific versions of GCC/binutils/GDB if you confirm it's OK
As I said, we'll update ARC toolchain instead:
- Primarily to add ARCv3 support and while ARC toolchian will be there anyway
- It makes sense to keep it for ARCompact/ARCv2 as there're some fixes and improvements which are not yet upstream (because release schedules don't match)
Quoted 3 lines
(2) Add readme.txt about the different defconfigs so we understand which platform they target, and where it can be found, if freely available.
We'll do that.
Quoted 3 lines
(3) Perhaps make it possible to build the ARC-specific qemu, so that we can out of the box have a qemu that we can use to boot test one ARC platform. Then we can enable that in our Gitlab CI
Well, QEMU for ARC is easily doable. I guess it's more of a question on how to integrate it with Buildroot's GitLab flow, any references to docs on the matter (sorry if asking something simple, but while I have your attention, possibly you may point me at something immediately)?
Quoted 3 lines
Yeah, definitely. Next year ELC will be in the US, there will be no ELC in Europe. There is Embedded Recipes in September in Paris, then FOSDEM in Brussels in February.
Good, I hope next year I'll be a bit luckier with traveling.
-Alexey
[1] https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2023.03-release
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Hello Alexey,
Quoted 5 lines · On Thu, 3 Aug 2023 07:59:56 +0000 Alexey Brodkin via buildroot…
Quoted 2 lines
Can we drop those special versions and assume what's in upstream GCC/binutils/GDB is good enough?
Well, we'll just update it to say 2023.03 [1] or maybe even 2023.09 later in the fall :)
Looking forward to your patch doing this.
Quoted 11 lines
And the reason is that ARCv3 support. As I mentioned ARCompact/ARCv2 is well supported in upstream GCC/Binutils/GDB etc and all the fixes go right to the upstream repos as we have our own maintainers who take care of that.
So, in theory it should be OK to remove "arc-xxxx.yy" toolchains from Buildroot. But since we were a bit late with ARCv3 changes for GCC 13, those will only land in GCC 14 which is going to happen sometime in 2024, I guess.
Thus, we'll need to have "arc-xxxx.yy" anyway with sources from our GitHub forks, primarily to support ARCv3 stuff. Thus, I didn't want to introduce that turbulence with removal of ARC toolchain and then adding it back next week.
Sounds good to me, but it should be maintained then :-)
Quoted 6 lines
Quoted 1 line
(1) Drop ARC-specific versions of GCC/binutils/GDB if you confirm it's OK
As I said, we'll update ARC toolchain instead:
- Primarily to add ARCv3 support and while ARC toolchian will be there anyway
- It makes sense to keep it for ARCompact/ARCv2 as there're some fixes and improvements which are not yet upstream (because release schedules don't match)
OK.
Quoted 5 lines
Quoted 3 lines
(2) Add readme.txt about the different defconfigs so we understand which platform they target, and where it can be found, if freely available.
We'll do that.
Good.
Quoted 8 lines
Quoted 3 lines
(3) Perhaps make it possible to build the ARC-specific qemu, so that we can out of the box have a qemu that we can use to boot test one ARC platform. Then we can enable that in our Gitlab CI
Well, QEMU for ARC is easily doable. I guess it's more of a question on how to integrate it with Buildroot's GitLab flow, any references to docs on the matter (sorry if asking something simple, but while I have your attention, possibly you may point me at something immediately)?
We probably need to simply tweak the existing Qemu package. Not a priority, but would be nice.
Something more important: fix the broken snps_arc700_axs101_defconfig. You're normally receiving e-mails about this. If not, let me know, because it means there is an issue in the notification machinery.
See:
https://gitlab.com/buildroot.org/buildroot/-/jobs/4795673779
https://bugs.busybox.net/show_bug.cgi?id=15446
Thanks a lot!
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 3 lines · On Sun, 6 Aug 2023 22:51:27 +0200 Thomas Petazzoni…
Something more important: fix the broken
snps_arc700_axs101_defconfig. You're normally receiving e-mails about this. If not, let me know, because it means there is an issue in the notification machinery.
Speaking of defconfigs, I just merged configs/snps_arc700_nsim_defconfig from Sergey, but he is apparently no longer at Synopsys:
<[email protected]> (expanded from
<[email protected]>): User is no longer with Synopsys
Should I move this defconfig to the ARC Maintainers entry in the DEVELOPERS file?
Is someone receiving and looking at the mails received at <[email protected]> ?
Thanks,
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 29 lines · Alexey Brodkin via buildroot
Hi Thomas,
Quoted 17 lines
Quoted 10 lines · On Wed, 2 Aug 2023 21:20:28 +0000 Alexey Brodkin <[email protected]>…
We do have an interest in ARC cores support in Buildroot and in fact we and our customers actively use it.
And the reason you were not seeing our contributions is two-fold.
From one point of view ARCompact & ARCv2 support is so good
in the upstream components that barely anything needs to be done for them. Possibly I'm missing something but the only report I keep getting with ARC-related problems it's glibc build failure for ARC700 - that problem was discussed some time ago and I sill have that action-item to fix it.Well, if the support in upstream GCC/binutils/GDB is so good, why do we still have ARC-specific version that are now outdated?
Quoted 6 lines
config
BR2_GCC_VERSION_ARC(based on gcc 10.x)
configBR2_BINUTILS_VERSION_ARC(based on binutils 2.34! super old) arc-2020.09-release-gdb for GDBCan we drop those special versions and assume what's in upstream GCC/binutils/GDB is good enough?
Well, we'll just update it to say 2023.03 [1] or maybe even 2023.09 later in the fall :)
Quoted 7 lines
And the reason is that ARCv3 support. As I mentioned ARCompact/ARCv2 is well supported in upstream GCC/Binutils/GDB etc and all the fixes go right to the upstream repos as we have our own maintainers who take care of that.
So, in theory it should be OK to remove "arc-xxxx.yy" toolchains from Buildroot. But since we were a bit late with ARCv3 changes for GCC 13, those will only land in GCC 14 which is going to happen sometime in 2024, I guess.
I think (Thomas correct me if I'm wrong) that we would actually prefer that
ARC just uses the normal toolchain, and that when ARCv3 is introduced in Buildroot, the "special toolchain" will depend on BR2_arc_v3_or_whatever_it_will_be_called rather than BR2_arc.
Quoted 3 lines
Thus, we'll need to have "arc-xxxx.yy" anyway with sources from our GitHub forks, primarily to support ARCv3 stuff. Thus, I didn't want to introduce that turbulence with removal of ARC toolchain and then adding it back next week.
[snip]
Quoted 6 lines
Quoted 1 line
(1) Drop ARC-specific versions of GCC/binutils/GDB if you confirm it's OK
As I said, we'll update ARC toolchain instead:
- Primarily to add ARCv3 support and while ARC toolchian will be there anyway
- It makes sense to keep it for ARCompact/ARCv2 as there're some fixes and improvements which are not yet upstream (because release schedules don't match)
And for those fixes, I think it's better for us if they're carried as patches
in Buildroot.
Using the upstream toolchain components is preferred because that way the user
has the version choice, rather than being forced to use the ARC-specific version of that moment. Also, when someone updates to a new GCC version, it immediately becomes available for ARC as well (instead of having to wait 3 years for the ARC-specific version to be updated...).
Regards,
Arnout
[snip]
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Hello,
Quoted 8 lines · On Fri, 11 Aug 2023 22:00:48 +0200 Arnout Vandecappelle <[email protected]> wrote:
Quoted 3 lines
So, in theory it should be OK to remove "arc-xxxx.yy" toolchains from Buildroot. But since we were a bit late with ARCv3 changes for GCC 13, those will only land in GCC 14 which is going to happen sometime in 2024, I guess.
I think (Thomas correct me if I'm wrong) that we would actually prefer that
ARC just uses the normal toolchain, and that when ARCv3 is introduced in Buildroot, the "special toolchain" will depend onBR2_arc_v3_or_whatever_it_will_be_calledrather thanBR2_arc.
[...]
Quoted 5 lines
Using the upstream toolchain components is preferred because that way the user
has the version choice, rather than being forced to use the ARC-specific version of that moment. Also, when someone updates to a new GCC version, it immediately becomes available for ARC as well (instead of having to wait 3 years for the ARC-specific version to be updated...).
This is a very good point indeed.
Alexey: when do you expect to submit ARCv3 support in Buildroot? Depending on when it comes we might decide to either drop or keep the ARC-specific toolchain components, and if need be re-introduce them for ARCv3.
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Thomas, Arnout,
Quoted 14 lines
Quoted 8 lines · On Fri, 11 Aug 2023 22:00:48 +0200 Arnout Vandecappelle <[email protected]> wrote:
Quoted 3 lines
So, in theory it should be OK to remove "arc-xxxx.yy" toolchains from Buildroot. But since we were a bit late with ARCv3 changes for GCC 13, those will only land in GCC 14 which is going to happen sometime in 2024, I guess.
I think (Thomas correct me if I'm wrong) that we would actually prefer that
ARC just uses the normal toolchain, and that when ARCv3 is introduced in Buildroot, the "special toolchain" will depend onBR2_arc_v3_or_whatever_it_will_be_calledrather thanBR2_arc.[...]
Quoted 7 lines
Quoted 5 lines
Using the upstream toolchain components is preferred because that way the user
has the version choice, rather than being forced to use the ARC-specific version of that moment. Also, when someone updates to a new GCC version, it immediately becomes available for ARC as well (instead of having to wait 3 years for the ARC-specific version to be updated...).This is a very good point indeed.
With that I agree.
Quoted 4 lines
Alexey: when do you expect to submit ARCv3 support in Buildroot? Depending on when it comes we might decide to either drop or keep the ARC-specific toolchain components, and if need be re-introduce them for ARCv3.
I'd say in coming weeks as I already started to work on clean-up and preparing for submission of first patches. In that sense I may handle that myself. One question to you though, if you prefer to have 2 patches:
1. Remove ARC-specific GCC & Binutils
2. Introduce ARCv3-specific tools: GCC, Binutils & glibc (uClibc is already upstreamed)
Or do it in one patch?
-Alexey
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot
Quoted 5 lines · On Fri, 11 Aug 2023 22:34:27 +0000 Alexey Brodkin…
I'd say in coming weeks as I already started to work on clean-up and preparing for submission of first patches. In that sense I may handle that myself. One question to you though, if you prefer to have 2 patches:
1. Remove ARC-specific GCC & Binutils
2. Introduce ARCv3-specific tools: GCC, Binutils & glibc (uClibc is already upstreamed)
Are the ARCv3-specific tools going to be different than the ARC-specific tools?
I think it could go like this:
- Update ARC-specific tools to newer versions (one patch)
- Add ARCv3 (one patch)
- Make ARC-specific tools only available for ARCv3 (one patch)
How does that sound?
Thomas
Signature · 7 lines
Thomas Petazzoni, co-owner and CEO, Bootlin Embedded Linux and Kernel engineering and training https://bootlin.com _______________________________________________ buildroot mailing list [email protected] https://lists.buildroot.org/mailman/listinfo/buildroot