[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkda8xPuVHpBvX6_Ez+ztn4neVZ+=x=AEWmHJyZgww-1jHg@mail.gmail.com>
Date: Wed, 20 Dec 2017 13:48:56 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Arnd Bergmann <arnd@...db.de>,
Russell King <linux@...linux.org.uk>,
Jonas Jensen <jonas.jensen@...il.com>
Cc: Lukasz Majewski <lukma@...x.de>,
Alexander Sverdlin <alexander.sverdlin@...il.com>,
Hartley Sweeten <hsweeten@...ionengravers.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Olof Johansson <olof@...om.net>
Subject: Re: [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
On Mon, Dec 18, 2017 at 12:55 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Sun, Dec 17, 2017 at 10:28 PM, Lukasz Majewski <lukma@...x.de> wrote:
>>> On Sun, Dec 17, 2017 at 8:41 PM, Lukasz Majewski <lukma@...x.de>
>>> wrote:
>>> >> >> We also need to think about upholding support in GCC for
>>> >> >> ARMv4(t) for the foreseeable future if there is a big web of
>>> >> >> random deeply embedded systems out there that will need
>>> >> >> updates.
>>> >> >
>>> >> > But we should definitely preserve at least what we have.
>>> >>
>>> >> Plain ARMv4 (and earlier) support in gcc is already marked
>>> >> 'deprecated' and will likely be gone in gcc-8 (it's still there as
>>> >> of last week). ARMv4T is going to be around for a while, and you
>>> >> can even keep building for ARMv4 using "-march=armv4t -marm" when
>>> >> linking with 'ld --fix-v4bx'.
>>> >
>>> > I think that we shall start complaining on the gcc-devel mailing
>>> > list now.
>>> >
>>> > I would be hard to wake up in 2 years time and realise that we don't
>>> > have a modern compiler.
(...)
>>> It would also be helpful
>>> to test whether the -march=armv4t/--fix-v4bx workaround produces
>>> working binaries for you, in that case you could report to the gcc
>>> developers that the removal of armv4 can continue but that
>>> the --fix-v4bx option in ld needs to stay around.
>>
>> I may ask this issue on OE/Yocto mailing list as well....
>
> To clarify, the only affected platforms are those based on either
> DEC/Intel StrongARM or Faraday FA526, i.e. EBSA-110,
> FootBridge, RPC, SA1100, Moxart and Gemini.
It's a bit unfortunate since there are users and active contributors to
these architectures, I think the OE community is being missed out
just because they "are not Debian". :/
Even NetWinder.org is still up and kicking.
Some of it may be nostalgia and platform-hugging with regards to
SA110 and SA1100 systems, I am certainly aware of such tendencies
in myself. And I understand if GCC drops support for old systems
that only have a bunch of elderly gentlemen running it for the fun of it.
What really worries me is if there are widely deployed SA110,
SA1100, FA526 or similar embedded systems using plain ARMv4
and doing regular kernel builds and userspaces for them, in
items with 20+ years support cycles.
With reports in the media about things like nuclear powerplants running
unsupported versions of Windows NT or 95, I want to make sure
that we're not creating a similar situation somewhere for deeply
embedded Linux. Sadly these users mostly seem to come out
of the shadows after-the-fact.
My own experiments with an upgraded Gemini platform are mostly
related to the fact that home routers using this ARMv4 SoC are still
being sold and deployed, using a v2.6 kernel (contributing to the
world of botnets I suppose). The hardware-accelerated gigabit ethernet
on these routers for the home make them still fully usable despite the
ARMv4 core, but securitywise they are a nightmare.
Yours,
Linus Walleij
Powered by blists - more mailing lists