[Buildroot] ARC support in Buildroot

[Buildroot] ARC support in Buildroot

[Thomas Petazzoni via 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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Alexey Brodkin via buildroot]

Hi Thomas,

> 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.

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.

> 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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Thomas Petazzoni via buildroot]

Hello Alexey,

Thanks for your feedback! See below.

On Wed, 2 Aug 2023 21:20:28 +0000
Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:

> 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?

> 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!

> 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 :)

> 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.

> 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 ;)

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

> 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

> 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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Alexey Brodkin via buildroot]

Hi Thomas,

> On Wed, 2 Aug 2023 21:20:28 +0000
> Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
> 
> > 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?

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.

> > 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.

> > 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 ;)
> 
> I think then it would be good to add a readme.txt in Buildroot about
> the snps_archs38_haps_defconfig configuration.

Clear, we'll clean-up that mess and will add readmes for all the relevant platforms.

> 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)

> (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.

> (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)?

> 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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Thomas Petazzoni via buildroot]

Hello Alexey,

On Thu, 3 Aug 2023 07:59:56 +0000
Alexey Brodkin via buildroot <buildroot@buildroot.org> wrote:

> > 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.

> 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 :-)

> > (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.

> > (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.

> > (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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Thomas Petazzoni via buildroot]

On Sun, 6 Aug 2023 22:51:27 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:

> 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:

<sergeyim@bouncer.synopsys.com> (expanded from
    <Sergey.Matyukevich@synopsys.com>): 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
<arc-buildroot@synopsys.com> ?

Thanks,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Arnout Vandecappelle via buildroot]

On 03/08/2023 09:59, Alexey Brodkin via buildroot wrote:
> Hi Thomas,
> 
>> On Wed, 2 Aug 2023 21:20:28 +0000
>> Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:
>>
>>> 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?
> 
> 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.

  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.


> 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]
>> (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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Thomas Petazzoni via buildroot]

Hello,

On Fri, 11 Aug 2023 22:00:48 +0200
Arnout Vandecappelle <arnout@mind.be> wrote:

> > 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.

[...]

>   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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Alexey Brodkin via buildroot]

Hi Thomas, Arnout,

> On Fri, 11 Aug 2023 22:00:48 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
> 
> > > 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.
> 
> [...]
> 
> >   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.

> 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
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] ARC support in Buildroot

[Thomas Petazzoni via buildroot]

On Fri, 11 Aug 2023 22:34:27 +0000
Alexey Brodkin <Alexey.Brodkin@synopsys.com> wrote:

> 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
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot