Academic OSS ELC

Managing the Wind: Remote Management for Zephyr Devices With LwM2M

Wed, 01 Jul 2020 00:00:00 +0000

LightweightM2M (LwM2M) by OMA SpecWorks is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. It is designed for the remote management of devices and is based on the Contrained Application Protocol (CoAP, RFC 7252), which itself provides an interaction model similar to the client/server model of HTTP.

The Zephyr RTOS from the Linux Foundation possesses built-in support for LwM2M. In this presentation, you will discover how to leverage LwM2M to manage Zephyr-based devices. You will understand the pros and cons of using Zephyr’s built-in LwM2M client. You will also learn about various LwM2m servers, including the Eclipse Leshan open source project, which you can use to build your own LwM2M management server.

LwM2M features

bootstrapping
Device Configuration
Firmware Update
Fault management
Configuration and Control
Reporting

LwM2M in the Zephyr Arch

IPSP
- Bluetooth profile leveraging 6LoWPAN (IPv6 over BLE)
LwM2M Client
- Runs on QEMU
- Runs on actual board
- requires server

A Server: Eclipse Leshan

Java library for implementing clients and servers
Simple (no framework, few dpenecneies)
Web UI for discovering
build using mvn install
based on Eclipse Californium (an implementation of CoAP)

LwM2m sample

lwm2m is lightweight. net/lwm2m.h.
Includes
main
Setup
Event processing

Demo

Deploy

west build -b nrf52_adafruit_feather samples/net/lwm2m_client -- - DCONF_FILE="prj.conf overlay-bt.conf"
west flash --runner jlink
sudo minicom -D /dev/ttyUSB0 -b 115200

6lowpan and assign IPv6 address

sudo su
modprobe bluetooth_6lowpan
echo 1 > /sys/kernel/debug/bluetooth/6lowpan_enable
hcitool lescan
echo "connect C2:FA:8D:93:21:DD 2" > /sys/kernel/debug/bluetooth/6lowpan_control
ip address add 2001:db8::2/64 dev bt0
ping6 2001:db8::1

Getting and starting Leshan Demo Server

wget
https://ci.eclipse.org/leshan/job/leshan/lastSuccessfulBuild/artifact/le
shan-server-demo.jar
java -Djava.net.preferIPv6Addresses=true
-jar leshan-server-demo.jar

you can read, write and modify values
Some are built into sample
- temperature sensor
- lights

Reproducible Builds and Hash Equivalence in the Yocto Project

Wed, 01 Jul 2020 00:00:00 +0000

As embedded Linux devices get more complex, many questions arise about the process of constructing these systems and how it can be improved. Can these complex systems be built more efficiently to reduce development time? How can developers be assured that these systems can be built reproducibly to ensure software supply chain integrity? Joshua will highlight two new features in the latest release of the Yocto project specifically designed to address these questions. The first feature is hash equivalence which reduces build times by collectively detecting when tasks have rebuilt unnecessarily and preventing rebuilds of downstream tasks. Joshua will explain how this feature works, how to apply it to your own projects, and what to expect when you do. The second feature is build reproducibility testing, which ensures that the project has binary identical outputs from one build to the next. Joshua will describe how these tests work, what they currently cover within the project, and how to enable them for your own projects. Taken together, these features improve the Yocto project’s unique ability to effectively construct complex Linux embedded systems that are cost effective and secure.

Notes

reproducible-builds

RunQueue

MIA

RunQueue with Hash Equivalence

Now each task also has unihash
breaks task hash from it’s upstream
unihash is tashhash by default.
outhash is calculated. Then stored in hashserver

Trickle down effect

all downstream tasks will still have taskhash updated.
if it’s a trivial task we would like not to have to rebuild the downstream tasks.
if the outhash is the same even if the taskhash changed, then the hashserver will set unihash to a certain value
- Now this unihash propagates down to downstream tasks.

Recipe Updates

Which updates work well with this hash equivalence server?

Library updates & CVE Fixes
Native tool updates

Output Hash Calc

Checksum of all files and metadata that goes into an sstate object
signature files can be found in depsig

Hash Equivalence Server

Reference impl in bitbake
- BB_HASHSERVE = "auto"
can be shared between multiple clients
- Specify server with BB_HASHSERVER
- Only makes sense if you are sharing SSTATE_CACHE

Debugging Hash Equiv.

Can configure logging in local.conf
- BB_LOGCONFG = "logconfig.json"

Future Improvements

Read-only hash server for CI centered workflows
- “read-only” flag for the client
- “read-mostly” flag for the client
better hash equivalence database introspection tools

Reproducable Builds

https://reproducible-builds.org/

Imrpove Hash Equiv. effectiveness
Code archival
Software supply chain
1. verify toolchain is not comprising your target

Build FLow

tool builds almost all the tools it needs
compile native tools from source

Reproducibility QA Test

reproducible build
- available since 3.0 (zeus) release

QA Test

Does an ‘A’ and ‘B’ build
- A uses sstate
- B from scratch
test images
- core-image-minimal
- core-image-full-cmdline
- core-image-sato
test packages formats
- deb
- ipk

What causes reproducibility issues?

build path differences
timestamp differences
host differences
- consider using docker container to reduce issues

diffoscope

report non-reproducible packages in browsable HTML
supports diff inside of archive files
- packages (deb, ipks)
- archives (tar, tar.xz, etc)

Future Imrpovements

NOTE: exttool-sdk provides all the tools required to rebuild

test more packages
- SDK images
- sato images
- world images
test rpm packages
test final rootfs images
test other deployed objectstest native tools
test more architectures
- Currently only tests x86-64
- AArch64 would be the highest priority
reproducible-builds.org recomended these things
- Use DisorderFS to test for file system ordering non-reproducibility
- Use libfaketime to do proper timestamp testing
  - psuedo library needs adjustments
  - provides fake timestamps

Conclusions

Community

Freenode IRC
- #yocto
- #oe
Monthly virtual planning meeting
- First Tuesday of each month at 8:00 AM Pacific Time
Bug triage
- Thursday at 7:30

Contact

JPEWhacker@gmail
Joshua.Watt@Garmin.com

Questions

QA with Speaker

restoring from sstate is called set-scene?
- Yes, bitbake actually executes a task called do_populate_sysroot_setscene in place of of do_populate_sysroot to do the actual restoring from setsecene
Is the hash server part of the sstate cache?
- No. It depends on the sstate cache contents (as I’ll cover in a bit), but it’s a separate entity.
Will the uni-hash always stay as the first ‘equivalent’ task-hask?
- The hash equivalence server currently uses the oldest reported hash as the “canonical” unihash, but the decision is internal to the server, so other things could be done.
What if a recipe doesn’t change it all but only a referenced file (using SRC_URI) which is copied by the recipe into the roots?
- hash equivalence is based on the output of sstate tasks, so if the file changes sstate output, then it won’t be equivalent, but if the state output is the same, than it will be equivalent.
This is true for any of the things that go into a tasks hash (files, variables, etc).
- how does hash equivalence work in a multiconfig scenario when building for both arm32 and aarch64?
Can you elaborate?
- Can the path for your own tests be in a location outside of the poky repo?
Yes. In fact, OE’s QA test core will look in those paths in any layer, so you can simply drop the file in that path relative to your own layer root and it will find it.
- Can you restate the reproducobilty project that recommend DisorderFS and Libfaketime? reproducible-builds.org, and it’s on my references slide

My Questions

Can you comment on ‘universal/’ and on ‘uninative’ with respect to sstate?
- uninative provides consistent native tools. allows you to use the same tools
- really “light” container

Notes

Paths encoded in dwarf symbols in debug symbols becomes problems

Software Update (OTA) for Zephyr

Wed, 01 Jul 2020 00:00:00 +0000

Zephyr devices can be connected in two possible (direct and in-direct) ways to the internet. Directly using Modem/WiFi/Ethernet medium or in-directly via local radio through Gateways like Linux. Upgrading such Zephyr system in the field is a complex task and must be robust, secure.

This talk will details various possible update solutions available like UpdateHub, Hawkbit, SWUpdate for Zephyr. Using a NXP FRDM-K64F board as an example, we will discuss and demo different possible ways for updating Zephyr system.

Agenda

McuBoot
Updatehub
mcumgr
ZUpdate
ZUpdate -Hawkbit
Future work

Linux vs Zephyra

on linux it handles both download and install
for zephyr this is split into two
- download handled by application
- install is handled by MCUBoot
First we focus on download.
Then we look at install

MCUBoot

Bootloader for Zephyr and mynewt
integrity and security check
multi image boot support
softwre update heavy lifting

MCUBoot Memory Layout

NXP Freedom kit

chosen {
zephyr,code-partition = &slot0_partition;
};
&flash0 {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
boot_partition: partition@0 {
label = "mcuboot";
reg = <0x00000000 0x00010000>;
read-only;
};
slot0_partition: partition@20000 {
label = "image-0";
reg = <0x00020000 0x00060000>;
};
slot1_partition: partition@80000 {
label = "image-1";
reg = <0x00080000 0x00060000>;
};
scratch_partition: partition@e0000 {
label = "image-scratch";
reg = <0x000e0000 0x00020000>;
};
};
};

Paritions

Mcuboot
slot0
slot1
scratch

MCUBoot operation

conditions: Interrupt swap, request swap, valid image
Video from Youtube

MCUBoot swap

swap status
- three stage operation
- slot1 to slot0

API

image confirmed
write image
request upgrade
erase

Live share

west flash -d ./frdm_mcuboot/

Software Update

Updatehub

What is it?
Polling Mode
Manual mode
Community vs Enterprise

Live Share

~/work/west/native/zephyr/samples/net/updatehub
west flash
~/work/west/native/zephyr/samples/net/updatehub
west flash -bin-file ./build/zephyr/zephyr-signed.bin

Web UI

Overview
Devices
Pakcages
Rollouts

Each rollout has

UID, version, hardware

MCUmgr

Management library for Zephyr and mynewt
OS and hwardware agnostic

Layered modular design

1: img_mgmt,fs_mgmt,log_mgmt,os_mgmt
2: mgmt
3: SMP
4: BLuetooth, Shell, UDP

Reference Screenshots

STM32 target initial slot list
Uploading the OTA image via the Bluetooth interface
STM32 target initial slot list after OTA push

ZUpdate architecture

Configuration Manager
ZUpdate Core
Download Handler
- Hawkbit
- updatehub
- SWUpdate
- Custom
StorageHandler
- SPI NOR
- FLash
- MMC
Low-Level Comm
- BLE
- WiFI
- LoRa

A Disciplined Approach to Debugging

Tue, 30 Jun 2020 00:00:00 +0000

A Disciplined Approach to Debugging

A large fraction of the time spent on software development and system design projects is used for debugging. However, effective debugging techniques are not as well-studied or formalized as those for writing code. Instead, debugging is typically tackled with ad-hoc and idiosyncratic approaches. This talk will present a systematic approach to debugging software and hardware in order to locate bugs more effectively. It will also describe a taxonomy to classify such “insects,” which should enable better code-writing practices.

Debugging faulty hardware, single executables, multi-threaded programs, and distributed applications will be covered. Tips and tricks for software and hardware debugging using tools like GDB, Wireshark, gperftools, and hardware protocol analyzers will also be presented, along with examples of both common and unusual bugs caught in the wild.

Observe

C++ glog
Python logging module
Shell logger, file redirect

Logging aggregators

splunlk
ElasticStack
Graphana

Check and print all return codes

assert is friend

strace - trace system calls

gdb

attach to running
don’t forget debug symbols
- debug symbolts don’t use too much space
set ulimit -c unlimited
compile with `-O0 for straightforward flow
- avoids jumping around codes.

Bisect

with or without hypothesis
disable parts of prgram / workflow
switch compiler optimzation
Only switch one variable at a time.
trust stack
- your code < library < compiler < OS < hardware
- trust but verify

Classifying

Hard error (easy)

crash
unrecoverable
wrong data output
resouce exhaustion

Soft error

only something happens
want to turn this into hard error

Turning soft to hard

tracking and exceptions

Other

EX: Disk I/O Errors

IO error log in program
“soft error” - intermittent - EIO is unpredicatable
Trying other errors (ENOENT, EPERM)
Look at errorno.h and errno-base.h
How about ELOOP? Try recursive symbolic links

Start up program

MIA

More GDB Features

Remote debugging with gdb-server and target command
Watchpoints
- watch <extpression> (write), rwatch (read), awatch (r,w)
- prefer HW watchpoints. HW watchpoints are free but limited in number (4 on x86)
Conditional breakpoints
Observe values at each break
- command <breakpoint>
- can run command at breakpoint
catch
- great for C++

EX: Debugging Hang with GDB

App hang periodically (one every 10,0000)
Stuck in read(), why?
- read() is a blocking call
- libpthread is not compiled with debug info. This is why we don’t see any of the code.
it’s reading input from stdin. it is meant to read from network.

(gdb) info registers

race between close() and read()
object is cleaned up, and memory used for something else that sets m_socket = 0.
To fix we added a flash, and then a wait() for the thread

Wireshark

wireshark is the best GUI for network capture/debug
tcpdump to cpature output to file, then visualize with wireshark
man 7 pcap-filter for capture
- tcpdump -i eth0 tcp port 80 and host 142..
MIA

Packet Loss

In wireshark look for RED, which indicates errors.

Hardware Debugging

Observability is key
get analyzer for any interface
I2C/SpI
- SAleae
- Beagle
- Easyi2c (win only)
USB
- TCpdump and wireshark support
- modprobe usbmod
- tcpdump -i usbmodn
MIA

I2C Example

Preioidc loss of I2C bus connected to Xilinx FPGA
Step 1 repoduce
- increase activity on i2c
- poll temp volt sensors
Step 2 observe
- IP block was encrypted
- use logic analyzer to watch probes

I2C ANlayzer Example

yellow - SCL CLock
green SDA data
zoomed region shows glitched on rise
causes “extra clock”
solution was to put stronger pull up
- faster rise time
sly770.pdf from ti.com has more info

Questions

Surge?
you can create your own version of assert if you need to avoid it being compiled out
-Wall is a good starting point.
Use static analysis tools
gcore will work hen process is hung
can attach to hung process directly with gbd
docker containers are great from debugging.
- drop packets
- set up docker container for other aritecture.
How to analyze core dump
- gdb will load up application.
- can’t step, but you can examin all information.
gdb has great thread support
valgrind and halgring
- halgrind is subset tool of valgrint
- halgrind slows down your code because it’s emulating the CPU
gdb is hard to find documentation
- Use gdb help
release debugging
- include -g. symbols are worth the minor space they add, minimal performance impact.
- don’t includee -O0 because it will slow down program

Building Bare Metal Toolchains, Crosstool-ng and Yocto Project

Tue, 30 Jun 2020 00:00:00 +0000

Recently I was tasked to create a bare metal toolchain to create software for a variety of embedded processor architectures and configurations. Crosstool-ng is often used to create these toolchains, but Yocto Project SDK builder is capable of doing this as well. This presentation will compare both crosstool-ng and the Yocto Project for this task, include my experiences working with both tools, include Yocto Project configuration information and give the audience an understanding when they may want to use one tool vs the other.

Agenda

crosstool-ng
Yocto Project SDK builder
Experience
Yocto Project Configuration
Recommendation
Questions

crosstool-ng

crosstool-ng is versatile cross toolchain generator
good at reproducable toolchain
`ct-ng list-samples
Runtime relocatable
- can install in one location and mount/run from many
binaries are very specific to the host environments they were built for
- determine which operating system the user is using
- builds on the oldest distro
- Can build from Cygwin
- expects you to have cygwin cross compiler
Configuration is similar to kernel config
Config process will create ctx files
xilinx typically distributed “multilib” versions

Yocto Project SDK builder

Yocto Project

yocto project is not linux specific
- FreeRTOS
- OpenAMP
- Bare Metal
Outputs include
- Run-time images
- SDK / eSDK

This talk is focusing on SDK

Yocto Project SDK

target SDK
- matches operating system runtime environment
defined SDK
- SDK where each component is define to be include in SDK
SDK can be multilib enabled
- multilib are built independently of each other
- slower, but safer approach foor complex configuration
self extracting installation file
built to isolate sdk environment from the host system
- SDK includes its own glibc, and some runtime components
- Don’t need your own cygwin and other environment
installation and runtime locations must be the same
automatic runtime relocation is not supported
- note - this is supported by the plain ‘sdk’

example

oe-init-build-env build-baremeta-tc
DISTRO=xilinx-standalone MACHINE=microblaze-tc bitbake meta-toolchain

slower than crosstool-ng
- more steps to prevent multilib contamination

SDK - distro conf - xilinx-standalone.conf

How to create SDK config (and distro) ?

LIBC_DEPENDENCIES
- newlib-static dev
- libgloss-staticdev
install static library
- clear defaults for distro feature backfill
- virtual runtime init manager
- preffered virtual kernel

# xilinx-standalone.conf
SDK_VERSION = ""xilinx-standalone

SDK - machine conf - microblaze-tc.conf

multilib
- MULTILIB_GLOBAL_VARIANTS
- MULTILIBS += “multilib:libmble”
- tons more
default tune
- DEFAULTTUNE = "microblaze"
- AVAILTUNES
- BASE_LIB
- TUNE_FEATURES
- PACKAGES_EXTRA_ARCH

Experience - part 1

Changes from crosstool-NG

binutils
- set diffferent defaults to match prior toolchain
GCC
- different default to match prior toolchain
- restore some previously disabled newlib options (sysroots)
- only build SDK GCC once, create symlinks for other multilibs (gnu-toolchain-canadian.bb)
newlib/libgloss
- adjust defaults
- workaround issues with multilibs conflicted
- workaround issues where libgloss and newlib dependency wasn’t multilib aware

Compare

cross
- MIA
yocto
- linux sample confs
- no baremetal confs
- not relocatable
- full feature toolchain
- support mingw

Experience - part 2

Xilinx Bare Meta Toolchain

transitions from crosstool-ng to Yocto Project SDK to unify toolchain source and testing
transition was not painless from development perspective
- 2-3 weeks for first few weeks
- took 3 months to iterate the get it stable
lots of questions about multilib configuration
why was this transition and maintence was hard
- people didn’t understand why certain settings were set
- old version of crosstool-ng, people were not keeping up on configuration
initial goals was compatability with fromer crosstool-ng and custom ARM toolchain
- pseudo runtime relocation capable

Bare Metal Multilibs

aarch32-tc.conf
aarch32
- standard ARM (A profile) 32bit instruction set
- multilib config based on GNU/ARM defaults
- 17 multilibs defined
  - custom defined to match GNU/ARM settings
first we got it working
Now we can focus on fine tuning
Custom arm-rm-tc.conf
ARM R/M
- readltime
- microcontroller
aarch64
- aarch64-tc.conf
Microblaze (microblaze-tc.conf)
- common microblaze isntruction set permulation
- custom config

Bare Meta Toolchain COnfiguration

binutils
- disable: gold as LD, gprof, shared
- enable: enable-lto, static, multilib
gcc
newlib/libgloss
- recipes-core
- xilinx baaremeta implements device specific items using libxil, but we use libgloss to provide the framework
- flags
  - enable-newlib-io-c99-format
  - long-long
  - io-flow
  - long-double
  - disable-newlib-supplied-syscall
- libgloss multilib
  - “${MLPREFIX}newlib”

This was one of the major issues:

disable ‘disable-initfini-array’

Lessons

more multilib - longer initial project parse time
microblaze parse time is nearly an hour (48 multilibs)
- devlopment workaround, build for only one multilib
mingw32 builds are sequential with linux version, using shared sstatic-cache
roughly 15 minutes on the same machine for mingw parts

Recommendations

for quick toolchain - use Crosstool-ng
Yocto Project makes sense if you need Cygwin
- less important since windows is moving to linux
Yocto Project take more time and effort
- easy way for common source and configuration switchs
- simplify defect handling and propagation of fixes for systems

Questions

Vivado vitis baremetal tools chians are built with this
How did you converge configuration
- query gcc
- check logs for what arguments were passed
- print config
which release was this against.
- 3.0 zeus
multilib vs multiconfig
- this was largely due to legacy reasons
- one gcc binary to execute

Author

kernel-crashing.org
author: fray

Developing, Building and Testing Your Baremetal Applications Using The Yocto Project and OpenEmbedded Infrastructure

Tue, 30 Jun 2020 00:00:00 +0000

Multiarchitecture SoCs are more widely used, usually containing a large architecture where it can run a full operating system such as Linux, and one or more small architectures designed to run an RTOS or a baremetal application,requiring less hardware resources,leveraging suitable tasks from one to another creating a more efficient product.

While the Yocto Project is well known for its capabilities on creating customized Embedded Linux Distributions,bitbake is also capable of building a toolchain to create Baremetal applications or an RTOS.

In this presentation Alejandro will show how to create baremetal applications using the same flow currently used in OpenEmbedded to develop Linux applications, using recipes, classes and user configuration files, he will show how users from the community can benefit from a single flow, showcasing how to run these applications on QEMU and create tests for them to be automatically tested using the OpenEmbedded infrastructure along with their corresponding Linux distributions.

Anyone from the community interested in learning about baremetal programming or about the Yocto Project might find the contents of this presentation interesting.

Notes

Multiarchitecture Embedded Devices

Azure Sphere
- Secured MCU
- Secured OS
- Cloud Security
- MT3620 Dev Board Diagram

OE Runtime Testing Infra

Testing a linux OS (poky)
TEST_TARGET
- QEMU
- Hardware (simpleremote)
  - Send commands via SSH (TEST_SERVER_IP)
TEST_SUITES
- auto
- cases: ping ssh scp parselogs
- meta/lib/oeqa/runtime/cases

TESTIMAGE_BOOT_PATTERNS in OE

testimage.bbclass
- TESTIMAGE_BOOT_PATTERNS
- TESTIMAGE_BOOT_PATTERNS[send_login_user]
qemurunner.py
- default_boot_pattern
- accepted_patterns

Testimageflow

H: Start booting
T: Login
H: ROOT\n
T: Prints out root username
H: SEND_COMMAND
T: Check for another prompt
H: READ

Baremetal Toolchain on the Yocto Project

MACHINE = "qemuarm64"
TCLIBC = "baremetal"

Then build and run in qemu

bitbake baremetal-helloworld
runqemu

Other tagets

bitbake meta-toolchain
bitbake baremetal-helloworld -c populate_sdk

TCLIBC="newlib" - little more than baremetal

Simple Baremetal HelloWorld on Aarch64

QEMU source code (virt)
UART, RAM, Kernel Address
ARM Developers Manual - UART PL011

What files do you need?

Start Code
Linker Script
Your source code

Example for aarch64

hello_baremetal_aarch64.c
startup_aarch64.s
linkerscript_aarch64.ld

Creating test for FreeRTOS

Overriding Patterns in local.conf
- TEST_SUITES = “freertos_echo”
defined new test cases
- meta-freertos
- [freertos_echo.py]](https://github.com/aehs29/meta-freertos/blob/de4c8530b9bb31b9bbf08124a21a3ffc47d0121f/lib/oeqa/runtime/cases/freertos_echo.py#L1)
These tests run in do_testimage

How to create FreeRTOS test

This is a simple example of using OEQA test framework with a baremetal application.

He then created a very basic C application that emulated the basic prompts for Linux.
Hacky, but a simple way to get an initial test in with a framework focused on Linux testing.
You could possibly get it working for libgloss

Questions

Q: Can a testimage.bb depend on something
A: tests can depend on other recipes. Works with the build system itself.

Finding Sources of Latency on your Linux System

Tue, 30 Jun 2020 00:00:00 +0000

In today’s computer systems the level of complexity has risen such that when a task or response to an event takes longer than expected, it is not easy knowing what the culprit is. The Linux operating system contains several utilities that allows a user to see where things may be held up. This talk will cover many of these utilities and briefly explain how to use them. From the hardware latency detector to the latency tracers. It will also discuss the new synthetic event interface that allows users to create a histogram on the time it takes any two events to occur.

I have previously discussed the latency tracers but they are soon to be obsolete, and the new synthetic event interface will be replacing them. There is still a lot more development going on with the synthetic events and this talk will briefly go over some of the new features that are yet to arrive.

Notes

Latency from Hardware
- System Mangement Interrupt (SMI)
Cache miss
branch prediction
Hyper-threading
Hardware Latency detector (HWLAT_TRACER)
fedora 31 not debian
tracefs

Measuring latency from interrupts

Linux on Open Source Hardware with RISC-V

Tue, 30 Jun 2020 00:00:00 +0000

Want to run Linux on open hardware? This talk will explore Open Source Hardware projects capable of that task, and explore how RISC-V and free software FPGA projects can be leveraged to create libre systems.

This talk will explore Open Source Hardware projects relevant to Linux, including boards like BeagleBone, Olimex OLinuXino, the Reform laptop and more.

I will also talk about the importance of the open RISC-V instruction set and free software FPGA toolchains. I will explain how myself and others at Hackaday Supercon teamed up to get Linux running on RISC-V core in the ECP5 FPGA badge. I will explain what LiteX is and how it enabled us to quickly build a SoC capable of running Linux.

Finally, I will explore the landscape of open source chip design projects and the Linux-capable RISC-V silicon chips on horizon for 2020.

Notes

What’s required to be “open hardware”

schematic
board layouts

RISC V: The instruction set for everything?

ISA=instruction set architecture
ARM requires commercial licening

What’s different about RISC-V

simple
clean slate design
modular
- extensively/specialization
- small standards base ISA, with multiple standard extensions
stable
community design

Ecosystem

opensource software
commercial software
open-source cores

Hardware

commercial cores
commercial core provisders
inhouse cores

Industry

Most people are just licensing cores from ARM
open source implementation
- BOOM, Rocket, PULP, SweRV

Chips

lowRISC

not-for-profit organisation
OpenTitan project with Google

SiFive

SiFive FE310 microcontroller
HiFive1: Arguino Compatible RISC-V dev kit

Linux on RISV-V

HiFive Unleashed
- best core if you want to run RISC-V Linux
- mostly just a proof of concept

Kendryte K210

8 mb of SRAM
$13
https://hackaday.com/2019/02/14/new-part-day-a-risc-v-cpu-for-eight-dollars/
Has MMU but too old to be supported by linux
will be suported in Linux 5.8

PolarFire

CORE-V Chassis - tapeout 2H 2020
Hard RISC-V with FPGA fabric

Open Source FPGA Tools

Linux on Badge

has ECP5 FPGA
- Supported by open source FPGA tool
Linux running on Supercon badge
2019 Supercon badget
32 MB of SDRAM to the Hackaday badge

Migen

HDL written in python
https://github.com/litex-hub/fpga_101

LiteX

Litex used to build cores, create SoCs and full FPGA designs
LiteX Hub - Collaborative FPGA projects around LiteX
Based on Migen

Linux on LiteX

https://github.com/litex-hub/linux-on-litex-vexriscv

What baords could you use?

ULX3S
- ECP FPGA dev board

Quickstart - FPGA

Fomu
- RGB LED
- MicroPython
- Verilog
- LiteX

Quickstart -No Hardware

Renode

Linux Stateless Video Decoder Support

Tue, 30 Jun 2020 00:00:00 +0000

While it has been under development for years, the support for video CODEC accelerators has gain a lot of traction in past year. A formal specification has now been merge into Linux Media subsystem and staging control APIs and drivers now exist. This allow for blob free HW accelerated decoding on popular SoC like Allwinner, i.MX8 and Rockchip.

In this talk, Nicolas will give an overview of the decoding process using such hardware accelerators along with an overview of the user space API and how it’s used within multimedia frameworks. Nicolas will also explain the relation between this and accelerators attached to modern GPUs. This presentation would not be complete without mentioning the development of FFMPEG and GStreamer native support and their major role in the development of the the new Open Source drivers.

This talk is addressed to multimedia enthusiasts and developers curious about video decoding and the upstream effort effort to make that available to users.

Notes

State-full Decoder

Begining of Linux Codecs

What is state-full?

stateful is a blackbox
blackbox gets bitstream

V4L2 M2M

output -> VPU -> capture

V4L2 output queue is used for the bitstream
capture queue is used for the decoded pictures
capability to seek and end stream

Pro/cons

pro: minimal per codec code needed
con: require a firmware
con: harder to multiplex

CODA Driver

Enabling iMX51 and iMX6
reversed enginerring from imx binary blobs

Begining of State-Less

2015

Rockchip
new type of CODEC hardware
Rockchip VDPU

What is State-Less

no processor
expose “accelarators”
1. inputs:
- reference
- bitstream
- parameters
1. accerator
1. outputs
- pictures
- may not be in order

What are GPU?

Crafting command stream is HW specific
only implement in userspace drivers (mesa)
commands are schedule by the GPU driver
multiple GPU hardware in the same application remains tedius

This is not what google did!

V4L2 M2M + Request (2015)

Instead, extend stateless: V4L2 M2M + Request

Added components

CODEC Controls
Request
Topology
Request API
- way to queue parameters, controls, and bitstream buffers
- added to media controller API

H.264

NALU Sequence
- SPS, PPS, IDR Slice, P Slice, B Slice
- P previous decoded pictures
- both past and future references
Annex B NALU
- Start-Code
- HDR, Paylod
AVCc NALU
- Size
- HDR, Payload

Decoding Process

MIA… Missed one slide
Fill SPS/ PPS, Decode Parameters, Slice parameters
Modify reference list
Decode the slide/frame
Do DPB management as per spec
- Display Picture management
Output frames that could be re-ordered

V4L2

Allocate a Request (an FD)
set per frame
queue a v4l2_buffer
queue the request
poll the request FD for completion

Continue in time

MediaTek VPU (State-full)

tiled output only (requires HW converter)

Qualcomm Venus

Stateful
lots of CODECS

Upstreaming Stalled

Could not settle on the Request/Job API
Low knowledge of CODEC decoing process by the linux-media maintainers
only one hardware to test the API design (Only rockchip)
No formal specific (not that state-full CODEC had one either)

Allwinner VPU support Kickstarter by Bootlin (2018)

Request API is finalized
MPEG2 Support in Staging
H.264 support was progressing (but only sliced based)
reverse engineered from binary userspace
VAAPI userspace drivers

2019

formal specification was merged
RK3288 driver was mainlined
H264, VP8, HEVC uAPI added as staging control API
RK3288 driver was renamed?

The Hantro Driver

I.MX8M Quad, using Hantro G1/G2
Registry compatible with the RK3288
Give email and you get specification

Hantro Company

Hantro Visibility Better
on2 technology
Google
- VP8 and VP9 royalty free
VeriSilicon

Other story of API rename

stmmac is an ethernet driver, that was thought to be STM design
later found to be DesignWare design, shared across numerous SoC
Since API was released it was unable to be renamed

Testing and Fixing

LibreELEC - just enough OS for KODI
- FFMPEG support
- bug fixing
- interlaced Content Support

2020

RK3399 JPEG, MPEG2, H.264, and VP9 support
Start having base class for Stateless
- DXVA2 and NVDEC support
VA V4L2 Request driver was abandoned

demo

linux kernel 5.7rc2
gstreamer has tool called ‘gst-build’ built on mesin
- allow you to run plugin
- gst-play-1.0
video layers are an overlay
prerolling.
three different streams
one two iMx8

Questions

performance stateless vs state-full
- have to wake up processor more
- more control over queuing
converting them to state-less is complex

Robot Operating System (ROS) 2 - How Open Source Software and Linux is Powering the Next Generation of Robotics

Tue, 30 Jun 2020 00:00:00 +0000

Robot Operating System (ROS) 2 - How Open Source Software and Linux is Powering the Next Generation of Robotics

Katherine Scott, Open Robotics

Robot Operating System (ROS) is a set of mature free and open source software packages used by the robotics community to program robots. Recently ROS had its first major version upgrade in a decade to ROS 2. This new version introduces a number of changes and new features, many of which simplify the development process and allow users to build virtual robots without ever touching a piece of hardware. ROS 2 is the version of ROS that supports Python 3 out of the box and has new additions that allow for high-fidelity simulations. Simulation makes learning advanced robotics topics more accessible, as you no longer need to outfit a robotics lab and you can simulate cutting edge hardware for free. In this talk we’ll cover the state of the open source robotics ecosystem and cover the changes made in ROS 2 to improve its simplicity, stability, safety, and security. These features, along with enhanced embedded hardware support, are helping ROS become the de facto standard for the developers of autonomous vehicles, drones, industrial, and agricultural robots. This talk will give the Linux community and update on ROS ecosystem and a starting point for learning how to use it.

Notes

ROS is a lyer on top of Linux for robots
metrics.ros.org

Windows

works on Windows
vscode

Intro

Software before times

research grade
proprietary
works on Windows 95
system integrators
vendors
bespoke
hardware controllers
Feed forwards

Catalyst

2004 competition for autonomous vehical

Input to innovation

flexible robots
IPO
FOSS
Willow Garage - 2007 Poof FOOS for robots

Three projects results

opencv
pcl
ROS

Two Robots born

Willow: Shared World Class Research
2013 Willow Folders but OS lives on

Ethos of Global Research Community

Small, Simple, Composable Utilities
Don’t Reivent the Wheel
Non-Exclusive (polyglot, packagin infrastructure)
Inclusive (in addition to, not in place of)
Freedom

Out of Willow was born:

OpenRobotics
ROS Industrial

ROS Philosophy

Federation over Centralation

Plus list from above.

Small, Simple, Composable Utilities
Don’t Reivent the Wheel
Non-Exclusive (polyglot, packagin infrastructure)
Inclusive (in addition to, not in place of)
Freedom

Order of topics

Don’t Reinvent

Dont Reinvent

Multiprocess Control

Components
- Sensors
- Control
- actuators
nodes are process encapsulation between languages
Imagine
- C++ Python programs all start concurently
- with hardware
- lots of config
- control flow based on config
- What would your shell script file look like?
- ROS nodes and launch files take care of this
- Tooling to start them.

Topics

pub/sub bus
ROS nodes communicate over topics
Cross language serialation primitives that predate protobuff, rabbitMQ, etc.
Standard messages allow
- plug and play
- loose coupling
Online introspection
quality of service capabilities
build as an abstraction
- DDS implementation, ensures security, robustness
- implementation of pub/sub is pushed off to other implementation

RVIZ

Robots make lots of data
- much of it is live
- with 3D context
- annotation
RVIZ is your GUI

Bags

standard serialzation library for transport also works for disk storage
- MIA
bags are amazing
- ML/CV/DL
- unit tests
- collaborators
- Black Box
collect on robot and transfer elsewhere for analysis
De-facto standard for sharing data
- Ford Autonomous Vehical Data
http://wiki.ros.org/ROS/Tutorials/Recording%20and%20playing%20back%20data

Services/Actions

Services: synchronous behavior API
Action: async behavior
- Handles request negotation
- with preemption
- with status callbacks
Callback driven API
build robot behvaiors, fast

Geometry/Kinematics

Hard robot problems
- where is everything
- where am I
- how to get A to B
- I can see X, how to graph it
- Many more
URDF: Universal Robot Description Format
- Defines 3D Geometry of a Robot
- Works with your CAD format
- gives a robot an idea of its shape and size
TF2 Transform 2
- transform coordinates from different frames
- API driven, minimal math

Forward/Inverse Kinematics

MoveIt

SLAM/Navigation

Path planning

Simulation

Robots are expensive, dangerous, slow
sharing a robot is hard
testing is hard
what if you don’t need robot?
What if you could have robot VM?

Simulation - Gazebo

build a virtual robot
simulate Physics, robot, and sensors
Plays well with ROS2
Allows yo build test debug from your desk

ROS: Getting to Plug and Play Hardware

Hardware Ready
Bridge between ROS 2 DDS layer and ROS

Community not just Code

ros.org
discourse.ros.org
answers.ros.org

ROS 2 Foxy

6th Ros 2 Release
First major LTS
Start now 3 year of patches and supports

I want to learn!

DARPA SubT Simulator has great tutorial
Autoware has Autonomy class
- Prepackaged docker container to run simulation
- awf-course
ROS 2 Docs
TurtleBot3

Contact

rosorg
kscottz
org.org
openrobics

Questions

Q: Gazebo included?
A: No
Q: I work on embedded projects that run on custom hardware for fancy PTZ cameras. I would love to convience our Python app developers how/if ROS could be leveraged. Where do you think I should start? Are their any consultants that could help analysis the specific use case?
A: This is something we are missing. She views robots broadly. MicroROS. Developing concepts for hardware. hardware interface framework.
Start with simulation

Using MIPI DSI as Main Display Interface

Tue, 30 Jun 2020 00:00:00 +0000

Using MIPI DSI as Main Display Interface

Marcel Ziswiler, Toradex AG

The MIPI Display Serial Interface (DSI) is the de-facto standard display interface featured by modern higher-end SoCs. Lacking the long-term availability of discrete MIPI DSI display panels most embedded systems rely on bridge chips converting to more common display interfaces like parallel RGB, LVDS, (e)DP or HDMI. Our generic system concept relies on DSI adapter boards integrating various such bridge chips. After introducing the Linux DSI subsystem this talk concentrates on the auto-detection of such DSI adapters based on parametrisation stored in EEPROMs. The U-Boot boot loader reads the EEPROM contents and chooses the applicable device tree overlay to be applied. The concept of DDC/EDID with hot-plug detect vs. a custom model-specific parametrisation is discussed. The talk continues covering the integration aspect of such DSI bridge chips within the Linux DRM stack. Various limitations of the DSI subsystem and possible solutions are discussed. The DSI bridge chip ecosystem is covered and we look into possible reasons only very few bridge chips are actually supported in mainline so far. The talk concludes with a live demo of our DSI auto-detection implementation.

Tordadex - swiss. Embedded. Computing

Intro

MIPI
U-Boot FIT Image
LIve Demo

MIPI Display Serial Interface (MIPI DSI)

Spec by MIPI Alliance
Low power (LP) mode or high speed (HS) mode
- HS is ussually one direction
MIPI DSI Spec initial version May 2006
MIPI DSI-2 Spec supports Ultra high definition (4k and 8k)
Physical Layer
- 1.0 Gbps/lane (1.01), 1.5, 2.5, 4.5 Gbps/lane (D-PHY 2.0)
- MIPI DCS - MIPI Display Command Set
- Incorportates Display Stream Compression (DSC)
  - Standard from VESA
- de-facto standard display interface feature by modern high-end SoC

Verdin products

Verdin MIPI DSI Display Adapter System Design

generic system concept
display adapter boards integrating various bridge chips
DSI Mezzanine Connector
- MIPI DSI: 1 clk + 4 data
- GPIO ( BLK1_EN, Touch Interrupt)
2 x I2C bridge chip + DDC/EDID
PWM backlight
I2S for optional audio
Generic system control signals
- PWR_EN_MOCI
- SLEEP_MOCI#
- RESET_MOCI#

Verdin iMX8M Mini

NXP i.MX 8M Mini SoC
Single display controller, LCDIF
MIPI DSI output w/ 4 data
MIPI D-PHY 1.2 max data per lane 1.5 GPS
Resoution up to 1920x180p60 and 1800x1200p60

Verdin DSI to HDMI Adapter

Lontium Se
HDMI V1.4 1080p, 8bit RGB up to 60Hz
ST HDMI2C1-14HD ESD prtect and signal conditiong
type A standard HDMI connector

Verdin DSI to LVDS Adatper

SN65DS184 MIPI DSI to dual link LVDS bridge
signle/dual-lane LVDS up to 1920x1200/1377x768
LVDS and touch connector compatible with Capacitive Touch Display 10.1” LVDS

Intro Linux DSI Subsystem

DRM MIPI DSI Core common logic helpers to deal with MIPI DSI peripherals

DRM Panel COre - Generic LVDS Panel (panel-lvds.c)
DRM Bridge Core TI SN65DS184 DSI to LVDS Bridge - (ti-sn65dsi84.c)
MIPI DSI Core - Northwest Logic MPI DSI Host COntroller (nwi-dsi.c)
DRM CORE - Display Engine Driver

DSI bridge chip integration

How does DSI bridge chip integrate with that?

DRM bridge
DRM connector
I2C device
MIPI DSI device

DSI Bridge Chip Integration Pitfalls

availability of super secret data sheets
- chinese vendors hide their data sheets
ancient downstream or bare skeleton drivers only
lots of hard-coded parmeters
link bring-up sequences not well documented
- lots of trial and error
Drivider frequency limitations on either controller side, bridge side or both
- may require running outside of recommended range

Bridge Chips in our current Adapters

How about Bridge Chips used in our designs current Adapters?

Lontium LT8912B MIPI DSI to HDMI bridge
Adopted driver from Rockchip Linux on Github
- Forward ported to later DRM API
- Reword driver to be proper I2C device
- full register set from Lontium psuedo code driver
- imrpoved regmap integration
- I2C sub addresses
- added regular I2C based DDC/EDID handling
- Added GPIO based hot-plug detection
  - Needed for I2C GPIO expander support
  - hot plug detect GPIO handling crashed GPIO exapdnder
- bus format was not properly set
not pretty but it works
Further clean-up and upstreaming pending
Texas Instruments SN65DSI84 MIPI DSI to dual-link LVDS bridge
Downstream driver taken from a patch in CompLab Yocto Meta Layer on Github

DSI Bridge Chip Ecosystem

Vendors still reluctant to maining drivers
Few mainline supported bridge chips
Few examples to copy from
procedure of actual silicon may be difficult
conformance of MIPI DSI host IP vs bridge chip silicon

Bridge Chips supported in Mainline

driver/gpu/drm/bridge
Differentiate between
- SoC internal IP
- discrete external bridge chips
- directly connected panels
SoC internal IP
- NXP i.MX 8 series
discrete external bridge chips
- ADV7533
- Parade PS8640 MIPI DSI to eDP converter
- SN65DSI86 DSI to eDP Bridge
- TC358764 DSI/LVDS Bridge
- TC358768AXBG/TC358778XBG MIPI DSI bridge chips
directly connected panels
- Rasperry Pi 7In touch. Toshiba TC358762 DSI to DPI aka parallel RGB bridge

Auto-Detection of DSI Adapter Base on EEPROM Contents

idea 1
- regular device tree: setting bridge stat to disable vs okay
- device graph: linking endpoint and remote-endpoint nodes?
- full flexbility requires device tree overlays
idea 2
- storing device tree overlay in EEPROM
- simple DTBO may be below 1kb more complex ones quickly more than 2kb
compromise. Store configuration block

U-Boot read EEPROM Contents and Selecting Applicatble Device Tree Overlay

Generalized ConfigBlock Handling from NAND/eMMC to EEPROM
table with product ID to device treee overlay file name mapping
Distroboot script to apply device tree overlays based on auto-detection as well as overlays.txt file
HDMI may do hot-plug detect
DDC/EDID
MIA…

DT Overlays

Verdin DSI

Verdin DSI to HDMI Adapter
- fragment for I2C bus
- fragment for I2C bus where you have bridge chip on
Verdin DSI to LVDS Adapter

Uboot FIT Image

board specfici device trees
display adapter specific device tree overlays
FIT image allows conveninet packing of Linux kernel binary toegether with various device trees, device tree overlays and/or ramdisk
booted as…
fdt_module is deduced form the EEPROM on the module. fdt_board from one on the carrier board. display_adapter_dtbo from one of the display adapters

mkimage -l tezi.itb
...

Device Tree Overlay Pitfalls

complex device tree overlays may require symbols
DTC_FLAGS='-@'
if reference device nodes with hex addresses.
- CASE SENSITIVE!!!
- use lower case!!!
troubleshooting
- Add dtc on target. opkg install dtc
- Use dtc -l fs on target and dump /proc/device-tree

Conclusion

Demo - DSI Auto-Detection Demo

Questions

Q: Used overlay stuff in u-boot
Q: Is Low power signaling Single ended?
Q: Can the end pane llike LVDS support partial update? How will the bridge propogate the presence/absence of particular DCS feature to Linux DRM driver subsytem?
Q: did you consider doing the overlays in linux kernel?
Q: Why is DRM required with DSI?
Q: Why are the vendors reluctant with regards to mainlining (or even docs)?
Q: Keep the conversation going. Please visit the #2-track-embedded-linux on our Slack Workspace after the session ends

PipeWire: The New Multimedia Service, Now Ready for Automotive

Mon, 29 Jun 2020 00:00:00 +0000

PipeWire: The New Multimedia Service, Now Ready for Automotive - Julian Bouzas, Collabora

PipeWire is the new emerging open source project that aims to greatly improve both audio and video handling on Linux systems, both desktop and embedded. It was recently adopted by Automotive Grade Linux as the core audio framework because its design’s flexibility makes it possible to address automotive requirements, replacing entirely previous solutions and addressing new use cases such as achieving ultra low latency with zero-copy media exchange, and allowing external session managers to define device policy logic.

In this talk, Julian is going to present the PipeWire project, how it evolved to overcome the automotive industry use cases, and what the current upstream status is. Julian will also present the WirePlumber policy management framework, which makes it easy to write use-case specific policy systems.

Notes

Intro

Fresh multimedia service for Linux

originally mean for video only: PulseAudio for Video (PulseVideo)
video capture
- cameras
- graphic sources (wayland, vulkan, OpenGL)
Audio playback and capture
- microphone and speaker
- bluetooth device

Why do we need Pipewire

Unified both pulseaudio and Jack audio servers
Permissions, support for container
Low Latency
- designed for small buffer sizes
- (1-2ms of latency)
Flexible: external session manager adaptable to any use cases
- can write your own session manager

Architecture and Design

Multimedia stack

DRM
PipeWire: Layer between Kernel and Applications
DRM -> Wayland compositor -> PipeWire
Kernel devices: DRM, V4L2, Bluetooth, Alsa
PipeWire Sessions Manager

Compatibilities APIs on top of PipeWirte

Alsa
Pulse AUdio
JACK

Architecture and Design

Modular with Plugin
Graph based like GStreamer: Nodes, ports and Links
Multi-Process
- external session manager configures and links the nodes
- daemon processes most of the data
Fully based on internal and simple plugin API library (SPA)
- extremely simple lightweight generic purpose multimedia libraries
- mostly header-only C library

Pipewire is very performant

Uses modern Linux Kernel APIs

Security

External session manager grants permission

Permissions

read - Visable, capture data
write, play data
execute: allow executing methods on object (setup format on nodes)

Adopted

Version 0.3.5 released in May 2020 and distributed in Fedora 32
Adopted by AGL

pipewire dot tool

Generates DOT graphs pw-dot pw.dot

WirePlumber Design

application that loads modules that were written with that library
allows external session manager
Plan to add PYthon/Rust bindings

Wire plumber Versions

v0.3.0 (2020 June) first version with desktop support
pavucontrol can still be used to control audio

Tutorial: Debugging Embedded Devices Using GDB - A Review of Some Lessons Learned

Mon, 29 Jun 2020 00:00:00 +0000

Tutorial: Debugging Embedded Devices Using GDB - A Review of Some Lessons Learned

Mike Anderson, The PTR Group

Linux has an incredible selection of tools for both debugging and profiling applications to get the most out of the system. In this session, we will start with gdb and show many of the lesser-known features that can significantly shorten debugging time. Next we will focus on the profiling and code coverage features found in gprof/gcov for determining both the performance of function calls and whether your test code is actually testing all of the code that it needs to test via examining the code coverage of the execution. Next, we will go into more sophisticated approaches using strace, ftrace, oprofile and LTTng and show how they work and why you might choose one over the other for certain tasks.

Notes

What we will talk about

GNU project, gcc and gdb
gdb CLI, TUI and gdbfront-ends
help, scripts, macro
attach to running app
breakpoints, watchpoints and more
fdbserver
strace
gprov/gcov
valgrint
LTTng and Ftrace

GNU Project

GNU: GNU’s Not Unix
front-end laguage parser and back-end code generator
numerous ‘binutils’ such as the linker, libraian

Line debug levels

g0 produce no debug info
g1 produce minimal info, enought for back trace, no info about local var and no line num
g2 default debug level
g3 extra info, macro definitions
-ggdb3 debug infor for gdb more than COFF,XCOFF or DWARF2 fof -g

Example

arm-linux-gnueabi-gcc -ggdb3 -o hello helloWorld.c
arm-linux-gnueabi-objdump -h hello

GDB GUI

ddd Data Display Debugger
- ddd supports: gdb, jdb, Python, Perl, TCL, and PHP
- debugger arm-linux-gnueabi-gdb myapp
MS Visual Studio Code

GDB help

aliases
breakpoints
data
files
internals
obscure
running
stack
status
support
tracepoints
user-defined

gdb script

.gdbinit in current directoy

useful init

set history save on
set print pretty on
set pagination off
set confirm off

gdb -x load at load time

gdb has built in python interpreter Just call python.

Working with Signals via gdb

Print table of how gdb will handle each signal:

info handle

Ways GDB can handle signla

nostop
stop
print
no-print
pass
nopass

handle signal keywords

signal SIGSEGV - deliver SEGV signal to the current program

Load/Execute your code

Use ‘file ’ to loca additional files
Helpful for using with kgdb

watchpoints

watch -l <address/symbol> # command is scope aware
rwatch <a/s> # stops if read
watch <a/s> thread 3 # stops if thread 3 modified
watch <a/s> if <a/s> > 5 # stops when contents > 5

gdbserver Cross Debug Example

gdbserver 192.168.7.1:1929 myapp &
(gdb) target remote 192.168.7.2:1929

gdbserver hostIP:2345 –attach PID

workds within GUI based fron-ends as well

strace

watch system called made from user space.

strace -c ./capture_stream -D /dev/video0 -w 764*331 -p 1 | ./viewer -w 680*480 -p 1

ltrace

ltrace allows us to trace library calls
strace for libraries

Ftrace (function tracer)

Kernelshark

https://kernelshark.org/
https://kernelshark.org/Documentation.html
https://lwn.net/Articles/425583/
TRACE-CMD The front-end application to Ftrace. The back-end application to KernelShark.

Tutorial: Introduction to the Embedded Boot Loader U-boot

Mon, 29 Jun 2020 00:00:00 +0000

U-Boot is the universal bootloader used on a vast majority of embedded systems, development kits, products and so on. This session is an introduction into the U-Boot bootloader, including a hands-on part, and covers practical topics like identifying that the board is running U-Boot, accessing and exploring the U-Boot shell, including advanced scripting techniques to make life easier, obtaining information about the current hardware, accessing buses and storage and finally booting the kernel. Furthermore, since every embedded project has it’s a unique set of requirements, U-Boot customization topics are briefly touched at the end of the session.

Notes

SPL - Secondary program Loader
- Just enough of U-Boot to load something else
Tertiary program loader
- smaller than SPL
- uncommon

U-boot Shell

original shell
HUSH shell
similar to bourne shell
You can get help for ‘usb’: help usb

contact

irc mailing list

Memory access

support for read/write mem and reg
support for byte/word/long/quad
memory modification interactivly mm, mn
cp copy memory
cmp compare

U-boot environment

env key value storage
default to compile time default
can have defaults read from somewhere
can be saved in memory
printenv print all env
env print arch
env set fookey barvaluse
env set foonowempty similar to unset foonowempty
saveenv for env persistence
run for running scripts. chain commands with ‘;’
The script environment is evaluate when set. You can escape $ to evaluate later

Special variables

ver
stdin, stdou, stderr
loadaddr
filesize
bootargs
bootcmd
preboo
ipaddr, netmask, serverip, gatewayip - network settings,
ethaddr, eth1addr

Other commands

setexpr - environment manipulation multitool

logical and conditional expression

if, ||, &&
can’t use ! in conditional.
while

u-boot data loading

SD/MMC mmc, usb, sata, nand
Uiversal FS access ls, load
Squash FS not supported

Example with SD card

mmc rescan
mmc part
# device and partition
ls mmc 0:1
load mmc 0:1 $loadaddr ID.txt
md.b $loadaddr $filesize

Loading from network

U-Boot network stack is UDP-only (no TCP)

support for TFTP, NFS, DHCP/BOOTP
ping
tftp
dhcp (obtain settings then tftp)

env set
ping $serverip
tftp $loadaddr $serverip:somefile
dhcp $loadaddr $serverip:somefile

Load over serial

X/Y modem
Srecord
kermit protocol
loady

Screen

loady
ctrl-a:exec !! sb -T yourbinary.bin

Booting the kernel

(z)Image
- Linux binary (with decompressor)
- no protection gainst bitrot
- just set up registers and jump
- optional separate device tree
uImage (originally support, now legacy)
- Legacy since forever
- wrapper around binary
fitImage - multi component image
- based on device tree
- support multiple files
- configurable checksum algorithm per entry
- support digital signatures
- like tar files

Booting

boot commands: bootz, booti, bootm

env set bootargs console=ttyO0,115200
load mmc 0:1 boot/dtbs/4.9.../am335x.dtb
load mmc 0:1 0x880000 boot/dtbs/4.9.../am335x.dtb

Device Tree

Data structure describing the hardware
asyclic graph
can link to any items

snippet

`images { kernel@1 { data
data = /incbin/("./arch/arm/boot/dts/...dtb")
}}

mkimage -f fitimage.its fitImage

bootm $fitimageaddr
iminfo imxtract

fdt

fdt command can maniuplate flattend device tree

fdt addr
fdt resize
fdt print
fdt set

gpio

gpio input
gpio set
gpio clear
gpio toggle

i2c command

i2c bus
i2c dev
i2c md
i2c mw - write registers to I2C device
i2c probe
i2c speed

qemu

qemu-system-arm -M virt -bios u-boot.bin

Demo

env set bootargs root= rootfstype= rootwait console=ttyO0,115200
mmc rescan
load mcc...
load mmc...

Task 7 build u-boot in sandbox mode

ALlows you to run u-boot as user application

make sandbox_defconfig

Other task

env ask mac 'MAC address ?'

Yocto Project LTS Releases - Nicolas Dechesne, Linaro & David Reyna, Wind River

Mon, 29 Jun 2020 00:00:00 +0000

Yocto Project LTS Releases - Nicolas Dechesne, Linaro & David Reyna, Wind River

Speakers: David Reyna, Nicolas Dechesne

Many projects struggle between the requirements for Long Term Support (LTS) and cadence delivery, the balance between stability versus agility and resources.

The Yocto Project is an open source project from the Linux foundation which provides tools and processes to build Linux systems. The Yocto Project makes releases every six months, and each release is maintained by the Yocto Project for a period of one year. This works great for keeping a tight integration loop with upstream. However the release cadence and the amount of changes that occur in each release make it less than ideal for certain markets. LTS releases have been one of the main feedback from our ecosystem for some time.

In this talk we will review the process behind this decision which is most likely the biggest change in the project since its inception. We will present how it will be implemented, how member organizations participated through the Yocto Project Advisory Board, discuss the potential impact on the Yocto Project ecosystem, and address the lessons learned in addition to the expected shortcomings and challenges.

Notes

First Linux Foundation project in 2010.
OpenEmbedded Started in 2003

Yocto Releases

6 month cadence (slide-8)
Release contains: OE-core, bitbake, meta-yocto, yocto-docs (slide 9)

Autobuilder

autobuilder
25 builders, 12+ hosts
ptests
Major improvements to reduce need for manual testing (slide 13)
hash equivalence is a way to get more efficiency

LTS background

Longer LTS cycle
LTS announced in March 2020
https://www.yoctoproject.org/yocto-project-long-term-support-announced/
Maintained for two years
Yocto 3.1 is first LTS (dunfell)
20 hrs a week fo maintainer duties
TSC is responsible for LTS releases, rpcoess and maintainer

What is not in LTS

meta-oe
vendor bsp
only test on virtualized tests
valudate use of CVE automated tools
replacement for vendor BSP support

Branching

LTS
stable (was 12-18 months, reduced to 8? months)
master

contribute LTS

submit patches to mailing list
patches should be on master, except whne incorporating a CVE/bug fix for old version