Re: Anyone using stretch/buster/sid on ARMv4t ?

[gregor herrmann]

On Tue, 07 Nov 2017 20:44:08 +0200, Adrian Bunk wrote:

> > > for the armel port in buster the question of raising the baseline came up.
> > That has been a recurring question over the time, the reason to
> > maintain ARMv4t instruction set was OpenMoko mobile phone, which lot
> > of people was using back in the days.
> A prerequisite for using buster would be a non-ancient kernel,
> which rules out most hardware including OpenMoko.

Even stretch's libc6 is too new for the "newest" OpenMoko kernel I'm
aware of. De facto Debian on the OpenMoko seems to be dead already,
unless I'm missing something. (And I'd love to hear the opposite.)
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: JBO: Symphonie der Verstopfung


signature.asc
Description: Digital Signature

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Adrian Bunk]

On Tue, Nov 07, 2017 at 07:45:35PM +, Wookey wrote:
>...
> I'm very happy if people mark problematic packages that no longer
> build for armv5 as 'notforus' if no-one steps up to fix them in a
> timely fashion, but killing the architecture because some upstreams
> no-longer care about v5 seems like a baby/bathwater scenario.
> 
> It would be nice if we had some way to either relax the migration
> rules so old somewhat-maintained architectures like this didn't get in
> the way of others,
>...

This whole "so many packages are broken on armel" narrative
is actually mostly FUD, and you are suggesting mitigations
for a nonexisting problem.

The only major package where armel is the only release architecture 
where it can no longer be built is Node.js, and not having the Node.js 
ecosysyem on armel has already been sorted out for stretch.

Every time the topic of armel-specific major problems comes up people 
are either not nameing any specific problems, or they mention problems 
that were fixed long ago.

> Wookey

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Wookey]

On 2017-11-07 11:48 +0100, W. Martin Borgert wrote:
> On 2017-11-07 11:08, Julien Cristau wrote:
> > Keeping armel on life support for 2 more
> > years is a significant drain on DSA and our hosters, for questionable
> > benefit.
> 
> I agree, that this support comes not for free, but the benefit
> is not questionable to me: There is still relevant hardware
> around which can run "armel", but not "armhf". *If* there are
> enough developers and build machines, there is no reason to drop
> the architecture prematurely. I can't see any relevance for
> ARMv4t anymore, however.

Agreed. I too have armv5 hardware in daily use runing Debian (it's my
house controller (solar, heating, MVHR)). For reasons of hardware
additions, (but also because it works just fine), I have no desire to
change it before it dies. For this use-case a proper 'stable' distro
is very attractive, so being relegated to 'unstable only' in ports is
less than ideal.

I'm very happy if people mark problematic packages that no longer
build for armv5 as 'notforus' if no-one steps up to fix them in a
timely fashion, but killing the architecture because some upstreams
no-longer care about v5 seems like a baby/bathwater scenario.

It would be nice if we had some way to either relax the migration
rules so old somewhat-maintained architectures like this didn't get in
the way of others, or if there was some way of having 'stable' (or at
least testing) for arches relegated to ports.

Liberal use of 'notforus' would help a lot with the 'not getting in
the way' part, or a way of reverting the 'used to build on this arch
once so we're not going to ignore it' bit in the package migration
rules. If upstream has given up and said 'we don't support that any
more' then it's quite reasonable for Debian to do the same. 

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Adrian Bunk]

On Tue, Nov 07, 2017 at 11:08:39AM +0100, Julien Cristau wrote:
> 
> That's not clear to me at all.  Keeping armel on life support for 2 more
> years is a significant drain on DSA and our hosters,
>...

What kind of significant drain exactly?

AFAIK so far noone has stated that it would be safe to build stretch 
armhf security updates on arm64 hardware, so in the likely event of 
stretch LTS support for armhf DSA and hosters are already kinda 
committed to maintain some of the current (or comparable) armv7
builders in 2 different locations until mid-2022.

Non-LTS support for buster will also end in mid-2022,
so if buildds (and likely porterbox) are still required
for armhf then armel hw needs are already covered.

> Cheers,
> Julien

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Adrian Bunk]

On Tue, Nov 07, 2017 at 01:43:50PM +0100, Héctor Orón Martínez wrote:
>...
> 2017-11-05 22:32 GMT+01:00 Adrian Bunk :
> 
> > for the armel port in buster the question of raising the baseline came up.
> 
> That has been a recurring question over the time, the reason to
> maintain ARMv4t instruction set was OpenMoko mobile phone, which lot
> of people was using back in the days.

A prerequisite for using buster would be a non-ancient kernel,
which rules out most hardware including OpenMoko.

>...
> Having outlined few part of current issues, we had a proposal in dc16:
>  >>>  * Partial armel architecture?
>...
> >>> * Update from v4t to v5tel and go headless?
>...
> Note that the above can be huge amount of work and it might need
> skilled people as well as funding to become a reality.
>...

It would be a huge amount of work with zero benefits.

Status quo is a full port that is overall in a good shape,
so what would be the point in spending a huge amount of
work on castrating that port?

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Marcin Juszkiewicz]

W dniu 07.11.2017 o 14:11, Thomas Goirand pisze:
> On 11/05/2017 10:32 PM, Adrian Bunk wrote:
>> 20 years ago you could go into a shop and buy a mobile phone
>> with a CPU supported by the armel port in stretch.

> I didn't know Stretch was released 20 years ago. :)

Stretch maybe not. But ARMv4t was ;D

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Thomas Goirand]

On 11/05/2017 10:32 PM, Adrian Bunk wrote:
> 20 years ago you could go into a shop and buy a mobile phone
> with a CPU supported by the armel port in stretch.

I didn't know Stretch was released 20 years ago. :)

Cheers,

Thomas Goirand (zigo)

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Steve McIntyre]

On Tue, Nov 07, 2017 at 01:43:50PM +0100, Hector Oron wrote:
>
>Also build daemons are aging, those were initially donated by Marvell
>(some development boards) which then they replaced with other
>development boards. We have been unable to find suitable hardware to
>build armel port and current ARMv8 server class instruction set lacks
>few instructions and we have been advised to not build armel ports in
>such hardware.
>  Current build daemons got into production in 2010 --
>https://blog.einval.com/2010/09/27
>We have no current replacement for that hardware, which it's already 7
>years old and still needs to keep up running for Stretch life cycle
>(and maybe LTS).
>There might be other issues, as upstream support in few other projects, etc...

Not quite - those are the old machines that we already replaced. The
current builders for armel are Marvell Armada XP GP dev boards,
commissioned in early 2014.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Héctor Orón Martínez]

>>>[+debian-embedded, feel free to adjust CC'd mailing lists on reply]

Hello,

  Thanks for bringing up this discussion! And apologies for adding
more complexity to the initial question.
  Find few comments inlined below,

2017-11-05 22:32 GMT+01:00 Adrian Bunk :

> for the armel port in buster the question of raising the baseline came up.

That has been a recurring question over the time, the reason to
maintain ARMv4t instruction set was OpenMoko mobile phone, which lot
of people was using back in the days.
I am unsure that is still relevant. However there are industrial
products based on old ARM CPU, but they are probably good to bump to
ARMv5tel.

> Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug
> reports from users on ARMv5 hardware in stretch, so it is clear that
> ARMv5 should stay supported (and of course also ARMv6 and ARMv7).

There are important issues to keep the port going forward, and it has
been flagged as deprecated in last couple DebConf's ARM BoF meetings:
  https://gobby.debian.org/export/debconf17/bof/ARM%20ports
  https://gobby.debian.org/export/debconf16/bof/arm-ports
  https://gobby.debian.org/export/debconf15/bof/state-of-the-arm

Also build daemons are aging, those were initially donated by Marvell
(some development boards) which then they replaced with other
development boards. We have been unable to find suitable hardware to
build armel port and current ARMv8 server class instruction set lacks
few instructions and we have been advised to not build armel ports in
such hardware.
  Current build daemons got into production in 2010 --
https://blog.einval.com/2010/09/27
We have no current replacement for that hardware, which it's already 7
years old and still needs to keep up running for Stretch life cycle
(and maybe LTS).
There might be other issues, as upstream support in few other projects, etc...

(For build daemon issue discussion, please feel free to fork the
thread and discuss at debian-arm mailing list.)

Having outlined few part of current issues, we had a proposal in dc16:
 >>>  * Partial armel architecture?
No clear plan for how to create and maintain a partial
architecture, let alone releasing.
Drop desktop tasks and dependencies.
Keep web server and mail server - trivial in comparison.
Lack of video use cases.
Headless partial arch for armel?
Build daemons would be a problem, so let armhf buildds do
the builds. Can't do that on ARMv8 (which can do armhf).
Kernel helper to emulate barriers but hardware support can
be lacking on ARMv8 hardware.

>>> * Update from v4t to v5tel and go headless?
  No kernel support for exclusive v4t.
  Openmoko would be ruled out of this partial arch.
  Kirkwood and Orion can be maintained.
  openssl and other updates would be useful within stretch.
  Propose to keep in stretch and go to v5tel partial arch after stretch.
  Not clear how much work it is.
  Packages would have to specify armel or it will not build.


In other words, as I see it, there are few tasks we could work on
(with added problem of lack of resources):

A) Select a package set to provide headless support, not only for
armel, but also for powerpc and other non-existent Debian
architectures.
B) Setup cross build daemon and cross build such set of packages,
provide build logs and fixes to package maintainers.
C) Follow up on bootstrapping work and make sure we are able to sanely
bootstrap architectures from cross built packages or bootstrap it from
sources.
D) Talk to release team and other involved teams and design a way to
support (cross built) partial architectures in official Debian.

Note that the above can be huge amount of work and it might need
skilled people as well as funding to become a reality.
In a way that's my personal vision to keep aged architectures around
supported in Debian and dropping our hardware dependency, and getting
also nice features that other parties might find interesting such
cross building support and bootstrapping.

(For technical discussion on cross building, please fork the thread
and CC debian-embedded.)

Regards,
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Re: Anyone using stretch/buster/sid on ARMv4t ?

[W. Martin Borgert]

Quoting "W. Martin Borgert" :

There is still relevant hardware
around which can run "armel", but not "armhf".


Forgot to mention some, that one can still buy:

On https://www.taskit.de/stamp-overview.html the three boards
named "9261", "9G20", and "9G45". AFAIK.

Also Raspberry Pi Zero, if I'm not mistaken.

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Tixy]

On Tue, 2017-11-07 at 02:49 -0800, Rick Thomas wrote:
> How do I know if a machine is ARMv4t?  I have a sheevaplug and a
> couple of openrd machines (one “client”, the other “ultimate”) that
> are still doing useful work.  Are they v4t?

They're ARMv5 (so still need armel). I too have similar devices running
Debian and in constant use.

-- 
Tixy

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Rick Thomas]

> On Nov 7, 2017, at 3:27 AM, Christian Seiler  wrote:
> 
> Hi,
> 
> Am 2017-11-07 11:49, schrieb Rick Thomas:
>> How do I know if a machine is ARMv4t?  I have a sheevaplug and a
>> couple of openrd machines (one “client”, the other “ultimate”) that
>> are still doing useful work.  Are they v4t?
> 
> cat /proc/cpuinfo should do the trick. It might not show the 't'
> after the 4, but it should definitely show whether it's an ARMv4
> or not. (And Debian's armel doesn't support any non-'t' ARMv4
> CPUs, so if it's ARMv4 and running Debian's armel port, it's
> ARMv4t.)

Thanks!  It looks like my machines are all 5TE — or maybe v5l ??  In any case, 
not v4t.

> rbthomas@client:~$ cat /proc/cpuinfo
> processor : 0
> model name: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS  : 1191.93
> Features  : swp half thumb fastmult edsp 
> CPU implementer   : 0x56
> CPU architecture: 5TE
> CPU variant   : 0x2
> CPU part  : 0x131
> CPU revision  : 1
> 
> Hardware  : Marvell Kirkwood (Flattened Device Tree)
> Revision  : 
> Serial: 

All three show the same output.

Enjoy!
Rick

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Christian Seiler]

Hi,

Am 2017-11-07 11:49, schrieb Rick Thomas:

How do I know if a machine is ARMv4t?  I have a sheevaplug and a
couple of openrd machines (one “client”, the other “ultimate”) that
are still doing useful work.  Are they v4t?


cat /proc/cpuinfo should do the trick. It might not show the 't'
after the 4, but it should definitely show whether it's an ARMv4
or not. (And Debian's armel doesn't support any non-'t' ARMv4
CPUs, so if it's ARMv4 and running Debian's armel port, it's
ARMv4t.)

Regards,
Christian

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Rick Thomas]

How do I know if a machine is ARMv4t?  I have a sheevaplug and a couple of 
openrd machines (one “client”, the other “ultimate”) that are still doing 
useful work.  Are they v4t?

Thanks,
Rick

> On Nov 5, 2017, at 1:32 PM, Adrian Bunk  wrote:
> 
> Hi,
> 
> for the armel port in buster the question of raising the baseline came up.
> 
> 20 years ago you could go into a shop and buy a mobile phone
> with a CPU supported by the armel port in stretch.
> 
> Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug 
> reports from users on ARMv5 hardware in stretch, so it is clear that
> ARMv5 should stay supported (and of course also ARMv6 and ARMv7).
> 
> But while it was mentioned that there exists ARMv4t hardware that works 
> with current mainline kernels [1], it is not clear whether there are any 
> actual users left - and without users we might not even notice if the 
> port is broken on the baseline.
> 
> If anyone is running stretch, buster or sid on ARMv4t hardware,
> then please let us know what device and kernel you are using
> and whether you intend to use buster.
> 
> cu
> Adrian
> 
> [1] https://lists.debian.org/debian-arm/2017/08/msg00046.html
> 
> -- 
> 
>   "Is there not promise of rain?" Ling Tan asked suddenly out
>of the darkness. There had been need of rain for many days.
>   "Only a promise," Lao Er said.
>   Pearl S. Buck - Dragon Seed
> 

Re: Anyone using stretch/buster/sid on ARMv4t ?

[W. Martin Borgert]

On 2017-11-07 11:08, Julien Cristau wrote:
> Keeping armel on life support for 2 more
> years is a significant drain on DSA and our hosters, for questionable
> benefit.

I agree, that this support comes not for free, but the benefit
is not questionable to me: There is still relevant hardware
around which can run "armel", but not "armhf". *If* there are
enough developers and build machines, there is no reason to drop
the architecture prematurely. I can't see any relevance for
ARMv4t anymore, however.

Re: Anyone using stretch/buster/sid on ARMv4t ?

[John Paul Adrian Glaubitz]

On 11/07/2017 11:08 AM, Julien Cristau wrote:

That's not clear to me at all.  Keeping armel on life support for 2 more
years is a significant drain on DSA and our hosters, for questionable
benefit.


I think a possible solution is the plan we had inside Debian Ports which is
to introduce a Britney instance within Debian Ports and hence be able to
provide a Debian testing release.

My dream would be to not to have the distinction between release architectures
and ports architectures, but rather something like Tier I and Tier II
architectures with the Tier II architectures sharing the characteristics of
the Tier I architectures but without any support and without the buildds
and porterboxes being maintained by DSA.

Adrian

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

Re: Anyone using stretch/buster/sid on ARMv4t ?

[Julien Cristau]

On 11/05/2017 10:32 PM, Adrian Bunk wrote:
> Hi,
> 
> for the armel port in buster the question of raising the baseline came up.
> 
> 20 years ago you could go into a shop and buy a mobile phone
> with a CPU supported by the armel port in stretch.
> 
> Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug 
> reports from users on ARMv5 hardware in stretch, so it is clear that
> ARMv5 should stay supported (and of course also ARMv6 and ARMv7).
> 
That's not clear to me at all.  Keeping armel on life support for 2 more
years is a significant drain on DSA and our hosters, for questionable
benefit.

Cheers,
Julien