Embedded Software Lab. @ SKKU 67 1 Sungkyunkwan University Tizen v2.3 Linux Kernel.

Embedded Software Lab. @ SKKU

67

1

Sungkyunkwan University

Tizen v2.3 Linux Kernel


67

2

• Memory Management• CMA (Contiguous Memory Allocator), IOMMU, dma_buf • ARM Linux has no DMA_ZONE on buddy• Some devices require physically contiguous memory (CMA), other

devices has IOMMU thus be able to use non-contiguous memory• Sharing DMA memory buffer for D/D to user

• Graphics• DRM (Direct Rendering Manager)

• Power management• CPUfreq, Devfreq, PM-QoS, Charger-manager

• KDBUS• Multimedia

• V4L2 (Video for Linux 2)

• EXTCON

Tizen v2.3 Kernel Additional features


67

3

• Linux 3.0.15– Obsolete LTS (Current: 3.4 & 3.10)

• Support RD-PQ (Tizen 2) & RD-210 (Tizen 1 & 2)– RD-PQ: Exynos4412– RD-210: Exynos 4210 (Linux 2.6.36 for Tizen 1)

• Not Good as Reference– Too many backported features.– Too OLD! No LTS/LTSI support– Many kernel hacks & dirty patches– git history removed.

• Forked from production kernel.• Hard to read

Previous Reference Kernel


67

4

• Long-Term Stable (LTS)– Maintained by Greg K.H.– Bugfixes for 2 years or longer.– Up to 2 LTS kernels at the same time.– Recent: 3.10.39 (2014/5/6)

• Long-Term Stable Initiative (LTSI)– Maintained by Greg K.H. and some manufacturers– Forked LTS for Industry. (LTS + Industry Patchset)– Maintain a common Linux base for use in a variety

of consumer electronics products– Longer support period.– Recent: 3.10.31-LTSI (2014/2/24)

Linux Kernel. LTS? LTSI?


67

5

• Two reference kernels: ARM/Intel

• ARM (armv7, aarch64)– Linux 3.10.y

• 3.10.33 @ 2014/05• Full git history

– Armv6 support (Raspberry Pi) Coming soon.– Test & validation phase (integration test with

userspace)

• Intel (x86, x86_64)– Linux 3.14.1– Recent ATOM Soc support merged

Status of Tizen Reference Kernels


67

6Tizen v2.3 Kernel Overview


67

7Tizen v2.3 Kernel Overview (Cont’d)


67

8Static Memory vs. CMA memory Multimedia example

dma_alloc_coherent()


67

9

• generalized memory manager that Google introduced in the Android 4.0 ICS

• Provides way for userland to allocate buffers from various “pools of memory” (aka: heaps)

• CMA also allows for large physically contiguous memory allocations by migrating memory to make room for the large allocation– CMA is kernel-internal only for now, and doesn't

have a interface to allow userland to allocate buffers or specify constraint options

– Migrating pages to make room can cause non-deterministic delays.

ION


67

10ION

Reserved Memory (Boot ) Dynamic Allocation

MEMBLOCK

KernelData / Code

PageTable CMA

ION- contiguous heap

ION- noncontigous heap

BUDDYsystem

C2Cblswitch

Media Drvier GPU

/sys/kernel/debug/memblock/reserved

/proc/cma

Allocation / Free

dma_bufDriver Attach

ION- chunk heap


67

11

Tizen v2.3 Memory Management


67

12

• Coupled with Graphics & Multimedia devices– Graphics & Multimedia devices = DMA devices

with HUGE Buffers

Tizen v2.3 Memory Management


67

13

• DRM is not Digital Right Management

• Direct Rendering Manager– Kernel-level graphics device driver that support

Direct Rendering Infrastructure.– Direct Rendering

• An application communicates directly with graphics device driver

– Display mode setting– Graphics memory management

What is DRM


67

14

• Can give display experiences similar to PC environment.

• Why not use DRM until now?– DRM was designed for PC– Embedded System

• Low performance• No dedicated graphics memory• Not one graphics card but separated hardware

devices

– Linux frame buffer driver

Why DRM


67

15

• Changed embedded environment– Powerful embedded SoCs– Requirements

• Display hotplug & clone, exteded mode• Unified memory management• Direct rendering• Varying device control with common interface

Why DRM (Cont’d)


67

16X11 infrastructure

DIX (Device-Independent X)DDX (Device-Dependent X),


67

17Early implementation of the Linux graphics stack

UMS (User-space Mode-Setting)


67

18Early implementation of the Linux graphics stack• XFree86 server: the first Linux 2D graphics hardware

acceleration– Super-user privileges– Access the card directly from user space, no kernel support – Simple and portable

• Utah-GLX: the first hardware-independent 3D accelerated design– User space 3D driver, directly accesses the graphics hardware from user

space– 3D hardware was clearly separated from 2D (3Dfx), completely

separate driver. • Framebuffer drivers

– Another component that could simultaneously access the graphics hardware directly.

– To avoid potential conflicts between the framebuffer and XFree86 drivers,

– On VT(virtual terminal) switches, the kernel would emit a signal to the X server telling it to save the graphics hardware state.

– More fragile and bug-prone drivers.• Drawbacks

– Security: unprivileged user space applications be allowed to access the graphics hardware for 3D.

– Performance: all GL acceleration had to be indirect through the X protocol


67

19DRI model


67

20DRI/DRM infrastructure

• To address the reliability and security concerns with the Utah-GLX model

• Additional kernel component whose duty is to check the correctness of the 3D command stream, security-wise.

• Instead of accessing the card directly, the unprivileged OpenGL application would submit command buffers to the kernel, which would check them for security and then pass them to the hardware for execution.

• Trusting user space is no longer required.

• Kernel Mode-Setting (KMS) – Merge the kernel framebuffer functionality into the DRM

module – X.Org access the graphics card through the DRM module

and run unprivileged. – DRM module is now responsible for providing mode-setting

services both as a framebuffer driver and to X.Org.Mode-setting: configuring video mode to get a picture on the screen. includes choosing the video resolution and refresh rates.


67

21Framebuffer Drivers

• Kernel graphics driver exposing its interface through /dev/fb*

• Despite their simplicity, framebuffer drivers are still a relevant option for basic 2D display.

• Especially for embedded systems– memory footprint is essential– do not require advanced graphics acceleration.

• Functionalities– Mode-setting– Optional 2D acceleration

• http://www.linux-fbdev.org/HOWTO/index.html


67

22Direct Rendering Manager

• Put critical initialization of the card in the kernel, for example uploading firmwares or setting up DMA areas.

• Share the rendering hardware between multiple user space components, and arbitrate access.

• Enforce security by preventing applications from performing DMA to arbitrary memory regions, and more generally from programming the card in any way that could result in a security hole.

• Manage the memory of the card, by providing video memory allocation functionality to user space.

• More recently, the DRM was improved to achieve mode-setting. – Simplifies the previous situation where

both the DRM and the framebuffer driver were fighting to access the same GPU.

– Instead, the framebuffer driver is removed and framebuffer support is implemented in the DRM.

Libdrminterfaces between user space and the DRM module, unprivileged user space component


67

23

• Currently, DRM support is only for Exynos SoCs. (ARM based)– Need Exynos specific DRM driver

• Exynos DRM driver– To support graphics hardware of Exynos SoCs– First ARM SoC graphics driver to use the DRM– Merged into the mainline linux 3.2 kernel– linux/drivers/gpu/drm/exynos

DRM of Tizen v2.3 kernel


67

24

• Graphics:– DRM (Direct Rendering Manager) / GEM

(Graphics Execution Manager)

Graphics (DRM / GEM)

GEM•Framework developed by Intel

• To manage graphics memory•Framework for buffer management

• Allocation and sharing


67

25

GEM Allocation steps @ Tizen (Generic)

1.DRM_IOCTL_MODE_CREATE_DUMB– Create GEM object(global) & user GEM handle(per process)

• dumb_create() of struct drm_driver– No physical memory allocated.

2.DRM_IOCTL_MODE_MAP_DUMB– Create fake mmap offset of a gem object and relay the object to

user• A hash key of the gem object.• dumb_map_offset() of struct drm_driver

3.MMAP1. Request mmap based on the hash key as the offset2. Create user address space3. Setup cache attribute.4. Not mapped to physical memory, yet

DRM / GEM Allocation


67

26

GEM Allocation steps @ Tizen (Generic)

4.On-demand Paging– Implement & Register a fault handler that

• With a page fault, allocate a page and map the page.– vma->vm_ops->fault = xxx_drm_gem_fault

5.Use!6.DRM_IOCTL_MODE_DESTROY_DUMB

4. Remove GEM handle & object5. Free memory6. Implement dumb_destroy() of struct drm_driver

DRM / GEM Allocation (Cont’d)


67

27

GEM Allocation steps @ Tizen (Exynos Only)

1.DRM_IOCTL_EXYNOS_GEM_CREATE– Only use user-desired size and buffer types.– Create gem object(global) & user gem handle(per process)– physical memory allocated.

2.DRM_IOCTL_EXYNOS_GEM_MMAP– Create user address space– Map the user address space to physical memory

3.LIBDRM of Exynos uses these APIs, not the generic.

DRM / GEM Allocation (Cont’d)


67

28

GEM Sharing @ Tizen

•DRM_IOCTL_GEM_FLINK– “I will share this GEM to others.”– Create GEM object name for the given GEM handle

• Global key value for sharing•DRM_IOCTL_GEM_OPEN

– “I want to use the shared GEM.”– Create GEM handle based on the given GEM object name

•DRM_IOCTL_GEM_CLOSE

DRM / GEM Sharing


67

29Tizen v2.3 Kernel MM –Multimedia (V4L2 / VB2)


67

30

• Tizen recommends to use V4L2 at Tizen kernel for Multimedia devices– Video input (codec & camera) & Radio– However, as long as the kernel has..:

• Gstreamer/OpenMAX plugins• A method to share with other F/W via DMABUF of

UMM• If V4L2/VB2 is used, things get easier.

V4L2 / VB2


67

31Tizen v2.3 Kernel MM –OpenGL / G3D-GPU


67

32

• Most ARM SoC GPUs (MALI, SGX, …) use their own memory manager– For mali400 GPU in Exynos4412– Three packages (for kernel 3.10)

• libump-mali-400.rpm (Unified Memory Provider Library)• libtbm-exynos4412.rpm (Tizen Buffer Manager Library)• gpu-ddk-mali-400.rpm (X11 Driver Development Kit)

– Source code is under the standard ARM commercial license to Mali GPU customers

– Mali DDK modified to be compatible with UMM-DMABUF.

• If GPU drivers use DRM, it would be great.– (and make them GPL)

OpenGL / G3D-GPU


67

33Graphic and Display Usage Scenario


67



67



67



67



67

38Tizen v2.3 kernel Buffer Sharing


67

39

• Requirement from Tizen platform and hardware– Different Memory Managers: GEM, VB2, GPU-

adhoc, …– Share buffers

• w/o memcpy• From and to users• Never expose directly to users (e.g., physical

address)

UMM DMABUF!

Tizen v2.3 Kernel Buffer Sharing (Cont’d)


67

40

• Introduced by Jesse Barker, 2011• Includes– DMABUF (sharing buffer)• Export–GEM/VB2/… object DMABUF

• Import–DMABUF GEM/VB2/… object

• Userspace sees DMABUF as a File Descriptor– DMA mapping API for allocation– CMA (Contiguous Memory Allocator)– IOMMU (MMU for I/O devs)

Unified Memory Management (UMM)


67

41DMA Buffer Sharing: Camera Display


67

42

• Camera App

1) Request V4L2 camera buffer (U)

2) Allocate CMA buffer (K)

3) Request a camera frame at the V4L2 buffer (U)

4) Store the camera frame & Notify user (K)

5) Request DMABUF export for the V4L2 camera buffer (U)

6) dma_buf_exporter() (K)

• Create DMABUF from V4L2 buffer

7) dma_buf_fd() (K)

• Provide FD of the DMABUF to user

DMA Buffer Sharing Example


67

43DMA Buffer Sharing Example (Cont’d)

• Camera App








7) dma_buf_fd() (K)



67


• Camera App








7) dma_buf_fd() (K)



67

45

• Camera App

8) Request FD->GEM conversion (U)

9) dma_buf_get(fd) (K)

• Get DMABUF from FD

10) dma_buf_attach(dma-buf) / dma_buf_map_attachment() (K)

• Get Buffer from DMABUF

11) Import as GEM, send user (K)

12) Request GEM object name (U)

13) Return GEM object name (K)

14) Send GEM object name to X (U)

DMA Buffer Sharing Example (Cont’d)


67


• Camera App

8) Request FD->GEM conversion (U)

9) dma_buf_get(fd) (K)

• Get DMABUF from FD

10) dma_buf_attach(dma-buf) / dma_buf_map_attachment() (K)

• Get Buffer from DMABUF

11) Import as GEM, send user (K)

12) Request GEM object name (U)

13) Return GEM object name (K)

14) Send GEM object name to X (U)


67

47

• X server 15) Convert given GEM object name to GEM. Display its content. (U & K)



67

48

• Close after usage1) “Free” the GEM object (U)2) Remove reference from the DMABUF (K)3) Close(DMABUF-FD) at cam app (U)4) (No more reference to DMABUF) Release callback executed (K)



67

49Buffer Synchronization


67

50

• Simple Usage Scenario– 1. CPU writes to buffer1.– 2. CPU tells GPU to do something on buffer1.– 3. GPU does something on buffer1.

• GPU finishes.

– 4. CPU reads the buffer1

Problem Definition

CPU GPU

BUS

DRAM

1 2

34

How to ensure CPU won’t use buffer 1 until step 4?


67

51

• What if there are two threads using GPU?– And if the two look at the same buffer?

• Not even aware of it?

• What if the two DMA devices (GPU, FIMC) share buffer?– But hard to know it at drivers or user threads.– FIMC never knows when GPU finishes– FIMC never knows when Threads1 stops using “buffer1”– Threads2 never know when GPU stops using “buffer1”

Problem Definition (Cont’d)


67

52

• TGL (Tizen Global Lock) @ Tizen 2.0– … Let userspace handle the issue …: dma_buf_sync– Kernel patch required.

• Sync Framework (Google)– Jun, 2012. Resources w/o DMABUF (similar with TGL)

• KDS (Kernel Dependency System, ARM)– May 2012 / DMABUF-compatible

• DMA Fence Framework (Canonical/TI/Samsung)– Aug 2012 / DMABUF-compatible– Jun 2013 / DMABUF-Sync Framework (Samsung)– https://bugs.tizen.org/jira/browse/PTF-11

Buffer Synchronization


67

53

K-dbus


67

54

• D-Bus– Message bus system– Method Call transaction– Signals– Broadcasting

Kdbus –D-bus is?


67

55

• Low-level, native kernel D-Bus transport– All communication between processes take place over

special character device nodes in /dev/kdbus• kernel copies the message from user space directly into

the receive buffer for the destination process.• Single copy to destinations

• memfds– File descriptor for memory regions– Zero copy implementation– Similar to ashmem in Android

Kdbus –K-dbus is?

http://lwn.net/Articles/580194/http://en.wikipedia.org/wiki/User:ScotXW/kdbus


67

56D-bus vs Kdbus


67

57

Others


67

58

• Extension of Android kernel's switch class located at linux/drivers/switch/

• Manage status of cable & ports– A port with multiple cables (docks, multi-cables, …)– A port with multiple modes (USB, HDMI, TA, …)

• 3.5pi: stereo, stereo+mic, stereo+mic+buttons, stereo+buttons, mono, …

• Compatible with Switch– Android Switch drivers can be easily ported

• Refer to Linux/Documentation (porting guide for switch driver)– Extcon drivers export both Switch and Extcon interfaces

(compat mode)• In Reference Device

– MUIC (USB+HDMI+TA+DOCK+…)– 3.5Pi Jack

EXTCON (External Connector)


67

59

• Charger Manager• /drivers/power/charger-manager.c– All needed by Tizen user space are prepared– No OAL modification required

• OR supply battery/charger interface with power-supply-class

• Use EXTCON for Cable-Input (MUIC in mobile)– Switch class is no longer available in Linux.

• Note: some SOC (state-of-charge) value is required for mobile profile. Unless, Tizen will assume that SOC is 0 Shutdown!

Charger


67

60Power Management (Tizen 2.x)

• Tizen v2.3 Kernel does not use opportunistic sleep like Android wake-lock

• Userspace(Power Manager) should request sleep directly


67

61Power Management (Tizen 3.0)

• Components (e.g., OOM) are merged and consolidated into Resourced.

• Tizen v3.0 use deviced Device control access is merged

into deviced

• Tizen v2.x use Power Manager App can access kernel device

node by using devman library


67

62

• Recommendation For Tizen3.0 or later– Do not use DVFS (CPUfreq/Devfreq) min/max ABIs• PASS (Power-Aware System Service in Deviced)

• PASS is a module in deviced/resourced (TBD, currently prototyped in system-server of Tizen 2.2) that monitors the userspace activities and controls #cores & DVFS conditions.

– Use (keep their standard ABIs for PASS)• CPUfreq& Devfreq (DVFS for non CPU devices if you have

them)• Thermal FW

– PASS gives hints to DVFS/Hotplug• based on the info from user space.• based on the other kernel ABIs (e.g., Thermal)• highly configurable. (control knob of performance & power)

Power Management


67

63

• Use ALSA Scenario (www.alsa-project.org)– Make hardware plugin and device driver based on ALSA

standard. • https://wiki.tizen.org/wiki/Porting_Guide#Audio

Other Peripherals: Sound


67

64

• Use Bluez(www.bluez.org)• https://wiki.tizen.org/wiki/

Porting_Guide#Bluetooth

Other Peripherals: BlueTooth


67

65

• Use wpa-supplicant• https://wiki.tizen.org/wiki/Porting_Guide#WLAN

Other Peripherals: WiFi


67

66

• Systemd (booting & daemon management)• Deviced/Resourced

– Power-manager, devman, and system-server are consolidated. • DBUS: The usage of Vconf is reduced

Core Daemons (Tizen 3.0)


67

67

• https://wiki.tizen.org/wiki/Porting_Guide#System_OAL• Tizen 2.0/adaptation/*

– Related to System FW:• Tizen 2.0/adaptation/ap_samsung/device-manager-plugin-

exynos• Tizen 2.0/adaptation/intel_mfld/device-manager-plugin-mfld-

blackbay– Related to Alsa (sound) :

• Tizen 2.0/adaptation/devices/alsa-scenario-*

OEM Adaptation Layer (OAL)

Date post:	20-Jan-2016
Category:	Documents
Upload:	harold-mathews
View:	230 times
Download:	4 times

Embedded Software Lab. @ SKKU 67 1 Sungkyunkwan University Tizen v2.3 Linux Kernel.

Documents