Transcript Zephyr RTOS - Real-Time Embedded Systems Lab

Zephyr RTOS -- Introduction
Computer Science & Engineering Department
Arizona State University
Tempe, AZ 85287
Dr. Yann-Hang Lee
[email protected]
(480) 727-7507
Real-time Operating System
 Use the computer hardware efficiently
 To manage system resource through
 system calls -- issued by tasks
 interrupts -- timer and external events
 Typical requirements
 Support for scheduling of real-time tasks and interrupt handlers
 low latency and deterministic
 Inter-process communication
 I/O support -- driver
 User control of system resource -- memory and file system
 Thread or process for task execution:
 smallest execution units that can be scheduled
 lives in a virtual, insulated environment
 uses or owns system resources
CSE 530 EOSI Fall 2016
1
Real-time Operating System
 Functions:
 task management,

 scheduling, dispatcher
 communication (pipe, queue)
 synchronization (semaphore, event)
External
interrupt
Timer
interrupt
System calls
(trap)
Interrupt
dispatch
memory management
 time management
 device driver
 interrupt service
Interrupt
service
Time service &
events
Scheduling
&
dispatcher
Task
execution
Services (create thread,
sleep, notify, send,…)
kernel
CSE 530 EOSI Fall 2016
2
RTOS Structures
 Small, fast, proprietary kernels
 Monolithic kernels that contains all services
 Component-based kernels or micro-kernel
 contain the minimal services
 small (10K bytes) and modular
 configurable by selecting components to compose a kernel
 RT extensions (to extend Unix or Windows)
 Why -- richer environment, more functionality, familiar interfaces
 Compliant kernel (LynxOS) -- Takes an existing RTOS and make it execute
other UNIX binaries
 Dual kernels– add an RTOS kernel between the hardware and the OS.
(RTLinux)
 OS kernel modifications – use patches to make Linux kernel more
deterministic (Real-time Linux distributions)
CSE 530 EOSI Fall 2016
3
RTOS vs. OS
 Often used as a control device in a dedicated application
 Well-defined fixed-time constraints
 The system allows access to sensitive resources with defined response
times.
 interrupt latency and time for context switch
 worst-case and average response times
 Requirements of RTOS
 predictable (??)
 upper bounds for system calls and memory usage
 configuration of memory layout and kernel data structures
 fine grain interrupt control
CSE 530 EOSI Fall 2016
4
Zephyr RTOS (1)
 Provide an OS that runs best on
MCUs for wearable and IoT devices,
where the cost of the silicon is
minimal.
 Highly Configurable
 Kernel mode only
 Nanokernel -- Limited functionality
targeting small footprint (below 10k)
 Microkernel (superset of nanokernel):
with additional functionality and
features.
 No user space and no dynamic
runtimes
 Memory and Resources are typically
statically allocated
 Cross architecture (IA32, ARM, ARC)
CSE 530 EOSI Fall 2016
(http://events.linuxfoundation.org/sites/events/files/slide
s/Zephyr%20Overview%20%20OpenIOT%20Summit%202016.pdf)
5
Zephyr RTOS (2)
 OS as a library
 One single executable which is executed in one single address space
 No loader is required to dynamically load applications at run-time
 Minimizing the operating system code
 System calls are implemented as function calls
 No context switches are required when calling an operating system call
 Lack of security through hardware memory separation
 Application and operating system calls are implemented as thread in the
same address space
 Bugs in one part of the system can affect the whole system
 Zephyr requires all system resources to be defined at compile-
time to reduce code size and increase performance.
CSE 530 EOSI Fall 2016
6
Zephyr Kernel Features
 Multi-threading services
 priority-based, non-preemptive fibers and priority-based, preemptive tasks
(with optional round robin timeslicing).
 Interrupt services
 compile-time and run-time registration of interrupt handlers
 Inter-thread synchronization services
 binary semaphores, counting semaphores, and mutex semaphores.
 Inter-thread data passing services
 basic message queues, enhanced message queues, and byte streams.
 Memory allocation services
 dynamic allocation and freeing of fixed-size or variable-size memory blocks.
CSE 530 EOSI Fall 2016
7
Zephyr Kernel Objects and Scheduling Contexts
 Fiber
 Cooperatively scheduled, i.e. run until they yield or call a blocking API
 Marked as not runnable and then the next highest priority fiber then runs
 Typically used for device drivers and performance-critical work
 Priority : 0 (highest) to 232-1
 Task
 A task is scheduled when no fibers are runnable
 Preemptible
 Highest priority task runs first and round-robin time-slicing between tasks of
equal priority
 Priorities -- 0 (highest) down to CONFIG_NUM_TASK_PRIORITIES-2.
CONFIG_NUM_TASK_PRIORITIES-1for the microkernel’s idle task.
 ISR
 Can interrupt fibers and tasks
 Nested ISRs are on by default
 ISRs can mark fibers or tasks as runnable
CSE 530 EOSI Fall 2016
8
Kernel Services
 Nanokernel
 Task Services – only one background task (main)
 Fiber Services
 Timer Services -- to determine whether or not a duration has elapsed
 Synchronization Services -- nanokernel Semaphore
 Data Passing Services – FIFO, LIFO, stack (array of words), ring beffer
 Interrupt Services
 Kernel Event Logger
 Microkernel
 Task Services
 Fiber Services
 Timer Services
 Memory Management Services – memory map and memory pool
 Synchronization Services – semaphore, mutex, and event
 Data Passing Services – FIFO, mailbox, and pipe
CSE 530 EOSI Fall 2016
9
Application Development in Zephyr (1)
 Application as a “main” function
 To be called after OS is initialized
 OS and application are statically linked as a single image
 make app integrated with kernel build by including $(ZEPHYR_BASE)/Makefile.inc
 CONFIG to control the configuration of the build
 ld script to allocate segments to RAM and produce an elf file
 To run an application
 Firmware to boot the hardware
 GRUB to load a pre-built elf image file to RAM
 Start to initialize nanokernel and microkernel (if needed) and then jump to main
 The entry point is defined by the linker
 the `-e' entry command-line option;
 the ENTRY(symbol) command in a linker control script;
 the value of the symbol start, if present;
 the address of the first byte of the .text section, if present;
 the address 0.
CSE 530 EOSI Fall 2016
10
Application Development in Zephyr (2)
 Build application
 Create a GRUB2 bootloader image
 Prepare boot device (SD card)
 copy kernel file (application + kernel) to SD card
 copy GRUB.efi to SD card
 create grub.cfg on SD card
 Zephyr == Wind River Rocket ??
 Try Wind River Helix App Cloud (a cloud-based software development platform)
 http://www.windriver.com/products/helix/app-cloud/
 register and create a project (C application template – Wind River Rocket for Intel Galileo Gen 2)
 Zephyr source code in GitHub
 https://github.com/01org/zephyr
 Note: calling convention for x86
 System V ABI -- parameters to functions are passed on the stack in reverse order
 IAMCU ABI -- the first three parameters of scalar types are passed in %eax, %edx, and %ecx.
CSE 530 EOSI Fall 2016
11
Application Development in Zephyr (3)
 Makefile and config file to build application+kernel
 Predefined variables configure the development project:
 ARCH: the build architecture for the kernel.
 ZEPHYR_BASE: the path to the kernel’s base directory.
 PROJECT_BASE: the application project directory path.
 SOURCE_DIR: the source code directory is set to $(PROJECT_BASE/)src/ by default.
 BOARD: Selects the board that the application’s build will use
 CONF_FILE: includes the kconfig configuration values that override the default ones.
 O: Optional. the output directory stores all the files generated during the build process.
The default is the $(PROJECT_BASE)/outdir directory.
 The example Makefile in $(PROJECT_BASE)
KERNEL_TYPE = nano
BOARD ?= qemu_x86
CONF_FILE = prj.conf
include ${ZEPHYR_BASE}/Makefile.inc
(KERNEL_CONFIG = $(ZEPHYR_BASE)/kernel/configs/$(KERNEL_TYPE).config
 The Makefile in $(PROJECT_BASE)/src: obj-y += main.o
CSE 530 EOSI Fall 2016
12
Linking and Loading for Zephyr
 The Makefile in $(SOURCE_DIR)
 Generates a file of link options: zephyr.lnk
 The default ld script file defined in Makefile
KBUILD_LDS := $(srctree)/boards/$(BOARD_NAME)/linker.ld
 Define memory region
MEMORY {
RAM (wx):
IDT_LIST:
ORIGIN = PHYS_LOAD_ADDR, LENGTH = CONFIG_RAM_SIZE*1K
ORIGIN = 2K, LENGTH = 2K }
 #include <arch/x86/linker-common-sections.h> to allocate sections
SECTION_PROLOGUE(_TEXT_SECTION_NAME, (OPTIONAL),) {
*(.text_start)
*(".text_start.*")
*(.text)
*(".text.*")
……
*(.init)
……
KEXEC_PGALIGN_PAD(MMU_PAGE_SIZE)
} GROUP_LINK_IN(ROMABLE_REGION)
 Generate the final_linker.cmd in /outdir
CSE 530 EOSI Fall 2016
13