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

Support for Linaro deliverables

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

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 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. Because of this and in order to maximize your chances of getting quick responses to your queries please follow these advices:

  1. provide precise and accurate information about the versions that you are running as well as the hardware configuration.
  2. describe the issue concisely and accurately: the more you can tell us about the problem with fewer words, the less time we will need to understand the background; do not be vague.
  3. Provide logs and terminal outputs that may apply to your case - error codes, build failures, kernel logs
  4. Provide a self contained test case if applicable.

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 community 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.

 

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?

Refer to https://bugs.linaro.org/

Viswanath Puttagunta February 5, 2014 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://releases.linaro.org/latest/components/toolchain/binaries)

2014.10 and later releases

  • Under construction

Pre-2014.10 releases

  • 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 Little Endian Aarch64 toolchain components (gcc, binutils, gdb, (e)glibc, newlib, ...)
  • gcc-linaro-aarch64_be-linux-gnu-*src.tar.bz2: Source for all Big Endian Aarch64 toolchain components (gcc, binutils, gdb, (e)glibc, newlib, ...)
  • gcc-linaro-arm-linux-gnueabihf-*src.tar.bz2: Source for Linux Little Endian ARMv7 toolchain components (gcc, binutils, gdb, (e)glibc, ...)
  • gcc-linaro-arm-none-eabi-*src.tar.bz2: Source for bare-metal Little Endian ARMv7 toolchain components (gcc, binutils, gdb, newlib, ...)
  • gcc-linaro-armeb-linux-gnueabihf-*src.tar.bz2: Source for all Big Endian ARMv7 toolchain components (gcc, binutils, gdb, (e)glibc, newlib, ...)
  • gcc-linaro-aarch64-linux-gnu-*_linux.tar.*: Linux 32-bit binaries for the Aarch64 Linux cross-toolchain
  • gcc-linaro-aarch64-none-elf-*_linux.tar.*: Linux 32-bit binaries for the Aarch64 bare-metal cross-toolchain
  • gcc-linaro-arm-linux-gnueabihf-*_linux.tar.*: Linux 32-bit binaries for the ARMv7 Linux cross-toolchain
  • gcc-linaro-arm-none-eabi-*_linux.tar.*: Linux 32-bit binaries for the ARMv7 bare-metal cross-toolchain
  • gcc-linaro-aarch64-linux-gnu-*_win32.*: Windows 32-bit binaries for the Aarch64 Linux cross-toolchain
  • gcc-linaro-aarch64-none-elf-*_win32.*: Windows 32-bit binaries for the Aarch64 bare-metal cross-toolchain
  • gcc-linaro-arm-linux-gnueabihf-*_win32.*: Windows 32-bit binaries for the ARMv7 Linux cross-toolchain
  • gcc-linaro-arm-none-eabi-*_win32.*: Windows 32-bit binaries for the ARMv7 bare-metal 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 (link to Android Toolchain question).

 

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

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

Victor Chong November 13, 2014 Linaro FAQ's & Knowledgebase

What is OP-TEE?

How do I use OP-TEE with ARM TF?

I don’t have a TrustZone integrated board. Can I still test OP-TEE?

Where can I get more information about Security WG OP-TEE?

 

What is OP-TEE?

OP-TEE is an Open Source TEE and is the result of collaboration work between STMicroelectronics and Linaro (Security Working Group). It contains the complete stack from normal world client API's (optee_client), the Linux kernel TEE driver (optee_linuxdriver) and the Trusted OS + the secure monitor (optee_os).

 

How do I use OP-TEE with ARM TF?

Please refer to the guide at https://github.com/OP-TEE/optee_os/blob/master/documentation/arm_trusted_firmware.md.

 

I don’t have a TrustZone integrated board. Can I still test OP-TEE?

Yes, you can use QEMU or the Foundation Model (FVP) HW emulator.

Instructions are at https://github.com/OP-TEE/optee_os/tree/master/scripts.

 

Where can I get more information about Security WG OP-TEE?

https://wiki.linaro.org/WorkingGroups/Security/OP-TEE

Esla Anzaku February 24, 2014 Linaro FAQ's & Knowledgebase

What is LAVA?

How is LAVA generally used?

Where can I find LAVA Documentation?

I am new to LAVA. How can I setup and install LAVA?

I have installed LAVA on a single machine. How can I add LAVA workers?

Where can I find help when I run into problems while using LAVA?

How can I backup/restore a LAVA instance running on a single server?

I want to move my LAVA installation to another server. How can I do this?

 

What is LAVA?

LAVA is an automated validation architecture primarily aimed at testing deployments of systems based around the Linux kernel on ARM devices, specifically ARMv7 and later.

 

How is LAVA generally used?

  • By using the LAVA server at validation.linaro.org

    If a member company wants to run automated tests on their platform(s) but does not want to install LAVA locally, The member talks to Linaro about this, sends their platform to Linaro LAVA engineers, it gets integrated into LAVA and becomes part of the Linaro LAVA lab at validation.linaro.org. Of Course, there is a mechanism within Linaro to grant access rights to the platform to any restricted group of individuals. Some member companies have done this already and their boards are managed by the LAVA lab at Cambridge. This allows the engineers in the member company to focus more on integrating their tests for LAVA to run. The QA team in Linaro is also willing to guide and help with tests integration if the need arises.

  • By installing LAVA locally

    For some valid reasons, some member companies prefer not to send their boards to the Cambridge office, or send only a selected number, but want to use LAVA locally and have full control of it. Anyone can install a LAVA server and manage it as desired

 

Where can I find LAVA Documentation?

  • LAVA main documentation can be found at http://validation.linaro.org/static/docs/
  • For anyone running their local LAVA labs, each installation comes with its documentation. Click on the "Documentation" on the webpage of your LAVA server. It is recommended to follow the documentation that comes along with your installation, since different versions of LAVA might have some differences in their documentations.
  • LAVA wiki page at https://wiki.linaro.org/Platform/LAVA

 

I am new to LAVA. How can I setup/install and use LAVA?

There are two ways LAVA can be installed, depending on the how you intend to use it.

  • If you are interested in connecting few target boards or Devices Under Test (DUT), the a single master installation would be sufficient.
  • If you intend to connect many DUTs or if it is not convenient to connect all the DUTs to a single server, then the distributed instances installation approach would be suitable. In the distributed instances, it  is suggested to use one machine (master) for the web frontend and the master scheduler with separate machines to act as remote worker nodes.

 

I have installed LAVA on a single machine. How can I add LAVA workers?

Here are the recommended steps to follow

  • Backup your LAVA instance
  • In your LAVA master run export LAVA_DB_ALLOWREMOTE=yes lava-deployment-tool upgrade <instance_name>
  • Install the LAVA workers. Don't forget to specify LAVA_MASTER=<master_IP> and LAVA_DB_PASSWORD=<auto-generated> during the installworker stage. Please refer to the question on installing multiple dispatchers for links to the documentation for more information. If you have not set LAVA_DB_PASSWORD, you can find the <auto-generated> password in /srv/lava/instance/<instance_name>/instance.conf
  • The LAVA workers should have the same instance name as the LAVA master

 

Where can I find help when I run into problems while using LAVA?

You may open a ticket on http://support.linaro.org or report bugs on https://bugs.launchpad.net/lava. You may also  join the #linaro-lava channel on IRC to ask your questions.

 

How can I backup/restore a LAVA instance running on a single server?

Please refer to http://validation.linaro.org/static/docs/deployment-tool.html#backi...

 

I want to move my LAVA installation to another server. How can I do this?

We assume that you want to move your LAVA instance from Server-A to Server-B, and you have installed a LAVA instance on Server-B

  • Stop and backup the LAVA instance running on Server-A. The snapshot of the backup is located at /srv/lava/backups/<instance_name>/
  • Copy the snapshot to /srv/lava/backups/<instance_name>/ on Server-B. If there has not been any backup carried out on Server-B before you may have to create the /srv/lava/backups directory first.
  • On Server-B restore the copied snapshot by running a command like: lava-deployment-too restore <instance_name> snapshot_id

WARNING: Information in the database of server-B would be lost.

 

How does the LAVA Lab at Cambridge manage the installation, upgrade, deployment of devices, e.t.c.?

The LAVA lab uses Salt to manage the LAVA master and LAVA workers' configurations. Please refer to https://docs.google.com/a/linaro.org/document/d/1ug4VtJ4sy8qsWcyy9s... for a summarized description of how this is done

Viswanath Puttagunta February 5, 2014 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.