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.
