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

Re: ARMEL in Buster CPU_Tag, instruction set



Hi Dick!

On 7/26/19 7:13 PM, Dick Hollenbeck wrote:
> The website says that you are supporting 4T in the ARMEL repo:
> 
> See the first sentence of this page:
> 
> 
> 	https://wiki.debian.org/ArmEabiPort

It is a wiki page, not the official Debian documentation. Unfortunately, this
page hasn't been updated yet.

> On that basis I invested a lot of time getting a kernel ready and scripts and C/C++
> development system ready, then I got body slammed after all that time when I learned that
> the minimum arm machine required for ARMEL BUSTER is 5T, not 4T.  At least this was the
> case for busybox-static and also systemd.  I could not boot into userspace.

That's unfortunate, indeed.

> $ readelf -a busybox | grep Tag_CPU
> 
> 
> This shows that this particular binary is not 4T compatible.  And I must say, this is a
> huge disappointment for me, given the time I have spent on it.  Because I am supporting
> multiple machines, 5 debian architectures in total, each with rootfs, custom kernels, and
> customer C/C++ toolkits, this was all hoping to come together on a common Debian version
> named buster.
> 
> It seems that the last support of 4T for ARMEL was Stretch.  But I cannot dovetail all
> these C/C++ toolkits using different versions of the tools.  I did this using multi-arch
> in a Docker container based on buster for all archs.
> 
> If this was an oversight, please consider rebuilding these packages using the corrected
> compiler options.  Or at least fix the website so somebody else does not lose so much time.

It was not an oversight. The bump happened because various other upstream projects
announced they would raise their minimum baselines to ARMv5T such as OpenJDK.

> In either case a policy statement seems to be needed.  Was this an oops or was it
> deliberate?  (Why deliberately make an architecture which is attempting to support old ARM
> CPUs NOT support old ARM CPUs?)

The raise to ARMv5T was necessary to keep armel supported. It wouldn't have been
possible to keep the port if had let it at ARMv4T.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


Reply to: