Hi all
Given the intention of Linaro seems to be improved Linux support for new and upcoming hardware, how would an individual dev who might be wanting to contribute acquire suitable hardware? Is there any hardware being targeted which is currently on the market (e.g. BeagleBoard type systems)? Or are emulators the intended development platform?
I have previous experience in embedded systems work and was the original author of the SPCA50x driver for Linux USB webcams. I have also worked on vxWorks ports and embedded JVM technology but I currently have a full time job I'm not planning on leaving (Greencard application) and would have to be a hobbyist contributor - it isn't clear if the Linaro project has scope for such due to the hardware issue. This I see as the main differentiation between the Ubuntu development and Linaro.
Thoughts?
Thanks
Joel
Hi,
On Thu, Jun 03, 2010 at 05:21:21PM -0500, Joel Crisp wrote:
Hi all
Given the intention of Linaro seems to be improved Linux support for new and upcoming hardware, how would an individual dev who might be wanting to contribute acquire suitable hardware? Is there any hardware being targeted which is currently on the market (e.g. BeagleBoard type systems)? Or are emulators the intended development platform?
There are a few things that are important to recognize. While Linaro is ment to ease the TTM for new boards and ensure that the software stack gets consolidated in a way that future hardware can be supported much more easily, we also want to use real hardware that exists now, so that developers and community like you can get their hands on something that is more than just a boring emulator.
Hence, while we are working on all the kernel, bootloader consolidation and tools support that would allow much faster enablement of new hardware, we had to pick some development platform(s) that are easily available to the community at a decent price.
Obviously there were not many modern armv7 boards available that matched those criteria, which made the choice quiet easy. So for now (as you rightly guessed) we start with beagle support, but will adopt new platforms as they become available and as their mainlining moves forward.
I have previous experience in embedded systems work and was the original author of the SPCA50x driver for Linux USB webcams. I have also worked on vxWorks ports and embedded JVM technology but I currently have a full time job I'm not planning on leaving (Greencard application) and would have to be a hobbyist contributor - it isn't clear if the Linaro project has scope for such due to the hardware issue. This I see as the main differentiation between the Ubuntu development and Linaro.
Thoughts?
How about you checking with our kernel folks in #linaro on irc.freenode.net and see where you can start contributing help?
- Alexander
On Thu, Jun 03, 2010, Joel Crisp wrote:
Is there any hardware being targetedwhich is currently on the market (e.g. BeagleBoard type systems)? Or are emulators the intended development platform?
Yes and yes, Alexander mentionned beagleboard and virtualization is supported. For QEMU, we currently have bits to emulate versatile, and we also look forward at having a fully working OMAP emulation; it seems to work alright with a n900 target, but not so well on beagle right now (Matt Waddel is doing a tremendous job at fixing this issue ATM).
Loïc Minier wrote:
Yes and yes, Alexander mentionned beagleboard and virtualization is supported. For QEMU, we currently have bits to emulate versatile, and we also look forward at having a fully working OMAP emulation; it seems to work alright with a n900 target, but not so well on beagle right now (Matt Waddel is doing a tremendous job at fixing this issue ATM).
Various CodeSourcery folks have a lot of experience with ARM QEMU. If there are things that we can do to improve QEMU in the context of Linaro, we're happy to do so!
On Fri, Jun 04, 2010, Mark Mitchell wrote:
Various CodeSourcery folks have a lot of experience with ARM QEMU. If there are things that we can do to improve QEMU in the context of Linaro, we're happy to do so!
There are tons of things which could be done on the QEMU front indeed!
We should coordinate things with Matt Waddel since he has been working a lot on this in the last weeks, to avoid work duplication. I Cc:ed him explicitly so that he monitors the thread. In fact, I expect him to have a better list of TODOs than mine.
a) qemu-maemo/-meego, beagleboard fixes
Matt has been working on top of the qemu-maemo/qemu-meego branches which provide beagleboard support; this branch has recently started being upstreamed by cmchao@gmail.com on the qemu-devel@ list. It would be nice to get the support patches in QEMU proper as to get the full beagleboard/n900 support in distros.
Matt produced some nice fixes for beagles when faced with the Ubuntu linux-ti-omap kernel, which has a bunch of things turned on exposing some QEMU bugs. Ideally, we'd be able to boot stock OMAP images from Angstrom, Ubuntu etc. in QEMU, but that currently fails in various places ATM.
b) buildd setup
Fast ARM hardware is not very widely available yet, which makes it hard to build things like native builds farms. It's also expensive and hard to maintain such a farm. Finally, some companies might not be happy to use the hardware from a competitor to run their build farm.
Using QEMU in a buildd setup on top of Intel hardware makes sense to address these issues. However, it's hard to find platforms which are both well supported in QEMU and well supported in the upstream kernel. Currently, Ubuntu provides versatile kernels to use with QEMU, patched ot run v7. This is a bit limitative and it's very slow too. Versatile is an old board, and has limitations around memory support (no sparse memory, the platform didn't support much RAM etc.).
It would be great to have a fully featured and more recent board, perhaps a realview one, or an omap3 one.
One thing which would probably boost performance significantly would be to add virtio support to ARM. It would allow for much faster disk and network I/O for sure.
c) support for more platforms
It might make sense to support more platforms and hardware to e.g. automate testing of binary images, kernels, or just to develop new features while the hardware stabilizes (allowing software development to start before hardware is available). This is more blue sky stuff, but having support for e.g. imx53 or OMAP4 would be awesome, but it seems out of reach unfortunately.
d) random features / bugs
* Would be great if we could easily run x86 binaries when running qemu-system-arm under x86 (this is possible in syscall emulation mode already)
* mono hangs when installed under QEMU ATM
* more syscalls / better emulation in syscall emulation mode
...
Hi Mark,
It's nice to hear from you. I wondered if our paths would cross again after m68knommu at Freescale.
On 06/04/2010 02:30 PM, Loïc Minier wrote:
On Fri, Jun 04, 2010, Mark Mitchell wrote:
Various CodeSourcery folks have a lot of experience with ARM QEMU. If there are things that we can do to improve QEMU in the context of Linaro, we're happy to do so!
There are tons of things which could be done on the QEMU front indeed!
We should coordinate things with Matt Waddel since he has been working a lot on this in the last weeks, to avoid work duplication. I Cc:ed him explicitly so that he monitors the thread. In fact, I expect him to have a better list of TODOs than mine.
a) qemu-maemo/-meego, beagleboard fixes
Matt has been working on top of the qemu-maemo/qemu-meego branches which provide beagleboard support; this branch has recently started being upstreamed by cmchao@gmail.com on the qemu-devel@ list. It would be nice to get the support patches in QEMU proper as to get the full beagleboard/n900 support in distros.
Matt produced some nice fixes for beagles when faced with the Ubuntu linux-ti-omap kernel, which has a bunch of things turned on exposing some QEMU bugs. Ideally, we'd be able to boot stock OMAP images from Angstrom, Ubuntu etc. in QEMU, but that currently fails in various places ATM.
Loïc summed things up pretty nicely. I have been chipping away at the bugs for a while now. It seems like qemu supports a single boot path and as soon as something changes a whole new set of bugs pop-up. I have been trying to get a stock beagleboard configuration to boot using the Linaro 1005 Release parts. I am using the qemu version at:
git://gitorious.org/qemu-maemo/qemu.git
I was building a kernel from scratch, but have switched over to using the parts from the 1005 release at:
https://image-share.canonical.com/linaro/10.05/
I just basically create a large image file and divide it into a small vfat partition and a larger ext3 partition. Right now all of the parts in the small vfat partition work (ie. - x-loader, u-boot.bin, kernel, and initrd). It's failing when init tries to switch to the real rootfs.
My goal here is to come up with a "build" system which will create an image that can be booted on real hardware or qemu without any modifications. (I think I am minutes and 1 bug away from success, but I've thought that before.)
b) buildd setup
Fast ARM hardware is not very widely available yet, which makes it hard to build things like native builds farms. It's also expensive and hard to maintain such a farm. Finally, some companies might not be happy to use the hardware from a competitor to run their build farm.
Using QEMU in a buildd setup on top of Intel hardware makes sense to address these issues. However, it's hard to find platforms which are both well supported in QEMU and well supported in the upstream kernel. Currently, Ubuntu provides versatile kernels to use with QEMU, patched ot run v7. This is a bit limitative and it's very slow too. Versatile is an old board, and has limitations around memory support (no sparse memory, the platform didn't support much RAM etc.).
It would be great to have a fully featured and more recent board, perhaps a realview one, or an omap3 one.
One thing which would probably boost performance significantly would be to add virtio support to ARM. It would allow for much faster disk and network I/O for sure.
I was going to start investigating virtio support for qemu as soon as I had a good beagleboard system going. However, if you have any thoughts on this it would be good to hear them.
c) support for more platforms
It might make sense to support more platforms and hardware to e.g. automate testing of binary images, kernels, or just to develop new features while the hardware stabilizes (allowing software development to start before hardware is available). This is more blue sky stuff, but having support for e.g. imx53 or OMAP4 would be awesome, but it seems out of reach unfortunately.
Supporting various TI platforms seems reasonable at this point. I'm not sure how difficult Freescale platforms would be. In my opinion it was easier to fix missing u-boot features than it was to fix kernel problems. The rootfs shouldn't make a difference between the various platforms once it is working.
I guess the thing to do is build the default configs in u-boot and the kernel and try them. We might be surprised.
Let me know if you need more information. (I see CodeSourcery copyright notices in a lot of qemu code so you all probably know a lot more about this stuff than I do, but I'm more than willing to help where I can.)
Best regards, Matt
d) random features / bugs
Would be great if we could easily run x86 binaries when running qemu-system-arm under x86 (this is possible in syscall emulation mode already)
mono hangs when installed under QEMU ATM
more syscalls / better emulation in syscall emulation mode
...
Matt Waddel wrote:
It's nice to hear from you.
You as well!
Let me know if you need more information. (I see CodeSourcery copyright notices in a lot of qemu code so you all probably know a lot more about this stuff than I do, but I'm more than willing to help where I can.)
I have never worked on QEMU, so, from a technical perspective, I don't know a lot. But, as a company, we've done a lot -- for example, the ARMv6 and ARMv7 support comes from CodeSourcery, and from Paul Brook in particular. I know that we did provide a version of QEMU that would boot standard Linux kernel images from linux.on-arm.com, and that building out more support for more virtual boards is definitely something we're capable of doing. As you suggest, we use QEMU internally for testing, in addition to physical hardware.
I will forward your email to Andrew and Julian, who are our initial Linaro people. We are working now on defining a workplan for the rest of the year, and I thinking putting some QEMU activity on that would likely make a lot of sense.
Thanks!
On Fri, Jun 4, 2010 at 3:30 PM, Loïc Minier loic.minier@linaro.org wrote:
On Fri, Jun 04, 2010, Mark Mitchell wrote:
Various CodeSourcery folks have a lot of experience with ARM QEMU. If there are things that we can do to improve QEMU in the context of Linaro, we're happy to do so!
There are tons of things which could be done on the QEMU front indeed!
We should coordinate things with Matt Waddel since he has been working a lot on this in the last weeks, to avoid work duplication. I Cc:ed him explicitly so that he monitors the thread. In fact, I expect him to have a better list of TODOs than mine.
a) qemu-maemo/-meego, beagleboard fixes
Matt has been working on top of the qemu-maemo/qemu-meego branches which provide beagleboard support; this branch has recently started being upstreamed by cmchao@gmail.com on the qemu-devel@ list. It would be nice to get the support patches in QEMU proper as to get the full beagleboard/n900 support in distros.
Matt produced some nice fixes for beagles when faced with the Ubuntu linux-ti-omap kernel, which has a bunch of things turned on exposing some QEMU bugs. Ideally, we'd be able to boot stock OMAP images from Angstrom, Ubuntu etc. in QEMU, but that currently fails in various places ATM.
b) buildd setup
Fast ARM hardware is not very widely available yet, which makes it hard to build things like native builds farms. It's also expensive and hard to maintain such a farm. Finally, some companies might not be happy to use the hardware from a competitor to run their build farm.
If it's to any use for you guys...
I do have some of spare ARM cycles to spare to help push this combined ARM tree development work, if your looking for daily native build testing.....
I am in the middle of adding 3 more new omap3 based nodes to my current build farm of 4 arm boards. (figure 1 a week-end, this is definitely in my spare time..)
I currently have 1 BeagleBoard and 1 Sheevaplug dedicated to building kernels for my customers, and these are currently idling about 50%ish of the time during the week..
http://rcn-ee.homeip.net:81/dl/farm/log/
And then I have another 2 Omap3 boards currently setup to do non-stop gcc trunk bootstrap and testsuite..
http://rcn-ee.homeip.net:81/dl/gcc/
My biggest problem is lack of bandwidth on my cable modem, so giving out of ssh access is pointless. But it would work fine as a build bot controlled thru the web...
For reference, the slowest node in my system (500MHz 256MB Omap3) takes 5-6 hours to build a complete linux kernel with almost every possible module enabled...
http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.34-l1_1.0-lucid.txt
Regards,
W
Hi Robert
This is an interesting offer, but it seems to be to almost be the wrong way around. AMD, Canonical among others are sponsoring Linaro; wouldn't it make more sense for them to throw a few thousand $ at a build farm somewhere and provide a work queue for that so that Linaro contributors could do farm based build and test? In terms of their daily expenditure it would be barely background noise. Provide some logins and some resource quotas, a few tens of JTAG connected boards of different types with a variety of peripherals rigged up and you have something sensible for development. After all, this initiative should ensure that they sell thousands more boards in the future. They should also be able to add samples of new product to the farm before general release.
Thoughts?
Joel
If it's to any use for you guys...
I do have some of spare ARM cycles to spare to help push this combined ARM tree development work, if your looking for daily native build testing.....
I am in the middle of adding 3 more new omap3 based nodes to my current build farm of 4 arm boards. (figure 1 a week-end, this is definitely in my spare time..)
I currently have 1 BeagleBoard and 1 Sheevaplug dedicated to building kernels for my customers, and these are currently idling about 50%ish of the time during the week..
http://rcn-ee.homeip.net:81/dl/farm/log/
And then I have another 2 Omap3 boards currently setup to do non-stop gcc trunk bootstrap and testsuite..
http://rcn-ee.homeip.net:81/dl/gcc/
My biggest problem is lack of bandwidth on my cable modem, so giving out of ssh access is pointless. But it would work fine as a build bot controlled thru the web...
For reference, the slowest node in my system (500MHz 256MB Omap3) takes 5-6 hours to build a complete linux kernel with almost every possible module enabled...
http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.34-l1_1.0-lucid.txt
Regards,
-- Robert Nelson http://www.rcn-ee.com/
Linaro-dev mailing list Linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 10-06-05 03:59 PM, Joel Crisp wrote:
W
Hi Robert
This is an interesting offer, but it seems to be to almost be the wrong way around. AMD, Canonical among others are sponsoring Linaro; wouldn't it make more sense for them to throw a few thousand $ at a build farm somewhere and provide a work queue for that so that Linaro contributors could do farm based build and test? In terms of their daily expenditure it would be barely background noise. Provide some logins and some resource quotas, a few tens of JTAG connected boards of different types with a variety of peripherals rigged up and you have something sensible for development. After all, this initiative should ensure that they sell thousands more boards in the future. They should also be able to add samples of new product to the farm before general release.
Thoughts?
Joel
If it's to any use for you guys... I do have some of spare ARM cycles to spare to help push this combined ARM tree development work, if your looking for daily native build testing..... I am in the middle of adding 3 more new omap3 based nodes to my current build farm of 4 arm boards. (figure 1 a week-end, this is definitely in my spare time..) I currently have 1 BeagleBoard and 1 Sheevaplug dedicated to building kernels for my customers, and these are currently idling about 50%ish of the time during the week.. http://rcn-ee.homeip.net:81/dl/farm/log/ And then I have another 2 Omap3 boards currently setup to do non-stop gcc trunk bootstrap and testsuite.. http://rcn-ee.homeip.net:81/dl/gcc/ My biggest problem is lack of bandwidth on my cable modem, so giving out of ssh access is pointless. But it would work fine as a build bot controlled thru the web... For reference, the slowest node in my system (500MHz 256MB Omap3) takes 5-6 hours to build a complete linux kernel with almost every possible module enabled... http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.34-l1_1.0-lucid.txt Regards, -- Robert Nelson http://www.rcn-ee.com/ _______________________________________________ Linaro-dev mailing list Linaro-dev@lists.linaro.org <mailto:Linaro-dev@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-dev
I might be missing something, but why do we need an ARM-based build farm to start with? What's wrong with setting up a bunch of cross-compilers tuned up for the different CPUs and use x86 machines to build ARM kernels? Finding spare x86 cycles shouldn't be a problem at all.
With time, resources, and hardware availability we could have an ARM-only build farm, but I don't see that as a mandatory stage to go through at this moment.
I would personally like as one of the outputs of the Linaro community to standardize on a process to build ARM cross-compilers.
On 10-06-05 06:38 PM, Pedro I. Sanchez wrote:
On 10-06-05 03:59 PM, Joel Crisp wrote:
W
Hi Robert
This is an interesting offer, but it seems to be to almost be the wrong way around. AMD, Canonical among others are sponsoring Linaro; wouldn't it make more sense for them to throw a few thousand $ at a build farm somewhere and provide a work queue for that so that Linaro contributors could do farm based build and test? In terms of their daily expenditure it would be barely background noise. Provide some logins and some resource quotas, a few tens of JTAG connected boards of different types with a variety of peripherals rigged up and you have something sensible for development. After all, this initiative should ensure that they sell thousands more boards in the future. They should also be able to add samples of new product to the farm before general release.
Thoughts?
Joel
If it's to any use for you guys... I do have some of spare ARM cycles to spare to help push this combined ARM tree development work, if your looking for daily native build testing..... I am in the middle of adding 3 more new omap3 based nodes to my current build farm of 4 arm boards. (figure 1 a week-end, this is definitely in my spare time..) I currently have 1 BeagleBoard and 1 Sheevaplug dedicated to building kernels for my customers, and these are currently idling about 50%ish of the time during the week.. http://rcn-ee.homeip.net:81/dl/farm/log/ And then I have another 2 Omap3 boards currently setup to do non-stop gcc trunk bootstrap and testsuite.. http://rcn-ee.homeip.net:81/dl/gcc/ My biggest problem is lack of bandwidth on my cable modem, so giving out of ssh access is pointless. But it would work fine as a build bot controlled thru the web... For reference, the slowest node in my system (500MHz 256MB Omap3) takes 5-6 hours to build a complete linux kernel with almost every possible module enabled... http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.34-l1_1.0-lucid.txt Regards, -- Robert Nelson http://www.rcn-ee.com/ _______________________________________________ Linaro-dev mailing list Linaro-dev@lists.linaro.org<mailto:Linaro-dev@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-devI might be missing something, but why do we need an ARM-based build farm to start with? What's wrong with setting up a bunch of cross-compilers tuned up for the different CPUs and use x86 machines to build ARM kernels? Finding spare x86 cycles shouldn't be a problem at all.
With time, resources, and hardware availability we could have an ARM-only build farm, but I don't see that as a mandatory stage to go through at this moment.
I would personally like as one of the outputs of the Linaro community to standardize on a process to build ARM cross-compilers.
Would it not make more sense to simply standardize on a readily available toolchain such as CodeSourcery's Lite ARM toolchain?
On 10-06-05 09:51 PM, Bill Traynor wrote:
On 10-06-05 06:38 PM, Pedro I. Sanchez wrote:
On 10-06-05 03:59 PM, Joel Crisp wrote:
W
Hi Robert
This is an interesting offer, but it seems to be to almost be the wrong way around. AMD, Canonical among others are sponsoring Linaro; wouldn't it make more sense for them to throw a few thousand $ at a build farm somewhere and provide a work queue for that so that Linaro contributors could do farm based build and test? In terms of their daily expenditure it would be barely background noise. Provide some logins and some resource quotas, a few tens of JTAG connected boards of different types with a variety of peripherals rigged up and you have something sensible for development. After all, this initiative should ensure that they sell thousands more boards in the future. They should also be able to add samples of new product to the farm before general release.
Thoughts?
Joel
If it's to any use for you guys... I do have some of spare ARM cycles to spare to help push this combined ARM tree development work, if your looking for daily native build testing..... I am in the middle of adding 3 more new omap3 based nodes to my current build farm of 4 arm boards. (figure 1 a week-end, this is definitely in my spare time..) I currently have 1 BeagleBoard and 1 Sheevaplug dedicated to building kernels for my customers, and these are currently idling about 50%ish of the time during the week.. http://rcn-ee.homeip.net:81/dl/farm/log/ And then I have another 2 Omap3 boards currently setup to do non-stop gcc trunk bootstrap and testsuite.. http://rcn-ee.homeip.net:81/dl/gcc/ My biggest problem is lack of bandwidth on my cable modem, so giving out of ssh access is pointless. But it would work fine as a build bot controlled thru the web... For reference, the slowest node in my system (500MHz 256MB Omap3) takes 5-6 hours to build a complete linux kernel with almost every possible module enabled... http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.34-l1_1.0-lucid.txt Regards, -- Robert Nelson http://www.rcn-ee.com/ _______________________________________________ Linaro-dev mailing list Linaro-dev@lists.linaro.org<mailto:Linaro-dev@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-devI might be missing something, but why do we need an ARM-based build farm to start with? What's wrong with setting up a bunch of cross-compilers tuned up for the different CPUs and use x86 machines to build ARM kernels? Finding spare x86 cycles shouldn't be a problem at all.
With time, resources, and hardware availability we could have an ARM-only build farm, but I don't see that as a mandatory stage to go through at this moment.
I would personally like as one of the outputs of the Linaro community to standardize on a process to build ARM cross-compilers.
Would it not make more sense to simply standardize on a readily available toolchain such as CodeSourcery's Lite ARM toolchain?
I used the plural form "cross-compilers" meaning any cross. Certainly, standardizing on one, backed up with a proper free/open source license, and with the support of a strong development community, would be ideal.
I personally use CodeSourcery and crosstool-ng for my ARM targets. I'm sure we all have our preferences. An output from the Linaro team would be to recommend at least one cross-compiler so that we can all put an effort to make it work well with as many processors as possible.
TTM-wise I consider a cross-compiler to be a vital tool and I'd like it to become a formal entry in Linaro's agenda.
On Sat, Jun 05, 2010, Pedro I. Sanchez wrote:
TTM-wise I consider a cross-compiler to be a vital tool and I'd like it to become a formal entry in Linaro's agenda.
Yes, we're committed to delivering cross-compiler packages as Ubuntu packages: https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-cross-compilers (click Read full spec to see the details)
And since we're trying to merge the CodeSourcery patchset in the Ubuntu ARM toolchain: https://blueprints.launchpad.net/ubuntu/+spec/arm-m-tool-chain-selection this should give a CS-alike cross-compiler as Ubuntu packages.
Bill Traynor wrote:
Would it not make more sense to simply standardize on a readily available toolchain such as CodeSourcery's Lite ARM toolchain?
Excellent suggestion! :-)
CodeSourcery is engaged with Linaro; some CodeSourcery folks are part of the Linaro Toolchain Working Group, and more will be starting in July. That working group will be doing various (yet to be decided) things to improve the toolchains (and oprofile and various other tools), in terms of quality, performance, and features.
The current tentative plan is that we'll start with CodeSourcery's latest Lite Edition release as a starting point for a 4.4-based toolchain. There will almost certainly also be a 4.5-based toolchain (with patches from our 4.4-based toolchain that didn't make FSF 4.5, but also with new functionality developed by Linaro, and with backports of things going into 4.6 that are relevant, whether those originate from CodeSourcery, ARM, or elsewhere).
We'll continue to do Sourcery G++ Lite Edition releases as well, and, of course, those will be tracking improvements from Linaro. Just as CodeSourcery's improvements have always flowed to the FSF tree, we'll now be pushing changes to Linaro as well, and just as we've always merged from the FSF, will now also be merging from Linaro.
Thanks,
On Sat, Jun 05, 2010, Joel Crisp wrote:
This is an interesting offer, but it seems to be to almost be the wrong way around. AMD, Canonical among others are sponsoring Linaro
(AMD?)
wouldn't it makemore sense for them to throw a few thousand $ at a build farm somewhere and provide a work queue for that so that Linaro contributors could do farm based build and test?
It's not good enough unfortunately; that's the way I thought we should approach the problem as well in the past, but it turns out that large companies don't like to rely on external resources/services. They are big enough that they feel their process should be self-hosted. I also thought they could build the same build farm as we would, but then you start meeting with the sensibilities/policitical issues around using hardware from a competitor to run your own build farm.
-
Alexander Sack -
Bill Traynor -
Joel Crisp -
Loïc Minier -
Mark Mitchell -
Matt Waddel -
Pedro I. Sanchez -
Robert Nelson