Welcome to Linaro Developer Technical Support (LDTS)

Stay updated with announcements or find answers to commonly asked questions. Submit a request or send us an email at support@linaro.org. Linaro - The future of Linux on ARM

 

LDTS

Viswanath Puttagunta August 13, 2013 Linaro FAQ's & Knowledgebase

Where can I find the Linaro Monthly releases? What does each release consist of?

What is Linaro Engineering Build (LEB)? Who is the primary audience for LEBs?

What is Linaro Member Build (LMB)? Who is the primary audience?

Where are the Linaro Project related bug databases?

Support for Linaro deliverables

 

Where can I find the Linaro Monthly releases? What does each release consist of?

Linaro makes releases on a monthly basis, typically on the last Thursday of every month. The latest release information is always available at http://www.linaro.org/downloads/

The main contents of the release page are the following:

i. Linaro Engineering Builds (LEB)

ii. Linaro Stable Kernel (LSK)

iii. Linaro-GCC toolchain binaries

The rest of the contents on release page are used internally within Linaro. Refer to the corresponding working group’s home page for more information. Please stay tuned for LSK related information. Until we provide more information, refer to notes in http://www.linaro.org/downloads/#tab1 (Release Notes for release)

 

What is Linaro Engineering Build (LEB)? Who is the primary audience for LEBs?

LEB is a full system build of popular open-source products that come with Linaro improvements pre-integrated.

These are the releases that the different working groups inside Linaro use to work on to add new features that are requested by Member Companies via their TSC (Technical Steering Committee) representatives. These new features that the working groups work on get fed back into the LEBs for every Linaro monthly release cycle. So, in summary, the primary audience of the LEBs are the Linaro working groups.

LEBs focus on integrating landing teams and working groups output; those are typically developed against the upstream trunk. Hence, you will find very recent/bleeding-edge kernel versions and other optimizations in user space in the LEBs.

If you need recent hardware enablement on an old kernel version for your product, the LEB is the wrong place to look for it.

The Builds & Baselines team in Linaro is responsible for the LEBs. They work with the different Linaro working groups (responsible for certain feature enablement/improvement) and the Landing team (responsible for the corresponding hardware platform) to make sure that all the different projects being fed into LEBs integrate properly without causing regression, and when they do cause some regression, work with them to resolve the issues before each Linaro Monthly Release.

 

What is Linaro Member Build (LMB)? Who is the primary audience?

LMB is a full system build of popular open-source products. LMBs are set up on specific request of a Linaro Core/Club Member company and the requirements or objectives for each LMB could be different based the corresponding Member Company objective.

The Linaro Builds & Baseline team initially helps with the Core/Club Member company in setting up the LMB, but it is really the responsibility of the Member Company Landing team to decide what features they want in the LMB,  the frequency with which they want to make the releases and what testing needs to be done on the LMB.

Note that the Builds & Baseline team can push back on a particular LMB release, should the LMB release fail to meet very basic requirements of compile and boot. This is to avoid redundant support requests when we know that the release doesn’t work at all.

The target audience for the LMB depends on the specific Member Company objectives.

 

Where are the Linaro Project related bug databases?

Working Group Name Bug Repository Comments/Description
Toolchain Working Group - Linaro GCC https://bugs.launchpad.net/gcc-linaro  
Toolchain Working Group - Linaro GDB https://bugs.launchpad.net/gdb-linaro  
Toolchain Working Group - Linaro Binutils https://bugs.launchpad.net/bintuils-linaro  
Toolchain Working Group - Linaro Toolchain Binaries https://bugs.launchpad.net/linaro-toolchain-binaries/  
LAVA https://bugs.launchpad.net/lava this link summarizes all bugs in the individual projects: https://launchpad.net/lava
LAVA Infrastructure https://bugs.launchpad.net/linaro-infrastructure this link summarizes all bugs in the individual projects: https://launchpad.net/linaro-infrastructure
Android https://bugs.launchpad.net/linaro-android  
Graphics - CDF Kernel Mailing list  
Graphics - hwcomposer NA Under initial development, bug system not as of yet identified
Graphics - piglit & waffle https://bugs.freedesktop.org/  
Graphics - HSA https://bugs.launchpad.net/hsa/+filebug  
Graphics - 64 bit graphics stack https://launchpad.net/linaro-aarch64  
Graphics - dma-buf linaro-mm-sig mailing list lists.linaro.org  
Kernel support.linaro.org Don't have any project specific bug repository
B&B: General https://bugs.launchpad.net/linaro-dev-platform List of individual projects can be found in project group: https://launchpad.net/linaro-dev-platform
B&B: Android https://bugs.launchpad.net/linaro-android/+filebug  

B&B: OpenEmbedded

https://bugs.launchpad.net/linaro-oe/+filebug  
Power management - Kernel https://bugs.launchpad.net/linaro-power-kernel We don't always fix platform-specific problems - that is left to the LTs; but we'll definitely be interested in looking at core framework bugs
Power management - Powertop https://bugs.launchpad.net/linaro-powertop  
Power management - Powerdebug https://bugs.launchpad.net/linaro-powerdebug  
Power management - PM-QA test suite https://bugs.launchpad.net/linaro-power-qa  
Power management - Idlestat https://bugs.launchpad.net/linaro-power-idlestat https://launchpad.net/linaro-power is our meta project containing all of these

Support for Linaro deliverables

Linaro Technical Support (LDTS) team is dedicated to support issues and questions associated with Linaro projects and monthly releases.

If you are unable to find the information you need, then you can open an LDTS ticket:

Please note that as a non-profit consortium, Linaro does not have a commercial product set; rather, we are Member funded for Member directed projects and efforts for Linux on ARM. LDTS gives priority to Member tickets and those tickets will be reviewed within 48 hours of submission by an LDTS Support Engineer. If you are from a Linaro Member company, please use your official email address when opening a ticket.

LDTS will work on community (non-Member) tickets on a best effort basis. If you are NOT from a Member Company, please be aware that your request will have a lower priority and will be worked on as time is available by the Support team.

To open a ticket to be viewed by our support team, you can send an email directly to support@linaro.org or

1. Click on “SUBMIT A REQUEST”

2. Your email address:

- Please sure to use your company email address especially if you are from a Linaro Member Company since we prioritize member company tickets over c

ommunity tickets.

- Otherwise you can use any email address, although, we highly recommend you using your company email address even if you are not a Linaro Member.

3. Subject:

- Enter the title of your request that best reflects the question or issue you are querying about.

4. For Description

- Enter a detailed description of the question or issue.

- When reporting an issue, please make sure you specify exact instructions of how to reproduce the issue.

5. Severity Level, Category Assigned

- Select the options that best fits the question or issue and the priority.

Viswanath Puttagunta Feb 05 Linaro FAQ's & Knowledgebase

What are all the components that go into Linaro Toolchain Binaries in monthly releases?

What components does the Toolchain Working Group work on?

What is the relation between GCC Linaro project and mainline (FSF) GCC project?

Where can I get more information about Linaro Toolchain working group?

 

What are all the components that go into Linaro Toolchain Binaries in monthly releases?

The toolchain binary releases consist of: (http://www.linaro.org/downloads/ >> Binaries)

  • crosstool-ng-linaro-*.tar.bz2: Source for the scripts used to build the toolchain binaries
  • gcc-linaro-aarch64-linux-gnu-*src*.tar.bz2: Source for all Aarch64 toolchain components (gcc, binutils, gdb, (e)glibc, ...)
  • gcc-linaro-arm-linux-gnueabihf-*src*.tar.bz2: Source for all ARMv7 toolchain components (gcc, binutils, gdb, (e)glibc, ...)
  • gcc-linaro-aarch64-linux-gnu-*_linux.tar.*: Linux binaries for the Aarch64 Linux cross-toolchain
  • gcc-linaro-aarch64-none-elf-*_linux.tar.*: Linux binaries for the Aarch64 bare-metal cross-toolchain
  • gcc-linaro-arm-linux-gnueabihf-*_linux.tar.*: Linux binaries for the ARMv7 Linux cross-toolchain
  • gcc-linaro-aarch64-linux-gnu-*_win32.*: Windows binaries for the Aarch64 Linux cross-toolchain
  • gcc-linaro-aarch64-none-elf-*_win32.*: Windows binaries for the Aarch64 bare-metal cross-toolchain
  • gcc-linaro-arm-linux-gnueabihf-*_win32.*: Windows binaries for the ARMv7 Linux cross-toolchain
  • gcc-linaro-aarch64-linux-gnu-*_runtime.*: Runtime libraries for Aarch64 Linux
  • gcc-linaro-arm-linux-gnueabihf-*_runtime.*: Runtime libraries for ARMv7 Linux
  • Android cross-toolchain binaries are released separately. Click here.

 

What components does the Toolchain Working Group work on?

Our main focus is the following projects. We work directly with upstream communities: GCC, Binutils, GDB, glibc, LLVM, QEMU

 

What is the relation between GCC Linaro project and mainline (FSF) GCC project?

The Linaro GCC project page is located at https://launchpad.net/gcc-linaro/

As mentioned in above project page, Linaro GCC is performance focused branch of the current GCC stable release and includes backports of the improvements and bug fixes that Linaro and others have done upstream. The project contains backports of work that we and the community have done to improve GCC on ARM.

Also, as Linaro is a not-for-profit company that works with open source, we work towards upstreaming the features we developed on linaro-gcc into mainline GNU GCC project.

 

Where can I get more information about Linaro Toolchain working group?

Home page: https://wiki.linaro.org/WorkingGroups/ToolChain

FAQ page: https://wiki.linaro.org/WorkingGroups/ToolChain/FAQ

Cbuild2 page: https://wiki.linaro.org/Cbuild2

Viswanath Puttagunta Feb 05 Linaro FAQ's & Knowledgebase

What is device tree blob mean? Where can I get more information about Device Tree?

How does the kernel boot process work?

Where can I get more information on configuration and usage of ftrace?

What is System Trace Macrocell?

How does a kernel feature that one of the Linaro Working Group works on typically end up upstream?

Where can I get more information about Linaro Stable Kernel?

What are ARM Architected timers? How do they affect BogoMIPs value?

Where can I get support for Linaro Kernel related questions or issues?

 

What is device tree blob mean? Where can I get more information about Device Tree?

The Device Tree blob is another term used to describe the Device Tree Binary (.dtb) file that results from compiling the Device Tree Source (.dts) file that provides a human readable description of a piece of hardware. For more information on device on using Device Tree, see Documentation/devicetree/usage-model.txt in the Linux kernel sources.

How does the kernel boot process work?

LEB is a full system build of popular open-source products that come with Linaro improvements pre-integrated.

Refer to the documentation in kernel source code at location Documentation/arm/Booting

Where can I get more information on configuration and usage of ftrace?

See Documentation/trace for information on configuring and using ftrace. http://elinux.org/Ftrace also provides some good examples of ftrace usage.

What is System Trace Macrocell?

System Trace Macrocell (STM) is an IP block in some modern ARM SOCs that provides a standard method for capturing debug information across the whole SOC. See http://www.arm.com/products/system-ip/debug-trace/trace-macrocells-... and http://www.mipi.org/specifications/debug for more information.

How does a kernel feature that one of the Linaro Working Group works on typically end up upstream?

Please refer to: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeP... for detailed explanation.

Where can I get more information about Linaro Stable Kernel?

Please refer to: https://wiki.linaro.org/LSK

What are ARM Architected timers? How do they affect BogoMIPs value?

For Cortex A7/CA15, there has been an effort to standardize the timer on a common specification. The CPUs have one generic timer block per CPU. If the architected-timer gets registered before loop calibration, then it will use
lpj_fine = timer->freq/HZ (refer arch/arm/lib/delay.c: register_current_timer_delay()).

Note that the ARM-Architected-timer frequency is independent of CPU frequency. Another thing to note is that the ARM-architected-timer frequency is constant and does not change if CPU frequency changes due to CPU frequency scaling.

Thus, the ARM-Architected-timer is much precise because it is real hardware clock module that has a real clock! Before such support, in previous CPU systems, the lpj (loops_per_jiffy) was calibrated using delay loop. This is both time consuming and inaccurate.

In the past, the bogoMIPS values that is dependent on lpj value used to reflect CPU frequency a little better, but for what actually really mattered, which is the lpj values used in delay loops (eg: udelay()), it was not very accurate. Note that the real purpose of bogomips value was only to calibrate a delay loop. The functions (Eg: udelay() etc) used to depend on the lpj value and used to spin in loops. But now they use ARM-Architected-timer routines in arch/arm/lib/delay.c, which are much more precise.

Now, as for the BogoMIPS value that is printed, after reviewing the code both in /arch/arm/lib/delay.c and /init/calibrate.c, the bogoMIPS value that is getting printed for our systems (Cortex-A7/A15) is
bogoMIPS = lpj / (500000/HZ) but
lpj = lpj_fine = timer->freq/HZ (set in arch/arm/lib/delay.c: register_current_timer_delay())

So, the bogoMIPS values is at present more reflective of the ARM-Architected-timer clock frequency, than it is of the actual CPU frequency. But note that in the end, the important thing is that kernel has better and more precise way of doing delay loops like udelay() etc. So, value that is printed for bogoMIPS is pretty much worthless and should not effect any real performance.

In fact, the printing of bogoMIPS value during boot and it's /proc/cpuinfo entry HAS BEEN REMOVED UPSTREAM (Commit: 9fc2105aeaaf56b0cf75296a84702d0f9e64437b) because people have been complaining that it is confusing. Look at the commit message. It is pretty self-explanatory. Note again that even though loops_per_jiffy is more reflective of of timer frequency than CPU frequency, it should not cause any performance issues.

Further references:
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka...
- http://en.wikipedia.org/wiki/BogoMips

Where can I get support for Linaro Kernel related questions or issues?

Please go to our Linaro Developer Technical questions homepage. (https://support.linaro.org/home) for more information.

Akira Tsukamoto Apr 16 Linaro FAQ's & Knowledgebase

Are the “CPU Migration” and the “big.LITTLE in-kernel-switcher” the same implementation but having two names?

How does the big.LITTLE in-kernel-switcher (big.LITTLE IKS) works inside the kernel?

Where can I get the patch set only for the big.LITTLE IKS?

Where can I get the entire kernel sources which includes the big.LITTLE IKS?

How is the switching decided between the big core and the little core in big.LITTLE IKS?

What is the good place and how to optimize the big.LITTLE IKS for Android?

What is the good place and how to optimize the big.LITTLE IKS on each different SoC in the kernel source?

Is the big.LITTLE IKS going to be merged in the upstream?

If the big.LITTLE IKS going to be merged in the upstream than which kernel version started to have portion and what is the estimation of kernel version when all be merged?

 

Are the “CPU Migration” and the “big.LITTLE in-kernel-switcher” the same implementation but having two names?

Yes, the “CPU Migration” and the “big.LITTLE in-kernel-switcher” are synonym, while “CPU Migration” are used in ARM materials and “big.LITTLE in-kernel-switcher” (aka IKS) are use used in Linaro.

How does the big.LITTLE in-kernel-switcher (big.LITTLE IKS) works inside the kernel?

This has been covered extensively on LWN, presentations and wikis. http://lwn.net/Articles/539840/ http://lwn.net/Articles/481055/ https://wiki.linaro.org/projects/big.LITTLE.MP/Big.Little.Switcher/... https://wiki.linaro.org/projects/big.LITTLE.MP/Big.Little.Switcher/...

Where can I get the patch set only for the big.LITTLE IKS?

This can be found in Nico’s git repository on git.linaro.org in the iks branch: http://git.linaro.org/gitweb?p=people/nico/linux.git;a=shortlog;h=r... However there is no guarantee this branch will stay there since everything has been merged upstream at this point and maintenance of IKS will happen upstream from now on.

Where can I get the entire kernel sources which includes the big.LITTLE IKS?

"Linaro Stable Kernel (LSK)" has the big.LITTLE MP patchset applied. The LSK is a recommended starting point on which to base big.LITTLE products. Refer to "LSK wiki page" for more information. It is also available in the mainline kernel repository from kernel.org since v3.13-rc1.

How is the switching decided between the big core and the little core in big.LITTLE IKS?

The decision is taken at the CPU freq driver level. If the required frequency can't be meet by the current CPU, a request to move to a different core is made to the IKS logic.

This is accomplished via the cpufreq infrastructure. Each A7 + A15 pair is represented by a pseudo CPU with a frequency table corresponding to the combination of both cores. A7 frequencies are virtualized and scaled down to half the actual frequencies to approximate a linear scale across the combined A7 + A15 range. When the requested frequency change crosses the A7-A15 boundary a core switch is invoked.

What is the good place and how to optimize the big.LITTLE IKS for Android?

IKS is a generic solution that isn't tailored to a specific distribution. Tuning is made at the cpufreq governor level.

What is the good place and how to optimize the big.LITTLE IKS on each different SoC in the kernel source?

Each SoC needs its HW specific backend for MCPI, cpufreq and cpu idle. The same MCPM backend is also required for big.LITTLE MP to work as well anyway. A shim driver for cpufreq might also be needed if the generic clock framework is not sufficient to change CPU frequencies. See above wiki links for more details and implementation for vexpress TC2 in the Linaro stable trees for concrete examples.

Is the big.LITTLE IKS going to be merged in the upstream?

This is all merged as of v3.13-rc1.

If the big.LITTLE IKS going to be merged in the upstream than which kernel version started to have portion and what is the estimation of kernel version when all be merged?

This is all merged as of v3.13-rc1.

Viswanath Puttagunta Mar 26 Linaro FAQ's & Knowledgebase

What’s the difference between "Global Task Scheduling" and "big.LITTLE MP"?

How does the big.LITTLE MP patchset work inside the kernel?

How to switch between big.LITTLE in-kernel-switcher(IKS) and Global Task Scheduling(GTS)?

Where can I get the entire kernel sources which include the big.LITTLE MP?

Can I get just the big.LITTLE MP patch set?

How does the kernel scheduler decide which thread should run on the big core or the little core in the big.LITTLE MP patchset?

Is the big.LITTLE MP going to be merged upstream?

If the code isn't upstream what is best way to use big.LITTLE MP for products now?

How do I optimize the big.LITTLE MP patchset for Android?

How do I optimize big.LITTLE MP on my SoC?

 

What’s the difference between "Global Task Scheduling" and "big.LITTLE MP"?

Global task scheduling is the technique of using all cores under control of the scheduler. The big.LITTLE MP patchset is a set of ARM-developed scheduler enhancement that implements the GTS technique.

How does the big.LITTLE MP patchset work inside the kernel?

The big.LITTLE MP patchset works by defining two scheduler 'domains'. One for high performance big cluster, and one for the super efficient LITTLE cluster. The patchset then uses the per-task-load metric to decide which domain to schedule a given task on. All under the intelligent control of the scheduler, requiring no work by the user or application developer. For more information, please contact Linaro at support@linaro.org

How to switch between big.LITTLE in-kernel-switcher(IKS) and Global Task Scheduling(GTS)?

See section "ENABLING THE IKS FUNCTIONALITY" in https://wiki.linaro.org/projects/big.LITTLE.MP/Big.Little.Switcher/...

Where can I get the entire kernel sources which include the big.LITTLE MP?

"Linaro Stable Kernel (LSK)" has the big.LITTLE MP patchset applied. The LSK is a recommended starting point on which to base big.LITTLE products. Refer to "LSK wiki page" for more information

The latest patchset can also be found based on Linux 3.10 kernel at http://git.linaro.org/arm/big.LITTLE/mp.git/shortlog/refs/heads/big...

Can I get just the big.LITTLE MP patch set?

To ease porting to different kernel revisions, Linaro also hosts an isolated package holding just the relevant patches. A link to this can be found linked from the latest LSK download page for ARM TC2 development platform. See the "About the TC2 Engineering Build" section in the release notes at http://releases.linaro.org/latest/android/vexpress-lsk

How does the kernel scheduler decide which thread should run on the big core or the little core in the big.LITTLE MP patchset?

The scheduler maintains a metric for each thread or task which describes how 'big' or 'heavy' it is in terms of CPU requirements. This is called the per-task-load or more correctly the 'load average contribution' and is used by the big.LITTLE MP patchset to decide both when and if a given thread should be migrated between the two types of clusters.

Is the big.LITTLE MP going to be merged upstream?

The MP patchset will not be merged upstream in current form. The implementation is highly optimized for big.LITTLE platforms and needs to be made generic for all users of the Linux scheduler, from mobile to cloud computing platforms. Discussions are currently being held upstream community around how an energy-aware scheduler can be implemented and this will include support for big.LITTLE platforms with GTS.

If the code isn't upstream what is best way to use big.LITTLE MP for products now?

Linaro and ARM recommend the Linaro Stable Kernel as the starting point for big.LITTLE products. This can be found at found at https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=su....

It is worth noting that the patches work unmodified on 64-bit kernels too. This is supported in the 64-bit LSK builds

How do I optimize the big.LITTLE MP patchset for Android?

Android was used by ARM as the development base for the big.LITTLE patchset. There is no additional Android specific tuning required.

How do I optimize big.LITTLE MP on my SoC?

The process of tuning big.LITTLE is much the same as for tuning power management on a non-big.LITTLE platform. The key is to

a) ensure the big cluster is used only when needed by removing spurious wakeups and

b) ensure DVFS is tuned appropriately

Occationally, it may be desirable to tune the migration thresholds (the levels of per-task-load at which threads are chosen to migrate) to meet product specific requirements but this is not a common requirement.

ARM has a tuning guide that they have produced which they provide on request.

Linaro has helped a number of it's members tune their platforms and will be presenting latest status at LCA14 in Macau.