Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Viewers also liked (20)
Similar to Overview of Landing Teams and ARM's Work
Similar to Overview of Landing Teams and ARM's Work (20)
Recently uploaded
Recently uploaded (20)
Overview of Landing Teams and ARM's Work
- 1. An Overview of Landing Teams inside Linaro Jamie Bennett, Release Manager Linaro.org
- 2. Schedule • Hardware Enablement • What is a Landing Team? • ARM’s Landing Team
- 3. Schedule • Hardware Enablement • What is a Landing Team? • ARM’s Landing Team
- 4. Hardware Enablement What is Hardware Enablement? “The engineering work involved in preparing a Linux- based software stack to work on a selected hardware platform”
- 5. Hardware Enablement What is Hardware Enablement? • Low-level initialization • Board configuration • Device driver development • Optimization of speed, power consumption • Validation of the integrated changes
- 6. Hardware Enablement What is Hardware Enablement? USB and Basic GFX Basic Linux Kernel Boot Loader Networking Output GFX Multimedia Acceleration Optimization Input/UI Power All Device Enhancement Management Drivers Complete
- 7. Hardware Enablement Upstreaming
- 8. Hardware Enablement Upstreaming • Kernel and tools versions increment every few months • Very tough for silicon partners to keep at leading edge for their SoCs/Dev board BSPs • OEMs and Distros increasingly wanting latest features, performance and stability
- 9. Hardware Enablement Upstreaming • Why Upstream? • Maintenance • Upstream/Community Relations • Free Testing • Problems of Upstreaming • Patch Author, Project Maintainer expectations • Potential long patch iterations • Significant communications • Upstream is a moving target!
- 10. Hardware Enablement Upstreaming • Buffer between constantly changing upstream and a stable platform • Decouples upstream from hardware enablement • System wide verification • Controlled Test verification • Its what all distributions do • Stable Target!
- 11. Hardware Enablement Staged Upstreaming • Buffer between constantly changing upstream and a stable platform • Decouples upstream from hardware enablement • System wide verification • Controlled Test verification • Its what all distributions do • Stable Target!
- 12. Schedule • Hardware Enablement • What is a Landing Team? • ARM’s Landing Team
- 13. Landing Teams • Where do Landing Teams fit in Linaro?
- 14. Landing Teams • What are Landing Teams? • Each Silicon Vendor gets one Landing Team • A Landing Team comprises of: • 1 Technical Liaison Engineer (a conduit between the vendor and Linaro) • 1 Project Manager • Number of Engineers depending of effort required to enable vendor hardware
- 15. Landing Teams • What do Landing Teams do? • Analyze any current board support patches • Integrate patches into Linaro vendor specific trees • Build kernel and vendor packages against the Linaro toolchain • Generate minimal images for validation • Fix any problems arising from this effort
- 16. Landing Teams • What do Landing Teams do (cont)? • Vendor specified Images (netbook, handset, ...) • Submission of vendor patches into the official Linaro trees (maintenance hand-off) • Drive upstream patch submission from vendors • Vendor specific toolchain optimizations and experimentations • Handle proprietary code • Project Manage
- 17. Landing Teams • What do Landing Teams need? • Hardware, hardware, hardware, hardware, ... • Vendor patches • Vendor specific software packages • Vendor engineering effort
- 18. Schedule • Hardware Enablement • What is a Landing Team? • ARM’s Landing Team
- 19. ARM’s Landing Team Initial area’s of Interest • Versatile Express • DS-5 Toolchain • New architecture development
- 20. ARM’s Landing Team Versatile Express current status • Bootloader • Kernel • rootfs • everything else
- 21. ARM’s Landing Team Versatile Express current status (1/4) • Bootloader • Refactored patches based on initial work done by Peter Pearse sent upstream 28th July • Matt Waddel leading the work • Initial upstream comments are favourable.
- 22. ARM’s Landing Team Versatile Express current status (2/4) • Kernel • All work being done by ARM engineers and being pushed upstream. ARM doing a perfect job. • Matt Waddel testing output • LTP tests being run • Frame buffer bug being worked on
- 23. ARM’s Landing Team Versatile Express current status (3/4) • rootfs • minimal and netbook rootfs both work with minimal tuning • Image building planned
- 24. ARM’s Landing Team Versatile Express current status (4/4) • Everything else • Hardware debugger support • gdb currently has some issues • QEMU support required?
- 25. ARM’s Landing Team DS-5 Toolchain • Nothing planned as of yet • Requirements need defining to determine the optimum landing team size • Great candidate for a more wide-spread distribution effort to gain exposure and help open source development
- 26. ARM’s Landing Team New architecture development • Landing teams can support features of up coming hardware • Can be shared at ARM’s discretion; Linaro understand the need to keep pre-announcement hardware private for a time • Requirements need defining
Editor's Notes
- 3 key area’s I want to talk about * Firstly the act of hardware enablement and what that involves * Secondly I’d like to talk a little about what a Landing Team actually is * And lastly about what ARM’s Landing team could be focusing on and to get input from you guys on exactly what Linaro should be doing for ARM.
- So, hardware enablement
- So heres one definition of what Hardware enablement is. So basically, getting some definition of Linux software running on a selected bit of hardware.
- There are many levels of hardware enablement, from low level initialisation, getting the boot loader working, booting to a kernel, through to getting key device drivers working to take advantage of onboard devices, and then at the top end producing a fully optimized distribution image. Of course validation is also key to any hardware enablement.
- Here we have the typical elements to a Hardware Enablement scenario. At the top, a basic enablement would consist of getting the kernel booting, tailoring the boot loader if necessary, integrating device drivers if they are available and some rudimentary graphics support. That would be an unaccelerated console or maybe as far as an X session which ever is required. Moving on to a more complete enablement scenario, these other elements would have to be worked on. Graphics acceleration is a big one, whether that be with a closed source binary component or something more open. Closely related to that is the multimedia work on codec accelerators, and generally getting media rich content running as smoothly as possible on the silicon. Enhancements for a specific user interface or distribution along with getting other devices running smoothly such as GPS receivers and telephony radios. Power Management is always a concern on mobile device and to truly enable a piece of silicon, this would have to have specific to the hardware.
- A large part of Hardware Enablement within Linaro is Upstreaming. This is the act of getting your code out of local repositories and folding it into the various projects where that could should belong. So for instance, in an ideal world, all vendor specific changes to the kernel really should live in the mainline kernel.
- You may of seen this rather complicated graphic before. Its shameless stolen from one of Dave Ruslings slide and I think cleverly depicts how a Vendor could try to get their in-house code changes into the upstream kernel.
- There are many advantages to upstreaming your code. Theres a maintenance cost to not upstreaming. A vendor has to rebase, back port, forward port and generally do a whole lot of work if their code isn’t maintained by the upstream project itself. Once you get that code upstream, the responsibility for at least making sure that code compiles on future version of the project then lies with the project maintainer. There is a minimal cost to maintaining your code once it is upstream. Getting code accepted upstream and working with the community is great PR. It shows commitment, it show a willingness to collaborate and building these relationships is key to any vendor fully leveraging open source. And of course once your code is upstream, your number of testers automatically increases. A basic compile test will be done on very release. Now getting your code upstream isn’t always easy. Theres often different expectations between the person producing the patch and the project maintainers who are the gate keepers to their upstream projects. This can lead to long iterations as the patches are discussed, comments made and the patch is resubmitted. Its a necessary step as these maintainers are committing to keeping you code working as their project moves forward. As you work more with the upstream projects, this process becomes easier. One other problem is that upstream never stays still, which is especially true for something like the Linux kernel. This can lead you patches quickly becoming out of date which will require work to rebase on the latest version.
- Its what all distributions do: All distributions take upstream code, integrate it into a more stable archive and produce a distribution from this. Buffer: System wide Verification: Known, stable software versions that do not change frequently throughout the enablement process
- Its what all distributions do: All distributions take upstream code, integrate it into a more stable archive and produce a distribution from this. Buffer: System wide Verification: Known, stable software versions that do not change frequently throughout the enablement process
- Most used slide Landing team is a Core Unit within Linaro Works closely with the Platform team to get vendor specific changes into the Linaro release
- Patches must be normalized against an agreed kernel tree, currently for 10.11 this is 2.6.35. There is some leeway for initial engagement. These patches will be integrated first into a vendor specific Linaro kernel tree with the intention of eventually folding this tree into the main Linaro ARM kernel tree once all necessary changes are made and the Linaro kernel maintainer is happy to accept them The vendors kernel will be built using the latest Linaro toolchain to verify that the silicon works with the latest and greatest features and the team is also responsible for producing daily validation images which can be used as a basis for testing.
- After the initial amount of work is done by the landing team and the vendor, there are more steps that can occur. A number of agreed vendor specific images, or heads, can be produced to validate the silicon. This could be a netbook image, say Ubuntu’s Unity or something like a MeeGo handset. As I said before, the landing team works to get the vendor kernel and patches in a suitable state that the official Linaro kernel maintainer will accept them. Once they are in the official Linaro tree, responsibility for the code at least building is up to the Linaro kernel maintainer. From the Linaro kernel tree, these patches will be further worked on to get them into a mainline submittable state. The Landing Team will work with the vendor on doing this but the final push upstream will be done by the vendor themselves.
- Hardware, 1 per enablement engineer and additional hardware for the validation farm. Should be refreshed as new revisions of the hardware become available.