Re: Summary of the ARM ports BoF at DC15

[Paul Wise]

On Wed, Sep 16, 2015 at 9:02 PM, Christoph Biedl wrote:

> So add me to your list. I run four Seagate DockStar (v5) and two
> Raspberry Pi (v6, first generation). Although bout the latter, I was
> hoping for a "arm6hf" port and used armel until then. But with more
> recent Pi models AFAIK being armhf compliant, this will not happen
> anymore. Combined with the really poor performance I should rather
> wait for the right moment to brush them under some carpet.

For hard-float with ARMv6 CPUs, you want the Raspbian Debian derivative:

https://wiki.debian.org/RaspberryPi
http://www.raspbian.org/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Summary of the ARM ports BoF at DC15

[Christoph Biedl]

Steve McIntyre wrote...

> First released with Lenny, supports ARMv4t & later. QNAS etc. kirkwood
> & some freedombox. Toolchain and kernel support upstream are probably
> never going away due to the massive number of simple ARM devices still
> being made and shipped, however...

Quite recently I saw an ARMv4 (without thumb, long-gone arm
architecture) hardware on sale. Probably too small for Debian, but
bigger boxes were sold until 2009-ish, and fell out of support rather
soon.

What I'm trying to say: Please keep old arches as long as reasonably
possible. There's still a surprising amount of people who use it. So
in my opinion it is *way* too early to consider ending armel support.
(But this is not a plea to restore arm, with oabi support dropped in
gcc it's really dead now. Although it still shows up on popcon.)

> Should we keep it for Stretch? Maybe with subarchitecture support,
> when available. We still have some users, but not *many*. tbm would
> miss it and is still supporting quite a lot of users. Could we get the
> people who care about armel to do a minimally-supported LTS for
> Jessie/Stretch? Typical users are now on NAS boxes or some
> Freedomboxes, just using server software - no X, no graphics etc.
> Should be possible?

It's sound to assume virtually nobody runs big packages like iceweasel
or libreoffice on armel boxes. My problem with a subset is rather why
you would want to do this at all. Is there any reason beside buildd
utilization? Since the whole idea raises a lot of questions: Where to
draw the line, and how to assert no breakage is introduced in build
dependencies.

As an example, if the armel box is a router, the admin might want to
install mtr-tiny to debug some kind of network problems. The mtr
source package also builds a GUI version "mtr", so either you'd still
have to support libgtk2.0-dev, and subsequently the X core - or you'd
have to split the build scripts for different use cases. Something
similar had been done before for stage builds, which is quite a pain
to understand and to maintain.

Long story short: You might drop a few leaf packages but anything
beyond this creates a lot of continuous work I doubt many people are
willing to do.

> Summary: if people care about armel for Stretch, they should make
> noise NOW and convince people it's needed and can/should be supported
> in future.

So add me to your list. I run four Seagate DockStar (v5) and two
Raspberry Pi (v6, first generation). Although bout the latter, I was
hoping for a "arm6hf" port and used armel until then. But with more
recent Pi models AFAIK being armhf compliant, this will not happen
anymore. Combined with the really poor performance I should rather
wait for the right moment to brush them under some carpet.

Also, flash size for the kernel image is not a problem: These boxes
boot from external mmc or usb.

Christoph

Re: Summary of the ARM ports BoF at DC15

[Lucy Wayland]

On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote:
> On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
> Does this issue go away entirely if we move from a v4t to v5 base, or
> are there also v5 instructions which are (potentially) absent in v8? (I
> think so, but I don't have my references to hand).

SWP and SWPB - these were deprecated in ARMv7 but absent in ARMv8.

Lucy

Re: Summary of the ARM ports BoF at DC15

[Wookey]

+++ Paul Wise [2015-09-14 15:31 +0200]:
> On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote:
> > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote:
> >> On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
> >> Does this issue go away entirely if we move from a v4t to v5 base, or
> >> are there also v5 instructions which are (potentially) absent in v8? (I
> >> think so, but I don't have my references to hand).
> >
> > SWP and SWPB - these were deprecated in ARMv7 but absent in ARMv8.
> 
> Should we have a lintian or other archive-wide scan for these
> instructions in the arm64 arch?

It would certainly be useful QA. As would scans for v7-only instructions
in armel, and proabably a range of similar checks on other arches.

There would be false positives from code that maintains multiple code paths.

Does a code-scanner for such things exist? IIRC ubuntu did some of
this for their armv5->armv5 transition.

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

Re: Summary of the ARM ports BoF at DC15

[Ian Campbell]

On Mon, 2015-09-14 at 15:31 +0200, Paul Wise wrote:
> On Mon, Sep 14, 2015 at 2:29 PM, Lucy Wayland wrote:
> > On Sat, Sep 12, 2015 at 03:55:38PM +0100, Ian Campbell wrote:
> > > On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:
> > > Does this issue go away entirely if we move from a v4t to v5 base, or
> > > are there also v5 instructions which are (potentially) absent in v8?
> > > (I
> > > think so, but I don't have my references to hand).
> > 
> > SWP and SWPB - these were deprecated in ARMv7 but absent in ARMv8.

Ah yes, thanks.

> Should we have a lintian or other archive-wide scan for these
> instructions in the arm64 arch?

ARMv8 AArch64 (== Debian arch arm64) has a different ISA from ARMv7 and
earlier, so I think that aarch64 simply doesn't have those instructions and
so there is no encoding and they cannot possibly exist in an arm64 binary.

Perhaps a scan for _deprecated_ instructions in armhf, representing things
which would be a problem when armhf was run in AArch32 mode on an ARMv8
processor would be useful?

+ what Wookey said wrt armel.

Ian.

Re: Summary of the ARM ports BoF at DC15

[Philippe Clérié]

This is microATX with 2 Gbe, 210Gbe and 4 SATA III ports. :
http://www.eteknix.com/latest-gigabyte-microatx-motherboard-arrives-with-octo-core-armv8-soc/
which is actually on-sale:
http://www.ldlc.com/fiche/PB00191584.html
But it's server kit so it's 950 EUR.

Wookey



Good to know that there is something out there. In this case though, 
it's way too expensive. I'll bet that dual 10Gbe is responsible for at 
least half the price; plus, I'am not ready yet for 10Gb.


Thanks for pointing it out.


--
Philippe

--
The trouble with common sense it that it is so uncommon.

Re: Summary of the ARM ports BoF at DC15

[Rob J. Epping]

On September 14, 2015 12:45:03 PM GMT+02:00, JM  wrote:
>On Fri, Sep 11, 2015 at 5:58 PM, Steve McIntyre 
>wrote:
>>
>> Summary: if people care about armel for Stretch, they should make
>> noise NOW and convince people it's needed and can/should be supported
>> in future.
>>
>
>I'm running Debian on QNAP TS-212P that was purchased new three months
>ago. I recommended one to a friend who's been looking for a cheap
>commodity NAS just the other week.
>
>I think Debian provides a very valuable service here - it enables
>people to easily replace the typical proprietary NAS software (often
>with ancient kernels, huge attack surface, spotty security updates and
>uncertain life cycles) with a Free alternative that gives them control
>over their own hardware. It also gives manufacturers incentive to keep
>their hardware easy to hack on (SSH root access, enough flash,
>soldered serial headers) as some people choose QNAP over e.g. Synology
>just because they can easily put Debian on it -- with the Debian
>Installer a careful individual doesn't even need serial access!
>
>The architecture may be a bit dated but it can still push a lot of
>packets over a gigabit cable and it's far from being dead - the recent
>DTB transition and 4.x kernels brought new features to kirkwood
>(cpuidle driver, working cpufreq, thermal zone support), bugs are
>being ironed out with upstream (coherency issue with syncbarriers a
>while back, IO problems with mtdblock driver investigated currently)
>and there is a brand-new rewrite of the crypto engine driver
>(marvell-cesa) in kernel 4.2 that I am very eager to test as soon as
>it hits unstable.
>
>There has been a lot of effort put into making Debian on QNAP work
>well (kudos to Martin Michlmayr and Ian Campbell among others) and I
>personally think it would be a huge waste to see it gone.
>
>Best regards,
>Jan

+1

Running 2 QNAP devices as "servers" here. Having them supported would be a good 
thing
-- 
Sent from my mobile device. Please excuse my brevity.

Re: Summary of the ARM ports BoF at DC15

[Nagel, Peter (IFP)]

Although I'm quite new to Linux I was able to setup jessy on a new QNAP 
TS-420U  (... many thanks to tbm and the list)
and it would be great if kirkwood devices would get support also in the 
future.
If (for whatever reason) this is not possible ... I hope that (at least) 
some kind of LTS will be available in the future.


Best regards,
Peter


Am 12.09.2015 um 19:14 schrieb Jeroen Dekkers:

I think it would be a pity if we wouldn't support kirkwoord devices
such as those QNAP NAS devices anymore. I've got a QNAP TS-221 that is
less than two years old and it would be nice if it would continue to
run the latest version of Debian, but I don't know how much work it would
cost to continue to support armel for Stretch.

Kind regards,
Jeroen Dekkers

Am 11.09.2015 um 17:58 schrieb Steve McIntyre:

Hi folks,

As promised, here's a quick summary of what was discussed at the BoF
session in Heidelberg.  ...

armel
=
... Summary: if people care about armel for Stretch, they should make
noise NOW and convince people it's needed and can/should be supported
in future.

Re: Summary of the ARM ports BoF at DC15

[Björn Wetterbom]

On Fri, Sep 11, 2015 at 5:58 PM, Steve McIntyre  wrote:

> Summary: if people care about armel for Stretch, they should make
> noise NOW and convince people it's needed and can/should be supported
> in future.
>

I'd hate to see my two QNAP NAS:es unsupported. Setting them up again with
new hardware would really be a pain. I'm ever so grateful for the hard work
done by all of the Debian team.

/Björn

Re: Summary of the ARM ports BoF at DC15

[Ian Campbell]

On Sat, 2015-09-12 at 23:26 +0100, Wookey wrote:
> +++ Ian Campbell [2015-09-12 15:55 +0100]:
> 
> > The other two subarches in the kernel are orion5x and versatile. I
> have
> > no personal interest in either. My gut suggests that orion5x (the
> > Marvell variant prior to kirkwood) is the one people might more
> > plausibly still be interested in, but I don't know that any is
> actually
> > still using it.
> 
> I think versatile is mostly there because it's the standard QEMU
> target. So it's useful if you need armel under qemu-system. Not sure
> if this has changed (and I may be confused on this matter).

That sounds likely, yes.

I don't know how much need there is for armel under qemu-system these
days though.

> > How much multithreading is there actually in building packages I
> wonder.
> 
> Anything using java failed to build on qemu (no multithreading) so
> that may be an area where it happens (if java uses the offending
> instructions for its thread support). And for other things I guess
> they will build, but any thread-using tests will fail.

I was assuming emulation support in the kernel, so I think they should
"work" but more slowly.

The question is how much more slowly in practice and is it so slow as
to be a problem. It may not really matter if e.g. swp emulation is,
say, 1,000x slower than running the instruction natively on h/w if only
1 in every 100,000 userspace instructions run on a buildd is a swp
instruction. It'll make things slower, for sure, but too slow, I don't
know. I think we'll have to wait and see. IMHO there's too many
variables to have a sensible guess.

Ian.

Re: Summary of the ARM ports BoF at DC15

[Philippe Clérié]

On 09/11/2015 11:58 AM, Steve McIntyre wrote:


Summary: if people care about armel for Stretch, they should make
noise NOW and convince people it's needed and can/should be supported
in future.



Thanks for that post. Very timely, as I was about to recommend some QNAP 
hardware because of armel support in Debian. Perhaps I will reconsider that.


I am personally using 4 armel devices (OpenRD, Dreambox, 2 QNAP) and I 
like them very much indeed. They are all running Debian and I would 
really like to keep it that way. It's not like there's much else out 
there. For what it's worth, these are all servers not running any X 
applications whatsoever.


armhf is not going away, right? The RaspberryPi is also important to me 
at the moment.


arm64: I wish. I'd love a MiniITX board with ARM64, GBe and a few SATA 
ports.


Thanks again!

--
Philippe

--
The trouble with common sense it that it is so uncommon.

Re: Summary of the ARM ports BoF at DC15

[Wookey]

+++ Philippe Clérié [2015-09-13 20:14 -0400]:
> On 09/11/2015 11:58 AM, Steve McIntyre wrote:
> 
> >Summary: if people care about armel for Stretch, they should make
> >noise NOW and convince people it's needed and can/should be supported
> >in future.
> >
> 
> Thanks for that post. Very timely, as I was about to recommend some
> QNAP hardware because of armel support in Debian. Perhaps I will
> reconsider that.
> 
> I am personally using 4 armel devices (OpenRD, Dreambox, 2 QNAP) and
> I like them very much indeed. They are all running Debian and I
> would really like to keep it that way. It's not like there's much
> else out there. For what it's worth, these are all servers not
> running any X applications whatsoever.
> 
> armhf is not going away, right? The RaspberryPi is also important to
> me at the moment.
> 
> arm64: I wish. I'd love a MiniITX board with ARM64, GBe and a few
> SATA ports.

This is microATX with 2 Gbe, 210Gbe and 4 SATA III ports. :
http://www.eteknix.com/latest-gigabyte-microatx-motherboard-arrives-with-octo-core-armv8-soc/
which is actually on-sale:
http://www.ldlc.com/fiche/PB00191584.html
But it's server kit so it's 950 EUR.

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

Re: Summary of the ARM ports BoF at DC15

[Jeroen Dekkers]

At Fri, 11 Sep 2015 16:58:42 +0100,
Steve McIntyre wrote:
> Summary: if people care about armel for Stretch, they should make
> noise NOW and convince people it's needed and can/should be supported
> in future.

I think it would be a pity if we wouldn't support kirkwoord devices
such as those QNAP NAS devices anymore. I've got a QNAP TS-221 that is
less than two years old and it would be nice if it would continue to
run the latest version of Debian, but I don't know how much work it would
cost to continue to support armel for Stretch.


Kind regards,

Jeroen Dekkers

Re: Summary of the ARM ports BoF at DC15

[Wookey]

+++ Ian Campbell [2015-09-12 15:55 +0100]:

> The other two subarches in the kernel are orion5x and versatile. I have
> no personal interest in either. My gut suggests that orion5x (the
> Marvell variant prior to kirkwood) is the one people might more
> plausibly still be interested in, but I don't know that any is actually
> still using it.

I think versatile is mostly there because it's the standard QEMU
target. So it's useful if you need armel under qemu-system. Not sure
if this has changed (and I may be confused on this matter).

> How much multithreading is there actually in building packages I wonder.

Anything using java failed to build on qemu (no multithreading) so
that may be an area where it happens (if java uses the offending
instructions for its thread support). And for other things I guess
they will build, but any thread-using tests will fail.

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

Re: Summary of the ARM ports BoF at DC15

[Ian Campbell]

On Fri, 2015-09-11 at 16:58 +0100, Steve McIntyre wrote:

> armel
> =
> 
> [...]
> Known worries/issues:
> 
>  * Kernel size due to very restrictive flash space; has been a
>problem, but not believed to be affecting current users so much
>now. Several problematic sub-arches have been dropped. The ixp
>flavour is *definitely* not going to be supported for another
>release. We've suggested in the past that the way to work around
>the restrictive flash space would be to write a trivial bootloader
>but there's not been any effort spent there.

The size restrictions encoded in the kernel are the lowest-common
-denominator, which I'm not sure really reflect the systems people are
actually using. While those do have limited amounts of flash are not as
constrained as the worst cases.

>  * There's a good chance that we've built some things that don't work
>on v4t already, due to not using v4t hardware for build and test
>any more. That was already likely when we were using v5 buildd
>hardware, and it's only going to become more of an issue now we're
>using v7 buildd hardware. We *might* have to shift to v5 at least 
>there are only a tiny number of v4t devices that people care about
>any more, it seems

FWIW I think shifting to v5 would be fine (the more so that we've
perhaps already done so by accident).

> Summary: if people care about armel for Stretch, they should make
> noise NOW and convince people it's needed and can/should be supported
> in future.

I think there are people who still care about specific subarches (or
actually, one specific subarch).

In particular the kirkwood subarch is still an interesting/active
platform which people use (due to being included in all sorts of NAS
devices etc) and which I at least do care about. I think kirkwood at
least will be viable through the lifetime of stretch and that makes it
worth continuing to support armel.

The other two subarches in the kernel are orion5x and versatile. I have
no personal interest in either. My gut suggests that orion5x (the
Marvell variant prior to kirkwood) is the one people might more
plausibly still be interested in, but I don't know that any is actually
still using it.

I think all of those 3 subarches are v5, and kirkwood certainly is, so
no need for v4t from that PoV.

> Buildds and hardware
> 
> 
[...]
> Some of the software for armel cannot run on the arm64 machines,
> unfortunately. There are ARMv4t instructions that trigger exceptions
> due to missing support in ARMv8 CPUs. This will be another problem for
> armel as we move forward. Kernel exception handling will allow this
> code to work in future, but *massively* slower than if supported in
> the hardware so it's not really an option for us.

I'm sure they will be slower, but I'm not sure that v5+some emulation
running on a 2GHz ARMv8 server SoC will be "too slow" compared to
running natively on a 500MHz embedded SoC. IOW I'm not sure they will
be unusably slow. I guess we will see.

Does this issue go away entirely if we move from a v4t to v5 base, or
are there also v5 instructions which are (potentially) absent in v8? (I
think so, but I don't have my references to hand).

Aren't most such instructions related to SMP (so from userspace PoV
effectively to multithreading)? How much multithreading is there
actually in building packages I wonder. Neither gcc nor make link
against libpthread on this machine at least. Or do they affect
multiprocess stuff like e.g. futexes as well? Another "I guess we will
see", I suppose.

Ian.