Linaro Connect Bangkok

Uninitialized memory can cause unpredict behavior and be hard to reproduce. Also Race conditions are among the most insidious and elusive programming errors. They typically cause erratic and mysterious failures, often long after the code has been deployed to production. Developers need to pay a lot of effort on testing and write code with care. Golang provides runtime tools for detecting those issues.

MemorySanitizer is a dynamic detector of uninitialized memory(UUM) in C and C++. The tool is based on compile time instrumentation and relies on bitprecise shadow memory at run-time. Shadow propagation technique is used to avoid false positive reports on copying of uninitialized memory. Also it’s a part of LLVM trunk and implemented as an LLVM optimization pass.

ThreadSanitizer is a dynamic detector of data races, implemented by hybrid algorithm(based on happens-befor and locksets) and is a part of compiler-rt in LLVM.

In this presentation I will share
1, What are MemorySanitizer and ThreadSanitizer
2, The algorithms of the two detectors
3, The relationship between them and LLVM
4, How to port them into Golang on arm64
5, The example used in Golang

Linaro has been building on KernelCI to handle continuous integration of the Linux kernel with multiple different compilers and compiler versions. This is used for catching regressions upstream in the Linux kernel and LLVM code bases. This helps ensure that Android and ChromeOS can reliably ship LTS branches of the kernel built with Clang. Come learn more about building Linux kernels with Clang, and how Linaro is helping enable this work via KernelCI.

There is a lack of unit tests available for the scheduler, energy aware scheduling, and CPU frequency management. In this session a recent effort to expand the available tests will be described and discussed.

A medley of short talks about stuff that LCG has worked on since the past Connect.

Open Asymmetric Multi-Processing (OpenAMP) provides an open source framework that allows operating systems to interact within a broad range of complex homogeneous and heterogeneous architectures and allows asymmetric multiprocessing applications to leverage parallelism offered by the multicore configuration.  This session will introduce the framework and how to use it.

This session will describe the OpenAMP libmetal shared memory API. The talk will include the interface default backend implementation in Linux system

Clang and the LLVM tools promise to be a drop in replacement for gcc and
support cross compilation out of the box. In practice trying to make this work
can be a frustrating experience, with little documentation or guidance
available.

This presentation will distil some of the experience gained by TCWG, covering:
- Clang's model of cross compilation and how it differs from gcc.
- Why there isn't a clang cross-compilation toolchain that I can download.
- Building a toolchain based on as many LLVM tools and libraries as possible.
- How to use clang when cross compiling with cmake.
- How some existing open source projects use clang tools targeting Arm
and AArch64.
- Common problems encountered when using clang as a substitute for gcc.

LLVM has reached a sufficient level as a compiler for system programming.
However, there are several problems as compilers for HPC applications.
Therefore, we are improving and enhancing LLVM for HPC.
In this presentation, we report our activities on register allocation,
vectorization, and software pipelining for AArch 64.
Also, we talk about some optimizations required to further
improve the performance of HPC applications.

The Vanguard program looks to expand the potential technology choices for leadership class High Performance Computing (HPC) platforms, not only for the National Nuclear Security Administration (NNSA) and the Department of Energy (DOE), but also for the wider HPC community. Specifically, there is a need to expand the supercomputing ecosystem by investing and developing emerging, yet-to-be-proven technologies and address both hardware and software challenges together and prove-out the viability of such novel platforms for production workloads.

The first deployment of Vanguard is Astra, a prototype Petascale ARM supercomputer sited at Sandia National Laboratories. This talk will focus on the architectural details of Astra, as well as the Advanced Tri-Lab Software Environment (ATSE) and significant investments being made towards the ARM software ecosystem. Furthermore, we will share initial performance results, first experiences, and outlay several planned research activities.

Bigtop provides an easy way for user to setup Big Data cloud platform and to deploy leading Hadoop-related projects, such as HDFS, Yarn, Mapreduce, and Spark.
A lot of commercial distributions are based on bigtop too, such as MapR.

Plus, since Bigtop 1.3, aarch64 is supported out of the box. No special patches are required any more. So, how to use it?

In this session, I will cover the following Bigtop 1.3.0, step-by-step:
* Build Bigtop from source (containerized)
* Smoke test with containers
* Deploy Bigtop on multiple physical machines

Machine Learning and Big Data applications are fundamentally changing the way that the processing of data happens. Classic processor data flows are now being augmented with off-chip accelerators that can be customized for specific types of applications from compute accelerators to network traffic acceleration. This has driven an industry wide movement towards accelerators and heterogeneous compute. For many of today’s compute tasks, accelerators can complete the needed functionality both faster and with lower power consumption than the processor working on its own. However, unmanaged heterogeneity can bring software complexity.
Cache Coherent Interconnect for Accelerators or CCIX™ (pronounced ‘see 6’) is a high-performance, chip-to-chip interconnect architecture that provides a cache coherent framework for heterogeneous system architectures. CCIX is designed with an aim to simplify heterogeneous system architecture while simultaneously improving performance – factors that are vital to design, optimization and deployment of accelerator based systems.

In this talk, we provide an introduction to CCIX from a software point of view. We will first introduce key CCIX features and capabilities, and how they benefit heterogeneous system design. We next illustrate why a CCIX system is fundamentally viewed as a NUMA system with heterogeneous properties. We will then provide a detailed introduction to individual components of the CCIX software stack – the CCIX boot firmware, UEFI and ACPI requirements, the CCIX programming model, hardware/software interfaces, OS and Management software architectures, Power Management and RAS.

We wrap up with a broad overview of ongoing efforts to enable CCIX in the existing ecosystems, and challenges thereof. We then solicit the audience’s suggestions on how these can be overcome in order to bring CCIX to full fruition in the Arm ecosystem.

Recently up-streamed changes to OP-TEE allow a board-port to provide a DTB overlay in-memory to be merged into a main DTB by a later boot phase.
This would be a brief description of how that works and why you might want to consider it for your project.

Testing a bootloader in LAVA is more difficult than running tests on a typical Linux-based operating system such as Debian or Android. Robustly provisioning a new bootloader requires boards to be better designed for automation and to be deeply integrated into LAVA. For bootloaders, we often have to drive the tests externally since, with an OS or POSIX shell we cannot simply launch scripts to manage execution of the test suite.

During this presentation, we will discuss these challenges in greater detail and look at what solutions LAVA offers to achieve bootloader automate testing. We’ll close out the session with an example test description that allows a bootloader test suite to be fully automated using LAVA.

Edge computing has some unique requirements and challenges in the boot area. LEDGE team and guests are digging in the details during a sprint at Connect. This BoF session  will summarize the findings and strategies to meet those requirements. Any presentation material will be made available after the sprint happens.

Covers running BigData/HiBench benchmark on Arm Servers. Topics include:
- Results brief
- Parameters tuning for hadoop, spark and flink
- Lessons learned

Reference: 
1). HiBench:
https://github.com/Intel-bigdata/HiBench
2). Yahoo Streaming Bench:
https://github.com/yahoo/streaming-benchmarks

During the first Automated Testing Summit [1], developers of some of the most popular open source testing projects in the world gathered in Edinburgh to discuss how to collaborate and share testing efforts in the future.

In this session, I will first introduce Fuego as a black box and show how Fuego can work together with existing testing tools to form a complete CI loop. Next, I will show a modularized view of Fuego internals, and explain how specific modules can be shared with other testing tools. The talk will be illustrated with examples, and will not require previous knowledge on Fuego. 

[1] https://elinux.org/Automated_Testing_Summit

We've heard what you've said and we're making a series of significant changes to our Developer and Community websites to help you learn, develop, and collaborate on Arm.

Join us to explore the new ways you can connect with our developer content and help us discover what works, and what doesn't, about our updated Arm Developer journeys.

When developing embedded systems, it is common to have mixed-criticality requirements: one application is critical, and often comes with real-time requirements, while the other application is far less critical and it is typically based on Linux. Static partitioning is the best way to meet these requirements.

This talk will introduce Dom0-less: a brand new way of using Xen to build mixed-criticality solutions. Dom0-less is a Xen feature that adds a novel approach to static partitioning based on virtualization. It allows multiple domains to start at boot time directly from the Xen hypervisor, decreasing boot times dramatically. Dom0-less makes booting a critical application in less than a second an achievable goal. Xen userspace tools, such as xl and libvirt, become only optional. Even Dom0, the cardinal point of every Xen deployment since its inception, becomes inessential.

Dom0-less extends the existing device tree based Xen boot protocol to cover information required by additional domains. Binaries, such as kernels and ramdisks, are loaded by the bootloader (u-boot) and advertised to Xen via new device tree bindings.

The audience will learn how to use Dom0-less to partition the system. Uboot and device tree configuration details will be explained to enable the audience to get the most out of this feature. The presentation will also include a live demo of the technology.