[ Please note the cross-post and Reply-To ] Hi folks, As promised, here's a quick summary of what was discussed at the BoF session in Heidelberg. Apologies for the delay - it takes a while to write these up, especially when struck down with the traditional post-DebConf plague. :-( Thanks to the awesome efforts of our video team, the session is already online [1]. I've taken a copy of the Gobby notes too, alongside my small set of slides for the session. [2] As part of the "Ports" track at DebConf, We spoke about the past/present/future state of ARM ports in Debian. armel ===== 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... 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? Still supported upstream but becoming problematic on some fronts. Hence, we need to consider the future, as we're spending real human effort supporting armel. Unless it's really important, should we reduce the effort being spent? On the flip side, Debian is the only mainstream distro that still supports older ARM hardware. ARMv5-based hardware is still being made and sold today. 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. * 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. 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. armhf ===== 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! arm64 ===== Most recent port, first shipped with Jessie. It's working well overall, with just some minor things left to port and optimise. Maddog is organising a competition to encourage people to port code and optimise code for arm64 in some packages. The hardest remaining bits are those language runtimes where the support is written *in* the language in question: porters need to have a deep understanding of the language *and* any new architecture. Big, important language runtimes have already happened due to upstreams already doing the work: Java being a good example. In some cases, upstream have done the work but it's not yet filtered into a Debian stable release (NodeJS, freepascal etc.) and there are others where ports are known to exist but are not yet publically released (e.g. Mono). But there's still plenty of scope for people to get involved and help with porting a lot of software. Real devices (including real servers) will be hitting the market very shortly, which will make life easier for us. Linaro's 96boards.org program was mentioned as a source of boards, and that prompted complaints about continuing lack of upstream support. We're hoping that will be fixed soon...! Fairly well-known PC component manufacturers like Gigabyte and Asus are already starting to sell hardware based around Applied Micro's X-Gene CPU. Certain other large vendors like HP are also producing higher-end X-Gene based hardware (Moonshot), so options are widening! We even had a demo of an arm64-powered laptop in the talk, courtesy of Chen Baozi. We tried to show it on video, but it didn't quite work. :-/ Lots of interesting projects out there, and we're hoping to see arm64 going mainstream in the near future. Due to the tighter design constraints being used for ARMv8 devices, we expect that we'll have a much easier time supporting all the likely arm64 platforms with a single kernel etc. ACPI is in the spec for arm64 servers, which will help. Buildds and hardware ==================== We have lots of donated Marvell Armada XP dev boards for building armel and armhf, and they're mostly great. Still have one remaining imx53 board as a porter box for people who might need to debug 32-bit Neon stuff. We have a range of options for arm64 hardware: donated Junos, X-Genes and an AMD Seattle. We have issues with the machines that we have at the moment, but things are improving. DSA want us to replace the dev boards with proper server machines that are more stable and easier to manage. We're hoping to get more people to donate/loan newer big arm64 machines as they become available, and this will make our lives easier. 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. Scientific software =================== People are seeing issues with unit test timing out - what should they do? Tests are working fine on normal machines but timing out on buildds. If they're actually just taking too long, then the buildd timeouts can be raised. BUT: they might actually be showing real problems, e.g. with locking. Check on a porterbox too. Ask on the debian-arm list for more help if needed. Is it worth building scientific packages on armel? Possibly - we currently try to build everything, you never know when people will have a valid use case that you didn't think of... Small use case devices ====================== For less popular, small use-case devices, are there any lower bounds on what we'll ship in terms of DTBs? If the dts is in mainline and works, then the dtb can be made available - it's very cheap for us! Question about Oluxino boards and making them work - currently needs modifying u-boot. Talk to Karsten Merker - he's the export on this! :-) QEMU ==== What differences should be expected when using qemu compared to developing with real hardware? Performance will change noticeably, threading may change quite a bit. Cross-compilers =============== Wookey wants to know what cross targets are useful for ARM-hosted systems. Talk to him! ARM live images =============== We're planning on doing some arm64 (and maybe armhf) images in the near future. Harder with armhf due to the variation in devices and booting support. arm64 with UEFI will be much easier. Hoping to be demoing stuff soon! lava.debian.net =============== Work is planned to set up a LAVA service running tests and CI on ARM devices hosted by Linaro, but there have been some holdups. More news coming soon, hopefully. ARM porting access ================== DDs have access to porter boxes already; Linaro is offering access to ARMv8 devices for upstream porting too. [1] http://meetings-archive.debian.net/pub/debian-meetings/2015/debconf15/ARM_ports_BoF.webm [2] http://www.einval.com/~steve/talks/Debconf15-state-of-the-arm/ -- Steve McIntyre, Cambridge, UK. steve@einval.com "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
Attachment:
signature.asc
Description: Digital signature