• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Linaro and Android Kernel

Linaro and Android Kernel



Copyright by Andy Green

Copyright by Andy Green



Total Views
Views on SlideShare
Embed Views



9 Embeds 1,109

http://asleepfromday.wordpress.com 1096
url_unknown 3
http://translate.googleusercontent.com 2
https://twitter.com 2
http://johncylee.github.io 2
http://webcache.googleusercontent.com 1
http://www.slashdocs.com 1
https://duckduckgo.com 1
https://www.google.com.tw 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Linaro and Android Kernel Linaro and Android Kernel Presentation Transcript

    • Linaro and Android KernelThanks to Matt Hsu and John Lee at 0xlabs, AzureWave and the other organizers for being so kind as to invite me
    • Linaro and Android Kernel 1. What is Linaro 2. Android kernel patches and Linaro 3. Angry BirdsAndy Green, TI Landing Team Lead, Linaro With thanks to John Stultz at Linaro
    • Linaro and Android 1. What is Linaro 2. Android kernel patches and Linaro 3. ARM Wrestling with Angry BirdsAndy Green, TI Landing Team Lead, Linaro With thanks to John Stultz at Linaro
    • Andy GreenHardware, software and SoC design for 25 years; FPGAearly adopter in 1989; wrote HTML5 libwebsocketsWorked as kernel maintainer at Openmoko with manypeople now at 0xlabs; architected txtr e-book readerTexas Instruments Landing Team Leader at LinaroMoving to Taiwan in August 2011 with my familyMy wife is progressing learning 中國語言I am stuck at 好, know a little にほんご though
    • Part 1: What is Linaro?
    • Part 1: What is Linaro?
    • StructurePaid for by its members“Not for profit” - money is spent on engineers andengineering“Core” members get a director on the board andrepresentatives on the “Technical Steering Committee”Three engineering sections:Working groupsPlatform engineeringLanding Teams
    • Working GroupsSpecialist teams focused on doing difficult tasks insidetheir domainKernel – eg, pushing Device Tree, Thumb2 kernelToolchain – eg, advanced gcc workPower Management – eg, idle state latency improvement,dynamic CPU multicore hotplugGraphics / Multimedia – eg, OpenGLES 2 compiz, prepareupcoming ARM GPUs kernel frameworkshttp://status.linaro.org
    • Landing TeamsWork closely with vendorsThree person team from Linaro works with vendorassigneesCooperate to get stuff upstream and in Nicolas Pitreslinux-linaro treeI lead the TI Landing Team, work with TI folks in Nice,France, and Bangalore, IndiaOMAP4 Panda and OMAP5 stuff shortly
    • ManpowerStarted with engineers from Canonical last yearContract EngineersEmployeesMember AssigneesOver 100 engineers now in totalSome big names like Nicolas Pitre
    • Linaro GoalsAgree common problems with the vendors and try tosolve them directly, or be the basis of wider solutionsSome problems cant be solved by one vendorSome problems might otherwise not be solved byvolunteersSome problems require a funded, stable, trustedorganization to lead the way to the solution
    • Linaro GoalsAgree common problems with the vendors and try tosolve them directly, or be the basis of wider solutionsSome problems cant be solved by one vendorSome problems might otherwise not be solved byvolunteersSome problems require a funded, stable, trustedorganization to lead the way to the solution *
    • Part 2: Android Kernel patches & Linaro
    • Android becoming ubiquitousAll the SoC vendors are quite clear Android is veryimportant for themMany of the vendors customers are quite clear Androidis very important to themExcepting a certain Finnish phone company recently for somereasonLinaro already engages with Android and has Androidexperts on boardAndroid is really “a Linux distro”
    • The whole Android “distro”Linux KernelAndroid Kernel PatchsetSpecial minimal libc – BionicOther librariesThe Dalvik VMApplication FrameworksApps themselves
    • Just going to cover Android kernelLinux KernelAndroid Kernel PatchsetSpecial minimal libc – BionicOther librariesThe Dalvik VMApplication FrameworksApps themselves
    • Android Kernel Patches Overview All features that mainline does not offer, or improvements
    • Android Kernel Patches scope 1 / 6AshmemAndroid Shared Memory, allows naming allocated memory andhaving it visible between multiple processes/dev/ashmem device node tracks usage count on the namedmemory blocksUnder memory pressure, kernel can free blocks with no currentusersBinderRPC scheme like CORBA
    • Android Kernel Patches scope 2 / 6PmemAllows userspace to map a given range of contiguous physicaladdressUsed for userland talking to DSPs and similar that cannottolerate scatter-gatherLoggerAndroids kernel logging, supports four logging buffers “main”,“events”, “radio”, and “system”Userland can read from the files down /dev/log/...
    • Android Kernel Patches scope 3 / 6Early SuspendAllows userland to coordinate a staged suspend action of fourlevelsFrom most awake to suspended, it first allows screen to beblanked, then stop access to the framebuffer, then turn off theframebuffer / crtc, and lastly stop all non-wake input devicesWakelocksAllow userland to veto either low power state (eg, stop CPUClock) and / or entry to suspend; a few kernel places need touse this too – ie, covering pending timers in input device driver
    • Android Kernel Patches scope 4 / 6Alarm TimerDeal with tracking elapsed time while in suspendSchedule wakeups from RTC alarm while CPU completely OFF;kernel already allows some of thisLow Memory KillerMore proactive and cooperative version of existing OOM KillerParanoid NetworkRestricts certain network operations to processes with magicgroup IDs
    • Android Kernel Patches scope 5 / 6RAM ConsoleDebugging helper similar to EARLY_PRINTK but buffering veryearly messages to RAM, good for silently dying bootApanicPanic handler tries to write the panic dump to flash where it canbe recovered the next bootADB Gadget DriverUSB Gadget driver enables debugger operations from host PC –also able to listen on a network interface
    • Android Kernel Patches scope 6 / 6Timed GPIOAdds a period capability to generic GPIO, allowing primitives like“set this high for 50ms”“Other”Small hacks and fixes for ARM, MMC, Bluetooth etc
    • Android Kernel Patches~250 patches for 2.6.38, 3.3MBytes of patchesRelatively thin layer of improvements over mainline,adding features that are not otherwise supported“Hey this OS is working great, lets send those patchesupstream!”Submitted Jan 2009
    • Lkml vs Android Patches threadsemails 1000 Use DBUS! Use OOM Killer! 500 Binder LowMem Killer Alarm Ashmem 0
    • Lkml vs Android Patches threadsemails 2000 1000 wakelock Binder LowMem Killer Alarm Ashmem 0
    • Lkml vs Google 2009 experience Proposed patchsets: 13 Accepted: 0
    • Not Invented HerePolitical, cultural and practical problems dealing with alarge after-the-fact patchbombGoogle just wanted their patches accepted since theywere shipping insane volumes already; stopped caringand got on with their job out of treeAs a compromise a copy of the Google patches (notproposed by Google itself) allowed in stagingSome folks tried to work with kernel process but thepatches were removed from staging in 2.6.33
    • Lkml vs Google 2010 experience
    • Limited re-engagement with lkmlAfter two years of rejection and stalled progress thereare real commits from @android.com in mainlineOver 100, > 50 from 2011But these are not the 13 critical patchsetsOut-of-tree model works well enoughWakelock impact on drivers makes practical difficultyworking on drivers at both mainline and Android thoughEveryone would be happier if they were all in mainline
    • Now Invented Hereruntime_pm apis added to kernel to do similar job towakelock by Rafael Wysocki; design at least influenced bywakelock discussionGregKH, who removed android stuff from staging, writeson his blog 23rd March that android drivers using this nativeimplementation are now welcomehttp://www.kroah.com/log/linux/android-wakelock-solution.htmlCompetes with existing Google implementation, political aswell as technical decision for Google; how to transition?Unclear if runtime_pm is full wakelock replacement
    • SummaryGoogle felt their contribution should have been taken inmainline based on awesome Android volume successand high quality results there.lkml felt targeted by a fait accompli that did not considerwider kernel architecture issues outside of phone caseIf Google had included lkml in the loop to start with theyprobably get easier ride, but lkml does not follow theirschedule
    • Linaro and the patchsetControversy about some elements of the patchesovershadowed good fixes and improvements“Trivial Tree” established; fixes split out in topic branchesand offered upstream by John Stultz from LinaroDifficulties defending the patches as third-party;uplevelling all the topic branches while out-of-tree issignificant effortJohn also working on mainline Posix Alarm Timers thatmay cover Android Alarm Timer functionality
    • Linaro Android PlatformUpstream-focused ARM Android Community gettingstartedLinaro toolchain packages for AndroidCloud-based build servicesARM board farm for automated testing, validation andbenchmarkingIntegration point for member SoC platform codeBased on linux-linaro tree from Nicolas Pitre
    • Linaro Android PlatformInstallable images and public code for low-cost Linaromember SoC boardsCombines latest public AOSP platform code with latestLinaro kernel and toolchain, plus member SoC platformcodeMonthly releases#linaro-android on Freenode IRC *
    • Part 3: Angry Birds
    • Linus, Sep 1998To Theodore Tsos complaints about lost patches... “...Quite frankly, this particular discussion (and others before it) has just made me irritable, and is ADDING pressure. Instead, Id suggest that if you have a complaint about how I handle patches, you think about what I end up having to deal with for five minutes. Go away, people. Or at least dont Cc me any more. Im not interested, Im taking a vacation, and I dont want to hear about it any more. In short, get the hell out of my mailbox. http://lkml.indiana.edu/hypermail/linux/kernel/9809.3/0850.html
    • AnalysisSymptom of overload due to successThis was before bitkeeper and later git, the amount ofmanual work was too high - “think about what I end uphaving to deal with”With awesome tools like git, Linus was able to do muchmore with the same effort and “scaled well”Able to keep up with the ecosystem and Linux hasgrown for another 12 years since then
    • Linus, June 2010I got a bit frustrated with ten different ARM pulls per day at one point.Theres something wrong with ARM development. The amount ofpure noise in the patches is incredibly annoying. Right now, ARM isalready (despite me not reacting to some of the flood) 55% of allarch/ changes since 2.6.34, and its all pointless churn in arch/arm/configs/ arch/arm/mach-xyz arch/arm/plat-blahand at a certain point in the merge window I simply could not find it in me to care about it any more. http://lwn.net/Articles/392135/
    • Linus sees ARM arch overloading himARM architecture is growing stronglyBit chaotic because outside the core ARM CPUs, it isvery diverse indeedRandom peripheral unit macrocells get implementedalongside custom DSP, custom interconnect, customIPC hardwareSame peripheral unit may be wired on different buses ondifferent SoC, need “glue layer” like MUSB
    • Platform layerRMK brings order to the chaos with “platform layer”A platform is, eg, OMAP2+ for later TI chips, imx forFreescale, etc, combining commonality as much aspossible and offering “just works” core code for chipsThere are more specific mach- files for boards that usesome or all the platform features plus extra support forother chips on the board“pointless churn... arch/arm/plat... arch/arm/mach...” per-board config in “arch/arm/configs”
    • How the ARM SoC world worksARM SoC vendors license CPU Core from ARMCheaper, quicker, more certain, better tool / OSecosystem than proprietary... and patentsSo how to differentiate?Pile on specialized integrated peripheral unitsTalk up special process sauce, eg, smartreflex biasingSell companion chips with special sauce (eg, OMAP4 vs twl6030PMIC and twl6040 audio)Twl6030 and CPU talk on dedicated serial link for voltage scaling
    • Interversion changed files peak 1700 Files changed in arch/arm 1800 1600 1400 1200 1000 files 800 600 400 200 0 V2.6.14 V2.6.18 V2.6.22 V2.6.26 V2.6.30 V2.6.34 V2.6.12 V2.6.16 V2.6.20 V2.6.24 V2.6.28 V2.6.32 V2.6.36 Source: git diff using linus tree
    • Interversion diffstat peak 250kloc300000250000200000150000 Lines - Lines +10000050000 0 V2.6.14 V2.6.18 V2.6.22 V2.6.26 V2.6.30 V2.6.34 V2.6.12 V2.6.16 V2.6.20 V2.6.24 V2.6.28 V2.6.32 V2.6.36 Source: git diff using linus tree
    • Why Linus is a bit stressed
    • 500 pull / version endurance limit Linus pulls 2.6.26 thru 2.6.35 2500 2000 1500 Patches total Pulls / Patches Patches direct Pulls Total 1000 Pulls in MW 500 0 “2.6.27” “2.6.29” “2.6.31” “2.6.33” “2.6.35” “2.6.26” “2.6.28” “2.6.30” “2.6.32” “2.6.34” version Data Source: http://lwn.net/Articles/393694/
    • Interversion commit count stable at ~11K 14000 12000 10000 8000 Commits 6000 4000 2000 0 v2.6.26 v2.6.27 v2.6.28 v2.6.29 v2.6.30 v2.6.31 v2.6.32 v2.6.33 v2.6.34 v2.6.35 v2.6.36 v2.6.37 Source: eg, git log v2.6.26..v2.6.27 --oneline | wc -l
    • Linus, March 2011Gaah. Guys, this whole ARM thing is a f*cking pain in the ass.You need to stop stepping on each others toes. There is no way that your changes to thosecrazy clock-data files should constantly result in those annoying conflicts, just becausedifferent people in different ARM trees do some masturbatory renaming of some randomdevice. Seriously.That usb_musb_init() thing in arch/arm/mach-omap2/usb-musb.c also seems to be totallyinsane. I wonder what kind of insanity Im missing just because I dont happen to see the mergeconflicts, just because people were lucky enough to happen to not touch the same file within afew lines.Somebody needs to get a grip in the ARM community. I do want to do these merges, just tosee how screwed up things are, but guys, this is just ridiculous. The pure amount of crazychurn is annoying in itself, but when I then get these "independent" pull requests from fourdifferent people, and they touch the same files, that indicates that something is wrong.
    • Linus, March 2011 (continued)And stop the crazy renaming already! Just leave it off. Dont rename boards anddrivers "just because", at least not when there clearly are clashes. Theres no point.Im not even talking about the file renames (which happened and can also make it"fun" to try to resolve the conflicts when somebody else then makes _other_changes), but about the stupid "change human-readable names in board files just toannoy whoever needs to merge the crap".Somebody in the ARM community really needs to step up and tell people to stopdicking around.(Im replying to the omap pull request, because thats the one I did last, but I dontknow who to "blame". I dont care. It really doesnt matter. I realize thar ARMvendors do crazy shit and havent figured out this whole "platform" thing yet, butyou guys need to push back on the people sending you crap). https://lkml.org/lkml/2011/3/17/492
    • AnalysisOverload handling merge conflicts between ARM arch treesRenames and missed common code opportunities are “crap”Asking for more management in ARM worldSubsequently made it clear he doesnt think Russell King(ARM Linux maintainer) is the problemBig crisis for ARM world, boss guy is raging but individualmaintainers unable to react aloneLOT of people dependent on flow to mainline...
    • Difficulty with MUSB – 1 / 5Linus complained about MUSB, what is it, whats theproblem?MUSB is Mentors USB OTG hardware IPMUSB is a good case study of general issueMentor sell hardware design tools including macrocellsUsing someone elses tested CPU core has advantages:same goes for someone elses tested USB OTGimplementation
    • MUSB peripheral unit generic view – 2/5
    • Devil in the details – 3 / 5
    • Led to Generic driver + SoC glue – 4 / 5MUSB Macrocell driver down drivers/usb/musb/Also set of “glue layer” files for SoCs to take care of themessy and different implementation details, eg,blackfin.c, omap4230.c etcFor example, if power interrupts are coming from adifferent chip, must be set up and enabled by that driver,not MUSB driver, despite MUSB controls the interruptSeems to be “not liked” but hardware realities canmandate this kind of setup
    • Limits of discoverability – 5 / 5AMBA bus used to hook up peripheral units on ARMSoC is more lightweight than PCI or USBProbing memory with no unit leads to death by busexception, so we have to know what we have alreadyConnectivity width is NOT a property the peripheral unitcan declare, its defined outside the unit itselfOMAP has hwmod “registry”, DT wants to claim that turfMaybe Linus will end up improving or at least impactingfuture SoC composition visibility
    • Unable to react: business as usual linux-next churn post-Linus rant From dirstat 80 Posted by 70 RMK Apr 14 60 50 percentage 40 Percentage 30 20 10 0 arch/arm arch/m68k arch/mips arch/x86 ? arch http://lists.infradead.org/pipermail/linux-arm-kernel/ 2011-April/048133.html
    • Xilinx blocked from mainlineRussell King - ARM Linux linux at arm.linux.org.ukMon Apr 18 13:18:57 EDT 2011Im very sorry for people with new platforms outstanding like John Linnwho are on the sharp end of this (who have platform code ready to go)but I see no solution at the moment. It really is the case that eitherI can say no to it, or I can put it in my tree and Linus will say no toit. So putting it in my tree *doesnt* help.Will we ever be able to put Johns code in the kernel? Honestly, I haveno idea.http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/048553.html
    • You are going on a dietLinus Torvalds torvalds at linux-foundation.orgMon Apr 18 12:23:51 EDT 2011Hint for anybody on the arm list: look at the dirstat that rmk posted,and if your "arch/arm/{mach,plat}-xyzzy" shows up a lot, its quitepossible that I wont be pulling your tree unless the reason it showsup a lot is because it has a lot of code removed.People need to realize that the endless amounts of new pointlessplatform code is a problem, and since my only recourse is to say "ifyou dont seem to try to make an effort to fix it, I wont pull fromyou", that is what Ill eventually be doing.Exactly when I reach that point, I dont know.http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/048543.html
    • Linaro working to form a solutionLinaro has “good offices” and good people that can helpwith a solution for all ARM SoC vendorsEg, Thomas Gleixner, Arnd Bergmann, Nicolas PitreWell placed to help form a solutionLinaro in contact with all the main participants these lastweeks*
    • Thanks for listening http://status.linaro.org