LINUX SOLUTIONS for ST IVI PLATFORMS - · In-vehicle Infotainment (IVI) In-vehicle Infotainment...

LINUX SOLUTIONS for ST IVI PLATFORMS

APG Automotive Infotainment Division

Navi&Mm Sys & Appli

Dott. Maddalena Brattoli

Dott. Ing. Giancarlo Asnaghi

11 Jan 2012

AGENDA

• STMicroelectronics: presentation

• Automotive In-Vehicle Infotainment

• Open Source ERA in Auto Industry: Genivi OS distributions

• Intel/ST IVI_ConneXt : an asymmetric multiprocessor for IVI

– Architecture overview

– ARM processor

– ConneXt SW: ARM FW, Linux bsp, Meego

• Independent programming for ConneXt Atom and/or ARM

• Linux rpmsg AMP framework in IVI_ConneXt dual-processor system

• Application use cases in IVI_ConneXt multiprocessor environment

AGENDA

• STMicroelectronics: presentation


• Open Source era in Auto Industry: Genivi OS distributions



– ARM processor



• Linux rpmsg AMP framework in IVI_ConneXt dual-

processor system

• Application use cases in IVI_ConneXt multiprocessor

environment

Among the world’s largest semiconductor companies

A leading Integrated Device Manufacturer serving all electronics segments

A leading technology innovator (13,000 researchers, ~20,000 patents)

Key strengths in Multimedia Convergence, Power Applications and Sensors

Rich, balanced portfolio (ASICs, Application-Specific Standard Products and

Multi-Segment Products)

A pioneer and visionary leader in sustainability

President and CEO: Carlo Bozotti

2010 revenue: $10.35 billion

Approximately 53,000 employees including ST-Ericsson (Q4 '10)

Advanced research and development centers in 10 countries

39 design and application centers

15 main manufacturing sites

Corporate Headquarters: Geneva, Switzerland

78 sales offices in 36 countries

Public since 1994 - shares traded on New York Stock Exchange (NYSE: STM), Euronext Paris,

and Borsa Italiana

Created as SGS-THOMSON Microelectronics in June 1987, from merger of SGS

Microelettronica and Thomson Semiconducteurs

Renamed STMicroelectronics in May 1998

STMicroelectronics at a Glance

A world leader in providing the semiconductor solutions

that help our customers improve quality of life for everyone,

both today and in the future

5

ST is everywhere

Our semiconductor products and technologies add benefits

to every aspect of daily life

6

Company Organization by Business segments

7

Sales by Region (% of Q4 '10 Sales)

Business Segments & Customer Base

8

Navigation &

Multimedia Audio & Power Car Radio

Positioning Connectivity

Navigation

&

Telematics

Power

Amplifiers

Power

Management

Satellite

Tuners

Terrestrial

Tuners

Analog

Signal

Processing

CD Control

Automotive Infotainment

#4 Navigation Processors

#2 Positioning #1 Power Amplifiers

#1 Satellite Tuners

#2 Terrestrial Tuners

#1 Analog Signal Processing

Product

Market

Position

Major

Customers

Product

Lines

ST: leading supplier for Car Infotainment

Ranking Company

1

2

3

4

5

9

2009 Sales Split By Region

Driving growth through

convergence of multiple

technologies & applications

2009 Ranking, source iSuppli, Q2 2010

2009 Sales split by segment

AGENDA

• STMicroelectronics: introduction





– ARM processor




processor system


environment

In-vehicle Infotainment (IVI)

In-vehicle Infotainment (IVI)

A combination of technologies,

applications, services and content

for, but not limited to, automobiles

which satisfy a broad variety of

consumer needs including

entertainment, communication,

navigation, safety, maintenance

and commerce

IVI: Modularized and Distributed Architecture

IVI - Integrated Technologies and Services

IVI key technologies: Audio Management

AGENDA






– ARM processor




processor system


environment

Open-source in Automotive IVI-System

• The car is the platform, another node on the network

• Extend home and office computing to vehicles, simply, safely and

protected

• Consumers desire CE-like solutions

– Seamless connectivity to CE devices

– Easy expandability and upgradeability

• Increasing SW complexity

• Increasing development and maintenance cost for automakers

• Rapidly evolving technology

OPEN-Source SW landing on IVI-systems

Genivi

• GENIVI is a non-profit industry alliance committed to

driving the broad adoption of an In-Vehicle Infotainment

(IVI) reference platform.

• It is focusing on the development of software and

hardware for in-vehicle infotainment. The driving forces in

this alliance are GM, BMW, Intel (Nasdaq: INTC), Monta

Vista and others.

17

http://www.intel.com/

ST Genivi membership

Genivi-compliant OS distributions

• Canonical Ubuntu IVI Remix

http://www.canonical.com/engineering-services/ubuntu-core

• Linux Foundation MeeGo IVI Project

https://www.meego.com/devices/in-vehicle

• Mentor Embedded IVI Base Platform

http://go.mentor.com/iviplatform

• MontaVista Automotive Technology Platform (ATP)

http://www.mvista.com/sol_detail_ivi.php

• Wind River Platform for Infotainment

http://www.windriver.com/solutions/automotive/infotainment.html












http://go.mentor.com/iviplatform

http://www.mvista.com/sol_detail_ivi.php

http://www.windriver.com/solutions/automotive/infotainment.html

AGENDA




• Intel/ST IVI_ConneXt : an asymmetric multiprocessor chip

for IVI platform


– ARM processor




processor system


environment

21

What is ConneXt ?

• Companion chip of

Intel’s Tunnel

Creek(**) for In-

Vehicle

Infotainment

market

• Expands the

connectivity

towards a wide set

of peripherals &

interfaces

SDVO

LVDS

Intel® High Definition Audio

DDR2 (up to 800MTs mem down)

14 GPIO

SPI Flash

SIO

LPC

PCIe 3x1

1 CAN

4 I2C

3 SPI

4 UART

1 USB2.0 client / OTG

3 USB2.0 host

2 SATA II 4 SD/SDIO/MMC

Ethernet 10/100 AVB

>8 GPIO

PCIe 1 x1

Tunnel Creek (**)

(**) Internal Intel code names, subject to change

6 I2S/TDM/SPI

MSP

Video-IN (multiplexed)

Converts to dRGB

& LVDS oLDI

Audio Router Multi IN / Multi OUT

SDVO

INTEL CONFIDENTIAL

INTEL CONFIDENTIAL

PC

Ie 4

x1

Interconnect Fabric

Oth

er

Clo

cks/

Tim

ing

Au

dio

I/F

PC

Ie x

2

Po

we

r

Mg

mt.

Sto

rag

e

I/Fs

Vid

eo

I/F

HS

Se

rial

I/Fs

Po

we

r /

VR

Lo

w S

pd

Se

rial I/F

s

Netw

ork

Inte

rface

s

Para

llel

I/F

Acce

l.

Tunnel Creek**

Processor

Core

Memory

Controller

Graphics

& Video

Audio

SPI/LPC

Display

Controller

IOH

Target Segment

High volume segments

with uniform I/O e.g. IVI,

Media Phone, Premise

Service Gateway

Flexibility -> Scalable & Optimized Solutions

Roadmap and features are subject to change without notification ** Internal code names, subject to change

animated

22

Description Tunnel Creek** CPU

CPU Core 0.6 to 1.3GHz LPIA Core Hyper-Threading and Virtualization (VTx) 45nm High K Process

Graphics Integrated 2D/3D Graphics Engine Running up to 400MHz Supports OpenGL ES2.0, OpenVG 1.0, DirectX9.L Fill Rate (MPPS): 667-800

Display LVDS & SDVO Dual Independent Display 18/24-bit 1channel LVDS with max resolution of 1280x768@60Hz SDVO max resolution of 1920x1080@50Hz

Video Engine Integrated Hi-Definition Video Decoder & Encoder Encode format: MPEG4, H.263, H.264 Decode format: MPEG2, MPEG4, VC1, WMV9, H.264

Memory Controller

Single 32-bit channel, DDR2 667/800, 1GB max, memory down

Audio Integrated Intel® Hi-Definition Audio

IO 4 PCIe x1 ports host only

TDP 2~3 W

Intel IVI reference starter kit

Tunnel Creek

Au

to C

on

ne

cto

r

HD Audio CODEC

IOH

MO

ST

FO

T

1 GB DDR2 USB mini-B

Connector

PCI-

Express*

x 1

LVDS (VIDEO)

MOST INIC

Audio

Connector

NAND Flash

Bluetooth

LPC

Radio Tuner

SM

A

HD Audio

On/Off

I/O

ControllerCAN

Vehicle I/O

SM

A

PC

I-Exp

ress x 1

SATA II x2

SD

Ca

rd

Slo

ts

Touch

Screen I/F

Gigabit

Ethernet

PHY

RJ

45

USB

ConnectorsUSB 2.0 x 3

To Antenna

To Antenna

1-DIN Motherboard

RS232

SDVO

Video Capture

SDIO

2 S

pa

re P

CI-E

xpre

ss x 1

PC

Ie

Min

islo

t

(1)

US

B 2

.0 x

1

dRGB or LVDS

System Power Supply

(IMVP compliant)VBATT

24

ConneXt block diagram

4 SDIO

AUDIO ROUTER

6 TDM / I2S

10-100 MAC

Ethernet

AVB

System Interconnect

PCIe

eSRAM

buffer

0 1 2 3 4 5

Block Diagram Revision 2.2

GPIOs

1 CAN

1 MLB

4 UART

3 SPI

4 HS I2C

Bridge

DISPLAY BRIDGE

Open LDI

/ dRGB

SDVO

Video-IN

656/dRGB

PHY PHY

2 SATA II

PHY PHY PHY

3 USB 2.0

HOST

PHY

1 USB 2.0

OTG

PH

Y

PHY PHY

SDVO dRGB LVDS

OpenLDI

6 Sample Rate Converters

system

DMA

25

ConneXt exhaustive features set

System Interfaces

• 3 USB 2.0 Host with integrated PHY

• 1 USB 2.0 OTG with integrated PHY

• 4 SD/SDIO/MMC interfaces

• Serial ATA controller with 2 Serial ATA ports (SATAII) and integrated PHY

IVI Networking • 1 CAN interface

• 1 MLB (3 pins interface)

• Ethernet 10/100 MAC with RMII supporting Audio-Video Broadcasting support

Standard Interfaces

• 4 UART interfaces

• 4 I2C

• 3 Synchronous Serial Port (SPI)

• 32-bit GPIO ports, for 128 GPIO out of which 8 dedicated IOs

Audio Subsystem

• Multi-port audio router allowing configurable routing among all the audio ports

• AudioPLL

• 6 multi-channel TDM serial ports (MSP)

• 2 sample rate converters of 3 stereo channels

Video Interface

• Video Input Port (ITU-R BT 601/ 656/ Digital RGB input)

• Display format converter from SDVO to Digital RGB out or LVDS/Open-LDI

Miscellanea

• Real Time Clock (RTC)

• Clock management Unit with internal PLLs

• Multi-channel multi-port system DMA controller, 64kB embedded memory

26

ConneXt Reference Board: top view

** Internal Intel code names, subject to change

ConneXt IOH System

27

28

PCIe description

• PCI Express link 1.0 compliant

• Embedded switch – 4 downstream ports

– Configurable port arbitration scheme (round robin / credit based)

– 128Byte max packet size

• 4 Embedded endpoints – 8 functions / endpoint scheme

EP1 EP2 EP3 EP0

Root

Complex

Switch

Amba Bus Matrix architecture

Internal AMBA Memory Mapping

30

PCI Express

RX

PCI Express

TX

PCI Express

to AHB

Converter

AHB

to PCI Express

Converter

Control,

Status,

Debug,

Registers

AHB Master AHB Slave

PCI Express to AMBA Flow

AMBA to PCI Express Flow

AMBA Control Flow

PCI Express Control Flow

Request Flow

Response Flow

PCI

domain

AMBA

domain

PCIe to AMBA Bridge – Data Flow

32

EP mapping table

EndPoint 1

0 SATA II Controller (2 ports)

1 I2C 0

2 I2C 1

3 I2C 2

4 I2C 3

5 SPI HS Controller (INIC devices compliant)

6 SPI Controller

7 SPI Controller

EndPoint 0

0 USB 2.0 Host Controller (3 ports)

1 USB OHCI Controller

2 USB 2.0 OTG device

3 UART 0

4 UART 1

5 UART 2

6 UART 3

7 SOC DMA

EndPoint 3

0 Video Input port (ITU-656 + ITU-601)

1 Display bridge port (SDVO/in - digRGB/out)

2 Audio router DMA

3 Audio Router SRCs

4 Audio Router MSPs

5 CAN

6 MLB

7

EndPoint 2

0 MAC 10/100 Ethernet

1 SDIO 0

2 SDIO 1

3 SDIO 2

4 SDIO 3

5 SOC infrastructure (PM, GPIO, etc.)

6

7

Listing PCI bus hyerarchy

33

-[0000:00]-+-00.0 8086:4114

+-01.0 8086:8183

+-17.0-[0000:01]----00.0 1095:3132

+-18.0-[0000:02-03]----00.0-[0000:03]--+-05.0 1131:1561

| +-05.1 1131:1561

| +-05.2 1131:1562

| \-06.0 10ec:8167

+-19.0-[0000:04-09]----00.0-[0000:05-09]--+-00.0-[0000:06]--+-00.0 104a:cc00

| | +-00.1 104a:cc01

| | +-00.2 104a:cc02

| | +-00.3 104a:cc03

| | +-00.4 104a:cc03

| | +-00.5 104a:cc04

| | +-00.6 104a:cc04

| | \-00.7 104a:cc05

| +-01.0-[0000:07]--+-00.0 104a:cc06

| | +-00.1 104a:cc07

| | +-00.2 104a:cc07

| | +-00.3 104a:cc07

| | +-00.4 104a:cc07

| | +-00.5 104a:cc0c

| | +-00.6 104a:cc14

| | \-00.7 104a:cc12

| +-02.0-[0000:08]--+-00.0 104a:cc09

| | +-00.1 104a:cc0a

| | +-00.2 104a:cc0b

| | +-00.3 104a:cc0b

| +-00.4 104a:cc0b

| | +-00.5 104a:cc15

| | +-00.6 104a:cc16

| | \-00.7 104a:cc11

| \-03.0-[0000:09]--+-00.0 104a:cc0d

| +-00.1 104a:cc13

| +-00.2 104a:cc08

| +-00.3 104a:cc08

| +-00.4 104a:cc08

| +-00.5 104a:cc0e

| +-00.6 104a:cc0f

| \-00.7 104a:cc10

+-1a.0-[0000:0a-0b]----00.0-[0000:0b]----00.0 102b:2527

+-1b.0 8086:811b

\-1f.0 8086:8186

$ lspci –H1 –vtn

lspci is a command for displaying

information about all PCI buses in the

system and all devices connected to

them.

Embedded processor subsystem

ARM966E-S integer core@208MHz

A coprocessor 15 (CP15) used for programming, TCM and

protection modules

A 32-bit AHB Master bus interface

Programmable Tightly-Coupled Memory (TCM) interfaces

for Instruction and Data

32 KB of eSRAM

– four instances of 8Kbyte modules configurable as TCM

– TCM memory configurable up to 16KB-I 16KBD

34

ARM966 interface with TCM memories

35

Intel <-> ARM communication: MAILBOX registers

36

A general

purpose

mailbox in

each direction

is provided for

each EP

AHB to PCIE Mailbox

AHB Host

37

PCI Host

PCI Host Enable

Mailbox

1. Write

message 2. Set Mailbox

Ready bit

3. Read

PAB_MAILBOX_AHBCR

Address Offset: B24

PAB_MAILBOX_AHBDR

Address Offset: B28

PAB_PEXIER_MISC

Address Offset: B94

Reset Value: 0x0000_03FE

PAB_PEXISR_MISC

Address Offset: BA8

5. Clear

Bit 0

AHB to PCIE Message Transfer

38

For the data transfer from AHB to PCIE

AHB host writes the data to the AHB Mail Box register

(PAB_MAILBOX_AHBDR @ 0xB28)

AHB host sets the ready bit in the AHB Mail Box control register

(PAB_MAILBOX_AHBCR @ 0xB24 )

PEX interrupt (MSI) is generated to PCIE if “AHB to PCIe Mailbox

Ready” bit is enabled in the PEX Interrupt Enable Register MISC

(PAB_PEXIER_MISC @ 0xB94). MSI int is sent on F0.

PCIE host clears the ready bit in the AHB Mail Box control register

(PAB_MAILBOX_AHBCR )

PCIE host clears the “AHB to PCIe Mailbox Ready” status bit in Pex

Interrupt status register MISC (PAB_PEXISR_MISC@ 0xBA8) after

reading the Data.

PCIE to AHB Mailbox

AHB Host

39

PCI Host

PCI Host Enable

Mailbox

1. Write

message 2. Set Mailbox

Ready bit

3. Read PAB_MAILBOX_PEXCR

Address Offset: B64

PAB_MAILBOX_PEXDR

Address Offset: B68

PAB_AHBI_MISCSTAT

Address Offset: C00

5. Clear

Bit 0

PAB_AHBI_MISCENABLE

Address Offset: BEC

Reset Value: 0x0000_03FE

PCIE to AHB Message Transfer

40

For the data transfer from PCIE to AHB,

PCIE host writes the data to the PCIE Mail Box register

(PAB_MAILBOX_PEXDR @ 0xB68)

PCIE host sets the ready bit in the PCIE Mail Box control register

(PAB_MAILBOX_PEXCR @ 0xB64).

AHB interrupt is generated to AHB Host if “PCIE to AHB Mailbox

Ready” bit is enabled in the AHB Interrupt Enable Register MISC

(PAB_AHBI_MISCENABLE @ 0xBEC).

AHB host clears the ready bit in PAB_MAILBOX_PEXCR @ 0xB64

AHB host clears the “PCIE to AHB Mailbox Ready” status bit in AHB

Interrupt status Register MISC (PAB_AHBI_MISCSTAT @ 0xC00)

after reading the Data.

ConneXt SW Overview

Four main components

• Bootstrap Code: ConneXt boot from ARM

– ARM966’s code to be executed at system startup

– stored into 32KB of embedded ROM

• BIOS / IPL: Tunnel Creek boot and platform startup

– Host CPU (Intel TC) code which perform enough hardware initialization to

load and start the OS

• e.g. enable disk for booting off disk, Ethernet for network boot

• OS kernel (Linux, WinCE, QNX)

– Host CPU (Intel TC) code including specific ConneXt device drivers

• Middleware and Application

– OS frameworks on TC (i.e. Moblin, MEEGO)

41

42

ConneXt boot firmware

• Minimal ROM code for initial startup

• Boot code loaded from eMMC and executed by embedded ARM uC in eSRAM

• It can be extended / customized for – Advanced IP configuration

– Optimized interrupt management

– Optimized peripheral management

• Boot code upgrade from SD Card available through GPIO bootstrap option

Tunnel Creek boot and Platform Startup

• Executed on TC and performing required startup

operations, i.e.

– initialize memory controller with RAM refresh rate

– set chip selects to enable hardware such as flash, etc.

– PCI enumeration and resource allocation (BAR, memory, interrupt)

– Boot device configuration for OS loading

• Platform Dependent:

– BIOS on Northville Platform

– Trinity Lake Bootloader on Crossville Platform

• Optimized Boot Time (targeting 0.5 msec boot)

– IPL (Initial Program Loader on HB QNX platfom)

43

OS kernel: ConneXt Linux bsp

• Set of drivers for configuration / control of ConneXt IC

• ConneXt Linux drivers released as open source (under GPL/LGPL license) on SourceForge

• Submission to official Linux kernel http://www.kernel.org : on-going

• Already integration in Meego IVI

44

Kernel.org http://meego.com/developers/hardware-enabling-process

http://www.kernel.org/

http://meego.com/developers/hardware-enabling-process





45

ConneXt driver overview

Block Diagram Revision 2.2

LVDS

OpenLDI

4 SDIO

10-100 MAC

Ethernet

AVB

System Interconnect

PCIe

eSRAM

buffer

0 1 2 3 4 5

GPIOs

1 CAN

1 MLB

4 UART

3 SPI

4 HS I2C

Bridge

DISPLAY BRIDGE

Open LDI

/ dRGB

SDVO

Video-IN

656/dRGB

PHY PHY

2 SATA II

PHY PHY PHY

3 USB 2.0

HOST

PHY

1 USB 2.0

OTG

PH

Y

PHY PHY

SDVO dRGB

6 Sample Rate

Converters

system

DMA

AUDIO ROUTER 6

TDM/I2S

USB EHCI / OHCI.ko USB_OTG.ko SATA _EHCI.ko ETH MAC VIP (656/601)

ETH AVB

I2C.ko

SPI.ko

UART.ko

MSP/I2S

GPIO.ko

CAN.ko

MLB.ko

MSP/TDM

SaRaC

SDI.ko

SDIO.ko

IEGD Port Driver

SYS DMA

ConneXt drivers om SF.net

Middleware and Application: Meego IVI for ConneXt

AGENDA





for IVI platform


– ARM processor




processor system


environment

Development PC

ARM only development chain

49

ARM

ARM COMPILER

ARM SOURCE CODE

ARM Binary

DEBUG

DE

BU

G

Lauterbach TODO Details

50

JTAG

Joint Test Action Group

Used for:

•Code upload

•debug

Lauterbach 2 details

51

Lauterbach 3 register access

Linux develoment chain

53

Development PC

x86

Linux Virtual Machine

X86 COMPILER

LINUX SOURCE CODE

Linux Development chain

• Debug, ssh, compiler, scp, rlogin,git

GIT

gcc rlogin

Development PC

Linux Virtual Machine

ARM & Linux Development chain

55

ARM

x86

ARM COMPILER X86 COMPILER

ARM SOURCE CODE LINUX SOURCE CODE

DEBUG D

EB

UG

AGENDA





for IVI platform


– ARM processor




processor system


environment

RPMsg

Remote Processor Messaging

• rpmsg - a virtio-based messaging bus that allows kernel drivers to

communicate with remote processors available on the system

• new open-source friendly Inter Processor Communication (IPC)

framework developed in 2011. RPMsg facilitates multimedia

applications to offload some of the processor-intensive tasks to

dedicated co-processors or hardware accelerators.

• RPMsg is the IPC component used within Android 4.0 (IceCream

Sandwich), and was first developed on top of Linux 3.0 kernel

SMP and AMP processors

“Modern SoCs typically employ a central symmetric multiprocessing (SMP)

application processor running Linux, with several other asymmetric

multiprocessing (AMP) heterogeneous processors running different instances of

operating system, whether Linux or any other flavor of real-time OS”

AMP remote processors usually employ dedicated multimedia hardware

accelerators and are often used to:

– offload cpu-intensive multimedia tasks from the main application processor.

– control latency-sensitive sensors

– drive arbitrary hardware blocks

– perform background tasks while the main CPU is idling.

SMP core

Linux

AMP#1

RTOS

AMP#2

RTOS

AMP#3

BIOS

Userland

Gstreamer

Kernel

drivers

AMP usage Requirements

• Device Management remoteproc module

• Messaging framework rpmsg module

SMP core

Linux

AMP#1

RTOS

Remoteproc

•Configure the device

•Load the firmware

•Create a virtio device

rpmsg

•Create the channel

•send/receive messages

remoteproc drivers/amp/remoteproc/

generic kernel component managing remote

processors and enables users access to these

remote processors. The main functionalities

implemented by remoteproc are:

• Device Loading & Bootup

• Power Management

• Exception Management & Error Recovery

remoteproc API

• rproc_boot- Get a handle to a remote processor instance

struct rproc *rproc_get(const char *name); – Power up the remote processor and boot it

– load the proper firmware image

• rproc_shutdown - Release the handle to the remote processor

void rproc_put(struct rproc *rproc); – Power off the remote processor

• rproc_set_constraints - Set specific constraints on a remote processor

device

int rproc_set_constraints(struct rproc *rproc, enum rproc_constraint type,

long v) – request specific constraints like frequency, bandwidth or latency on a particular remote processor.

Connext ARM

• Load the firmware (ARM code)

• Manage the status of the remote processor

stm smARMTCM

TCM 8I-8D - code

loading

TCM 16I-8D -

Execution

AHB - ARM WFI

Code load B0 B1

ARM bootstrap

HW initialization

Cold Boot

TCM 16I-8D

copy B3 to B0

rpmsg – drivers/amp/rpmsg

• Send messages

• Receive messages

• Multiple channel

static struct rpmsg_driver sample_client = {

...

.id_table = sample_id_table,

.probe = sample_probe,

.callback = sample_rx_callback,

} static int __init client_sample_init(void)

{

return register_rpmsg_driver(&sample_client);

}

static int sample_probe(struct rpmsg_channel

*rpdev)

{

return rpmsg_send(rpdev, “test”, 4); static void sample_rx_callback(struct

rpmsg_channel *rpdev,

void *data, int len, void *priv, u32 src)

{

// incoming message ! Let's do something

smart...

}

static struct rpmsg_device_id sample_id_table[] = {

{ .name = "rpmsg-client-sample" }, { },

}

rpmsg API – configuration functions

• rpmsg_create_ept - Create a communication end point

struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev, void (*cb)(struct rpmsg_channel *,

void *, int, void *, u32), void *priv, u32 addr); Every rpmsg address in the system is bound to an rx

callback (so when inbound messages arrive, they are dispatched by the rpmsg bus using the

appropriate callback handler) by means of an rpmsg_endpoint struct.

• This function allows drivers to create such an endpoint, and by that, bind a callback, and possibly some

private data too, to an rpmsg address (either one that is known in advance, or one that will be

dynamically assigned for them).

• Simple rpmsg drivers need not call rpmsg_create_ept, because an endpoint is already created for them

when they are probed by the rpmsg bus (using the rx callback they provide when they registered to the

rpmsg bus).

• So things should just work for simple drivers: they already have an endpoint, their rx callback is bound

to their rpmsg address, and when relevant inbound messages arrive (i.e. messages which their dst

address equals to the src address of their rpmsg channel), the driver's handler is invoked to process it.

• rpmsg_destroy_ept - Destroy or Delete an existing communication end point

void rpmsg_destroy_ept(struct rpmsg_endpoint *ept);

• register_rpmsg_driver - Register a rpmsg client driver with rpmsg bus

int register_rpmsg_driver(struct rpmsg_driver *rpdrv);

• unregister_rpmsg_driver - Unregister a rpmsg client driver with rpmsg bus

void unregister_rpmsg_driver(struct rpmsg_driver *rpdrv);

Rpmsg API 2 – send functions

• rpmsg_send - Send a message on a rpmsg device.

int rpmsg_send(struct rpmsg_channel *rpdev, void *data, int len); Sends a message across to the remote processor on a

given channel. The caller should specify the channel, the data it wants to send, and its length (in bytes).

• In case there are no TX buffers available, the function will block until one becomes available (i.e. until the remote

processor will consume a tx buffer and put it back on virtio's used descriptor ring), or a timeout of 15 seconds elapses..

• rpmsg_sendto - Send to a specific endpoint tied on a rpmsg device

int rpmsg_sendto(struct rpmsg_channel *rpdev, void *data, int len, u32 dst); Sends a message across to the remote

processor on a given channel, to a destination address provided by the caller.

• rpmsg_send_offchannel - Send a message to a specific endpoint from a specific endpoint

int rpmsg_send_offchannel(struct rpmsg_channel *rpdev, u32 src, u32 dst, void *data, int len);

• rpmsg_trysend - Non-blocking rpmsg_send function

int rpmsg_trysend(struct rpmsg_channel *rpdev, void *data, int len);

• In case there are no TX buffers available, the function will immediately return -ENOMEM without waiting until one

becomes available.

• rpmsg_trysendto - Non-blocking rpmsg_sendto function

int rpmsg_trysendto(struct rpmsg_channel *rpdev, void *data, int len, u32 dst); Sends a message across to the remote

processor on a given channel, to a destination address provided by the user.

• In case there are no TX buffers available, the function will immediately return -ENOMEM without waiting until one

becomes available. The function can only be called from a process context (for now). Returns 0 on success and an

appropriate error value on failure.

• rpmsg_trysend_offchannel - Non-blocking rpmsg_send_offchannel function

int rpmsg_trysend_offchannel(struct rpmsg_channel *rpdev, u32 src, u32 dst, void *data, int len);

Rpmsg Resources

• http://lwn.net/Articles/464391/

• http://lwn.net/Articles/448562/

• http://www.gossamer-threads.com/lists/linux/kernel/1399674

• http://elinux.org/images/3/32/AMP_ELCE2011.pdf

• Linux kernel:

Documentation/ABI/testing/sysfs-bus-rpmsg

Documentation/remoteproc.txt

Documentation/rpmsg.txt

http://lwn.net/Articles/464391/

http://lwn.net/Articles/448562/

http://www.gossamer-threads.com/lists/linux/kernel/1399674







http://elinux.org/images/3/32/AMP_ELCE2011.pdf

AGENDA





for IVI platform


– PCI-AMBA bridge

– ARM processor




processor system


environment

68

Embedded processing capabilities

• Embedded Microcontroller: – ARM966@208MHz

– TCM memory configurable up to 16KB-I 16KBD

Potential Use Cases:

• WLAN data transfer optimization

• Extend ConneXt audio/video filtering capabilities

• Audio Processing optimization

• SDIO interrupts load optimization

• Advanced boot management – Early audio routing

– Early peripherals configuration (Video-in, etc.)

– Flexible local I/O management (CAN, I2C, etc.)

69

Example #1: WLAN data transfer optimization

• Intel CPU driver is responsible for the initialization of the WLAN chip and ARM

• Data transfer is controlled by the ARM

• The ARM gets a list of receive and transmit descriptors (scatter/gather) from the Intel driver

• ARM processes descriptors and controls the whole data transfer autonomously after it was started by the Intel driver

70

Example #2: Video Input Filtering

Offload Intel TC from Video Input Color Conversion

YUV422 raster to YUV420

planar conversion

71

Example #3: Audio Processing Optimization – Physical view

FM

Ra

dio

A

ud

io

Cod

ec

AK

46

28

Blu

eto

oth

MEM

1GB

DDR2

TC

AR

M

Data

Control

Example #3: Audio Processing Optimization – Linux Component View

cmp cd tunneling route

PA (Pulse Audio

Sound Serv er)

ALSA1:::ALSA dev ice

0 PCM playback


0 PCM playback


1 PCM capture


1 PCM capture

ALSA1::Alsa Card 1

ALSA1::Alsa Card 2

ALSA1::MSP 1

ALSA1::MSP 2

ALSA1::FM Radio

ALSA1::I2C

ALSA1::AK4628

AudioCodec

ALSA1::I2C

«use»

«use»

«use»

«use»

«flow»

«use»

«use»

I2S (PCM)

«flow»

«use»

control

«flow»

I2S (PCM)

«flow»

«use»

Control

«flow»

«flow»

• FM Radio playback on the ConneXt audioCodec

THANK YOU! THANK YOU!

LINUX SOLUTIONS for ST IVI PLATFORMS - · In-vehicle Infotainment (IVI) In-vehicle Infotainment...

Documents

Transcript of LINUX SOLUTIONS for ST IVI PLATFORMS - · In-vehicle Infotainment (IVI) In-vehicle Infotainment...