ARMv4 (not v4t) marked obsolete in gcc-6

ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
we currenly support in the Linux kernel.

The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
and it will be removed in the following release (gcc-7) one year later, unless someone
raises concerns over it.

We will of course be able to compile kernels for a long time using older compilers, but
this tends to get harder over the years as people upgrade to newer distros.

Here is an overview of which ARMv4 platforms we still have as of Linux-4.6:

* Moxart: this is the only one that was recently (2013) added, and is apparently
  hardware that remains commercially available.

* Gemini: officially supported in OpenWRT today, with the latest compiler. This one
  will likely cause the most issues for actual users. It would be helpful to get
  some numbers about users or downloads here, to see whether it can be dropped
  in a future OpenWRT release or if it might be possible to leave this on
  gcc-6.x when the other platforms move on to gcc-7+

* sa1100: A lot of people have these, but I'm guessing this is mostly interesting
  for hobbyists that are able to keep using older gcc versions.

* RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
  the past but only remain in small quantities as far as I know. Russell still
  uses them. He also uses older compilers, so probably isn't affected
  immediately.

	Arnd

ARMv4 (not v4t) marked obsolete in gcc-6

[Russell King - ARM Linux]

On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
> * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
>   the past but only remain in small quantities as far as I know. Russell still
>   uses them. He also uses older compilers, so probably isn't affected
>   immediately.

And I'm unlikely to _ever_ move off them, unless there's some miraculous
change which means I end up with server type systems to replace them.
That's been very unlikely for some time, as there's little interest in
hardware people producing such platforms and I'm no longer in a position
where, even if someone did, I'd end up with such hardware.

So I'm pretty much stuck with what I have unless I replace it with x86
systems.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Thursday 10 March 2016, Russell King - ARM Linux wrote:
> On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
> > * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
> >   the past but only remain in small quantities as far as I know. Russell still
> >   uses them. He also uses older compilers, so probably isn't affected
> >   immediately.
> 
> And I'm unlikely to ever move off them, unless there's some miraculous
> change which means I end up with server type systems to replace them.
> That's been very unlikely for some time, as there's little interest in
> hardware people producing such platforms and I'm no longer in a position
> where, even if someone did, I'd end up with such hardware.
> 
> So I'm pretty much stuck with what I have unless I replace it with x86
> systems.

Which compiler version do you have at the moment on those? Are you also
stuck on OABI for the same reasons? 

	Arnd

ARMv4 (not v4t) marked obsolete in gcc-6

[Russell King - ARM Linux]

On Thu, Mar 10, 2016 at 05:59:37PM +0100, Arnd Bergmann wrote:
> On Thursday 10 March 2016, Russell King - ARM Linux wrote:
> > On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
> > > * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
> > >   the past but only remain in small quantities as far as I know. Russell still
> > >   uses them. He also uses older compilers, so probably isn't affected
> > >   immediately.
> > 
> > And I'm unlikely to ever move off them, unless there's some miraculous
> > change which means I end up with server type systems to replace them.
> > That's been very unlikely for some time, as there's little interest in
> > hardware people producing such platforms and I'm no longer in a position
> > where, even if someone did, I'd end up with such hardware.
> > 
> > So I'm pretty much stuck with what I have unless I replace it with x86
> > systems.
> 
> Which compiler version do you have at the moment on those? Are you also
> stuck on OABI for the same reasons?

Well, the compiler version on the platforms is irrelevant as they're
cross-built kernels, for which I'm currently using gcc 4.7.4 for all
kernel builds.

The platforms themselves are pretty much stuck on OABI for ever
because there's no way to progressively convert them to EABI in a
sane manner.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Thursday 10 March 2016, Russell King - ARM Linux wrote:
> On Thu, Mar 10, 2016 at 05:59:37PM +0100, Arnd Bergmann wrote:
> > On Thursday 10 March 2016, Russell King - ARM Linux wrote:
> > > On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
> > > > * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
> > > >   the past but only remain in small quantities as far as I know. Russell still
> > > >   uses them. He also uses older compilers, so probably isn't affected
> > > >   immediately.
> > > 
> > > And I'm unlikely to ever move off them, unless there's some miraculous
> > > change which means I end up with server type systems to replace them.
> > > That's been very unlikely for some time, as there's little interest in
> > > hardware people producing such platforms and I'm no longer in a position
> > > where, even if someone did, I'd end up with such hardware.
> > > 
> > > So I'm pretty much stuck with what I have unless I replace it with x86
> > > systems.
> > 
> > Which compiler version do you have at the moment on those? Are you also
> > stuck on OABI for the same reasons?
> 
> Well, the compiler version on the platforms is irrelevant as they're
> cross-built kernels, for which I'm currently using gcc 4.7.4 for all
> kernel builds.
> 
> The platforms themselves are pretty much stuck on OABI for ever
> because there's no way to progressively convert them to EABI in a
> sane manner.

Ok, got it, for some reason I thought you were building the kernel
natively for these machines. So at least you can use gcc-6.0 to build
an EABI kernel with OABI compat (if that's not what you are doing already).

I had wondered about the R_ARM_V4BX trick already, and if that keeps working
until binutils get changed (Ramana mentioned that it will be a while after
the gcc removal before that happens), you can keep using gcc-7 and higher
for at least a while longer.

I think for the RiscPC platform, the fact that we need to pass -march=armv3
means that as soon as armv3 and armv4 support get removed in gcc, you are
stuck with the last supported compiler version. My understanding is that
gcc-4.9 already has serious bugs (internal compiler error) when building
certain files in the kernel, but the bug I opened when I found this has
recently been fixed, so it might again work with gcc-6, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254

	Arnd

ARMv4 (not v4t) marked obsolete in gcc-6

[Dmitry Eremin-Solenikov]

Hello,

2016-03-10 12:13 GMT+03:00 Arnd Bergmann <arnd@arndb.de>:
> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
> we currenly support in the Linux kernel.
>
> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
> and it will be removed in the following release (gcc-7) one year later, unless someone
> raises concerns over it.

In which form should we raise concerns? Is it about stepping up as a
maintainers, or just
about telling them that platforms are used? My main concern with
limiting ARMv4 platforms
to older compilers would be that sooner or later we won't be able to
use newer kernels,
as the mainline will stop supporting older compilers.


-- 
With best wishes
Dmitry

ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Thursday 10 March 2016, Dmitry Eremin-Solenikov wrote:
> 2016-03-10 12:13 GMT+03:00 Arnd Bergmann <arnd@arndb.de>:
> > I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
> > so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
> > we currenly support in the Linux kernel.
> >
> > The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
> > and it will be removed in the following release (gcc-7) one year later, unless someone
> > raises concerns over it.
> 
> In which form should we raise concerns? Is it about stepping up as a
> maintainers, or just
> about telling them that platforms are used? 


As I understand it, having someone step up as an active maintainer would leave the
architecture supported indefinitely, while saying you still need the support
can at least delay the process a bit. Ramana can probably clarify further
what the gcc folks are looking for exactly.

> My main concern with
> limiting ARMv4 platforms
> to older compilers would be that sooner or later we won't be able to
> use newer kernels,
> as the mainline will stop supporting older compilers.

I think we've been doing ok with keeping old compilers working, gcc-4.2 
from 2007 seems to work fine for the older targets (it misses support for
some of the armv7 platforms in turn) and in theory we should be able to
get older ones working with a few patches: according to the README
file in the kernel, we support gcc-3.2 (from 2002) in theory, but I'm
running into some trickier problems with some of the older compilers.

It's definitely clear that at some point we will stop supporting gcc-6
for building the kernel, but I don't know if that's already 2022 or
only 2038 (when all sort of software breaks).

How long do you think you need for your systems?
Do you still ship new products, or are these all legacy devices that
will have a failing battery or flash at some point in the future?

	Arnd

ARMv4 (not v4t) marked obsolete in gcc-6

[Dmitry Eremin-Solenikov]

2016-03-10 19:38 GMT+03:00 Arnd Bergmann <arnd@arndb.de>:
> On Thursday 10 March 2016, Dmitry Eremin-Solenikov wrote:
>> 2016-03-10 12:13 GMT+03:00 Arnd Bergmann <arnd@arndb.de>:
>> > I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
>> > so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
>> > we currenly support in the Linux kernel.
>> >
>> > The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
>> > and it will be removed in the following release (gcc-7) one year later, unless someone
>> > raises concerns over it.
>>
>> In which form should we raise concerns? Is it about stepping up as a
>> maintainers, or just
>> about telling them that platforms are used?
>
>
> As I understand it, having someone step up as an active maintainer would leave the
> architecture supported indefinitely, while saying you still need the support
> can at least delay the process a bit. Ramana can probably clarify further
> what the gcc folks are looking for exactly.

It would be good to know exactly.

> How long do you think you need for your systems?
> Do you still ship new products, or are these all legacy devices that
> will have a failing battery or flash at some point in the future?

I'm using several old PDAs with StrongARM CPU. They have CF cards
and battery life isn't that important for me. I really see no point in dropping
support for them just because GCC folks told us so.

And BTW: I'm using EABI with that v4bx trick both in kernel and userspace.

-- 
With best wishes
Dmitry

ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Friday 11 March 2016 00:49:20 Dmitry Eremin-Solenikov wrote:
> > How long do you think you need for your systems?
> > Do you still ship new products, or are these all legacy devices that
> > will have a failing battery or flash at some point in the future?
> 
> I'm using several old PDAs with StrongARM CPU. They have CF cards
> and battery life isn't that important for me. I really see no point in dropping
> support for them just because GCC folks told us so.

The question for now is whether it's ok for you if gcc-7 stops shipping
with support for -march-armv4. If you can either keep using your platforms
with -march=armv4t and --fix-v4bx, or stop upgrading the toolchain after
gcc-6, I think everything is fine from the platform point of view.

> And BTW: I'm using EABI with that v4bx trick both in kernel and userspace.

Do you have a patch for the kernel for this? I believe we never pass
--fix-v4bx today, but we should probably start doing that on all
linkers that understand it, so we don't get surprised by bugs when
the compiler starts requiring it.

	Arnd

ARMv4 (not v4t) marked obsolete in gcc-6

[Baruch Siach]

Hi Arnd,

On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
> we currenly support in the Linux kernel.
> 
> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
> and it will be removed in the following release (gcc-7) one year later, unless someone
> raises concerns over it.
> 
> We will of course be able to compile kernels for a long time using older compilers, but
> this tends to get harder over the years as people upgrade to newer distros.
> 
> Here is an overview of which ARMv4 platforms we still have as of Linux-4.6:
> 
> * Moxart: this is the only one that was recently (2013) added, and is apparently
>   hardware that remains commercially available.
> 
> * Gemini: officially supported in OpenWRT today, with the latest compiler. This one
>   will likely cause the most issues for actual users. It would be helpful to get
>   some numbers about users or downloads here, to see whether it can be dropped
>   in a future OpenWRT release or if it might be possible to leave this on
>   gcc-6.x when the other platforms move on to gcc-7+
> 
> * sa1100: A lot of people have these, but I'm guessing this is mostly interesting
>   for hobbyists that are able to keep using older gcc versions.
> 
> * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
>   the past but only remain in small quantities as far as I know. Russell still
>   uses them. He also uses older compilers, so probably isn't affected
>   immediately.

There are also quite a few ARM920T (ARMv4) based SoCs: EP93xx, Atmel 
AT91RM9200, Samsung S3C24xx, Freescale i.MX1.

baruch

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

ARMv4 (not v4t) marked obsolete in gcc-6

[Robin Murphy]

Hi Baruch,

On 10/03/16 09:40, Baruch Siach wrote:
> Hi Arnd,
>
> On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
>> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
>> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
>> we currenly support in the Linux kernel.
>>
>> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
>> and it will be removed in the following release (gcc-7) one year later, unless someone
>> raises concerns over it.
>>
>> We will of course be able to compile kernels for a long time using older compilers, but
>> this tends to get harder over the years as people upgrade to newer distros.
>>
>> Here is an overview of which ARMv4 platforms we still have as of Linux-4.6:
>>
>> * Moxart: this is the only one that was recently (2013) added, and is apparently
>>    hardware that remains commercially available.
>>
>> * Gemini: officially supported in OpenWRT today, with the latest compiler. This one
>>    will likely cause the most issues for actual users. It would be helpful to get
>>    some numbers about users or downloads here, to see whether it can be dropped
>>    in a future OpenWRT release or if it might be possible to leave this on
>>    gcc-6.x when the other platforms move on to gcc-7+
>>
>> * sa1100: A lot of people have these, but I'm guessing this is mostly interesting
>>    for hobbyists that are able to keep using older gcc versions.
>>
>> * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
>>    the past but only remain in small quantities as far as I know. Russell still
>>    uses them. He also uses older compilers, so probably isn't affected
>>    immediately.
>
> There are also quite a few ARM920T (ARMv4) based SoCs: EP93xx, Atmel
> AT91RM9200, Samsung S3C24xx, Freescale i.MX1.

ARM920T is, as the "T" suggests, v4t, not v4, hence unaffected. It's 
only pre-Thumb architectures that GCC wants to drop.

Robin.

>
> baruch
>

ARMv4 (not v4t) marked obsolete in gcc-6

[Dave Martin]

On Thu, Mar 10, 2016 at 10:13:04AM +0100, Arnd Bergmann wrote:
> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
> we currenly support in the Linux kernel.
> 
> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
> and it will be removed in the following release (gcc-7) one year later, unless someone
> raises concerns over it.
> 
> We will of course be able to compile kernels for a long time using older compilers, but
> this tends to get harder over the years as people upgrade to newer distros.
> 
> Here is an overview of which ARMv4 platforms we still have as of Linux-4.6:
> 
> * Moxart: this is the only one that was recently (2013) added, and is apparently
>   hardware that remains commercially available.
> 
> * Gemini: officially supported in OpenWRT today, with the latest compiler. This one
>   will likely cause the most issues for actual users. It would be helpful to get
>   some numbers about users or downloads here, to see whether it can be dropped
>   in a future OpenWRT release or if it might be possible to leave this on
>   gcc-6.x when the other platforms move on to gcc-7+
> 
> * sa1100: A lot of people have these, but I'm guessing this is mostly interesting
>   for hobbyists that are able to keep using older gcc versions.
> 
> * RiscPC, Footbridge, EBSA110: Classic systems that used to be popular in
>   the past but only remain in small quantities as far as I know. Russell still
>   uses them. He also uses older compilers, so probably isn't affected
>   immediately.
> 
> 	Arnd

_If_ gcc -march=armv4t -marm will still be generating R_ARM_V4BX relocs
and --fix-v4bx is being retained in the linker, then I think compiling
for v4 plain should still be possible, even if ARM/Thumb interworking
is mandatory, IIUC.

I don't know what gcc's plans are relating to that, though.

---Dave

ARMv4 (not v4t) marked obsolete in gcc-6

[Hans Ulli Kroll]

Hi
> 
> * Gemini: officially supported in OpenWRT today, with the latest compiler. This one
>   will likely cause the most issues for actual users. It would be helpful to get
>   some numbers about users or downloads here, to see whether it can be dropped
>   in a future OpenWRT release or if it might be possible to leave this on
>   gcc-6.x when the other platforms move on to gcc-7+

I don't have any numbers from the OPenWRT people.
For the NAS BOXes itself, I get one/two support questions a month on the 
german based forum.
I think most people know about the SATA bug, which makes the platform 
unreliable for some SATA drives.
y
Hans Ulli

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[John Crispin]

On 11/03/2016 06:44, Hans Ulli Kroll wrote:
> Hi
>>
>> * Gemini: officially supported in OpenWRT today, with the latest compiler. This one
>>   will likely cause the most issues for actual users. It would be helpful to get
>>   some numbers about users or downloads here, to see whether it can be dropped
>>   in a future OpenWRT release or if it might be possible to leave this on
>>   gcc-6.x when the other platforms move on to gcc-7+
> 
> I don't have any numbers from the OPenWRT people.
> For the NAS BOXes itself, I get one/two support questions a month on the 
> german based forum.
> I think most people know about the SATA bug, which makes the platform 
> unreliable for some SATA drives.
> y
> Hans Ulli

Hi,

We have several active users. Roman has done a great job to constantly
maintain and update the target. We have been including gemini in our
releases for years thanks to Romans effort. It would be a shame to to
see support being dropped, even if there are few yet active users.

	John

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[Roman Yeryomin]

On 2016-03-11 08:48, John Crispin wrote:
> On 11/03/2016 06:44, Hans Ulli Kroll wrote:
>> Hi
>>> 
>>> * Gemini: officially supported in OpenWRT today, with the latest 
>>> compiler. This one
>>>   will likely cause the most issues for actual users. It would be 
>>> helpful to get
>>>   some numbers about users or downloads here, to see whether it can 
>>> be dropped
>>>   in a future OpenWRT release or if it might be possible to leave 
>>> this on
>>>   gcc-6.x when the other platforms move on to gcc-7+
>> 
>> I don't have any numbers from the OPenWRT people.
>> For the NAS BOXes itself, I get one/two support questions a month on 
>> the
>> german based forum.
>> I think most people know about the SATA bug, which makes the platform
>> unreliable for some SATA drives.
>> y
>> Hans Ulli
> 
> Hi,
> 
> We have several active users. Roman has done a great job to constantly
> maintain and update the target. We have been including gemini in our
> releases for years thanks to Romans effort. It would be a shame to to
> see support being dropped, even if there are few yet active users.
> 

Thanks, John.
I'm actively using it as a backup box and know at least several other 
people. Although it's quite old I can't stop using it, it serves well 
for me and I don't see any reason to throw it out.
I've heard of SATA problems but never seen them myself.
As to the numbers I think that people like me (or others trying out 
OpenWrt) usually don't go to the forums, so number of questions there 
doesn't tell much (but even there latest messages are from last month, 
so not dead at all). Maybe number of downloads from 
downloads.openwrt.org can tell more but I would guess that actual users 
would rather compile it themselves.

So I vote for not killing it at least until it's supported by kernel.

Actually that reminds me to upgrade to 4.4 and do proper sysupgrade 
support.


Regards,
Roman

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[Hans Ulli Kroll]

HI

On Fri, 11 Mar 2016, Roman Yeryomin wrote:

> On 2016-03-11 08:48, John Crispin wrote:
> > On 11/03/2016 06:44, Hans Ulli Kroll wrote:
> > > Hi
> > > > 
> > > > * Gemini: officially supported in OpenWRT today, with the latest
> > > > compiler. This one
> > > >   will likely cause the most issues for actual users. It would be
> > > > helpful to get
> > > >   some numbers about users or downloads here, to see whether it can be
> > > > dropped
> > > >   in a future OpenWRT release or if it might be possible to leave this
> > > > on
> > > >   gcc-6.x when the other platforms move on to gcc-7+
> > > 
> > > I don't have any numbers from the OPenWRT people.
> > > For the NAS BOXes itself, I get one/two support questions a month on the
> > > german based forum.
> > > I think most people know about the SATA bug, which makes the platform
> > > unreliable for some SATA drives.
> > > y
> > > Hans Ulli
> > 
> > Hi,
> > 
> > We have several active users. Roman has done a great job to constantly
> > maintain and update the target. We have been including gemini in our
> > releases for years thanks to Romans effort. It would be a shame to to
> > see support being dropped, even if there are few yet active users.
> >
> 
> Thanks, John.
> I'm actively using it as a backup box and know at least several other people.
> Although it's quite old I can't stop using it, it serves well for me and I
> don't see any reason to throw it out.
> I've heard of SATA problems but never seen them myself.

The SATA bug occurs first on Samsung devices. 
I bought a HDD to test this by my self and check if it's possible to fix. 
There are some 'hidden' registers to tweak to PATA controller, the 
names can be found in the PATA header from the original sources.
No avail !
So I asked Paulius sometime ago about this and the PATA/SATA mux, he has 
also no clue for fixing this.

> As to the numbers I think that people like me (or others trying out OpenWrt)
> usually don't go to the forums, so number of questions there doesn't tell much
> (but even there latest messages are from last month, so not dead at all).
> Maybe number of downloads from downloads.openwrt.org can tell more but I would
> guess that actual users would rather compile it themselves.

The support thread on the german board is very long, so most of the 
questions are answered there. The experienced don't need this, so the 
numbers *are* wrong.

And I'm using two of the NAS boxes for backup and another for kernel work

> So I vote for not killing it at least until it's supported by kernel.
> 

ACK !!

Hans Ulli

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Friday 11 March 2016 17:56:12 Hans Ulli Kroll wrote:
> On Fri, 11 Mar 2016, Roman Yeryomin wrote:
> > On 2016-03-11 08:48, John Crispin wrote:
> > > On 11/03/2016 06:44, Hans Ulli Kroll wrote:

> > As to the numbers I think that people like me (or others trying out OpenWrt)
> > usually don't go to the forums, so number of questions there doesn't tell much
> > (but even there latest messages are from last month, so not dead at all).
> > Maybe number of downloads from downloads.openwrt.org can tell more but I would
> > guess that actual users would rather compile it themselves.
> 
> The support thread on the german board is very long, so most of the 
> questions are answered there. The experienced don't need this, so the 
> numbers *are* wrong.
> 
> And I'm using two of the NAS boxes for backup and another for kernel work
> 
> > So I vote for not killing it at least until it's supported by kernel.
> > 
> 
> ACK !!

Thanks everyone for the input. So if OpenWRT wants to keep the support
for the Gemini platform, I see two ways forward:

- have a separate toolchain for target/linux/gemini when the other
  platforms upgrade to gcc-7. That means no action needed for now,
  but possibly more work to keep it going in the long run

- make the upstream kernel work with compilers that lack -march=armv4
  support.

I think we want the second one if at all possible, as it also addresses
most of the other affected platforms (not rpc, which requires -march=armv3).

The patch below might be enough, passing -march=armv4t whenever -march=armv4
is not supported, and passing --fix-v4bx whenever we build for ARMv4:

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 9fb3fee0e908..3c312d37a83a 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -19,6 +19,11 @@ LDFLAGS_vmlinux	+= --be8
 LDFLAGS_MODULE	+= --be8
 endif
 
+ifeq ($(CONFIG_CPU_32v4),y)
+LDFLAGS_vmlinux	+= $(call ld-option,--fix-v4bx)
+LDFLAGS_MODULE	+= $(call ld-option,--fix-v4bx)
+endif
+
 ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
 LDFLAGS_MODULE	+= -T $(srctree)/arch/arm/kernel/module.lds
 endif
@@ -75,7 +80,7 @@ arch-$(CONFIG_CPU_32v6K)	=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
 endif
 arch-$(CONFIG_CPU_32v5)		=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
 arch-$(CONFIG_CPU_32v4T)	=-D__LINUX_ARM_ARCH__=4 -march=armv4t
-arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 -march=armv4
+arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
 arch-$(CONFIG_CPU_32v3)		=-D__LINUX_ARM_ARCH__=3 -march=armv3
 
 # Evaluate arch cc-option calls now
@@ -93,8 +98,8 @@ tune-$(CONFIG_CPU_ARM922T)	=-mtune=arm9tdmi
 tune-$(CONFIG_CPU_ARM925T)	=-mtune=arm9tdmi
 tune-$(CONFIG_CPU_ARM926T)	=-mtune=arm9tdmi
 tune-$(CONFIG_CPU_FA526)	=-mtune=arm9tdmi
-tune-$(CONFIG_CPU_SA110)	=-mtune=strongarm110
-tune-$(CONFIG_CPU_SA1100)	=-mtune=strongarm1100
+tune-$(CONFIG_CPU_SA110)	=$(call cc-option,-mtune=strongarm110)
+tune-$(CONFIG_CPU_SA1100)	=$(call cc-option,-mtune=strongarm1100)
 tune-$(CONFIG_CPU_XSCALE)	=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
 tune-$(CONFIG_CPU_XSC3)		=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
 tune-$(CONFIG_CPU_FEROCEON)	=$(call cc-option,-mtune=marvell-f,-mtune=xscale)

Does this look reasonable?

	Arnd

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[John Crispin]

On 15/03/2016 16:59, Arnd Bergmann wrote:
> On Friday 11 March 2016 17:56:12 Hans Ulli Kroll wrote:
>> On Fri, 11 Mar 2016, Roman Yeryomin wrote:
>>> On 2016-03-11 08:48, John Crispin wrote:
>>>> On 11/03/2016 06:44, Hans Ulli Kroll wrote:
> 
>>> As to the numbers I think that people like me (or others trying out OpenWrt)
>>> usually don't go to the forums, so number of questions there doesn't tell much
>>> (but even there latest messages are from last month, so not dead at all).
>>> Maybe number of downloads from downloads.openwrt.org can tell more but I would
>>> guess that actual users would rather compile it themselves.
>>
>> The support thread on the german board is very long, so most of the 
>> questions are answered there. The experienced don't need this, so the 
>> numbers *are* wrong.
>>
>> And I'm using two of the NAS boxes for backup and another for kernel work
>>
>>> So I vote for not killing it at least until it's supported by kernel.
>>>
>>
>> ACK !!
> 
> Thanks everyone for the input. So if OpenWRT wants to keep the support
> for the Gemini platform, I see two ways forward:
> 
> - have a separate toolchain for target/linux/gemini when the other
>   platforms upgrade to gcc-7. That means no action needed for now,
>   but possibly more work to keep it going in the long run
> 
> - make the upstream kernel work with compilers that lack -march=armv4
>   support.
> 
> I think we want the second one if at all possible, as it also addresses
> most of the other affected platforms (not rpc, which requires -march=armv3).
> 

yes please option 2 would be favorable as we try to keep the amount of
toolchains to a minimum.
	
	John

> The patch below might be enough, passing -march=armv4t whenever -march=armv4
> is not supported, and passing --fix-v4bx whenever we build for ARMv4:
> 
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 9fb3fee0e908..3c312d37a83a 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -19,6 +19,11 @@ LDFLAGS_vmlinux	+= --be8
>  LDFLAGS_MODULE	+= --be8
>  endif
>  
> +ifeq ($(CONFIG_CPU_32v4),y)
> +LDFLAGS_vmlinux	+= $(call ld-option,--fix-v4bx)
> +LDFLAGS_MODULE	+= $(call ld-option,--fix-v4bx)
> +endif
> +
>  ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
>  LDFLAGS_MODULE	+= -T $(srctree)/arch/arm/kernel/module.lds
>  endif
> @@ -75,7 +80,7 @@ arch-$(CONFIG_CPU_32v6K)	=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
>  endif
>  arch-$(CONFIG_CPU_32v5)		=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
>  arch-$(CONFIG_CPU_32v4T)	=-D__LINUX_ARM_ARCH__=4 -march=armv4t
> -arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 -march=armv4
> +arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
>  arch-$(CONFIG_CPU_32v3)		=-D__LINUX_ARM_ARCH__=3 -march=armv3
>  
>  # Evaluate arch cc-option calls now
> @@ -93,8 +98,8 @@ tune-$(CONFIG_CPU_ARM922T)	=-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_ARM925T)	=-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_ARM926T)	=-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_FA526)	=-mtune=arm9tdmi
> -tune-$(CONFIG_CPU_SA110)	=-mtune=strongarm110
> -tune-$(CONFIG_CPU_SA1100)	=-mtune=strongarm1100
> +tune-$(CONFIG_CPU_SA110)	=$(call cc-option,-mtune=strongarm110)
> +tune-$(CONFIG_CPU_SA1100)	=$(call cc-option,-mtune=strongarm1100)
>  tune-$(CONFIG_CPU_XSCALE)	=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>  tune-$(CONFIG_CPU_XSC3)		=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>  tune-$(CONFIG_CPU_FEROCEON)	=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> 
> Does this look reasonable?
> 
> 	Arnd
> 

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[Ard Biesheuvel]

On 15 March 2016 at 16:59, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 11 March 2016 17:56:12 Hans Ulli Kroll wrote:
>> On Fri, 11 Mar 2016, Roman Yeryomin wrote:
>> > On 2016-03-11 08:48, John Crispin wrote:
>> > > On 11/03/2016 06:44, Hans Ulli Kroll wrote:
>
>> > As to the numbers I think that people like me (or others trying out OpenWrt)
>> > usually don't go to the forums, so number of questions there doesn't tell much
>> > (but even there latest messages are from last month, so not dead at all).
>> > Maybe number of downloads from downloads.openwrt.org can tell more but I would
>> > guess that actual users would rather compile it themselves.
>>
>> The support thread on the german board is very long, so most of the
>> questions are answered there. The experienced don't need this, so the
>> numbers *are* wrong.
>>
>> And I'm using two of the NAS boxes for backup and another for kernel work
>>
>> > So I vote for not killing it at least until it's supported by kernel.
>> >
>>
>> ACK !!
>
> Thanks everyone for the input. So if OpenWRT wants to keep the support
> for the Gemini platform, I see two ways forward:
>
> - have a separate toolchain for target/linux/gemini when the other
>   platforms upgrade to gcc-7. That means no action needed for now,
>   but possibly more work to keep it going in the long run
>
> - make the upstream kernel work with compilers that lack -march=armv4
>   support.
>
> I think we want the second one if at all possible, as it also addresses
> most of the other affected platforms (not rpc, which requires -march=armv3).
>
> The patch below might be enough, passing -march=armv4t whenever -march=armv4
> is not supported, and passing --fix-v4bx whenever we build for ARMv4:
>
> diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> index 9fb3fee0e908..3c312d37a83a 100644
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@ -19,6 +19,11 @@ LDFLAGS_vmlinux      += --be8
>  LDFLAGS_MODULE += --be8
>  endif
>
> +ifeq ($(CONFIG_CPU_32v4),y)
> +LDFLAGS_vmlinux        += $(call ld-option,--fix-v4bx)
> +LDFLAGS_MODULE += $(call ld-option,--fix-v4bx)

Does this have any effect on partial linking? I would expect the
module loader to handle the R_ARM_V4BX relocation in this case

> +endif
> +
>  ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
>  LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
>  endif
> @@ -75,7 +80,7 @@ arch-$(CONFIG_CPU_32v6K)      =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
>  endif
>  arch-$(CONFIG_CPU_32v5)                =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
>  arch-$(CONFIG_CPU_32v4T)       =-D__LINUX_ARM_ARCH__=4 -march=armv4t
> -arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 -march=armv4
> +arch-$(CONFIG_CPU_32v4)                =-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
>  arch-$(CONFIG_CPU_32v3)                =-D__LINUX_ARM_ARCH__=3 -march=armv3
>
>  # Evaluate arch cc-option calls now
> @@ -93,8 +98,8 @@ tune-$(CONFIG_CPU_ARM922T)    =-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_ARM925T)     =-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_ARM926T)     =-mtune=arm9tdmi
>  tune-$(CONFIG_CPU_FA526)       =-mtune=arm9tdmi
> -tune-$(CONFIG_CPU_SA110)       =-mtune=strongarm110
> -tune-$(CONFIG_CPU_SA1100)      =-mtune=strongarm1100
> +tune-$(CONFIG_CPU_SA110)       =$(call cc-option,-mtune=strongarm110)
> +tune-$(CONFIG_CPU_SA1100)      =$(call cc-option,-mtune=strongarm1100)
>  tune-$(CONFIG_CPU_XSCALE)      =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>  tune-$(CONFIG_CPU_XSC3)                =$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
>  tune-$(CONFIG_CPU_FEROCEON)    =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
>
> Does this look reasonable?
>
>         Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[OpenWrt-Devel] ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Tuesday 15 March 2016 21:26:08 Ard Biesheuvel wrote:
> On 15 March 2016 at 16:59, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 11 March 2016 17:56:12 Hans Ulli Kroll wrote:
> >> On Fri, 11 Mar 2016, Roman Yeryomin wrote:
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 9fb3fee0e908..3c312d37a83a 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -19,6 +19,11 @@ LDFLAGS_vmlinux      += --be8
> >  LDFLAGS_MODULE += --be8
> >  endif
> >
> > +ifeq ($(CONFIG_CPU_32v4),y)
> > +LDFLAGS_vmlinux        += $(call ld-option,--fix-v4bx)
> > +LDFLAGS_MODULE += $(call ld-option,--fix-v4bx)
> 
> Does this have any effect on partial linking? I would expect the
> module loader to handle the R_ARM_V4BX relocation in this case

I have checked that the recursive linking stages don't need it for
the built-in files, only the final link step for vmlinux does.

For loadable modules, the loader indeed applies the same fix,
and apparently also does this on ARMv4T and ARMv5 machines even
when it's not needed there. I think for consistency it makes
sense to set the flag for both vmlinux and modules (as we
do for --be8).

	Arnd

ARMv4 (not v4t) marked obsolete in gcc-6

[Ramana Radhakrishnan]

On 10/03/16 09:13, Arnd Bergmann wrote:
> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
> we currenly support in the Linux kernel.
> 
> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
> and it will be removed in the following release (gcc-7) one year later, unless someone
> raises concerns over it.

Support for armv4 has been deprecated but not yet obsoleted. We'd like to remove support for it in a future release of the compiler which could be as early as GCC 7 depending on the feedback we receive over the coming weeks / months. Removing support for armv4 will allow us to assume interworking by default which helps in cleaning up and simplifying the ARM backend. Further no one is really testing support for anything earlier than v4t really in the GCC community. While we would like to be cautious about removing support for armv4 from the tools, we think 2016 is a good time to start asking questions around removing support for this in the backend of the compiler.

Folks building the kernel / applications that require armv4 support can continue using the linker option --fix-v4bx which should take care of the fixups. Ideally we would have liked to have removed support for v4 in binutils as well at some point of time in the future, but it appears as though there is a significant community of users who would like to build kernels / other apps for v4 based systems - thus I suspect that support will live for quite a while as it also keeps old assembler code going but ends up simplifying the compiler code base.

In terms of registering opinions on keeping support for armv4 going, we'd prefer folks to discuss these with posts onto gcc at gcc.gnu.org describing their reasons for the same. There is a maintenance cost on keeping support for this going as there is a quite a bit of special casing for interworking vs non-interworking targets that we would like to clean up in the future once support goes out. At this point of time I haven't seen any good reasons to keep support going for armv4 in the *compiler*, since the linker option is available.


Thanks,
Ramana

ARMv4 (not v4t) marked obsolete in gcc-6

[Dmitry Eremin-Solenikov]

2016-03-17 19:18 GMT+03:00 Ramana Radhakrishnan
<ramana.radhakrishnan@foss.arm.com>:
>
>
>
> On 10/03/16 09:13, Arnd Bergmann wrote:
>> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
>> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
>> we currenly support in the Linux kernel.
>>
>> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
>> and it will be removed in the following release (gcc-7) one year later, unless someone
>> raises concerns over it.
>
> Support for armv4 has been deprecated but not yet obsoleted. We'd like to remove support for it in a future release of the compiler which could be as early as GCC 7 depending on the feedback we receive over the coming weeks / months. Removing support for armv4 will allow us to assume interworking by default which helps in cleaning up and simplifying the ARM backend. Further no one is really testing support for anything earlier than v4t really in the GCC community. While we would like to be cautious about removing support for armv4 from the tools, we think 2016 is a good time to start asking questions around removing support for this in the backend of the compiler.
>
> Folks building the kernel / applications that require armv4 support can continue using the linker option --fix-v4bx which should take care of the fixups. Ideally we would have liked to have removed support for v4 in binutils as well at some point of time in the future, but it appears as though there is a significant community of users who would like to build kernels / other apps for v4 based systems - thus I suspect that support will live for quite a while as it also keeps old assembler code going but ends up simplifying the compiler code base.
>
> In terms of registering opinions on keeping support for armv4 going, we'd prefer folks to discuss these with posts onto gcc at gcc.gnu.org describing their reasons for the same. There is a maintenance cost on keeping support for this going as there is a quite a bit of special casing for interworking vs non-interworking targets that we would like to clean up in the future once support goes out. At this point of time I haven't seen any good reasons to keep support going for armv4 in the *compiler*, since the linker option is available.

Removing armv4 support means also removing -mtune support for those
chips (I'm especially concerned about strongarm1100).
Would it be possible to remove armv4 support, but leave performance
settings/tunings intact?

Regarding testing. We have a small community doing system builds for
SA1100/SA1110 chips,
if that matters.


-- 
With best wishes
Dmitry

ARMv4 (not v4t) marked obsolete in gcc-6

[Ramana Radhakrishnan]

On 17/03/16 19:34, Dmitry Eremin-Solenikov wrote:
> 2016-03-17 19:18 GMT+03:00 Ramana Radhakrishnan
> <ramana.radhakrishnan@foss.arm.com>:
>>
>>
>>
>> On 10/03/16 09:13, Arnd Bergmann wrote:
>>> I've found out that ARMv3 and ARMv4 is now on track to get removed from gcc in the future,
>>> so I'm trying to alert everyone that I have knowledge of using ARMv4 based platforms that
>>> we currenly support in the Linux kernel.
>>>
>>> The architecture has been declared obsolete here: https://gcc.gnu.org/gcc-6/changes.html
>>> and it will be removed in the following release (gcc-7) one year later, unless someone
>>> raises concerns over it.
>>
>> Support for armv4 has been deprecated but not yet obsoleted. We'd like to remove support for it in a future release of the compiler which could be as early as GCC 7 depending on the feedback we receive over the coming weeks / months. Removing support for armv4 will allow us to assume interworking by default which helps in cleaning up and simplifying the ARM backend. Further no one is really testing support for anything earlier than v4t really in the GCC community. While we would like to be cautious about removing support for armv4 from the tools, we think 2016 is a good time to start asking questions around removing support for this in the backend of the compiler.
>>
>> Folks building the kernel / applications that require armv4 support can continue using the linker option --fix-v4bx which should take care of the fixups. Ideally we would have liked to have removed support for v4 in binutils as well at some point of time in the future, but it appears as though there is a significant community of users who would like to build kernels / other apps for v4 based systems - thus I suspect that support will live for quite a while as it also keeps old assembler code going but ends up simplifying the compiler code base.
>>
>> In terms of registering opinions on keeping support for armv4 going, we'd prefer folks to discuss these with posts onto gcc at gcc.gnu.org describing their reasons for the same. There is a maintenance cost on keeping support for this going as there is a quite a bit of special casing for interworking vs non-interworking targets that we would like to clean up in the future once support goes out. At this point of time I haven't seen any good reasons to keep support going for armv4 in the *compiler*, since the linker option is available.
> 
> Removing armv4 support means also removing -mtune support for those
> chips (I'm especially concerned about strongarm1100).
> Would it be possible to remove armv4 support, but leave performance
> settings/tunings intact?

I'm not sure how ugly the end result will be if we went down the route, the simplest egregious hack would be to treat strongarm as v4t but then relying on the linker to fix things up. However ...

Are you able to compare performance by tuning for arm9 on strongarm as I see that is the closest in terms of tuning to strongarm ? The only differences are in the number of instructions to conditionalize 3 for sa vs 5 for arm9 and the latency of multiplies being 3 rather than 4 in the legacy scheduler.

> 
> Regarding testing. We have a small community doing system builds for
> SA1100/SA1110 chips,
> if that matters.

Good to know. Thanks for the feedback. 

regards
Ramana

> 
> 

ARMv4 (not v4t) marked obsolete in gcc-6

[Arnd Bergmann]

On Friday 18 March 2016 13:25:43 Ramana Radhakrishnan wrote:
> > 
> > Removing armv4 support means also removing -mtune support for those
> > chips (I'm especially concerned about strongarm1100).
> > Would it be possible to remove armv4 support, but leave performance
> > settings/tunings intact?
> 
> I'm not sure how ugly the end result will be if we went down the route, the simplest egregious hack would be to treat strongarm as v4t but then relying on the linker to fix things up. However ...

At that point, you could simply define armv4 to be synonymous with armv4t
and leave the bx fixup up to the user.
 
> Are you able to compare performance by tuning for arm9 on strongarm as I see that is the closest in terms of tuning to strongarm ? The only differences are in the number of instructions to conditionalize 3 for sa vs 5 for arm9 and the latency of multiplies being 3 rather than 4 in the legacy scheduler.

It also depends on whether Dmitry wants to build just the kernel with
gcc >= 7.0 or also user space. The kernel has very little code that really
benefits from optimizing for a specific core, and we don't really try to
pick the best tuning options: For ARMv7 we just use the default of the
compiler even when we know which core we have, and for both fa526
and arm926ejs, we explicitly set -mtune=arm9tdmi, even though both
have their own pipeline descriptions in gcc.

I couldn't find out from the gcc source, but is there any noticeable
difference between building with -mtune=arm9tdmi and mtune=arm926ejs?

Also, for a combined armv6/v7 kernel that might run on any Cortex-A
(including the 64-bit ones) as well as ARM11, Krait, Scorpion and PJ4,
is there an option that works better overall than -mtune=arm1136?
We currently use that whenever some ARMv6 target is enabled, and
I don't think anyone has even touched those options in the last 10
years.

	Arnd