(Probably informal) The toolchain is available in Ubuntu and Linaro Android, and as an community option in a range of other build systems. Discuss Yocto support.

Give an overview of what is currently being done for Android toolchain benchmarking in Linaro. Discuss future enhancements we should look into. Agenda: * explain what I currently do each month * discuss some of the short-comings * discuss some of the future ideas we have and get other ideas on what we should do to improve this Goals: * decide what areas we should focus on related to android toolchain benchmarking going forward * get an idea of the effort required * does Andy have the time to do this on his own

We're planning to support KVM on A15. This session is to discuss the QEMU parts of this. It's engineering-focused and QEMU-focused (the more general discussion and aspects which cut across different Linaro and external teams will be done in a different session).

Afternoon engineering and hacking session for Member Services

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Discussion of ARM SOC upstream process, what's working, what's not, what needs to be changed. Etherpad @ http://summit.linaro.org/uds-p/meeting/19256/linaro-kernel-arm-soc-process/

In this session we will talk about device tree on Android. Description ------------------ Linaro has a goal of creating a single runtime image that can run across SoC hardware. The Android team is supporting this effort by using a common Linaro Android tree as a base for all our trees and working to unify all the SoC trees into one. Once unification is done, device tree will allow us to re-factor basic support that was once compile time configurable into runtime configurable options. Having this support on Android early will help us towards this goal and ensure that our kernels can boot as device tree becomes more widespread. Linaro Kernel WG and OCTO have worked on getting Device Tree support accepted into the mainline kernel, and initial support for all recent member SoCs is available. Ubuntu images are already using Device Tree; the next logical step is to make Device Tree be used by default in Linaro's Android LEBs. This feature requires improvements to the Linaro Android builds to enable production of binary flattened device trees as part of the platform build. Also required is updating installation tools and u-boot to ensure that the FDT is used during the boot process as needed. Additional fixes in Android-specific kernel and driver code may be required. Acceptance Criteria ------------------------------- 1. LEB Android builds come with u-boot and kernel that have device tree support enabled 2. LEB Android builds include appropriate flattened device tree in the 'boot' artifact 3. Installing LEB images using linaro-android-media-create will yield an image with device tree being used by u-boot and kernel See https://linaro.papyrs.com/page/4112/ANDROID2011-FDT-LEB for the original description. Agenda ------------ TBD Goal of this Session ----------------------------- To brainstorm and generate concrete work items for landing device tree in all LEBs.

Howto

Right now, we're just using a single server, and deploying packages that line up with our monthly releases. As LAVA is quickly growing and becoming more and more important in Linaro, we should explore how to make it more scalable and how we can support a more agile cycle of development, testing, and deployment of lava components. Session Notes: Current performance is "decent" * LMC uses flock to serialize runs - ACTION: investigate doing this on a ramdisk - Offloading this to another machine that is not handling other dispatcher activities would be better - offload jenkins too - main host should just be for interactive things Celery needed to help us spawn workers - maybe can Using the cloud - some worker tasks with low transfer requirements could be used right away if we have anything like that - eventually, deploying web server nodes, database, etc to cloud would be possible, and keeping dispatcher local - use juju for easy deployment Measurements - collectd is running, but not terribly useful - database transactions/min would be useful - google analytics type hit rate counter - ACTION: investigate graphite and statsd - sentry monitoring for django apps - should we run in canonical datacenter for things other than the dispatcher? - deployment might be an issue there - submitting RTs for changes - could we experiment with running some secondary staging server there ACTION: Launchpad has a script that measures how long transactions run for. This should help us avoid making db transactions that take too long Postgres schema migrations are disruptive, distributed postgres might have issues with this many processes have to talk to the database (scheduler, dashboard,..) could they talk through the queue web server performance (responsiveness) database performance System load (with a notification) - investigate using nagios or new relic for this Memory/swap usage uwsgi has a feature to let you know and/or take action if a request takes longer than a given threshold ACTION: Make sure we're making use of this when we do the new deployment ACTION: Does postgres have a slow queries log? Caching * global enablement is not going to work * enable globally for anon users and dropping timeout to a few minutes would be better - measurements first * cache reports at api level * tests are cache aware because they will see the stale data - need to figure out how to turn off by testing * wall clock time is ok to check if this is improving * is there a way to measure cache hit/miss rate? - memcached could probably help measure this Sentry could be used to track lots of different kinds of errors, including deploy failures ACTION: Investigate sentry Zyga: look at getting caching enabled, celery, sentry Michael: statsd/graphite Dave/Paul: other monitoring things

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

In this session we will talk about plans to more effectively parameterize Android builds across kernels, toolchains, compiler flags, etc.

In this session we will talk about automated Android testing. Description ------------------ Before each change is accepted it undergoes premerge testing. The tester, LAVA, runs a set of tests on a test build that contains the change. To get the most out of the test loop, we would like to identify areas of improvement so that faults found in this loop can be efficiently analysed and fixed. Agenda ------------ 1. Introduce what we have and what's happened recently with reviewing, building and testing. 2. Open a discussion on improvements/new features  * What improvements can we make in LAVA  * What improvements can we make in Gerrit  * Speed ups/efficiencies. Goals -------- 1. Discuss new tests 2. Plan for keeping a unit alive in a failed state 3. Plan for bootloader testing (JTAG) 4. Discuss the best way to capture and present test results for developers

In this session we'll talk about the future of Linaro Android and brainstorm ways we can make things better for the platform. Agenda: ICS Android's Pandaboard Build Community unification Phone builds/components RT Linux Android LTS (long-term-support) Single Android image Getting to 48 hour monkey Goals: Have a lively discussion about Linaro's future Android plans Generate ideas for future topics

Placeholder for the first presentation for the NEON Optimization Forum. Mans Rullgard will give a presentation on NEON optimization best practices.

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

In this session we will talk about adding standard Linux developer tools to Android. Description ------------------ To improve the tools available for embedded developers that care about the core platform, kernel and user space code, the Linaro Android Platform team considers it important to provide tools commonly used by low level GNU/Linux developers. We continuously monitor and identify areas where porting and integrating those tools with Android will benefit the overall Android community. Discussion and reviews lead us to believe that focusing on the binary debugging front would be the most useful next step. The first part of this effort will be a research project that reviews debugging tools commonly used by embedded Linux developers, checking for applicability of those use cases to Android. We will also identify equivalent tools or gaps in the offering of the stock AOSP NDK and SDK. Potential candidates taken from pre-discussion that this research project will pay special attention to are: oprofile perf valgrind powerdebug Based on the findings from the effort above, a priority ordered list of tools will be defined and the engineering plan expanded accordingly. Acceptance Criteria ------------------------------- 1. Results of the research project with a significant list of tools for porting are published 2. Debugging tools identified are integrated and available in Linaro Android Images or the NDK See https://linaro.papyrs.com/page/4115/ANDROID2011-DEVTOOLS-1/# for the original description. Agenda ------------ Give a quick overview of what is already there (and what theoretically should be there) Discuss what other tools we need (and what tools are realistic to port) Best way to get there [see rsalveti comment on the BP whiteboard] Goal of this Session ----------------------------- To identify the tools Android needs and brainstorm and generate concrete work items to integrate those tools into Linaro's LEBs.

Planning session for integrating UCM support into PulseAudio.

Session for getting camera header installed for pandaboard - solder experience required, or maybe a experienced volunteer can do it?

The Toolchain WG currently runs an extensive test suite hosted in Michael Hope's personal laboratory. The LAVA team will work with the TCWG team to ensure this setup is migrated, as-is, into the LAVA lab. We will also work to ensure that all the resulting toolchain build and test data gets properly submitted to LAVA, the dashboard providing the facilities needed to allow the Toolchain WG to analyze this data. It is expected that the reporting facilities in the LAVA dashboard will be driven and partly implemented by the Toolchain WG itself using the available extension mechanisms. == Validation lab next steps == We now have the toolchain build system running on boards hosted by validation. What do we do next, such as:  * Start capturing test results using LAVA  * Start regular benchmarks  * Capture benchmarks results using LAVA  * Shift components to Jenkins or LAVA  * Shift the x86 builds first? Every time we have a merge request, we want to test and make sure there are no regressions - They are doing this today on seabright Many tests will fail, they are interested in the delta, not the total failures This runs a test of every commit to the branch 1 test on v7 1 test on v5 (but they don't have v5 hardware so they test on v7 x86, x64 1. create scripts for the test suites that run right now 2. create results parser that will let us get those into lava dashboard - or at least make sure the existing one works 3. poll launchpad, find the merge request we need to pull, create tarball, create job in lava with that tarball location as a parameter (template for this testing that gets filled in) (This could be part of the extension listed below) - For the merge request, we have multiple templates that kick off tests on the different hardware types needed (v7, v5, x86, x86_64) 4. create lava extension for visualizing results and comparing tests to the baseline (merge request should be able to figure out what was HEAD, and we can compare against that) ACTION: mockup needed for visualization ACTION: investigate using the ssh client to run this test in a chroot, they do the 32bit testing on a 64bit machine in a 32bit personality chroot ACTION: zygmunt to see what we can reuse from tarmac - email notification of jobs startig could be done with tarmac also - there should be 2 comments, when starting and when finishing this part and the job is about to be created - also send link to the scheduler job so they can cancel if they see something wrong Hardware considerations: USB Sticks and scheduler support for tagging those machines Do we need swap enabled on those machines? Benchmarking =========== Needs a customized rootfs that is consistant and stripped down - make sure there are no extraneous services running project for building, keeping attachements of the binaries that we built, etc They can submit a branch for pulling a branch they have, pulling it, and building it The resulting artifact can be used in the benchmarking run IMPORTANT: for private tests, we also need to have private scheduler jobs so that the raw output is not public also B we benchmark on a8, a9, and a15 eventually They can build it and point us at the toolchain, or we can build it as part of the run - if we bould it, it should be built and feed into this Next we want to run the benchmark with build parameters some of their benchmarks need to be private because of licensing - and results need to be kept private

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Afternoon of engineering and hacking for Member Services

Profile guided optimisation is where you run a program, collect data on how it actually runs, then use that to make a further optimised build. We'd like to use PGO as a theme in a future quarter but need to investigate PGO and the potential gains first. Discuss.

Currently for every kernel flavour we need the following packages: - kernel-headers-abi - kernel-headers-abi-flavour - kernel-image-abi-flavour - kernel-image-abi-flavour-dbgsym - linux-tools-abi-flavour - linux-tools-common Until we have one single kernel that could support different flavours, we need to support having different packages at our overlay. Common issues we have with the current solution: - DKMS depends on linux-headers/image-generic - How to depend on a common and single headers package - same dependency issue with the debug package This session is about discussin possible ways to fix this long standing issues at the Ubuntu LEB, and future planing on how to properly add new flavors in the future.

Delivering an ARM KVM product - Product definition - Technical project management / leadership - Involved parties - GNU/Linux platforms Kernel pieces - Linux as hypervisor - clocksource - SMP - virtual GIC - virtio? QEMU / qemu-kvm bits - Host ABI - Guest boot process -- boot ROM/kernel+initrd? - Virtio? Continuous integration using Fast Models

Delivering an ARM KVM product - Product definition - Technical project management / leadership - Involved parties - GNU/Linux platforms Kernel pieces - Linux as hypervisor - clocksource - SMP - virtual GIC - virtio? QEMU / qemu-kvm bits - Host ABI - Guest boot process -- boot ROM/kernel+initrd? - Virtio? Continuous integration using Fast Models

Afternoon engineering and hacking sessions for Member Services

Afternoon engineering and hacking sessions for Member Services