Linaro uses Landing Teams to help hardware vendors enable their systems on Linux. The ARM Landing Team is working on enabling the Versatile Express board by upstreaming the bootloader and kernel code. They have bootloader patches accepted and are testing the kernel. The rootfs is working with minimal tuning. The team will also look to enable the DS-5 toolchain and support new ARM architectures.
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
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!
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
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
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.
