linux solutions for st ivi platforms - · in-vehicle infotainment (ivi) in-vehicle infotainment...
Post on 08-Jun-2020
9 Views
Preview:
TRANSCRIPT
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
• 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
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
• 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
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
• STMicroelectronics: introduction
• 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
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
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
AGENDA
• STMicroelectronics: introduction
• Automotive In-Vehicle Infotainment
• Open Source era in Auto Industry: Genivi OS distributions
• Intel/ST IVI_ConneXt : an asymmetric multiprocessor chip
for IVI platform
– 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
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
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
• STMicroelectronics: introduction
• Automotive In-Vehicle Infotainment
• Open Source era in Auto Industry: Genivi OS distributions
• Intel/ST IVI_ConneXt : an asymmetric multiprocessor chip
for IVI platform
– 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
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
• STMicroelectronics: introduction
• Automotive In-Vehicle Infotainment
• Open Source era in Auto Industry: Genivi OS distributions
• Intel/ST IVI_ConneXt : an asymmetric multiprocessor chip
for IVI platform
– 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
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
AGENDA
• STMicroelectronics: introduction
• Automotive In-Vehicle Infotainment
• Open Source era in Auto Industry: Genivi OS distributions
• Intel/ST IVI_ConneXt : an asymmetric multiprocessor chip
for IVI platform
– Architecture overview
– PCI-AMBA bridge
– 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
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
ALSA1:::ALSA dev ice
0 PCM playback
ALSA1:::ALSA dev ice
1 PCM capture
ALSA1:::ALSA dev ice
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!
top related