> * which devices do we need to cover? > * beagleboard -- would probably work in QEMU > * google nexus one > * should probably cover vexpress and imx51 babbage
FYI, we have a guy in ARM who created patches to run Android on ARM realView platforms using upstream linux kernel or Catalin's kernel tree (ARM AEL) - i.e. the patches are the diff between the upstream tree and Google's trees + a few patches for ARM platforms. Our goal was to get a unified kernel for linux AEL and Android. More information on http://www.linux-arm.org/LinuxKernel/LinuxAndroidPlatform#Patching_and_building_the_kernel We need to do the same thing on a more recent version of the kernel (2.6.35 - against Linaro's tree) Guillaume > -----Original Message----- > From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev- > boun...@lists.linaro.org] On Behalf Of Loïc Minier > Sent: 07 September 2010 15:40 > To: Linaro Dev > Cc: Vandervennet Yves-R55763 > Subject: Notes on Android call 2010/09/07 > > Hi > > == Attendees == > > * Scott Bambrough > * Loïc Minier > * Yves Vandervennet > > == Minutes == > > * build and provide a downloadable Android toolchain > * base it on our toolchain as soon as possible > * provide a Linaro Android distribution, with a set of git trees for > Android components > * should use the Google trees when we don't modify them > * could use either a set of mirrored trees, or only host modified > trees, not sure which option is best; the former allows changing > the base URL from the start (at the time of repo init), the latter > would mean changing the URL at the time of repo sync > * need a build infrastructure > * need a way for people using the Linaro output to replicate the > build infrastructure for daily builds, Hudson would probably do > * wont be able to watch multiple git repos with hudson > * need a kernel tree > * want a consolidated linux-linaro-android tree, just like > linux-linaro > * should track at least the Android kernel tree > * can't target Android development tree because it's not public > * do we want to rebase on newer linux kernels, i.e. newer than > Android provides? > * main use case would be the devicetree stuff; that one is > really > easy to backport, so might not be a good idea to move Android > forward > * Freescale's needs are mostly on the multimedia side, with the > OpenCore framework in particular, since it seems like a poor fit for > hardware accelerators > * mostly interested in basing on a regular Android build, and trying > to swap OpenCore with something else, or integrate existing stuff > into OpenCore > * are there some needs with current architecture which need to > complete > * SMP safety of bionic library; might be a good topic > * hard-float? NEON? is this well supported in Android? probably > just in isolated places, in isolated libraries > * dalvik would probably break with hard-float > * what kind of licensing constraints should we operated under? > * Freescale didn't get any pushback on GPL stuff from OEMs so far; > at > least not on u-boot > * are there needs to extend the Android architecture to cover new type > of hardware in upcoming SoCs? e.g. new type of hardware > accelerators > or something like that? > * apparently, not that much in the pipe; everything seems covered by > Android already > * are TSCMs interested mostly looking at phones or tablets? > * mostly tables and not phones in the case of Freescale > * what's more important? improving the runtime or improving the > development experience and services? > * a faster build would be nice; that is, compilation is really slow > * the overall process is too long between the time where people > start > cloning and the time they have builds > * could improve source code overlays > * could provide pre-built Android parts > * could provide infrastructure to fork source trees into multiple > projects and do fast server-side builds > * not clear how the development experience would look like with > remote builds; would help in download and build time, but might be > clumsy > * can use adb with local builds to push modified files directly > * which devices do we need to cover? > * beagleboard -- would probably work in QEMU > * google nexus one > * should probably cover vexpress and imx51 babbage > * should we do intel builds? might not be a good idea for an ARM > group :-) Freescale didn't need to do any Intel builds at least > * main advantage is that they work on more hardware and so support > more devices etc. > * should enable more people to build for their devices rather than > doing it all ourselves > * strong desire to see the Android kernel patches upstreamed > * performance is probably the biggest thing which vendors care about, > not infrastructure or features; in particular boot time and power > management and execution speed > * middleware > * web browser > * accelerated rendering: leveraging the GPU for page rendering > * telephony > * graphics stack > * should probably explore with other vendors and TSCMs, especially > company selling *phones* with android > * improving the Android architecture is more of a topic for later > > Cheers, > -- > Loïc Minier > > _______________________________________________ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
