Summary of the ARM ports BoF at DC16

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Summary of the ARM ports BoF at DC16

Steve McIntyre
[ Please note the cross-post and Reply-To ]

Hi folks,

As promised, here's a quick summary of what was discussed at the ARM
ports BoF session in Cape Town.

This year, unfortunately the session did not have video so I can't
link to it. I've taken a copy of the Gobby notes from the session,
alongside my small set of slides for the session (that also didn't get
shown!). [1]

We spoke about the past/present/future state of ARM ports in Debian.

armel
=====

armel is the longest-running of our current ARM ports in Debian,
starting in 2007. It's starting to become difficult to support. Debian
is the only common distro still supporting ARMv4t. While there is
still good upstream support in most major packages (e.g. Linux and
gcc), we're seeing a growing number of issues. Some packages
(e.g. NodeJS) don't support pre-ARMv7 at all any more. Another problem
is the lack of direct support for C++11 atomics - it's possible to use
a kernel helper to cover for this lack, but performance will be
terrible.

Possible future options for armel:

 * Partial armel architecture?

   We've talked about this in the past for various architectures, but
   nobody has stepped up to work on it. The vast majority of the
   outstanding armel use cases are going to be in headless servers so
   we could maybe drop the desktop tasks and dependencies and keep
   things like web server / mail server tasks that are much simpler.

   Downside: There's no clear plan for how to create/maintain a
   partial architecture, let alone how to release one. Potentially
   huge amount of work needed.

 * Update to ARMv5t (and maybe go headless)

   We might be able to extend the life of armel by upping the minimum
   spec, and would be able to continue supporting Kirkwood and Orion
   based machines (e.g. NAS boxes) for a while longer. This would kill
   support for v4t devices like Openmoko, but there are precious few
   of these older devices still around.

   Downside: as above if we try to do the partial architecture route;
   if we don't we'll still have to support a full range of software on
   older hardware.

   Will need volunteers to make this work in either form, and while
   some people are prepared to *help* (e.g. bdale and zumbi), nobody
   stepped up in the BoF to lead such an effort. It needs both skill
   and commitment of time.

 * Release armel with stretch, then drop it

   **This is the favoured option.** That would give EOL for armel in
   2020, *potentially* later if there's an LTS release for stretch and
   armel is included (as it is in wheezy). That would depend on
   external labour or funding.

   It's not easy (or popular) to remove an architecture from Debian,
   but we're giving 4 years' notice of end of support.

armhf
=====

Much as in the Heidelberg BoF in terms of support and future.

Current port, first released with Wheezy. Due to cross-distro effort,
this setup (ARMv7 EABI using VFPv3D-16) is the default supported
32-bit ARM architecture in all distros now. We've got a couple of
kernel variants that will support just about any new devices shipping,
given updated drivers and device tree support.

Despite the ubiquity of v7 hardware that works, some people are still
making CPUs that *don't* work, e.g. new CPUs this year without any
hardware FPU. Not much we can or will do to support such broken
hardware.

Ignoring known-broken hardware stuff, almost any currently-shipping
ARMv7 device is likely to work with armhf. Yay!

There's been a recent effort to add an EFI shim layer into modern
U-Boot, which may allow for easier consistent boot support but there's
still issues to think about in terms of EFI variables etc.

arm64
=====

Most recent ARM port. All looking good now - we've been mostly able to
move on from Juno development platforms to real server hardware
now. We're using some APM Mustang machines and an AMD Seattle box
hosted by ARM and Linaro at the moment, and even real arm64 server
machines are finally coming available. Looking to move more of our ARM
buildds over onto these arm64 servers in the future, as this will
improve reliability and manageability.

We're using a single kernel for arm64, using DTB or ACPI for
configuration. Works well.

Affordable, usable machines are available now, e.g. the Cello or
SoftIron 1000 for ~$600. Linaro's 96boards machines are not using a
standard form factor which is sub-optimal. There's a Marvell arm64
board due soon (H2 2016) in ATX. The SoftIron 1000 doesn't have PCI,
but should be good for development/buildd otherwise. Another cheap
option is the Pine64. It's stuck on a vendor kernel for now, but
that's being steadily worked on. Cheap: quad A53, 2GB RAM, $29.

Other issues:

 * ci.debian.net could do with more arm64 hardware, we'll see what we
   can do to help
 * UEFI Secure Boot for arm64 has an issue - there's nobody providing
   a root CA. HP are doing their own for now; not sure what other
   vendors can/will do. It's complicated (TM).

arm64 boards - http://www.96boards.org/
               http://softiron.co.uk/

Misc
====

armhf question about using Neon extensions: We don't mandate Neon
support in the armhf ABI, as not all the supported boards have Neon -
including our own Marvell Armada XP based buildds. The armhf porter
box (harris.d.o) has Neon if people need to test. If software is
depending on detecting hardware support at compile time, that's
*broken* - detection should be done at runtime. Similar to SSE support
on X86 machines. There are good options already supported here. For
libraries, packages can build multiple copies with differing
optimisation and use hwcaps support in the runtime linker to select
the correct version. Alternatively, use ifunc to select the right
version(s) of specific functions at runtime.

Big endian support on ARM: While this is doable on the hardware (ARM
is endian-agnostic), it doesn't make sense for general purpose
distributions like Debian to (re)build everything in BE mode too -
there's not a compelling use case for us to spend the effort.

ILP32 port (arm64 equivalent of X32: a new 32-bit ABI for 64-bit
hardware) is in a similar place. While some folks may consider it
useful, there's no compelling reason for Debian or any other general
purpose distribution to ever care about it.

[1] http://www.einval.com/~steve/talks/Debconf16-arm-bof/

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Roger Shimizu
[ intentionally keep d-d CCed ]

On Fri, 22 Jul 2016 02:36:05 +0100
Steve McIntyre <[hidden email]> wrote:

> [ Please note the cross-post and Reply-To ]
>
> Hi folks,
>
> As promised, here's a quick summary of what was discussed at the ARM
> ports BoF session in Cape Town.

Thanks for the summary!

I'm ARM porter on armel/marvell (orion5x/kirkwood).
Stretch will be frozen and released soon, which makes me bit depressed,
because it means armel will be dropped out of unstable/testing as the
conclusion of Cape Town BoF.

So I'm writing to ask if there's any chance ...

> We spoke about the past/present/future state of ARM ports in Debian.
>
> armel
> =====
>
> armel is the longest-running of our current ARM ports in Debian,
> starting in 2007. It's starting to become difficult to support. Debian
> is the only common distro still supporting ARMv4t. While there is
> still good upstream support in most major packages (e.g. Linux and
> gcc), we're seeing a growing number of issues. Some packages
> (e.g. NodeJS) don't support pre-ARMv7 at all any more. Another problem
> is the lack of direct support for C++11 atomics - it's possible to use
> a kernel helper to cover for this lack, but performance will be
> terrible.
>
> Possible future options for armel:
>
>  * Partial armel architecture?
>
>    We've talked about this in the past for various architectures, but
>    nobody has stepped up to work on it. The vast majority of the
>    outstanding armel use cases are going to be in headless servers so
>    we could maybe drop the desktop tasks and dependencies and keep
>    things like web server / mail server tasks that are much simpler.
>
>    Downside: There's no clear plan for how to create/maintain a
>    partial architecture, let alone how to release one. Potentially
>    huge amount of work needed.
>
>  * Update to ARMv5t (and maybe go headless)
>
>    We might be able to extend the life of armel by upping the minimum
>    spec, and would be able to continue supporting Kirkwood and Orion
>    based machines (e.g. NAS boxes) for a while longer. This would kill
>    support for v4t devices like Openmoko, but there are precious few
>    of these older devices still around.
Dropping v4t devices seems won't cause big problem, as you said there's few
devices around currently.
So I personally prefer this option.

>    Downside: as above if we try to do the partial architecture route;
>    if we don't we'll still have to support a full range of software on
>    older hardware.

I don't see any detailed downside reason here.
I think armel dropping v4t is just like i386 dropping 586-class CPU [0].
If we can dropping 586-class CPU support for i386, by changing a few
configure files in gcc/dpkg/kernel packages, why we cannot do the same for
armel?

[0] https://lists.debian.org/debian-devel-announce/2016/05/msg00001.html

I'm a "high-level" ARM porter, merely knowing the basic device-tree stuff
to support new device.
So I'm lack of knowledge in lower chipset level and maybe missed something
here.
Could you kindly help to list the detailed work other than listed above?

>    Will need volunteers to make this work in either form, and while
>    some people are prepared to *help* (e.g. bdale and zumbi), nobody
>    stepped up in the BoF to lead such an effort. It needs both skill
>    and commitment of time.

If specific working items are clearly listed, I think there would be someone
stepping out, since the armel user/devel base is still big.

Thanks and look forward to your feeback!

Cheers!
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Steve McIntyre
On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:

>[ intentionally keep d-d CCed ]
>
>On Fri, 22 Jul 2016 02:36:05 +0100
>Steve McIntyre <[hidden email]> wrote:
>
>> [ Please note the cross-post and Reply-To ]
>>
>> Hi folks,
>>
>> As promised, here's a quick summary of what was discussed at the ARM
>> ports BoF session in Cape Town.
>
>Thanks for the summary!
>
>I'm ARM porter on armel/marvell (orion5x/kirkwood).
>Stretch will be frozen and released soon, which makes me bit depressed,
>because it means armel will be dropped out of unstable/testing as the
>conclusion of Cape Town BoF.
>
>So I'm writing to ask if there's any chance ...
>
>> We spoke about the past/present/future state of ARM ports in Debian.
>>
>> armel
>> =====
>>
>> armel is the longest-running of our current ARM ports in Debian,
>> starting in 2007. It's starting to become difficult to support. Debian
>> is the only common distro still supporting ARMv4t. While there is
>> still good upstream support in most major packages (e.g. Linux and
>> gcc), we're seeing a growing number of issues. Some packages
>> (e.g. NodeJS) don't support pre-ARMv7 at all any more. Another problem
>> is the lack of direct support for C++11 atomics - it's possible to use
>> a kernel helper to cover for this lack, but performance will be
>> terrible.
>>
>> Possible future options for armel:
>>
>>  * Partial armel architecture?
>>
>>    We've talked about this in the past for various architectures, but
>>    nobody has stepped up to work on it. The vast majority of the
>>    outstanding armel use cases are going to be in headless servers so
>>    we could maybe drop the desktop tasks and dependencies and keep
>>    things like web server / mail server tasks that are much simpler.
>>
>>    Downside: There's no clear plan for how to create/maintain a
>>    partial architecture, let alone how to release one. Potentially
>>    huge amount of work needed.
>>
>>  * Update to ARMv5t (and maybe go headless)
>>
>>    We might be able to extend the life of armel by upping the minimum
>>    spec, and would be able to continue supporting Kirkwood and Orion
>>    based machines (e.g. NAS boxes) for a while longer. This would kill
>>    support for v4t devices like Openmoko, but there are precious few
>>    of these older devices still around.
>
>Dropping v4t devices seems won't cause big problem, as you said
>there's few devices around currently. So I personally prefer this
>option.

AFAIK there are potentially still similar problems with ARMv5 - lack
of architcture-defined barrier primitives for C++11 atomics to
work. (I'd love to be corrected on this if people know better!) This
is one of the key points here. More and more software is expecting to
use these primitives, and a lack of them is a major problem. To
demonstrate using gcc, you can see that lock-free atomics only started
appearing in ARMv6 and were improved in ARMv7:

$ for arch in 4 5 6 7-a; do echo ARMv${arch}; echo | g++ -march=armv${arch} -dM -E - | grep -i lock_free; done
ARMv4
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv5
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv6
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
ARMv7-a
#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 2
#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
#define __GCC_ATOMIC_POINTER_LOCK_FREE 2
#define __GCC_ATOMIC_INT_LOCK_FREE 2
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 2
#define __GCC_ATOMIC_LONG_LOCK_FREE 2
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
#define __GCC_ATOMIC_SHORT_LOCK_FREE 2

There are kernel helpers available to provide some atomic support, but
they'll be very slow compared to real hardware support at this level.

>>    Downside: as above if we try to do the partial architecture route;
>>    if we don't we'll still have to support a full range of software on
>>    older hardware.
>
>I don't see any detailed downside reason here. I think armel dropping
>v4t is just like i386 dropping 586-class CPU [0]. If we can dropping
>586-class CPU support for i386, by changing a few configure files in
>gcc/dpkg/kernel packages, why we cannot do the same for armel?

It's a similar thing, but further up the curve - that's all. We added
armhf (as the equivalent of i686, maybe) a while back, targeting
ARMv7. The much older CPU designs based on ARMv4 and ARMv5 are getting
harder to support than the i586 here. The world has moved on,
basically.

>[0] https://lists.debian.org/debian-devel-announce/2016/05/msg00001.html
>
>I'm a "high-level" ARM porter, merely knowing the basic device-tree
>stuff to support new device. So I'm lack of knowledge in lower
>chipset level and maybe missed something here. Could you kindly help
>to list the detailed work other than listed above?
>
>>    Will need volunteers to make this work in either form, and while
>>    some people are prepared to *help* (e.g. bdale and zumbi), nobody
>>    stepped up in the BoF to lead such an effort. It needs both skill
>>    and commitment of time.
>
>If specific working items are clearly listed, I think there would be someone
>stepping out, since the armel user/devel base is still big.

You're the first armel developer to offer to dive in here, so that's a
good start!

 * It will need somebody happy to dive into the lower levels of the
   various toolchains to verify support for atomics and make things
   work where it's not already, by adding support for the kernel
   helpers.

 * *If* we wanted to try the partial architecture thing, that will
   need some effort to make it work. That's not well-defined right
   now, as it's only a vague concept at best (sorry!)

 * There are going to be some packages that just won't work,
   particularly JIT compilers and other code generators that assume
   ARM == ARMv7. Fixing those up might raneg between feasible and
   ~impossible depending on the size of the codebase...

>Thanks and look forward to your feeback!

HTH!

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch

Emilio Pozuelo Monfort-4
On 07/12/16 16:53, Steve McIntyre wrote:
>  * It will need somebody happy to dive into the lower levels of the
>    various toolchains to verify support for atomics and make things
>    work where it's not already, by adding support for the kernel
>    helpers.

There has been some recent work on this, but it seems stalled and it's not clear
whether it works on all the armel targeted hardware (e.g. v4t), see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

Emilio

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch

Steve McIntyre
On Wed, Dec 07, 2016 at 05:05:58PM +0100, Emilio Pozuelo Monfort wrote:

>On 07/12/16 16:53, Steve McIntyre wrote:
>>  * It will need somebody happy to dive into the lower levels of the
>>    various toolchains to verify support for atomics and make things
>>    work where it's not already, by adding support for the kernel
>>    helpers.
>
>There has been some recent work on this, but it seems stalled and it's not clear
>whether it works on all the armel targeted hardware (e.g. v4t), see:
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

ACK. I'd missed the updates there - thanks for the links!

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch

Roger Shimizu
Dear Steve,

Thanks for your comments!
Very informative!

On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre <[hidden email]> wrote:
>
> There are kernel helpers available to provide some atomic support, but
> they'll be very slow compared to real hardware support at this level.

Are those kernel helper already reached Debian?
Or there's still some work here?

>>>    Downside: as above if we try to do the partial architecture route;
>>>    if we don't we'll still have to support a full range of software on
>>>    older hardware.
>>
>>I don't see any detailed downside reason here. I think armel dropping
>>v4t is just like i386 dropping 586-class CPU [0]. If we can dropping
>>586-class CPU support for i386, by changing a few configure files in
>>gcc/dpkg/kernel packages, why we cannot do the same for armel?
>
> It's a similar thing, but further up the curve - that's all. We added
> armhf (as the equivalent of i686, maybe) a while back, targeting
> ARMv7. The much older CPU designs based on ARMv4 and ARMv5 are getting
> harder to support than the i586 here. The world has moved on,
> basically.

Just like the world already moves on to amd64, but Debian still
support i386 and i686,
I think the community need armel and armhf, for quite a long time if
it's feasible.

> You're the first armel developer to offer to dive in here, so that's a
> good start!

Thanks, but my knowledge don't cover the lower part such as building toolchains,
still need someone with more experience.

>  * It will need somebody happy to dive into the lower levels of the
>    various toolchains to verify support for atomics and make things
>    work where it's not already, by adding support for the kernel
>    helpers.

> On Wed, Dec 07, 2016 at 05:05:58PM +0100, Emilio Pozuelo Monfort wrote:
>>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820535
>>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735

I guess above 2 links, provided by Emilio (thanks so much!), can
resolve the concern on building toolchains.

>  * *If* we wanted to try the partial architecture thing, that will
>    need some effort to make it work. That's not well-defined right
>    now, as it's only a vague concept at best (sorry!)

Maybe we can avoid to do partial arch?

>  * There are going to be some packages that just won't work,
>    particularly JIT compilers and other code generators that assume
>    ARM == ARMv7. Fixing those up might raneg between feasible and
>    ~impossible depending on the size of the codebase...

If something breaks, I guess it breaks now already.
We need to fix before Stretch.
If the issue is fixed, I think there's no need to remove armel
immediately after releasing Stretch.

Please correct me if I missed something. Thank you!

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch

Ben Hutchings-3
On Thu, 2016-12-08 at 20:19 +0900, Roger Shimizu wrote:

> Dear Steve,
>
> Thanks for your comments!
> Very informative!
>
> > On Thu, Dec 8, 2016 at 12:53 AM, Steve McIntyre <[hidden email]> wrote:
> >
> > There are kernel helpers available to provide some atomic support, but
> > they'll be very slow compared to real hardware support at this level.
>
> Are those kernel helper already reached Debian?
> Or there's still some work here?
[...]

The cmpxchg32 helper has been there since 2.6.12 while the cmpxchg64
helper was added in 3.1.  So all supported Debian releases have them.

Ben.

--
Ben Hutchings
When in doubt, use brute force. - Ken Thompson


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Christoph Biedl-7
In reply to this post by Roger Shimizu
Roger Shimizu wrote...

> I'm ARM porter on armel/marvell (orion5x/kirkwood).
> Stretch will be frozen and released soon, which makes me bit depressed,
> because it means armel will be dropped out of unstable/testing as the
> conclusion of Cape Town BoF.

Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
it gives a bad feeling having to trash them some day just because
there's no support any more.

On the other hand, they face another problem I guess is typical for
that generation, just by the age: Memory. So for quite some time I
wanted to start a thread here but there are too many other things I
have to take care of. Now however that the discussion has started ...
I would have written something like the following:


As far as I know, there is no such thing as "minimal hardware
requirement" for Debian besides some lines in the installer pages. For
RAM, the minimum value is 128 megabytes, and I think it's about time
to raise that. Yes, you can run Debian on that but it's not fun:

Locale generation needs a lot of RAM. You can work around it by
installing locales-all which however takes long time to install on
slow flash drives. Or disable locales entirely. Err.

Side-effects of over-eagerly used xz compression. This is a relict of
time when xz was pretty new and maintainers added the -9 compression
option, probably completely unaware this makes no sense for small
packages, unlike gzip or bzip2. Also, even unpacking unconditionally
allocates some 65 Mbyte memory then, easiliy driving a 128 Mbyte-box
to the limits. One of the worst is the traceroute package that
actually carries some 110 kbyte; however I was unable to install it
due to the above problem.

The amount of data apt deals with reflects more or less the size of
the Packages indexes. As they get bigger each release, this will
become a problem. Already now apt gets OOM-killed every now and then.


About xz, I considered doing a MBF (severity normal the most) asking
to end this, it's about 45 packages.

About apt I have an idea to provide "reduced" Packages indexes. They
would be smaller so the memory usage is no longer a problem, also apt
should become somewhat faster. But since it's virtually impossible to
create a complete subset, I'd declare incompleteness a feature: If
somebody manages to hit the limits by requesting installation of
packages that are referenced only - tough luck, use the full index,
please. But somebody would have to promote and maintain that feature.


Another way to deal with this however was to raise the minimum memory
requirements. To 256 MB, or perhaps even 512 MB. It feels wrong since
it works around a problem instead of solving it. But since all
components become more greedy over time, this will have to be done
sooner or later anyway. And will render armel de-facto obsolete.

Still I wouldn't mind armel in buster, perhaps restricted to armv5.
But I understand the odds aren't quite in favour.

    Christoph

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Ben Hutchings-3
On Thu, 2016-12-08 at 23:12 +0100, Christoph Biedl wrote:

> Roger Shimizu wrote...
>
> > I'm ARM porter on armel/marvell (orion5x/kirkwood).
> > Stretch will be frozen and released soon, which makes me bit depressed, 
> > because it means armel will be dropped out of unstable/testing as the 
> > conclusion of Cape Town BoF.
>
> Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
> it gives a bad feeling having to trash them some day just because
> there's no support any more.
>
> On the other hand, they face another problem I guess is typical for
> that generation, just by the age: Memory.
[...]

Also, dedicated tiny flash partitions for the kernel and initrd.  I
wouldn't be surprised to be find that by the time we want to release
buster we can't build a useful kernel that fits into the 2 MB partition
that most of these devices seem to have.

As it is, stretch will be supported until 2020, maybe 2022 on armel.
Is it really worthwhile to add another 2 years to that?

Ben.

--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Roger Shimizu
On Fri, 09 Dec 2016 00:53:17 +0000
Ben Hutchings <[hidden email]> wrote:

> Also, dedicated tiny flash partitions for the kernel and initrd.  I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devices seem to have.

Actually those limitations are only for a few old orion5x models.
For Linkstation kirkwood series I maintain for, kernel can be 2.5MB
and initrd can be 8MB.

I'm not sure about the exact limitation size because the vendor doesn't
disclose this specification clearly.
But size listed above should be much easier to achieve for kernel
maintainers.

> As it is, stretch will be supported until 2020, maybe 2022 on armel.
> Is it really worthwhile to add another 2 years to that?

If the effort to maintain the armel is limited under certain level,
and the those hardware are still in good condition, IMHO the longer
the better.

Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

debacle
In reply to this post by Ben Hutchings-3
Quoting Ben Hutchings <[hidden email]>:
> Also, dedicated tiny flash partitions for the kernel and initrd.  I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devices seem to have.

Non-HF devices can be very different, look at e.g. this ARM926EJ-S one:
http://www.taskit.de/stamp9g20.html

> As it is, stretch will be supported until 2020, maybe 2022 on armel.
> Is it really worthwhile to add another 2 years to that?

This depends on the effort, of course. But for environmental reasons
I'ld say the longer the better.

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Ben Hutchings-3
In reply to this post by Roger Shimizu
On Fri, 2016-12-09 at 22:14 +0900, Roger Shimizu wrote:

> On Fri, 09 Dec 2016 00:53:17 +0000
> > Ben Hutchings <[hidden email]> wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd.  I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a useful kernel that fits into the 2 MB partition
> > that most of these devices seem to have.
>
> Actually those limitations are only for a few old orion5x models.
> For Linkstation kirkwood series I maintain for, kernel can be 2.5MB
> and initrd can be 8MB.
OK, that's much less of a problem.  Please add this information to the
comment on size limitations (debian/config/armel/defines).

> I'm not sure about the exact limitation size because the vendor doesn't
> disclose this specification clearly.

I think we should assume that whatever fits in the flash partition will
work, unless we discover another limitation in the boot loader.

Ben.

> But size listed above should be much easier to achieve for kernel 
> maintainers.
>
> > As it is, stretch will be supported until 2020, maybe 2022 on armel. 
> > Is it really worthwhile to add another 2 years to that?
>
> If the effort to maintain the armel is limited under certain level,
> and the those hardware are still in good condition, IMHO the longer
> the better.
>
> Cheers,
--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch

Christian Seiler
In reply to this post by Ben Hutchings-3
On 12/09/2016 01:53 AM, Ben Hutchings wrote:

> On Thu, 2016-12-08 at 23:12 +0100, Christoph Biedl wrote:
>> Roger Shimizu wrote...
>>
>>> I'm ARM porter on armel/marvell (orion5x/kirkwood).
>>> Stretch will be frozen and released soon, which makes me bit depressed,
>>> because it means armel will be dropped out of unstable/testing as the
>>> conclusion of Cape Town BoF.
>>
>> Same here. My Dockstars (orion5x/kirkwood) still work like a charm and
>> it gives a bad feeling having to trash them some day just because
>> there's no support any more.
>>
>> On the other hand, they face another problem I guess is typical for
>> that generation, just by the age: Memory.
> [...]
>
> Also, dedicated tiny flash partitions for the kernel and initrd.  I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devices seem to have.

I'd like to mention my package tiny-initramfs here, which can help
keep the size required for the initramfs down quite a bit (without
modules it's ~12-14 kiB (!) with gzip on armel, modules increase it
by their own size, but nothing else; separate /usr is explicitly
supported), and may be useful for at least some of that hardware:

https://tracker.debian.org/pkg/tiny-initramfs
https://github.com/chris-se/tiny-initramfs/

That doesn't help if there's a limit on the kernel image alone and
that is exceeded, of course.

Regards,
Christian

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Paul Wise via nm
In reply to this post by Ben Hutchings-3
On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:

> Also, dedicated tiny flash partitions for the kernel and initrd.  I
> wouldn't be surprised to be find that by the time we want to release
> buster we can't build a useful kernel that fits into the 2 MB partition
> that most of these devices seem to have.

Is it possible to put a bootloader like u-boot in the flash partitions
and have it load the Linux kernel and initrd from elsewhere?

--
bye,
pabs

https://wiki.debian.org/PaulWise

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

wookey-4
In reply to this post by Steve McIntyre
On 2016-12-07 15:53 +0000, Steve McIntyre wrote:
> On Wed, Dec 07, 2016 at 08:50:40PM +0900, Roger Shimizu wrote:

> >I'm ARM porter on armel/marvell (orion5x/kirkwood).
> >Stretch will be frozen and released soon, which makes me bit depressed,
> >because it means armel will be dropped out of unstable/testing as the
> >conclusion of Cape Town BoF.
> >
> >> Possible future options for armel:
> >>
> >>  * Partial armel architecture?
> >>
> >>    We've talked about this in the past for various architectures, but
> >>    nobody has stepped up to work on it. The vast majority of the
> >>    outstanding armel use cases are going to be in headless servers so
> >>    we could maybe drop the desktop tasks and dependencies and keep
> >>    things like web server / mail server tasks that are much simpler.

> >>    Downside: There's no clear plan for how to create/maintain a
> >>    partial architecture, let alone how to release one. Potentially
> >>    huge amount of work needed.

We can do poor-mans partial arch by just being fairly agressive about
disabling armel for packages that are broken or not suitable. Not very
clever or efficient, but it is easy to do and requires no infra or
tooling changes at all. So long as someone is volunteering for that
(easy but unexciting) work that could work.

Obviously something fancier and more centralised/general would be
'better' but it requires a different skill-set and realistically will
probably take a long time.

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Ben Hutchings-3
In reply to this post by Paul Wise via nm
On Sat, 2016-12-10 at 09:54 +0800, Paul Wise wrote:
> On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd.  I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a useful kernel that fits into the 2 MB partition
> > that most of these devices seem to have.
>
> Is it possible to put a bootloader like u-boot in the flash partitions
> and have it load the Linux kernel and initrd from elsewhere?

It may well be, and that has been proposed before, but someone will
need to do the work to make flash-kernel upgrade (or at least detect
and support upgrades) to this configuration.

Ben.

--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch

Julien Cristau-6
In reply to this post by wookey-4
On 12/09/2016 05:22 PM, Wookey wrote:
> We can do poor-mans partial arch by just being fairly agressive about
> disabling armel for packages that are broken or not suitable. Not very
> clever or efficient, but it is easy to do and requires no infra or
> tooling changes at all. So long as someone is volunteering for that
> (easy but unexciting) work that could work.
>
We wouldn't necessarily want to call the result a Debian release, though.

Cheers,
Julien

Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Christoph Biedl-7
In reply to this post by Paul Wise via nm
Paul Wise wrote...

> On Fri, Dec 9, 2016 at 8:53 AM, Ben Hutchings wrote:
>
> > Also, dedicated tiny flash partitions for the kernel and initrd.  I
> > wouldn't be surprised to be find that by the time we want to release
> > buster we can't build a useful kernel that fits into the 2 MB partition
> > that most of these devices seem to have.
>
> Is it possible to put a bootloader like u-boot in the flash partitions
> and have it load the Linux kernel and initrd from elsewhere?

That how I've been running my Dockstars through all the years. As as
far as I know this worked with the Debian kernels as well (I use my
own kernels for reasons).

    Christoph

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

Christoph Biedl-7
In reply to this post by debacle
W. Martin Borgert wrote...

> Quoting Ben Hutchings <[hidden email]>:
> >Also, dedicated tiny flash partitions for the kernel and initrd.  I
> >wouldn't be surprised to be find that by the time we want to release
> >buster we can't build a useful kernel that fits into the 2 MB partition
> >that most of these devices seem to have.
>
> Non-HF devices can be very different, look at e.g. this ARM926EJ-S one:
> http://www.taskit.de/stamp9g20.html

Maximum RAM is 128 Mbytes. Wouldn't buy this to run Debian on it.

> >As it is, stretch will be supported until 2020, maybe 2022 on armel.
> >Is it really worthwhile to add another 2 years to that?
>
> This depends on the effort, of course. But for environmental reasons
> I'ld say the longer the better.

Certainly, with some limits though. At some point new hardware is that
much more energy efficient the inital cost pays off over the intended
time of usage. Want my old P4 server?

    Christoph

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: armel after Stretch (was: Summary of the ARM ports BoF at DC16)

debacle
On 2016-12-10 17:54, Christoph Biedl wrote:
> Maximum RAM is 128 Mbytes. Wouldn't buy this to run Debian on it.

Depends on the use case. My employer is using it successfully
since years. Of course: No X, no database, no big data, but some
hungry Pythons and a web interface :~)

> At some point new hardware is that
> much more energy efficient the inital cost pays off over the intended
> time of usage. Want my old P4 server?

The forementioned hardware needs < 0.5 W, the manufacturer even
claims 0.18 W. AFAIK, most newer ARM boards that are capable to
run Debian need more energy or am I wrong?

(Furthermore, any replacement of hardware has many environmental
effects apart of energy consumption: Use of rare materials,
production side effects, transport, waste problems, etc.)

123