[ Basically as found at
http://summit.linaro.org/lcq2-12/meeting/20696/linaro-general-q112-cross-dis...
but etherpad data has a lovely habit of going away over time... ]
Current Status ==============
Overall, everything works!! ;-) \o/
Fedora ======
Fedora 17 has been released for primary platforms, but not for ARM yet. Still some remaining work.
* OMAP4 "doesn't work" (crashes), likely due to reliance on pure upstream OMAP support rather than TI branches. Other distros have used TI patches.
* Might be more similar issues around other SoCs that lack support in upstream kernel.
* omapdrm support will wait until F18 (likely).
* Still need to apply the arm hard-float linker path patches, including the hacky patch for supporting old and new SONAME
* Still scrubbing code base for use of GCC locking intrinsics (or, rather where packages have rolled their own). Sharing patches considered good here.
* "We suck" - Jon Masters
* Normal installer not working for ARM, still using dd mechanism to flash images to cards.
* Fedora are doing two ARM distros: v7 hardfloat (armv7hl) and v5 softfloat (armv5tel). v5 will be supported for another couple of years, mainly for RaspberryPi users.
Debian ======
* Architecture qualification underway for next release (Wheezy/version 7).
* armhf (v7 hardfloat) is fully expected to be accepted as an architecture for the next release, but not *officially* labelled as such yet.
* armel is still targetting ARMv4t; will continue to stay supported until absolute confirmation of no more devices in developer hands.
* need banchmarks to check how much speed is lost with staying to armv4 and/or reasons from toolchain people why v4t is no longer supported/doesn't work. Time to open discussion about this again after the Wheezy release.
* There's an *unofficial* port being made for for RaspberryPi (raspbian.org) ARMv6 hardfloat enabled for this (forward compatible with armhf). To support this better in future, would need additional support in HWCAPS to indicate which instructions are used in this binary/can be used on this hardware. Could use ELF headers for similar info for binaries. And corresponding info in package control file so dpkg can do something sensible (i.e. stop you installing v7 binaries on v6/v5 hardware.
* Starting early ground work for ARMv8 port.
* No omapdrm support in Debian due to "insane" use of 3.2 kernel for Wheezy
Ubuntu ======
* Ubuntu 12.04 LTS released (3.2 kernel). Main ARM support is armhf (v7 hardfloat).
* armel port used to be v7 soft-float, but is now slowly being downgraded from v7 to v5t. May be deprecated altogether in the future.
* Quantal (12.10) will likely use Linux 3.5 kernel
* LLVM built code not correct for armhf; under investigation.
* janimo officially volunteered (by infinity) to resolve issues around Mono.
* Starting early ground work for ARMv8 port.
General / actions =================
As all the distros are going to be working on bootstrapping ARMv8, plan to keep using the cross-distro list for discussion of issues. Linaro will host a bug tracker to help people share work better.
[ACTION] SteveMcIntyre to get BTS going
Steve's major Ruby issue on ARM (reported widely, see http://bugs.debian.org/652674 for details) is resolved. Now we can rely on getcontext/setcontext support in glibc, rather than on Ruby's (broken) internal implementation from Ruby v1.9+. Re-enable the test suites now!
[ACTION] Enumerate disabled testsuites across all distros and get them re-enabled
More regular cross-distro meetings (monthly conf call) considered useful.
[ACTION] SteveMcIntyre to chase down DaveRusling about reviving cross-distro meetings.
Cheers,
On Thu, Jun 7, 2012 at 6:09 PM, Steve McIntyre steve.mcintyre@linaro.org wrote:
[ Basically as found at
http://summit.linaro.org/lcq2-12/meeting/20696/linaro-general-q112-cross-dis...
but etherpad data has a lovely habit of going away over time... ]
Current Status
Overall, everything works!! ;-) \o/
Fedora
Fedora 17 has been released for primary platforms, but not for ARM yet. Still some remaining work.
* OMAP4 "doesn't work" (crashes), likely due to reliance on pure upstream OMAP support rather than TI branches. Other distros have used TI patches.
It now works fine. It's a bug in the CONFIG_OMAP4_ERRATA_I688 that arrived in the 3.3 kernel. Disabled that and it now works fine.
* Might be more similar issues around other SoCs that lack support in upstream kernel.
The SoC's we support (omap, tegra, imx, kirkwood, highbank and vexpress) all work fine with a few minor patches to fix build issues and bugs. Most of the patches are just a few lines.
* omapdrm support will wait until F18 (likely).
No it won't, it will be in F-17 and is tested working. We had to pull in a single patch that's not upstream to make this work.
* Still need to apply the arm hard-float linker path patches, including the hacky patch for supporting old and new SONAME
* Still scrubbing code base for use of GCC locking intrinsics (or, rather where packages have rolled their own). Sharing patches considered good here.
* "We suck" - Jon Masters
I actually disagree with that sentiment strongly. We have over 11K source packages built on ARM with not that much difference between x86 and ARM. We have java, eclipse and a number of other complex package stacks built and working across a number of devices. We have gnome with touch working. I don't see that we're much worse than others and I think we've made a lot of progress, of course there's a lot more work to do but we're certainly getting there.
* Normal installer not working for ARM, still using dd mechanism to flash images to cards.
* Fedora are doing two ARM distros: v7 hardfloat (armv7hl) and v5 softfloat (armv5tel). v5 will be supported for another couple of years, mainly for RaspberryPi users.
And for the kirkwood based plug devices as there seems to be many variants of these that people are interested in using.
Regards, Peter
Debian
* Architecture qualification underway for next release (Wheezy/version 7).
* armhf (v7 hardfloat) is fully expected to be accepted as an architecture for the next release, but not *officially* labelled as such yet.
* armel is still targetting ARMv4t; will continue to stay supported until absolute confirmation of no more devices in developer hands.
* need banchmarks to check how much speed is lost with staying to armv4 and/or reasons from toolchain people why v4t is no longer supported/doesn't work. Time to open discussion about this again after the Wheezy release.
* There's an *unofficial* port being made for for RaspberryPi (raspbian.org) ARMv6 hardfloat enabled for this (forward compatible with armhf). To support this better in future, would need additional support in HWCAPS to indicate which instructions are used in this binary/can be used on this hardware. Could use ELF headers for similar info for binaries. And corresponding info in package control file so dpkg can do something sensible (i.e. stop you installing v7 binaries on v6/v5 hardware.
* Starting early ground work for ARMv8 port.
* No omapdrm support in Debian due to "insane" use of 3.2 kernel for Wheezy
Ubuntu
* Ubuntu 12.04 LTS released (3.2 kernel). Main ARM support is armhf (v7 hardfloat).
* armel port used to be v7 soft-float, but is now slowly being downgraded from v7 to v5t. May be deprecated altogether in the future.
* Quantal (12.10) will likely use Linux 3.5 kernel
* LLVM built code not correct for armhf; under investigation.
* janimo officially volunteered (by infinity) to resolve issues around Mono.
* Starting early ground work for ARMv8 port.
General / actions
As all the distros are going to be working on bootstrapping ARMv8, plan to keep using the cross-distro list for discussion of issues. Linaro will host a bug tracker to help people share work better.
[ACTION] SteveMcIntyre to get BTS going
Steve's major Ruby issue on ARM (reported widely, see http://bugs.debian.org/652674 for details) is resolved. Now we can rely on getcontext/setcontext support in glibc, rather than on Ruby's (broken) internal implementation from Ruby v1.9+. Re-enable the test suites now!
[ACTION] Enumerate disabled testsuites across all distros and get them re-enabled
More regular cross-distro meetings (monthly conf call) considered useful.
[ACTION] SteveMcIntyre to chase down DaveRusling about reviving cross-distro meetings.
Cheers,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
cross-distro mailing list cross-distro@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro
On 06/07/2012 02:05 PM, Peter Robinson wrote:
On Thu, Jun 7, 2012 at 6:09 PM, Steve McIntyre
- "We suck" - Jon Masters
I actually disagree with that sentiment strongly. We have over 11K source packages built on ARM with not that much difference between x86 and ARM. We have java, eclipse and a number of other complex package stacks built and working across a number of devices. We have gnome with touch working. I don't see that we're much worse than others and I think we've made a lot of progress, of course there's a lot more work to do but we're certainly getting there.
WARNING: Humor Alert. I hope it's not necessary to point out, but clearly I did not actually mean that we really "suck". It was a silly comment taken out of context that we left on the etherpad for giggles.
Jon.
On Thu, Jun 07, 2012 at 06:43:23PM -0400, Jon Masters wrote:
On 06/07/2012 02:05 PM, Peter Robinson wrote:
On Thu, Jun 7, 2012 at 6:09 PM, Steve McIntyre
- "We suck" - Jon Masters
I actually disagree with that sentiment strongly. We have over 11K source packages built on ARM with not that much difference between x86 and ARM. We have java, eclipse and a number of other complex package stacks built and working across a number of devices. We have gnome with touch working. I don't see that we're much worse than others and I think we've made a lot of progress, of course there's a lot more work to do but we're certainly getting there.
WARNING: Humor Alert. I hope it's not necessary to point out, but clearly I did not actually mean that we really "suck". It was a silly comment taken out of context that we left on the etherpad for giggles.
Ack, Apologies, should have taken that out. Without the context of the folks at the Connect session it's not very meaningful.
/me blames this ^$$%^$ jetlag.
Cheers,
On 06/07/2012 02:05 PM, Peter Robinson wrote:
On Thu, Jun 7, 2012 at 6:09 PM, Steve McIntyre
Fedora
Fedora 17 has been released for primary platforms, but not for ARM yet. Still some remaining work.
- OMAP4 "doesn't work" (crashes), likely due to reliance on pure
upstream OMAP support rather than TI branches. Other distros have used TI patches.
It now works fine. It's a bug in the CONFIG_OMAP4_ERRATA_I688 that arrived in the 3.3 kernel. Disabled that and it now works fine.
Right. It was interesting, that we turn out to be almost the only folks using an upstream kernel. I talked with some TI folks about how to get better upstream-only testing with configs like Fedora. Let's followup on that. This might be a config issue, but hopefully we can get some others to help test configs and find this kind of thing more quickly.
- Might be more similar issues around other SoCs that lack support in
upstream kernel.
The SoC's we support (omap, tegra, imx, kirkwood, highbank and vexpress) all work fine with a few minor patches to fix build issues and bugs. Most of the patches are just a few lines.
Indeed. But the point is still there. Lots of other folks are using non-upstream trees as their source, which is a difference, and so we wanted to convey that Fedora is taking a different (and I think ultimately the right one, but I'm biased) approach.
Jon.
On 08.06.2012, at 00:48, Jon Masters wrote:
On 06/07/2012 02:05 PM, Peter Robinson wrote:
On Thu, Jun 7, 2012 at 6:09 PM, Steve McIntyre
Fedora
Fedora 17 has been released for primary platforms, but not for ARM yet. Still some remaining work.
- OMAP4 "doesn't work" (crashes), likely due to reliance on pure
upstream OMAP support rather than TI branches. Other distros have used TI patches.
It now works fine. It's a bug in the CONFIG_OMAP4_ERRATA_I688 that arrived in the 3.3 kernel. Disabled that and it now works fine.
Right. It was interesting, that we turn out to be almost the only folks using an upstream kernel. I talked with some TI folks about how to get better upstream-only testing with configs like Fedora. Let's followup on that. This might be a config issue, but hopefully we can get some others to help test configs and find this kind of thing more quickly.
- Might be more similar issues around other SoCs that lack support in
upstream kernel.
The SoC's we support (omap, tegra, imx, kirkwood, highbank and vexpress) all work fine with a few minor patches to fix build issues and bugs. Most of the patches are just a few lines.
Indeed. But the point is still there. Lots of other folks are using non-upstream trees as their source, which is a difference, and so we wanted to convey that Fedora is taking a different (and I think ultimately the right one, but I'm biased) approach.
Not sure I agree here. OpenSUSE is 100% upstream - the only place we have Linaro (read: non-upstream) code around is for u-boot on omap, and that will be replaced by the upstream versions soon enough.
IIUC Debian is pretty heavy on their upstream only policies too.
So that leaves only Ubuntu as major distro out there. And we all know that they ship whatever kernels they see fit :).
Alex
On 06/07/2012 07:11 PM, Alexander Graf wrote:
On 08.06.2012, at 00:48, Jon Masters wrote:
On 06/07/2012 02:05 PM, Peter Robinson wrote:
On Thu, Jun 7, 2012 at 6:09 PM, Steve McIntyre
Fedora
Fedora 17 has been released for primary platforms, but not for ARM yet. Still some remaining work.
- OMAP4 "doesn't work" (crashes), likely due to reliance on pure
upstream OMAP support rather than TI branches. Other distros have used TI patches.
It now works fine. It's a bug in the CONFIG_OMAP4_ERRATA_I688 that arrived in the 3.3 kernel. Disabled that and it now works fine.
Right. It was interesting, that we turn out to be almost the only folks using an upstream kernel. I talked with some TI folks about how to get better upstream-only testing with configs like Fedora. Let's followup on that. This might be a config issue, but hopefully we can get some others to help test configs and find this kind of thing more quickly.
- Might be more similar issues around other SoCs that lack support in
upstream kernel.
The SoC's we support (omap, tegra, imx, kirkwood, highbank and vexpress) all work fine with a few minor patches to fix build issues and bugs. Most of the patches are just a few lines.
Indeed. But the point is still there. Lots of other folks are using non-upstream trees as their source, which is a difference, and so we wanted to convey that Fedora is taking a different (and I think ultimately the right one, but I'm biased) approach.
Not sure I agree here. OpenSUSE is 100% upstream
Good to know. I don't want to make this about distro X or Y (even on cross-disto!) but more about the notion. It's clear that there is some difference in opinion and usage and I think the main thing I want to convey is that this is a reality. So it's not a "blame" thing, it's just that there's a difference in approach and more than I thought was the case some of the sub-trees are getting more direct use out there.
Again, it all feeds back into getting stuff tested with non-defconfig.
Jon.
Hello,
2012/6/8 Alexander Graf agraf@suse.de:
On 08.06.2012, at 00:48, Jon Masters wrote:
Indeed. But the point is still there. Lots of other folks are using non-upstream trees as their source, which is a difference, and so we wanted to convey that Fedora is taking a different (and I think ultimately the right one, but I'm biased) approach.
Not sure I agree here. OpenSUSE is 100% upstream - the only place we have Linaro (read: non-upstream) code around is for u-boot on omap, and that will be replaced by the upstream versions soon enough.
IIUC Debian is pretty heavy on their upstream only policies too.
I can confirm Debian uses upstream kernels with back ported features. But the ARM SoC support in upstream linux kernels could improve, as most ARM SoC lack features that you can find in out of tree kernels.
Regards,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 8 Jun 2012 12:43:09 +0200 Hector Oron hector.oron@gmail.com escribió:
Hello,
2012/6/8 Alexander Graf agraf@suse.de:
On 08.06.2012, at 00:48, Jon Masters wrote:
Indeed. But the point is still there. Lots of other folks are using non-upstream trees as their source, which is a difference, and so we wanted to convey that Fedora is taking a different (and I think ultimately the right one, but I'm biased) approach.
Not sure I agree here. OpenSUSE is 100% upstream - the only place we have Linaro (read: non-upstream) code around is for u-boot on omap, and that will be replaced by the upstream versions soon enough.
IIUC Debian is pretty heavy on their upstream only policies too.
I can confirm Debian uses upstream kernels with back ported features. But the ARM SoC support in upstream linux kernels could improve, as most ARM SoC lack features that you can find in out of tree kernels.
Right, i would love to support a framebuffer on the trimslice, as well as the genesi smartbook and smarttop. but right now there is no drivers in the upstream kernels. so while they would make great developer devices where they could run all there usual tools. and use them as a development workstation. today you can really only use them as shell boxes to do remote work. hopefully tegradrm makes it upstream soon and we will be able to have the trimslice fully functional. i know that the genesi hardware is further behind in development of good drivers that could go upstream.
How can we as the cross distribution community help the vendors make sure that their devices are fully supported in linus's tree? other than communicating with the vendors, i think the best way is to make sure that we all only use the mainline linus kernel and work with the vendors to get their patches through the sub-system trees and up into linus's tree. calxeda are doing a pretty good job of making sure that the patches get upstream. Im not convinced any other vendor is.
It is my belief that working upstream is the only way to be successful long term. It is healthy to have some distro competition as it challenges us to improve and be better. ultimately fragmentation will only hurt us all. I would strongly encourage all distros to do better at getting there work upstream. I know that ive failed with a couple of patches ive written to fix some build failures in the mainline kernel. mostly they are 1 liners to fix up Kconfig deps.
Dennis
-
Alexander Graf -
Dennis Gilmore -
Hector Oron -
Jon Masters -
Peter Robinson -
Steve McIntyre