[llvmlinux] Testing Android on LAVA

Tinti viniciustinti at gmail.com
Mon Nov 25 23:32:16 UTC 2013


Just a comment concerning AOSP.

On Mon, Nov 25, 2013 at 9:28 PM, Behan Webster <behanw at converseincode.com>wrote:

> Sorry for the delay. I was away teaching a course last week, and am only
> just catching up now...
> On 11/18/13 09:33, Renato Golin wrote:
> > Hi LAVA folks,
> >
> > I don't know if you guys know, but Android is moving to LLVM for the
> > next release or so. As such, we'll need to do a lot of testing between
> > now and next release to make sure each component can be compiled (and
> > runs correctly) with LLVM on an incremental basis.
> Awesome!
> > We're trying to come up with a way for remotely testing the Linux
> > kernel booting on ARM devices, more specifically an Android stack, and
> > I'm finding it hard to do that with my home equipment. Doing that in
> > LAVA would be ideal, and I know the Android team does it already, but
> > our constraints could be a little different.
> >
> > Basically, there are two fronts:
> >
> > 1. Building Android components with LLVM, using a GCC-compiled kernel
> > booting on an ARM board, in LAVA. This is something we should work
> > internally on how to do it, and it'll be between Android, LAVA and
> > Toolchain groups.
> >
> > 2. Building the Linux kernel with LLVM, and using a GCC-compiled image
> > (like stock CyanogenMod) to test the kernel. We don't have such a
> > kernel (many patches), but the LLVMLinux guys do, and that's where
> > they come in.
> >
> > On the second case, the topic of this email, we'd have to liaise with
> > them to fire jobs at LAVA from their own infrastructure (originally,
> > manually only), and that might need some thinking. But ultimatelly, we
> > want to have those jobs running on LAVA, so that later on we'd be able
> > to have a third layer: Linux+Android built with LLVM with the same
> > system level tests.
> >
> > Since the LLVMLinux guys don't have access to much ARM hardware, and
> > since it's easier for us to scale (or to re-define) hardware
> > requirements, having them running on LAVA makes even more sense.
> >
> > Is this something we can do? Is this being done already? Is this just
> > a question of legal/corporate decision, or is there any technical
> > issues we have to look into?
> We've merely been using CyanogenMod for our (albeit minimal) Android
> testing since it was what supported the Android devices we had to work
> with. Using AOSP would be preferable.
> The issue right now, as I understand it, is that most Android devices
> have their own kernel tree, which often is based on the SoC's vendor
> Android kernel tree, and not mainline, nor the Google Android kernel tree.

AOSP is working to. You just need to follow the same procedure described
at http://llvm.linuxfoundation.org/index.php/Nexus_7 but using AOSP and
ignoring the part that needs to comment the building process. AOSP by
default uses a prebuilt kernel.

> > Android folks,
> >
> > It might make more sense if you guys just grab their kernel and build
> > the Android system based on that internally, so that we don't need
> > external access to job submissions in LAVA, but that would mean work
> > from you guys to patch it up, and that might not be in the roadmap for
> > the next months. Is that a feasible route?
> The LLVMLinux project maintains a set of patches on top of mainline. We
> port to specific kernels for testing purposes, but we don't actually
> have our own project kernel. We do have patches for the original N7
> kernel however.
> I'd suggest we agree to a platform upon which to test, and then the
> patches can be ported to that particular kernel tree.

> Behan
> --
> Behan Webster
> behanw at converseincode.com
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux

Simplicity is the ultimate sophistication
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20131125/a0cf8187/attachment-0001.html>

More information about the LLVMLinux mailing list