-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 07/09/10 16:39, Loïc Minier wrote:

   * 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

Loic, did you mean to say that it's _easy_ to backport it or _not easy_?

Thanks Zygmunt

• 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_build... 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-bounces@lists.linaro.org [mailto:linaro-dev- bounces@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.