[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ARM Ports BoF: armel in buster



On 08/27/2017 07:36 PM, W. Martin Borgert wrote:
> On 2017-08-28 06:53, Paul Wise wrote:
>> On Sun, Aug 27, 2017 at 9:49 PM, Roger Shimizu wrote:
>>
>>> However, I think armel is time to transit to v5.
>> As someone who can no longer run Debian stable on his MIPS device due
>> to the CPU requirements bump in stretch, I'm not sure that bumping CPU
>> requirements is a good idea in general. If there are actual benefits
>> to v5 as the default then bumping it could be a good idea. OTOH the
>> only relevant hardware for armel these days seems to be RPi, so why
>> not make armel into armhfv6 instead?
> The most relevant hardware is probably RPi 1 and RPi Zero.
> But there are also many ARM9EJ-S based devices used in
> industrial applications (hardware with long life cycles).
> If I'm not mistaken this is v5 without FP unit, right?

Yes it is.

This conversation caught my eye as we've been leveraging Debian for years
to create a custom armel userland for an arm926ej-s core SoC.  Internal
licensing politics have us switching to an RPM based distro where the armel
situation is much worse, with ARMv5 having been abandoned after F18.
So we needed to reach quite far back for a binary distro to get ourselves
bootstrapped and even then we're building packages which AFAIK aren't
seeing significant (or any) build and soak elsewhere.  In doing so we're
conceptually taking on a self-support burden as ARMv7 is the only mainstream
arm32 ABI still supported by the project.

We probably should be leveraging a cross built embedded class distro which
would place us in that mainstream and solve many of our logistical problems.
The underlying issue in all of this being server/workstation class distros
evolving away from what was then more mainstream arm32 platforms but
now has been left to the embedded linux world.  The "long life cycles" for
this arm32 application area is quite true.  But support of that architecture
was likely never more than a coincidental goal for non-embedded
server/workstation distros.



Reply to: