Fábio Coutada
ae6144a1c5
- Extract 37 of 45 PDFs under docs/ to docs-extracted/ - Preserve directory structure (apex, cdk, development, platform, etc.) - Add docs-extracted/index.md with navigation table - 8 PDFs were 0-byte/empty and could not be extracted
330 KiB
| title | source | category | pages | extracted |
|---|---|---|---|---|
| Platform Manual Arm | docs/platform/platform-manual-ARM.pdf | platform | 140 | 2026-07-06T23:05:36.432917 |
Platform Manual Arm
Extracted from
docs/platform/platform-manual-ARM.pdf(140 pages). Figures, diagrams, and tables may not render accurately in plain text.
PikeOS Platform Manual for ARM v7 Boards
Am Pfaffenstein 14, D-55270 Klein-Winternheim
Notice: The contents of this document are proprietary to SYSGO GmbH and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by SYSGO GmbH. PikeOS Platform Manual for ARM v7 Boards PikeOS D5.0, Document Version D5.0-461
c 2005 – 2019 SYSGO GmbH
SYSGO GmbH Email: office@sysgo.com Am Pfaffenstein 14 55270 Klein-Winternheim, Germany http://www.sysgo.com
All rights reserved. PikeOS is a trademark of SYSGO GmbH. The designations used to identify other software or hardware products in this publication may be trademarks of their manufacturers or sellers. Contents
1 About this Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 QEMU ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Set-up Environment for QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.4 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.5 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 i.MX6 Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.5 The PikeOS Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.6 PSP Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Nvidia Jetson TK1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.5 The PikeOS Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5 ZYNQ ZC702 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.5 The PikeOS Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.5.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.6 ZedBoard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.6.5 The PikeOS Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.6.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.7 LS102XA Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.7.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.7.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
4 CONTENTS
2.7.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.8 Cyclone V Family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.8.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.8.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.8.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.8.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.8.5 The PikeOS Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.8.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3 PSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Common PSP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3 IO Sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.4 KDEV Drivers IO Memory Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.5 Interrupts on ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.6 PSP qemu-arm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6.1 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6.2 Memory Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6.3 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.7 PSP imx6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7.1 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7.1.1 Cache L2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7.1.2 Performance Counters from User . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.7.2 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.7.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.7.4 IOMUX configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.7.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.7.4.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.7.4.3 Configuration example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.7.5 IO device driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.7.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.7.5.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.7.5.3 Usage instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.7.6 GPIO interrupt configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.7.7 PCI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.7.7.1 Controller initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.7.7.2 Configuring the integration project . . . . . . . . . . . . . . . . . . . . . . . . 53 3.7.8 Watchdog support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.8 PSP tegra-k1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.8.1 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.8.1.1 Performance Counters from User . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.8.2 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.8.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.9 PSP zynq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.9.1 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.9.1.1 Cache L2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
CONTENTS 5
3.9.1.2 Performance Counters from User . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.9.2 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.9.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.9.4 GPIO Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.9.5 IO Sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.10 PSP ls102xa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.10.1 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.10.2 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.10.3 PCI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.10.3.1 Controllers identification and initialization . . . . . . . . . . . . . . . . . . . . . 59 3.10.3.2 Configuring the integration project . . . . . . . . . . . . . . . . . . . . . . . . 59 3.10.4 MSI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.10.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.11 PSP cyclone-v . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.11.1 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.11.1.1 Cache L2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.11.1.2 Performance Counters from User . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.11.2 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.11.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4 Boot Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1 Serial drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.1 Serial IMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.1.1 User Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.1.2 Kernel Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.1.2.1 Kernel Fusion Project . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.1.2.2 Configuring the Integration Project . . . . . . . . . . . . . . . . . . . 66 5.1.2 Serial XuartPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.1.3 Serial PL011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.3.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.4 Serial 8250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.1.4.1 Driver Specific Configuration Parameters . . . . . . . . . . . . . . . . . . . . . 69 5.1.4.2 Driver IOCTL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1.4.3 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1.4.4 User Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1.4.5 Kernel Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.1.4.5.1 Kernel Fusion Project . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.1.4.5.2 Configuring the Integration Project . . . . . . . . . . . . . . . . . . . 71 5.1.5 Serial LPUART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2 Ethernet Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1 Ethernet IMX FEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.1.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.2.1.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 5.2.1.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2.1.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2.2 Ethernet XemacPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 5.2.2.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5.2.2.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
6 CONTENTS
5.2.2.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.2.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.3 Ethernet smc91cX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.3.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.4 Ethernet Felic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.4.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.4.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.4.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.4.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.5 Ethernet CPSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.5.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.5.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.5.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.5.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.6 Ethernet TSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.6.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.6.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.6.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.6.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.7 Ethernet DWC GMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.7.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.7.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.7.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.7.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.8 Ethernet virtio-net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.8.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.2.8.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.8.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.8.4 Maximum Transfer Size Configuration . . . . . . . . . . . . . . . . . . . . . . . 93
5.2.8.5 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.2.9 Ethernet e1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.2.9.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.9.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.9.3 BSP Configuration / PCI Device Configuration . . . . . . . . . . . . . . . . . . 95
5.2.9.4 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2.9.5 Maximum Transfer Size Configuration . . . . . . . . . . . . . . . . . . . . . . . 96
5.2.9.6 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3 Watchdog Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.1 Watchdog IMX WDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.3.1.1 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4 Block Device and MTD Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.1 Block Device and MTD Simulator blkdrvsim . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.1.1 Driver Specific Configuration Parameters . . . . . . . . . . . . . . . . . . . . . 97
5.4.1.1.1 blkdrvsim Base Component . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.1.1.2 blkdrvsim Device Component . . . . . . . . . . . . . . . . . . . . . . 98
5.4.1.2 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.1.3 Usage of the User Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.1.3.1 Integration Project for the User Level Driver . . . . . . . . . . . . . . . 99
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
CONTENTS 7
5.4.1.4 Usage of the Kernel Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.1.4.1 Fusion Project for the Kernel Level Driver . . . . . . . . . . . . . . . . 100
5.4.1.4.2 Integration Project for the Kernel Level Driver . . . . . . . . . . . . . . 100
5.4.1.5 Demonstration Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4.1.6 Driver Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4.2 Block uSDHC Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.4.2.1 Driver Specific Configuration Parameters . . . . . . . . . . . . . . . . . . . . . 102
5.4.2.1.1 SDHC Base Component . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4.2.1.2 USDHC Device Component . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.2.1.3 Operation Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4.2.1.4 BLK Devices for disk drive partitions . . . . . . . . . . . . . . . . . . . 103
5.4.2.1.5 SDHC Device Partition Component . . . . . . . . . . . . . . . . . . . 104
5.4.3 Partitioned Image Creation Tool mkblkimage . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5 PCI Controller Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.5.1 PSP PCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.5.2 PCI Layerscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5.2.1 General configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5.2.2 Component configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5.2.3 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5.3 MSI Layerscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.5.3.1 Component configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 5.5.3.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.5.3.3 Affinity support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 5.6 Clock Manager Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.6.1 i.MX6 Clock Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.6.1.1 Clock types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.6.1.2 List of clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.6.2 ZYNQ Clock Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.6.2.1 Clock types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.6.2.2 List of clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 5.7 GPIO Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.7.1 GPIO IMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.7.1.1 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.8 CAN Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.8.1 FlexCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.8.1.1 User Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.9 IOMMU Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.9.1 SMMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.9.1.1 System Memory Management Unit driver configuration . . . . . . . . . . . . . . 120 5.9.1.2 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6 The PikeOS CDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.1 Target binaries v7hf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7 Interrupt Setup on ARM Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.1 Periodic Timer Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.1.1 Cortex A9 and A15 Based Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.1.2 Other Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.2 GPIO Interrupt Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.3 MSI and MSI-X interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
8 CONTENTS
A Architecture Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.1 Supported Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.2 ASP Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.3 Address Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.4 Basic Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.5 User Mode Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.5.1 Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 A.5.2 Short Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 A.5.3 FPU Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 A.5.4 Thumb Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.5.5 ThumbEE Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.5.6 Jazelle Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.5.7 TLS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.5.8 Linux Signal Handling Helper Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 A.6 Mapping Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 A.6.1 Translation of PikeOS Access Permissions to Architecture Specific Access Permissions . . 130 A.6.2 Translation of Architecture Specific Access Permissions to PikeOS Access Permissions . . 131 A.6.3 Supported Caching Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 A.6.4 VMIT Cache Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 A.7 Translation of Architecture Specific Exceptions to PikeOS Trap Codes . . . . . . . . . . . . . . . 132 A.8 Kernel Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.8.1 Non-LPAE Kernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.8.2 LPAE Kernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 A.9 Cache Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 A.9.1 Data Cache Operations With a PL310 or L2C-310 Cache Controller . . . . . . . . . . . . . 135 A.10 Cache Attributes Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 A.10.1 ARM Erratum 782772 on Cortex A9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 A.11 Integer division-by-zero . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 A.11.1 Behavior of division-by-zero when using UDIV/IDIV . . . . . . . . . . . . . . . . . . . . . 136 A.11.2 Behavior of division-by-zero when using software division . . . . . . . . . . . . . . . . . . 136 A.11.2.1 Provide division-by-zero handlers . . . . . . . . . . . . . . . . . . . . . . . . . 136 A.12 Speculative Execution Side Channels Mitigations - Meltdown and Spectre . . . . . . . . . . . . . 137 A.13 Detection of Heterogeneous Processor Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 A.14 Building PSP for Cortex-A7 from source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 A.15 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 B Boards Fusion/PSP Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 C Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
1 About this Manual
This manual describes additional platform specific information and supported boards for the ARM architecture. The manual is organized as follows. The Boards sub-chapters discuss the individual board support packages for each board. Each BSP chapter con- tains information about available drivers, board specific settings or pre-compiled system software with additional system extensions. The platform support packages (PSPs) chapter mimics the structure of BSP chapters and discusses more low level information and possible limitations. The Boot Strategies chapter discusses the setup of bootloaders for different boot strategies supported by the BSPs. The Drivers chapter discusses supported device drivers, the device driver configuration and usage. The CDK chapter provides information about the compiler usage and settings. The Architecture Dependencies chapter discusses various low level interfaces and information from the PikeOS kernel point of view. The Boards Fusion/PSP Projects chapter gives an overview of the corresponding kernel and PSSW fusion projects for each BSP.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2 Boards
2.1 Introduction
PikeOS supports multiple processor architectures and, for each architecture, multiple board types. This manual covers support for ARMv7 CPUs and the reference boards supported by PikeOS at the moment this manual was published. PikeOS supports ARMv7 processors with MMU (VMSA configuration) and VFP / Advanced SIMD (Neon) exten- sion.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.2 QEMU ARM
QEMU is a fast processor emulator. Using full system emulation it can emulate a fairly complete Cortex A8 system. It is recommended to use QEMU 1.2 or higher; a suitable, pre-compiled QEMU comes shipped with PikeOS. The PikeOS board name for this board is qemu-arm-v7hf. The standard QEMU integratorcp board doesn’t support virtio devices - thus it was modified to support virtio MMIO bus. 4 devices are supported, the devices are attached to memory area 0x1d000000 + 0x200 * idx, and use IRQs 16 + idx. The ’idx’ is assigned by QEMU backwards - thus the first device instantiated via command line is assigned idx == 3.
2.2.1 The Board Configuration
PikeOS provides drivers and configuration for the following board resources:
• Serial controller (PL011), section 5.1.3, page 68
• Ethernet controller (virtion-net), section 5.2.8, page 90
2.2.2 Set-up Environment for QEMU
The QEMU virtio-net controller can be reached from outside of QEMU. The QEMU network setup is described in the detail in the PikeOS User Manual. To load and run the ROMimage with networking support, use the generated QEMU command line. By default, the virtio-net device is instantiated using ’-device virtio-net-device,vlan=0’ command line option. To enable QEMU’s serial line support, add the option ’-serial {device}’ to the QEMU command line, where {device} might be one of stdio, vc, pty, null.
2.2.3 The PSP Configuration
For the PSP configuration options see section 3.6, page 42.
2.2.4 The PSSW Configuration
No driver is included in the PSSW for QEMU ARM.
2.2.5 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to the QEMU ARM board. To load and run the pre-compiled "Hello World" image, start QEMU with the following command:
sh# /opt/pikeos-D5.0/target/arm/v7hf/boot-images/simple-pikeos-qemu-arm-v7hf-qemu.qemu_cmdline
Now you should see the following output generated by the "Hello World" image:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
12 Boards
PikeOS (C) Copyright SYSGO AG, Germany ROM image build: devel-pikeos@builder.sysgo.com-250317-00:47 Kernel build: 4.2-1558, type: noassert tracesys smp v7 ASP: "arm_v7hf" ARM v7, endian: little, VFP: d0-31 PSP build: 4.2-193 PSP: "qemu-v7hf" CORTEX A15 on QEMU Features: RETAIL TRACER-SYSCALL OPT SMP(1/32) Configuration limits: respart: 63 task: 256 thread: 511 timepart: 63 priority: 256 interrupts: 1024 TP windows: 256 thr sstack: 4096 B Resource partition 0 kernel memory refill strategy: dynamic (on demand) Time stamp counter clock: 1000000 kHz, via system call System ticker: periodic mode, resolution 10000000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Free memory: 128044 KiB PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587 eth0: Registered MAC address(02:70:34:12:34:57) for channel ’3’ eth0: Registered MAC address(06:70:34:12:34:57) for channel ’2’ eth0: Registered MAC address(0a:70:34:12:34:57) for channel ’1’ eth0: Registered MAC address(0e:70:34:12:34:57) for channel ’0’ virtio-net: Provider "eth0" started, Build: 4.2-30 Production PL011: Provider "ser0" started, Build: 4.2-27 Production Hello World, starting up. Hello World, this is task 22, thread 0 Hello World, this is task 22, thread 0 ...
2.2.6 Limitations
The pre-compiled QEMU that comes shipped with PikeOS doesn’t support SMP. See section 3.6, page 42 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.3 i.MX6 Family
The i.MX6 Family are Systems-on-a-Chip introduced by Freescale. The PSP imx6 provides support for boards based on the i.MX 6Quad chip. Boards based on i.MX 6ULL, i.MX 6Ul- traLite, i.MX 6SoloLite, i.MX 6SoloX, i.MX 6Solo, i.MX 6DualLite, i.MX 6Dual, i.MX 6DualPlus and i.MX 6QuadPlus chips are not recognized.
2.3.1 The Board Configuration
PikeOS provides support for the following i.MX6Q based boards:
• imx6q - Freescale i.MX6QUAD (Generic configuration)
• imx6q_sabrelite - Freescale i.MX 6Quad SABRE LITE
• imx6q_sabreauto - Freescale i.MX 6Quad SABRE AUTO
• imx6q_sabresd - Freescale i.MX 6Quad SABRE SD
The following drivers are available for the mentioned boards: Serial (IMX Ethernet (IMX PCI (PCI Clock (Clock SD controller Uart) section FEC) section Layerscape) Manager) sec- (uSDHC) sec- 5.1.1, page 65 5.2.1, page 73 section 5.5.2, tion 5.6, page tion 5.4.2, page page 107 110 101 imx6q Yes Yes Yes Yes On demand imx6q_sabrelite Yes Yes Yes Yes On demand imx6q_sabreauto Yes Yes Yes Yes On demand imx6q_sabresd Yes Yes Yes Yes On demand
• The driver for FlexCAN controller (flexcan2) section 5.8.1, page 119 is available on demand for some of the
above boards.
• The driver for Watchdog Timer (imx_wdt) section 5.3.1, page 96 is available on demand.
• The PSP PCI driver is always present in the PSPs for these boards.
2.3.2 The PSP Configuration
For the PSP configuration options see section 3.7, page 43.
2.3.3 The PSSW Configuration
No driver is included in the PSSW for i.MX6 Family.
2.3.4 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to all i.MX6 Family boards. If you are not familiar with TFTP boot and terminal emulations like kermit or minicom, please take
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
14 Boards
a look at the PikeOS User Manual. For all questions related to the U-Boot firmware, please use the command line help system of U-Boot or refer to the documentation which comes with the board. The i.MX6 Family boards are shipped with the U-Boot firmware already installed in the MMC/SD-Card provided with the board. The U-Boot firmware can be used to download and start a PikeOS image. To download and run the pre-compiled "Hello World" image, perform the following steps:
• Connect the serial interface of the target with a serial port on your development host using a nullmodem
cable. The board is shipped with the default communication parameters 115200, 8N1 (115200 baud, 8 data
bits, no parity bit, and 1 stop bit).
• Connect the ethernet interface of the target to your network.
• Start a terminal emulation program like kermit or minicom on your development host with the proper
communication parameters. You have to switch carrier detection off.
• Start or reset your board, you should see the boot message of the U-Boot firmware. The output should look
like:
U-Boot 2009.08 (Jan 12 2012 - 17:06:11)
CPU: Freescale i.MX 6 family 0.0V at 792 MHz
Temperature: can’t get valid data!
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock : 66000000Hz
ipg per clock : 66000000Hz
uart clock : 80000000Hz
cspi clock : 60000000Hz
ahb clock : 132000000Hz
axi clock : 264000000Hz
emi_slow clock: 29333333Hz
ddr clock : 528000000Hz
usdhc1 clock : 200000000Hz
usdhc2 clock : 200000000Hz
usdhc3 clock : 200000000Hz
usdhc4 clock : 200000000Hz
nfc clock : 24000000Hz
Board: MX6Q-SABRELITE:[ POR]
Boot Device: I2C
I2C: ready
DRAM: 1 GB
MMC: FSL_USDHC: 0,FSL_USDHC: 1
JEDEC ID: 0xbf:0x25:0x41
Reading SPI NOR flash 0xc0000 [0x2000 bytes] -> ram 0x276009b8
SUCCESS
In: serial
Out: serial
Err: serial
Net: got MAC address from IIM: 00:19:b8:00:e5:7e
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
i.MX6 Family 15
FEC0 [PRIME]
Hit any key to stop autoboot: 0
• Hit a key to stop the boot process.
• This step is only needed if the bootloader starts with another baudrate (unlikely): Change the baud rate of the serial port to 115200 baud since this is the baudrate used by the "Hello World" image. To do this you have to execute the U-Boot command:
> set baudrate 115200
## Switch baudrate to 115200 bps and press ENTER ...
After doing this, you have to disconnect you terminal session and adapt the baud rate setting of your
terminal. If you reconnect your terminal session, you have to press ENTER before you will see the U-Boot
prompt again.
• To store the baudrate setting, you have to set the corresponding environment variable:
> setenv baudrate 115200
• Configure the target for your network environment. You have to set the target-, TFTP-server-, and gateway ip-addresses and your net mask:
> setenv ipaddr 172.22.49.15
> setenv serverip 172.22.49.10
> setenv gatewayip 172.22.1.1
> setenv netmask 255.255.0.0
• Save the environment with the command:
MX6Q SABRELITE U-Boot > saveenv
Saving Environment to SPI Flash...
Erasing SPI flash...Erasing SPI NOR flash 0xc0000 [0x2000 bytes]
..SUCCESS
Writing to SPI flash...Writing SPI NOR flash 0xc0000 [0x2000 bytes] <- ram 0x276009b8
SUCCESS
done
• Copy the binary image into the TFTP boot directory and name it imx6.boot. Make sure that it has read permission for world:
sh# cp /opt/pikeos-D5.0/target/arm/v7hf/boot-images/simple-pikeos-imx6q_sabrelite-uboot
/tftpboot/imx6.boot
sh# chmod a+r /tftpboot/imx6.boot
• Start the download with the command:
> tftp ${loadaddr} imx6.boot
You should see an output similar to:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
16 Boards
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 172.22.45.11; our IP address is 172.22.45.13
Filename ’imx6.boot’.
Load address: 0x10020000
Loading: ################################
done
• If the download has completed successfully, run the image with the command:
> bootm ${loadaddr}
U-Boot analyzes the image, prints some information about it and starts it:
PikeOS (C) Copyright SYSGO AG, Germany
ROM image build: devel-pikeos@builder.sysgo.com-250317-00:35
Kernel build: 4.2-1558, type: noassert tracesys smp v7
ASP: "arm_v7hf" ARM v7, endian: little, VFP: d0-31
PSP build: 4.2-222
PSP: "imx6x" Freescale i.MX 6 (SMP - L2C)
Features: RETAIL TRACER-SYSCALL OPT SMP(4/32)
Configuration limits:
respart: 63
task: 256
thread: 511
timepart: 63
priority: 256
interrupts: 1024
TP windows: 256
thr sstack: 4096 B
Resource partition 0 kernel memory refill strategy: dynamic (on demand)
Time stamp counter clock: 1000000 kHz, via system call
System ticker: periodic mode, resolution 10000000 ns
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
Free memory: 1044824 KiB
PikeOS PCI Manager KDEV, Build: 4.2-172
PCIMGR: message: PSP returned empty PCI device list
PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587
iMX_UART: Provider "ser0" started, Build: 4.2-80 Production
Hello World, starting up.
Hello World, this is task 22, thread 0
Hello World, this is task 22, thread 0
...
• If you save the boot command in the bootcmd variable, this command will be executed automatically when
the board comes up.
> setenv bootcmd tftpboot ${loadaddr} boot.img\;bootm ${loadaddr}
> saveenv
2.3.5 The PikeOS Console
On the i.MX6 Family has up to 5 UARTs (UART-1 to UART-5), but usually only uses one to three. By default, the imx6 PSP uses UART-2 as system console.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
i.MX6 Family 17
The PikeOS system console is configured to use the communication parameters 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit).
Note: If you are going to change the interface, which you want to use as a system console, you need to change the two following parameters accordingly: the property psp/console/port and the project configuration parameter KERNEL_CONSOLE. The first one tells PSP where the system console messages will be printed and the second tells the serial driver (if added to the project), that it should not re-initialize this console after the boot, because it is already initialized by the PSP.
Warning: Concurrent use of this interface as system console and serial device controlled by an I/O server may result in unexpected behavior.
2.3.6 PSP Drivers
The imx6 PSP includes some drivers (IOMUX and GPIO). See section 3.7, page 43 for a detailed description.
2.3.7 Limitations
See section 3.7, page 43 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.4 Nvidia Jetson TK1
The Nvidia Jetson TK1 are Systems-on-a-Chip introduced by NVIDIA. PikeOS is currently officially supported on the version featuring a quad-core Cortex A15. The PikeOS board name for this board is tegra-jetson-tk1. The PSP cortex-a15 provides support for boards based on the NVIDIA K1 chip.
2.4.1 The Board Configuration
PikeOS provides drivers and configuration for the following board resources:
• Nvidia-jetson-tk1 - Tegra Jetson TK1 Cortex A15 Core (NVIDIA)
Serial controller (8250), section 5.1.4, page 69
2.4.2 The PSP Configuration
The PSP and kernel properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39.
2.4.3 The PSSW Configuration
No driver is included in the PSSW for Nvidia Jetson TK1.
2.4.4 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to the jetson-tk1 board. If you are not familiar with TFTP boot and terminal emulations like kermit or minicom, please take a look at the PikeOS User Manual. For all questions related to the U-Boot firmware, please use the command line help system of U-Boot or refer to the documentation which comes with the board. The Nvidia Jetson TK1 board is shipped with the U-Boot firmware already installed in the boards’ flash. The U-Boot firmware can be used to download and start a PikeOS image. To download and run the pre-compiled "Hello World" image, perform the following steps:
• Connect the serial interface of the target with a serial port on your development host using a nullmodem
cable. The board is shipped with the default communication parameters 115200, 8N1 (115200 baud, 8 data
bits, no parity bit, and 1 stop bit).
• Start a terminal emulation program like kermit or minicom on your development host with the proper
communication parameters. You have to switch carrier detection off.
• If you now reset the board, you should see the boot message of the U-Boot firmware. The output should
look like:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Nvidia Jetson TK1 19
U-Boot SPL 2014.10-rc2-00001-g9f88c9e (Dec 01 2014 - 14:29:15)
U-Boot 2014.10-rc2-00001-g9f88c9e (Dec 01 2014 - 14:29:15)
TEGRA124
Board: NVIDIA Jetson TK1
I2C: ready
DRAM: 2 GiB
MMC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
tegra-pcie: PCI regions:
tegra-pcie: I/O: 0x12000000-0x12010000
tegra-pcie: non-prefetchable memory: 0x13000000-0x20000000
tegra-pcie: prefetchable memory: 0x20000000-0x40000000
tegra-pcie: 2x1, 1x1 configuration
pcie: probing port 0, using 2 lanes
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, retrying
tegra-pcie: link 0 down, ignoring
tegra-pcie: probing port 1, using 1 lanes
In: serial
Out: serial
Err: serial
Net: RTL8169#0
Hit any key to stop autoboot: 0
Tegra124 (Jetson TK1) #
• Hit a key to stop the boot process.
• To start the "Hello World" image it needs to be loaded from a tftpserver. Adapt the command line below to your network settings to load a binary image to the target:
=> setenv ipaddr 172.24.16.25; setenv serverip 172.24.16.10; tftp 0x90000000
simple-pikeos-tegra-jetson-tk1-uboot;
You should see an output similar to:
Using RTL8169#0 device
TFTP from server 172.24.16.31; our IP address is 172.24.16.39
Filename ’tegra.img’.
Load address: 0x90000000
Loading: #########################################
3.3 MiB/s
done
Bytes transferred = 206791 (327c7 hex)
• If the upload has completed successfully, run the image with the command:
=> bootm
U-Boot analyzes the image, prints some information about it and starts it:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
20 Boards
PikeOS (C) Copyright SYSGO AG, Germany
ROM image build: pikeos@builder.sysgo.com 280317-11:45
Kernel build: 4.2-1558, type: noassert tracesys smp v7 lpae
ASP: "arm_v7hf" ARM v7, LPAE, endian: little, VFP: d0-31
PSP build: 4.2-176
PSP: "tegra-k1" Nvidia Tegra K1 (SMP-LPAE)
Features: RETAIL TRACER-SYSCALL OPT SMP(4/32)
Configuration limits:
respart: 63
task: 256
thread: 511
timepart: 63
priority: 256
interrupts: 1024
TP windows: 256
thr sstack: 4096 B
Timer: virtual (irq: 27, freq: 12000000, factor: 83, reload: 120481)
Resource partition 0 kernel memory refill strategy: dynamic (on demand)
Time stamp counter clock: 1000000 kHz, via system call
System ticker: periodic mode, resolution 10000000 ns
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
Free memory: 2028848 KiB
PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587
PIKEOS_MON: Started, version: 4.2-321
8250: Provider "ser0" started, Build: 4.2-155 Production
Hello World, starting up.
Hello World, this is task 22, thread 0
Hello World, this is task 22, thread 0
...
Note: As the U-Boot bootloader is only able to handle compressed bootimages whose uncompressed size is not larger than 8MB, you should use the uncompressed strategy when your image exceeds this limit.
2.4.5 The PikeOS Console
The Nvidia Jetson TK1 board has only one serial line available. This line is UART-1 and it is used by the PikeOS system console.
Warning: Concurrent use of this interface as system console and serial device controlled by an I/O server may result in unexpected behavior.
The PikeOS system console is configured to use the communication parameters 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit).
2.4.6 Limitations
See section 3.8, page 54 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Nvidia Jetson TK1 21
Atomic / Exclusive Operations
The Tegra K1 processor supports atomic operations in cacheable memory only. The processor encounters an asynchronous external abort exception when performing exclusive load or store operations on device or strongly- ordered memory. To mitigate this problem, untrusted partitions should not be able to set custom caching attributes, nor should they access uncached memory. Due to this, the P4_AB_CACHE_CHANGE ability must not be granted to any partition running an untrusted code.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.5 ZYNQ ZC702
The ZYNQ ZC702 is composed of Systems-on-a-Chip boards introduced by Xilinx.
2.5.1 The Board Configuration
PikeOS provides drivers and configuration for the following board resources:
• Serial controller (XuartPS), section 5.1.2, page 67
• Ethernet controller (XemacPS), section 5.2.2, page 75
• Clock Manager, section 5.6, page 110
The drivers for the following resources are available on demand:
• QSPI controller
• CAN controller
• (E)MIO pins
2.5.2 The PSP Configuration
For the PSP configuration options see section 3.6, page 42.
2.5.3 The PSSW Configuration
No driver is included in the PSSW for ZYNQ ZC702.
2.5.4 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to all ZYNQ ZC702 boards. If you are not familiar with TFTP boot and terminal emulations like kermit or minicom, please take a look at the PikeOS User Manual. For all questions related to the U-Boot firmware, please use the command line help system of U-Boot or refer to the documentation which comes with the board. The ZYNQ ZC702 boards are shipped with the U-Boot firmware already installed in the MMC/SD-Card provided with the board. The U-Boot firmware can be used to download and start a PikeOS image. To download and run the pre-compiled "Hello World" image, perform the following steps:
• Connect the serial interface of the target with a serial port on your development host using a nullmodem
cable. The board is shipped with the default communication parameters 115200, 8N1 (115200 baud, 8 data
bits, no parity bit, and 1 stop bit).
• Connect the ethernet interface of the target to your network.
• Start a terminal emulation program like kermit or minicom on your development host with the proper
communication parameters. You have to switch carrier detection off.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ZYNQ ZC702 23
• Start or reset your board, you should see the boot message of the U-Boot firmware. The output should look like:
U-Boot 2010.09-01937-g08bd7a6 (May 15 2012 - 11:33:17)
DRAM: 256 MiB
## Unknown FLASH on Bank 1 - Size = 0x00000000 = 0 MB
Flash: 0 Bytes
MMC: SDHCI: 0
Using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
• Hit a key to stop the boot process.
• This step is only needed if the bootloader starts with another baudrate (unlikely): Change the baud rate of the serial port to 115200 baud since this is the baudrate used by the "Hello World" image. To do this you have to execute the U-Boot command:
> set baudrate 115200
## Switch baudrate to 115200 bps and press ENTER ...
After doing this, you have to disconnect you terminal session and adapt the baud rate setting of your
terminal. If you reconnect your terminal session, you have to press ENTER before you will see the U-Boot
prompt again.
• To store the baudrate setting, you have to set the corresponding environment variable:
> setenv baudrate 115200
• Configure the target for your network environment. You have to set the target-, TFTP-server-, and gateway ip-addresses and your net mask:
> setenv ipaddr 172.22.49.15
> setenv serverip 172.22.49.10
> setenv gatewayip 172.22.1.1
> setenv netmask 255.255.0.0
• Copy the binary image into the TFTP boot directory and name it zynq.boot. Make sure that it has read permission for world:
sh# cp /opt/pikeos-D5.0/target/arm/v7hf/boot-images/simple-pikeos-zynq-zc702-uboot_unc
/tftpboot/zynq.boot
sh# chmod a+r /tftpboot/zynq.boot
• Start the download with the command:
> tftp ${loadaddr} zynq.boot
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
24 Boards
You should see an output similar to:
Trying to set up GEM link...
Resetting PHY...
PHY reset complete.
Waiting for PHY to complete auto-negotiation...
Link is now at 100Mbps!
TFTP from server 172.22.49.10; our IP address is 172.22.49.15
Filename ’zynq.boot’.
Load address: 0x0
Loading: ##############################
done
• If the download has completed successfully, run the image with the command:
> bootm
U-Boot analyzes the image, prints some information about it and starts it:
PikeOS (C) Copyright SYSGO AG, Germany
ROM image build: devel-pikeos@builder.sysgo.com-250317-00:42
Kernel build: 4.2-1558, type: noassert tracesys smp v7
ASP: "arm_v7hf" ARM v7, endian: little, VFP: d0-31
PSP build: 4.2-168
PSP: "zynq" Xilinx ZYNQ-7000 EPP (SMP - L2C)
Features: RETAIL TRACER-SYSCALL OPT SMP(2/32)
Configuration limits:
respart: 63
task: 256
thread: 511
timepart: 63
priority: 256
interrupts: 1024
TP windows: 256
thr sstack: 4096 B
Resource partition 0 kernel memory refill strategy: dynamic (on demand)
Time stamp counter clock: 1000000 kHz, via system call
System ticker: periodic mode, resolution 10000000 ns
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
Free memory: 1044276 KiB
PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587
<DRV INFO> eth0: OUI 0x005043, model 0x0024, rev. 0
XUARTPS: Provider "ser0" started, Build: 4.2-108 Production
<DRV INFO> eth0: Registered MAC address(02:70:34:00:01:23) for channel ’3’
<DRV INFO> eth0: Registered MAC address(06:70:34:00:01:23) for channel ’2’
<DRV INFO> eth0: Registered MAC address(0a:70:34:00:01:23) for channel ’1’
<DRV INFO> eth0: Registered MAC address(0e:70:34:00:01:23) for channel ’0’
xemacps: Provider "eth0" started, Build: 4.2-59 Production
Hello World, starting up.
Hello World, this is task 22, thread 0
Hello World, this is task 22, thread 0
...
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ZYNQ ZC702 25
• The environment cannot be saved. The command ’saveenv’ is not available with this U-Boot version. Note: an environment variable can be run and therefore can be used to execute several actions, ex: > sete actions ’sete ipaddr is 172.22.49.15; sete serverip 172.22.49.10; tftp 0 zynq.boot; bootm’ > run actions
These actions will set IP addresses, upload your image and run it.
2.5.5 The PikeOS Console
ZYNQ ZC702 has up to 2 UARTs (UART-0 to UART-1), but usually only uses one. By default, the ZYNQ PSP uses UART-1 as system console.
Warning: Concurrent use of this interface as system console and serial device controlled by an I/O server may result in unexpected behavior.
The PikeOS system console is configured to use the communication parameters 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit).
2.5.6 Limitations
The integrated USB-to-UART converter on the board will disconnect when the board is reset or powered down and your terminal session will be terminated. See section 3.9, page 56 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.6 ZedBoard
The ZedBoard is a development board consisting of Zynq-7000 series SoC and programmable logic component.
2.6.1 The Board Configuration
PikeOS provides drivers and configuration for the following board resources:
• Serial controller (XuartPS), section 5.1.2, page 67
• Ethernet controller (XemacPS), section 5.2.2, page 75
• Clock Manager, section 5.6, page 110
The drivers for the following resources are available on demand:
• QSPI controller
• CAN controller
• (E)MIO pins
2.6.2 The PSP Configuration
For the PSP configuration options see section 3.6, page 42.
2.6.3 The PSSW Configuration
No driver is included in the PSSW for ZedBoard.
2.6.4 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to all ZedBoard boards. If you are not familiar with TFTP boot and terminal emulations like kermit or minicom, please take a look at the PikeOS User Manual. For all questions related to the U-Boot firmware, please use the command line help system of U-Boot or refer to the documentation which comes with the board. The ZedBoard boards are shipped with the U-Boot firmware already installed in the SD-Card provided with the board. The U-Boot firmware can be used to download and start a PikeOS image. To download and run the pre-compiled "Hello World" image, perform the following steps:
• Install the CY7C64225 USB-to-UART driver if necessary (should be supported out of the box on recent
Linux kernels).
• Connect the development host to the ZedBoard’s USB UART (J14) using Micro USB cable. The board is
shipped with the default communication parameters 115200, 8N1 (115200 baud, 8 data bits, no parity bit,
and 1 stop bit).
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ZedBoard 27
• Connect the ethernet interface of the target to your network.
• Start a terminal emulation program like kermit or minicom on your development host with the proper communication parameters. You have to switch carrier detection off.
• Start or reset your board, you should see the boot message of the U-Boot firmware. The output should look like:
U-Boot 2011.03-dirty (Jul 11 2012 - 16:07:00)
DRAM: 512 MiB
MMC: SDHCI: 0
Using default environment
In: serial
Out: serial
Err: serial
Net: zynq_gem
Hit any key to stop autoboot: 0
• Hit a key to stop the boot process.
• This step is only needed if the bootloader starts with another baudrate (unlikely): Change the baud rate of the serial port to 115200 baud since this is the baudrate used by the "Hello World" image. To do this you have to execute the U-Boot command:
> set baudrate 115200
## Switch baudrate to 115200 bps and press ENTER ...
After doing this, you have to disconnect you terminal session and adapt the baud rate setting of your
terminal. If you reconnect your terminal session, you have to press ENTER before you will see the U-Boot
prompt again.
• To store the baudrate setting, you have to set the corresponding environment variable:
> setenv baudrate 115200
• Configure the target for your network environment. You have to set the ip addresses of the target, TFTP- server, and gateway, and your net mask:
> setenv ipaddr 172.22.49.15
> setenv serverip 172.22.49.10
> setenv gatewayip 172.22.1.1
> setenv netmask 255.255.0.0
• Copy the binary image into the TFTP boot directory and name it zynq-zed.boot. Make sure that it has read permission for world:
sh# cp /opt/pikeos-D5.0/target/arm/v7hf/boot-images/simple-pikeos-zynq-zed-uboot_unc
/tftpboot/zynq-zed.boot
sh# chmod a+r /tftpboot/zynq-zed.boot
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
28 Boards
• Start the download with the command:
> tftp ${loadaddr} zynq-zed.boot
You should see an output similar to:
Trying to set up GEM link...
Resetting PHY...
PHY reset complete.
Waiting for PHY to complete auto-negotiation...
Link is now at 100Mbps!
TFTP from server 172.22.49.10; our IP address is 172.22.49.15
Filename ’zynq.boot’.
Load address: 0x0
Loading: ##############################
done
• If the download has completed successfully, run the image with the command:
> bootm
U-Boot analyzes the image, prints some information about it and starts it:
## Booting kernel from Legacy Image at 00000000 ...
Image Name: PikeOS Boot Image
Created: 2017-01-25 1:08:02 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 606864 Bytes = 592.6 KiB
Load Address: 00120000
Entry Point: 00120000
Verifying Checksum ... OK
Loading Kernel Image ... OK
PikeOS (C) Copyright SYSGO AG, Germany
ROM image build: devel-pikeos@builder.sysgo.com-250317-00:37
Kernel build: 4.2-1558, type: noassert tracesys smp v7
ASP: "arm_v7hf" ARM v7, endian: little, VFP: d0-31
PSP build: 4.2-168
PSP: "zynq" Xilinx ZYNQ-7000 EPP (SMP - L2C)
Features: RETAIL TRACER-SYSCALL OPT SMP(2/32)
Configuration limits:
respart: 63
task: 256
thread: 511
timepart: 63
priority: 256
interrupts: 1024
TP windows: 256
thr sstack: 4096 B
Resource partition 0 kernel memory refill strategy: dynamic (on demand)
Time stamp counter clock: 1000000 kHz, via system call
System ticker: periodic mode, resolution 10000000 ns
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
ZedBoard 29
Free memory: 518964 KiB
PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587
<DRV INFO> eth0: OUI 0x005043, model 0x001d, rev. 1
XUARTPS: Provider "ser0" started, Build: 4.2-108 Production
<DRV INFO> eth0: Registered MAC address(02:70:34:00:01:22) for channel ’3’
<DRV INFO> eth0: Registered MAC address(06:70:34:00:01:22) for channel ’2’
<DRV INFO> eth0: Registered MAC address(0a:70:34:00:01:22) for channel ’1’
<DRV INFO> eth0: Registered MAC address(0e:70:34:00:01:22) for channel ’0’
xemacps: Provider "eth0" started, Build: 4.2-59 Production
Hello World, starting up.
Hello World, this is task 22, thread 0
Hello World, this is task 22, thread 0
...
• The environment cannot be saved. The command ’saveenv’ is not available with this U-Boot version. Note: An environment variable can be run and therefore can be used to execute several actions, example: > sete actions ’sete ipaddr is 172.22.49.15; sete serverip 172.22.49.10; tftp 0 zynq.boot; bootm’ > run actions
These actions will set IP addresses, upload your image and run it.
2.6.5 The PikeOS Console
ZedBoard has up to 2 UARTs (UART-0 to UART-1), but usually only uses one. By default, the ZYNQ PSP uses UART-1 as system console.
Warning: Concurrent use of this interface as system console and serial device controlled by an I/O server may result in unexpected behavior.
The PikeOS system console is configured to use the communication parameters 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit).
2.6.6 Limitations
The integrated USB-to-UART converter on the board will disconnect when the board is reset or powered down and your terminal session will be terminated. The last megabyte of memory is left unused, the psp/memory/size property is set to 0x1FF00000 by default. This is done to avoid memory corruption issues by unfinished DMA transfers not turned off by UBoot. For other limitations, see section 3.9, page 56 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.7 LS102XA Family
The LS102XA Family are Systems-on-a-Chip introduced by NXP. The PSP ls102xa provides support for boards based on the ls102xa chip.
2.7.1 The Board Configuration
PikeOS provides drivers and configuration for the following board resources:
• ls1021a-iot - QorIQ LS1021A-IoT Gateway Reference Design
Serial controller (8250), section 5.1.4, page 69
Ethernet controller (TSEC), section 5.2.6, page 85
PCI (Layerscape PCI), section 5.5.2, page 107 (with MSI/MSI-X support, section 5.5.3, page 108)
• vpx3-1701 - VPX3-1701 3U VPX ARM Cortex A7 SBC
Serial controller (8250), section 5.1.4, page 69
Ethernet controller (TSEC), section 5.2.6, page 85
2.7.2 The PSP Configuration
For the PSP configuration options see section 3.10, page 59.
2.7.3 The PSSW Configuration
No driver is included in the PSSW for LS102XA Family.
2.7.4 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to all LS102XA Family boards. If you are not familiar with TFTP boot and terminal emulations like kermit or minicom, please take a look at the PikeOS User Manual. For all questions related to the U-Boot firmware, please use the command line help system of U-Boot or refer to the documentation which comes with the board. The LS102XA Family boards are shipped with the U-Boot firmware already installed in the MMC/SD-Card provided with the board. The U-Boot firmware can be used to download and start a PikeOS image. To download and run the pre-compiled "Hello World" image, perform the following steps:
• Connect the serial interface of the target with a serial port on your development host using a nullmodem
cable. The board is shipped with the default communication parameters 115200, 8N1 (115200 baud, 8 data
bits, no parity bit, and 1 stop bit).
• Connect the ethernet interface of the target to your network.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
LS102XA Family 31
• Start a terminal emulation program like kermit or minicom on your development host with the proper communication parameters. You have to switch carrier detection off.
• Start or reset your board, you should see the boot message of the U-Boot firmware. The output should look like:
U-Boot 2015.01+ls1+g3281947 (Aug 31 2015 - 15:06:00)
CPU: Freescale LayerScape LS1021E, Version: 2.0, (0x87081120)
Clock Configuration:
CPU0(ARMV7):1000 MHz,
Bus:300 MHz, DDR:800 MHz (1600 MT/s data rate),
Reset Configuration Word (RCW):
00000000: 0608000a 00000000 00000000 00000000
00000010: 20000000 08407900 60025a00 21046000
00000020: 00000000 00000000 00000000 20038000
00000030: 20024800 881b1340 00000000 00000000
Board: LS1021AIOT
CPLD: V2.5
I2C: ready
DRAM: 1 GiB
Using SERDES1 Protocol: 32 (0x20)
MMC: FSL_SDHC: 0
EEPROM: NXID v1
PCIe1: Root Complex no link, regs @ 0x3400000
PCIe2: Root Complex no link, regs @ 0x3500000
In: serial
Out: serial
Err: serial
SEC0: RNG instantiated
SATA link 0 timeout.
AHCI 0001.0300 1 slots 1 ports ? Gbps 0x1 impl SATA mode
flags: 64bit ncq pm clo only pmp fbss pio slum part ccc
scanning bus for devices...
Found 0 device(s).
SCSI: Net: eTSEC1 is in sgmii mode.
eTSEC2 is in sgmii mode.
Phy 4 not found
PHY reset timed out
eTSEC1 [PRIME], eTSEC2, eTSEC3
Hit any key to stop autoboot: 0
• Hit a key to stop the boot process.
• This step is only needed if the bootloader starts with another baudrate (unlikely): Change the baud rate of the serial port to 115200 baud since this is the baudrate used by the "Hello World" image. To do this you have to execute the U-Boot command:
> set baudrate 115200
## Switch baudrate to 115200 bps and press ENTER ...
After doing this, you have to disconnect you terminal session and adapt the baud rate setting of your
terminal. If you reconnect your terminal session, you have to press ENTER before you will see the U-Boot
prompt again.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
32 Boards
• To store the baudrate setting, you have to set the corresponding environment variable:
> setenv baudrate 115200
• Configure the target for your network environment. You have to set the target-, TFTP-server-, and gateway
ip-addresses and your net mask:
> setenv ipaddr 172.22.49.15
> setenv serverip 172.22.49.10
> setenv gatewayip 172.22.1.1
> setenv netmask 255.255.0.0
• Save the environment with the command:
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
• Copy the binary image into the TFTP boot directory and name it imx6.boot. Make sure that it has read
permission for world:
sh# cp /opt/pikeos-D5.0/target/arm/v7hf/boot-images/simple-pikeos-ls1021a-iot-raw
/tftpboot/ls1021a-iot.boot
sh# chmod a+r /tftpboot/ls1021a-iot.boot
• Start the download with the command:
> tftp 0x80020000 ls1021a-iot.boot
You should see an output similar to:
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 172.24.11.1; our IP address is 172.24.11.102
Filename ls1021a-iot.boot.
Load address: 0x80020000
Loading: #################################################################
#################################################################
##########################
3.5 MiB/s
done
Bytes transferred = 795280 (c2290 hex)
• If the download has completed successfully, run the image with the command:
> go 0x80020000
U-Boot analyzes the image, prints some information about it and starts it:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
LS102XA Family 33
PikeOS (C) Copyright SYSGO AG, Germany
ROM image build: devel-pikeos@builder.sysgo.com-250317-00:44
Kernel build: 4.2-1558, type: noassert tracesys smp v7 lpae
ASP: "arm_v7hf" ARM v7, LPAE, endian: little, VFP: d0-31
PSP build: 4.2-176
PSP: "ls102xa" LS102XA Cortex A7 (SMP-LPAE)
Features: RETAIL TRACER-SYSCALL OPT SMP(2/32)
Configuration limits:
respart: 63
task: 256
thread: 511
timepart: 63
priority: 256
interrupts: 1024
TP windows: 256
thr sstack: 4096 B
Timer: secure physical (irq: 29, freq: 12500000, factor: 80, reload: 125000)
Resource partition 0 kernel memory refill strategy: dynamic (on demand)
Time stamp counter clock: 1000000 kHz, via system call
System ticker: periodic mode, resolution 10000000 ns
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
Free memory: 1047132 KiB
PikeOS PCI Manager KDEV, Build: 4.2-172
PCIMGR: message: PSP returned empty PCI device list
PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587
<DRV INFO> eth1: OUI 0x001374, model 0x0007, rev. 4
<DRV INFO> eth0: OUI 0x001374, model 0x0007, rev. 4
8250: Provider "ser0" started, Build: 4.2-155 Production
<DRV INFO> eth1: Registered MAC address(02:04:8f:01:0a:51) for channel ’3’
<DRV INFO> eth0: Registered MAC address(02:04:8f:00:0a:51) for channel ’3’
<DRV INFO> eth1: Registered MAC address(02:04:8f:01:0a:50) for channel ’2’
<DRV INFO> eth0: Registered MAC address(02:04:8f:00:0a:50) for channel ’2’
<DRV INFO> eth1: Registered MAC address(02:04:8f:01:0a:49) for channel ’1’
<DRV INFO> eth0: Registered MAC address(02:04:8f:00:0a:49) for channel ’1’
<DRV INFO> eth1: Registered MAC address(00:04:9f:00:9c:84) for channel ’0’
<DRV INFO> eth0: Registered MAC address(0e:70:34:63:02:6d) for channel ’0’
tsec: Provider "eth1" started, Build: 4.2-66 Production
tsec: Provider "eth0" started, Build: 4.2-66 Production
Hello World, starting up.
Hello World, this is task 22, thread 0
Hello World, this is task 22, thread 0
...
• If you save the boot command in the bootcmd variable, this command will be executed automatically when the board comes up.
> setenv bootcmd tftpboot 0x80020000 boot.img\;go 0x80020000
> saveenv
2.7.5 Limitations
See section 3.10, page 59 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
34 Boards
Warning: ls1021a-iot board only support the following communication parameters for 8250 serial driver: 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit)
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
2.8 Cyclone V Family
The Cyclone V is a Systems-on-a-Chip introduced by Altera. The PSP cyclone-v provides support for boards based on the Cyclone V chip.
2.8.1 The Board Configuration
PikeOS provides drivers and configuration for the following board resources:
• cyclone-v-sockit - Terasic Development Kit for New SoC Device
Serial controller (8250), section 5.1.4, page 69
Ethernet controller (dwc_gmac), section 5.2.7, page 88
• cyclone-v-soc-dk - Altera Cyclone V SX SoC Development Board (available only on demand)
Serial controller (8250), section 5.1.4, page 69
Ethernet controller (dwc_gmac), section 5.2.7, page 88
2.8.2 The PSP Configuration
For the PSP configuration options see section 3.11, page 61.
2.8.3 The PSSW Configuration
No driver is included in the PSSW for Cyclone V Family.
2.8.4 Running the Hello World Image
The PikeOS distribution contains a ROM image which can be used to verify that development host and target are setup correctly. This section explains only the steps of the setup and boot procedure which are specific to all Cyclone V Family boards. If you are not familiar with TFTP boot and terminal emulations like kermit or minicom, please take a look at PikeOS User Manual. For all questions related to the U-Boot firmware, please use the command line help system of U-Boot or refer to the documentation which comes with the board. The Cyclone V Family boards are shipped with the U-Boot firmware already installed. The U-Boot firmware can be used to download and start a PikeOS image. To download and run the pre-compiled "Hello World" image, perform the following steps:
• Connect the serial interface of the target with a serial port on your development host using a nullmodem
cable. The boards are shipped with the default communication parameters:
Terasic Development Kit: 57600, 8N1 (57600 baud, 8 data bits, no parity bit, and 1 stop bit)
Altera SoC Development Board: 115200, 8N1 (115200 baud, 8 data bits, no parity bit, and 1 stop bit)
• Connect the ethernet interface of the target to your network.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
36 Boards
• Start a terminal emulation program like kermit or minicom on your development host with the proper
communication parameters. You have to switch carrier detection off.
• Start or reset your board, you should see the boot message of the U-Boot firmware. The output should look
like:
U-Boot SPL 2012.10 (Jun 14 2013 - 20:18:21)
SDRAM : Initializing MMR registers
SDRAM : Calibrationg PHY
SEQ.C: Preparing to start memory calibration
SEQ.C: CALIBRATION PASSED
DESIGNWARE SD/MMC: 0
U-Boot 2012.10 (Mar 29 2013 - 12:54:06)
CPU : Altera SOCFPGA Platform
BOARD : Altera SOCFPGA Cyclone 5 Board
DRAM: 1 GiB
MMC: DESIGNWARE SD/MMC: 0
In: serial
Out: serial
Err: serial
Net: mii0
Hit any key to stop autoboot: 0
• Hit a key to stop the boot process.
• This step is only needed if the bootloader starts with another baudrate (unlikely): Change the baud rate
of the serial port to 57600 baud for the Terasic Development Kit or to 115200 baud for the Altera SoC
Development Board since this is the baudrate used by the "Hello World" image. For example, to do this you
have to execute the U-Boot command for the Terasic Development Kit:
> set baudrate 57600
## Switch baudrate to 57600 bps and press ENTER ...
After doing this, you have to disconnect you terminal session and adapt the baud rate setting of your
terminal. If you reconnect your terminal session, you have to press ENTER before you will see the U-Boot
prompt again.
• To store the baudrate setting, you have to set the corresponding environment variable:
> setenv baudrate 57600
• Configure the target for your network environment. You have to set the target-, TFTP-server-, and gateway
ip-addresses and your net mask:
SOCFPGA_CYCLONE5 # setenv ipaddr 192.168.1.2
SOCFPGA_CYCLONE5 # setenv serverip 192.168.1.1
SOCFPGA_CYCLONE5 # setenv gatewayip 192.168.1.1
SOCFPGA_CYCLONE5 # setenv netmask 255.255.0.0
• Save the environment with the command:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Cyclone V Family 37
SOCFPGA_CYCLONE5 # saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
• Copy the binary image into the TFTP boot directory and name it sockit.img. Make sure that it has read permission for world:
sh# cp /opt/pikeos-D5.0/target/arm/v7hf/boot-images/simple-pikeos-cyclone-v-sockit-raw
/tftpboot/sockit.img
sh# chmod a+r /tftpboot/sockit.img
Note: BEWARE: For the Altera SoC Development Board boot-image will be named simple-pikeos-
cyclone-v-soc-dk-raw.
• Start the download with the command:
SOCFPGA_CYCLONE5 # tftp 0x120000 sockit.img
You should see an output similar to:
Waiting for PHY auto negotiation to complete. done
ENET Speed is 100 Mbps - FULL duplex connection
Using mii0 device
TFTP from server 192.168.1.1; our IP address is 192.168.1.2
Filename ’sockit.img’.
Load address: 0x120000
Loading: T #####################################
done
Bytes transferred = 541484 (8432c hex)
• If the download has completed successfully, run the image with the command:
SOCFPGA_CYCLONE5 # go 0x120000
U-Boot analyzes the image, prints some information about it and starts it:
PikeOS (C) Copyright SYSGO AG, Germany
ROM image build: devel-pikeos@builder.sysgo.com-250317-00:47
Kernel build: 4.2-1558, type: noassert tracesys smp v7
ASP: "arm_v7hf" ARM v7, endian: little, VFP: d0-31
PSP build: 4.2-49
PSP: "cyclone-v" Altera Cyclone V (SMP - L2C)
Features: RETAIL TRACER-SYSCALL OPT SMP(2/32)
Configuration limits:
respart: 63
task: 256
thread: 511
timepart: 63
priority: 256
interrupts: 1024
TP windows: 256
thr sstack: 4096 B
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
38 Boards
Resource partition 0 kernel memory refill strategy: dynamic (on demand)
Time stamp counter clock: 1000000 kHz, via system call
System ticker: periodic mode, resolution 10000000 ns
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
Free memory: 1043316 KiB
PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587
<DRV INFO> eth0: Altera Version: 1.0 Synopsis Version 3.7
<DRV INFO> eth0: dwc_gmac_hw_init() called
Hello World, starting up.
Hello World, this is task 22, thread 0
Hello World, this is task 22, thread 0
...
• If you save the boot command in the bootcmd variable, this command will be executed automatically when
the board comes up.
SOCFPGA_CYCLONE5 # setenv bootcmd tftp 0x120000 sockit.img \;go 0x120000
SOCFPGA_CYCLONE5 # saveenv
2.8.5 The PikeOS Console
The Cyclone V Family boards have 1 UART, but the Cyclone V provides 2 UARTs. By default, the cyclone-v PSP uses UART-0 as system console. The PikeOS system console is configured to use the communication parameters:
• 57600, 8N1 (57600 baud, 8 data bits, no parity bit, and 1 stop bit) for the Terasic Development Kit
• 115200, 8N1 (115200 baud, 8 data bits, no parity bit, and 1 stop bit) for the Altera SoC Development Board
Note: If you are going to change the interface, which you want to use as a system console, you need to change the psp/console/port property accordingly. It tells PSP where the system console messages will be printed
Warning: Concurrent use of this interface as system console and serial device controlled by an I/O server may result in unexpected behavior.
2.8.6 Limitations
The last megabyte of memory is left unused, psp/memory/size property is set to 0x1FF00000 by default. This is done to avoid memory corruption issues by unfinished DMA transfers not turned off by UBoot. See section 3.11, page 61 for the PSP limitations.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3 PSPs
3.1 Introduction
This chapter describes the platform support packages (PSPs) and their configuration. The first section describes the common PSP configuration properties which may be used to configure various options of the PSP. The following section discusses low level details, functionalities and limitations of each supported PSPs including PSP specific properties.
3.2 Common PSP Properties
Some features of the PSP can be controlled via properties stored in the ROMImage in property file system. This section describes the available PSP properties for the different PSPs. The default value which is listed in table 1 is used if the corresponding property is not specified.
Path Type Default
psp/console/baudrate uint32 mandatory
This property aslkd specifies the baud rate in bauds for the console port.
psp/memory/size uint64 PSP-specific
This property specifies the size of the on-board RAM.
psp/memory/test bool false
This property provides a simple memory tester, which will test all PSP specified P4_MRT_URW regions. The
memory test consists of two passes. The first pass will fill all regions with the address pattern, second pass
fills the regions with the bit-inverted address pattern. The memtester checks if the address pattern matches
after each pass. The value 0 disables the feature, the value 1 enables this test.
Table 1: Default values for PSP Properties
3.3 IO Sequencer
IO Sequencer is a mechanism to allow a user to make simple board-specific register adjustments without writing a driver or a custom PSP. The adjustments to be made are described in the property file system, by default under the board/config/io_seq directory. The configuration consists of property sub-directories named 0 . . . n − 1, each describing a write to a memory location (presumably a memory-mapped register). The properties listed in table 2 are used to describe the memory operation.
addr addr Address of memory location that should be changed.
The address is a virtual address, translation depends on
the PSP.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
40 PSPs
value uint64 Value that should be written at the given address. Only
the lowest bytes matching the size property are used.
size uint32 Size of the memory write, either 1, 2, 4 or 8 bytes. If
the property is not present, the size is assumed to be 4
bytes.
mask uint64 Bitmask specifying which bytes should be changed. If the
property is not present, whole memory location is over-
written. If the property is present, the memory location is
read, masked with a one-complement of this mask and
ORed with the value property.
io_port uint32 This flag can be used to specify that the operation should
be performed on IO ports instead of MMIO. In that case,
size must not be 8 bytes and only the lower 16 bits of
addr are used. This flag is only supported on x86. If the
property is not specified, it is assumed to be false
Table 2: Memory operation properties
If any of the properties does not conform to the specification, the PSP will refuse to boot and print an error message. If console is available at the time when the IO sequencer runs (depends on the BSP), you can get verbose information about the operations performed by the IO sequencer by setting the UK_BOOT_MESSAGE kernel configuration parameter to Verbose boot. Unless noted otherwise in the corresponding PSP’s documentation, the IO sequencer configuration mechanism is supported by the PSP and the IO sequencer is run just after initializing the PSP console. As an example, the following snippet will configure the IO sequencer on x86 machines to write letter ’X’ to the serial port (assuming it is already configured).
<prop_dir name="board"> <prop_dir name="config"> <prop_dir name="io_seq"> <prop_dir name="0"> <prop_addr name="addr" data="0x3F8" /> <prop_uint64 name="value" data="0x58" /> <prop_uint32 name="size" data="1" /> <prop_bool name="io_port" data="true" /> </prop_dir> </prop_dir> </prop_dir> </prop_dir>
3.4 KDEV Drivers IO Memory Mapping
When a KDEV driver calls drv_io_phys_to_kernel() then kernel calls PSP to get mapped kernel virtual address for accessing a given IO physical address. A dedicated mapping is required to access IO resources: typically UNCACHED memory is used to access IO devices, while the mapping for kernel memory is cached.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Interrupts on ARM 41
The PSP during boot time iterates through all memory requirement properties with type P4_PROP_T_MEMMAP in prop:board/io and check if they are covered by the existing mappings in PSP. If the mapping is not found then the following message is printed on the console:
Cannot add KDEV memory regions: feature is not supported by the ASP
If the whole memory area passed to drv_io_phys_to_kernel() is covered by a property in prop:board/io then it returns the corresponding kernel virtual address based on the information provided by the property.
3.5 Interrupts on ARM
The ARM architecture is defining 3 kind of hardware interrupts:
• Software Generated Interrupt (SGI): Those interrupts are generated purely in software and are used to
generate inter-processor interrupts. That’s the interrupt numbers 0 to 15.
• Private Peripheral Interrupt (PPI): Those interrupts are generated from peripherals that are private to cores.
This kind of interrupt is used for example by the core timer as there is one timer per core on the system.
That’s the interrupt numbers 16 to 31.
• Shared Peripheral Interrupt (SPI): Those interrupts are generated from external peripherals and can be
routed by the interrupt controller to one specific cores. That’s the interrupt numbers 32 to 1020.
Only the SPI interrupts should be granted to applications running in partitions as they are the only ones which can be routed by PikeOS to the right core depending on the core the thread waiting for is on. SGI interrupts should never be used by any driver. PPI interrupts could be used from a kernel driver for very specific use case and must be handled carefully as they could be raised on several cores in parallel. The core on which it is asked to unmask a PPI interrupt is ignored by the PSP as this is not possible to define in the GIC interrupt controller.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3.6 PSP qemu-arm
3.6.1 The PSP Configuration
The PSP and kernel properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39. By default, the PikeOS PSPs uses serial channel 1 as system console.
Warning: Concurrent use of serial interface as system console and 8250 driver may result in unexpected behavior.
The PikeOS system console is configured to use the communication parameters 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit).
3.6.2 Memory Size
The PSP does not detect the memory size in QEMU. As a consequence if you modify the memory available through the -m argument you need to change the PSP memory size property to reflect this change. By default this value is set to 128M (see psp/memory/size property in 3.2).
3.6.3 PSP Specific Properties
None present.
3.6.4 Limitations
For the PikeOS kernel ARM related architecture limitations see section A.15, page 138.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3.7 PSP imx6
3.7.1 The PSP Configuration
The PSP and kernel properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39. By default, the PikeOS PSPs uses serial channel 2 as system console.
Warning: Concurrent use of serial interface as system console and by imx_uart driver may result in unexpected behavior.
The default value of psp/memory/size property is 1 GiB.
3.7.1.1 Cache L2 Support
A specific configuration parameter allows you to enable or disable the L2 cache support. This parameter is setting a boolean in the property filesystem retrieved by the PSP on startup:
<prop_dir name="board/config"> <prop_bool name="l2c_support" data="true"/> </prop_dir>
Enabling L2 cache will improve performance but will require some manual cache flushing on drivers to maintain coherency between data in the cache and what could be modified by hardware in the memory through DMA operations. When the L2 cache is enabled, and the flags P4_CACHE_FLAG_DMA or P4_CACHE_FLAG_ALL are used in cache operation with p4_cache(), additional cache clean/invalidate operations are performed on the L2 cache as described in section A.9.1, page 135 in the PikeOS Platform Manual. Also, the PSP does not flush the L2 cache on time partition switches.
3.7.1.2 Performance Counters from User
The ARM Cortex A9 contains some performance counters that can be used from user applications to get access to an high resolution counter (up to the cycle) in order to do some benchmarks for example. For security reasons, those counters are by default not accessible from user mode. To make them usable you will have to enable Performance from user parameter of the PSP. This parameter is setting a property retrieved by the psp on startup:
<prop_dir name="board/config"> <prop_bool name="user_perf" data="true"/> </prop_dir>
The following gives some function example that you can copy to use the performance counters.
static inline unsigned int get_cyclecount (void) { unsigned int value;
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
44 PSPs
// Read CCNT Register
__asm__ __volatile("MRC p15, 0, %0, c9, c13, 0\t\n": "=r"(value));
return value;
}
static inline void init_perfcounters (P4_sint32_t do_reset, P4_sint32_t enable_divider) { // in general enable all counters (including cycle counter) P4_sint32_t value = 1;
// perform reset:
if (do_reset)
{
value |= 2; // reset all counters to zero.
value |= 4; // reset cycle counter to zero.
}
if (enable_divider)
value |= 8; // enable "by 64" divider for CCNT.
value |= 16;
// program the performance-counter control-register:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 0\t\n" :: "r"(value));
// enable all counters:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 1\t\n" :: "r"(0x8000000f));
// clear overflows:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 3\t\n" :: "r"(0x8000000f));
}
3.7.2 PSP Specific Properties
Path Type Default
psp/console/port uint32 2
This property specifies the console output port. The value 0 disables the console output, a value of 1, 2, 3,
4 and 5 cause the console output to be directed to the selected UART channel. Any other value disables the
console output.
psp/clock/pll_ref uint32 24000000 Hz
This property specifies the frequency of the PLL reference clock in Hertz. All the clocks in the system are
derived from this frequency.
Table 3: PSP specific properties
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP imx6 45
3.7.3 Limitations
For the PikeOS kernel ARM related architecture limitations see section A.15, page 138.
3.7.4 IOMUX configuration
3.7.4.1 Introduction
The i.MX6 Family chips contains a lot of functional blocks (UART, ethernet, Video, CAN, ...) but a limited number of external pins - called PAD. The IOMUX controller provide a means for several external signals - provided by functional blocks - to share one PAD. In order to have the wanted device connected to external pins, the correct IOMUX configuration should be provided.
Warning: On this paragraph, ’PAD’ and ’pin’ words have exactly the same signification
Generally, each board is connected to i.MX6 Family chip with a specific configuration. Therefore an IOMUX configuration should be provided for each supported board using the i.MX6 Family chip. Modification of the default IOMUX configuration should be only needed if the user modify an existing board or build his own board.
3.7.4.2 Configuration
The IOMUX configuration is done by the PSP which reads the IOMUX register value from the file system property. The root element of the configuration is the iomux_signals directory. Each subdirectory represents a signal. For each output signal (TX), two registers must be configured:
• PAD register, the configuration of the pin (pull-up resistor values, ...).
• MUX register, the configuration of the multiplexer: The pin associated to the signals.
Input signal (RX) contains also a SELECT INPUT register, in order to set the daisy chain. SELECT INPUT register needs to fit with the MUX register value. Registers are represented by two values on the property file system
• offset, the offset of the register on the IOMUX configuration memory area.
• value, the value of the register.
For more information, see the chapter 36 - IOMUX Controller (IOMUXC) - on i.MX 6 Reference Manual.
3.7.4.3 Configuration example
This configuration example below sets two signals, both owned by the FlexCAN functional block:
<prop_dir name="iomux_signals"> <prop_dir name="0"> <prop_string name="sig_name" data="FLEXCAN1_RX"/> <prop_dir name="MUX"> <!--IOMUXC_SW_MUX_CTL_PAD_KEY_ROW2 Mode: KEY_ROW2_ALT2
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
46 PSPs
Ball: W4-->
<prop_uint32 name="offset" data="0x020C"/>
<prop_uint32 name="value" data="0x00000002"/>
</prop_dir>
<prop_dir name="PAD">
<!--IOMUXC_SW_PAD_CTL_PAD_KEY_ROW2-->
<prop_uint32 name="offset" data="0x05DC"/>
<prop_uint32 name="value" data="0x0001B0B0"/>
</prop_dir>
<prop_dir name="SELECT_INPUT">
<!--IOMUXC_FLEXCAN1_RX_SELECT_INPUT-->
<prop_uint32 name="offset" data="0x07E4"/>
<prop_uint32 name="value" data="0x00000000"/>
</prop_dir>
</prop_dir>
<prop_dir name="1">
<prop_string name="sig_name" data="FLEXCAN1_TX"/>
<prop_dir name="MUX">
<!--IOMUXC_SW_MUX_CTL_PAD_KEY_COL2
Mode: KEY_COL2_ALT2
Ball: W6-->
<prop_uint32 name="offset" data="0x0208"/>
<prop_uint32 name="value" data="0x00000002"/>
</prop_dir>
<prop_dir name="PAD">
<!--IOMUXC_SW_PAD_CTL_PAD_KEY_COL2-->
<prop_uint32 name="offset" data="0x05D8"/>
<prop_uint32 name="value" data="0x0001B0B0"/>
</prop_dir>
</prop_dir>
</prop_dir>
The first signal, called FLEXCAN1_RX, is a reception signal. With the MUX register this signal is associated to the PAD KEY_ROW2, which corresponds to the W4 pin on the chip. The SELECT_INPUT register of FLEXCAN1 is also configured in order to use KEY_ROW2 PAD. The second signal, called FLEXCAN1_TX, is a transmission signal. With the MUX register this signal is associated to the PAD KEY_COL2, which corresponds to the W6 pin on the chip.
3.7.5 IO device driver
3.7.5.1 Introduction
The IO device driver provides memory access to the physical memory. The list of physical addresses which can be accessed, is statically configured in the psp component file. This driver is used to allow direct hardware access for code outside of the PikeOS kernel. This is mainly used for direct I/O P4Linux or Android partitions with drivers that expect access to a certain physical address. Warning: This allows direct physical hardware access and therefore circumvents partitioning. Access to this device and usage should only be granted to trusted partitions.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP imx6 47
3.7.5.2 Configuration
The appropriate access permission needs to be granted to the corresponding property file /psp/driver/IO in order to allow usage of the IO driver inside the partition. This can be done by adding a new file access to the file access list of the partition (vmit editor):
AccessMode: "VM_O_RD VM_O_MAP" FileName: "prop:psp/driver/IO"
This will add the following line into the vmit4.xml file:
Note: A partition with above access rights can access ALL configured physical addresses. No further separa- tion of access is possible. Two partitions with access to the device will share the access to the same physical addresses.
The list of addresses that can be accessed is configured in the psp component file under the property directory board/drv/io (into the RomimageTable). The valid form of properties is:
<prop_uint32 name="reg0" data="0x020DC000"/>
The name can be in the form "regX" where X is a number from 0 to 9. The data attribute contains the accessed physical address. This can be added directly by using the Romimage editor with the following steps:
• add a new prop_dir named "drv" as a sub-property of "board" (if not present).
• add a new prop_dir named "io" as a sub-property of "drv" (if not present).
• add a new prop_uint32 named "regX" with the physical address needed as data.
3.7.5.3 Usage instructions
Applications running inside the partition need to request a device grant first before the driver can be accessed. This can be done using the following code snippet:
P4_devid_t dev;
vm_file_desc_t fd;
P4_e_t err;
err = vm_open("prop:psp/driver/IO", VM_O_RD | VM_O_MAP, &fd);
if (err == P4_E_OK)
{
err = vm_prop_dev_grant(&fd, "", &dev);
vm_close(&fd);
}
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
48 PSPs
The driver is accessed through the p4_dev_call() function call. Please see the document kernel-reference- manual.pdf for a detailed description of this function call. For this driver, the function can be used in the following way:
#define IO_READ_OPERATION 0x00 #define IO_WRITE_OPERATION 0x01 #define IO_AND_OPERATION 0x02 #define IO_OR_OPERATION 0x03
/*
* Physical address that is going to be accessed. These addresses are
* configured in the psp component file.
*/
P4_cpureg_t reg_addr = 0x020DC000;
/* For the read value. */
P4_cpureg_t value;
P4_e_t result;
/* Read example */
p4_result = p4_dev_call(dev, IO_READ_OPERATION, reg_addr, (P4_cpureg_t) &value, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("Read 0x%X\n", value);
/* Write example */
p4_result = p4_dev_call(dev, IO_WRITE_OPERATION, reg_addr, 0x00000000, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("Writen 0x%X\n", 0x00000000);
/* OR example */
p4_result = p4_dev_call(dev, IO_OR_OPERATION, reg_addr, 0x00200000, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("ORed 0x%X\n", 0x00200000);
/* AND example */
p4_result = p4_dev_call(dev, IO_AND_OPERATION, reg_addr, 0x00100000, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("ANDed 0x%X\n", 0x00100000);
The func parameter can have values 0, 1, 2, 3. Meaning of the values is evident from the code examples (IO_READ_OPERATION, . . . ). The driver also supports special identify function (func = 0xFFFFFFFF ) that al-
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP imx6 49
lows verification if the expected device is opened. This is done via a magic version number to avoid interface compatibility issues. The version magic for the current driver interface is 0x49A32FE1. The arg1 parameter is used for the physical address of the accessed memory, or as the identity magic for the identify function. The semantics of the parameter arg2 differs for different function. For the IO_READ_OPERATION function the argument must contain an address of memory where the read result will be stored. For the other functions an integer value is expected. The meaning of the value reflects the function. The driver call may return one of the following error codes:
• P4_E_OK The memory has been accessed successfully or the driver identity is as expected.
• P4_E_PERM The accessed address is not specified in the driver configuration.
• P4_E_NOENT The specified function (i.e. value of funct parameter) is not valid.
• P4_E_INVAL The driver has different identity magic.
Here is the full example that can be used in a PikeOS native application.
#define IO_READ_OPERATION 0x00 #define IO_WRITE_OPERATION 0x01 #define IO_AND_OPERATION 0x02 #define IO_OR_OPERATION 0x03 #define IO_IDENTITY_FUNCTION 0xFFFFFFFF
#define IO_ACCESS_DRIVER_IDENTITY_MAGIC 0x49A32FE1
/**
-
@purpose "Main" function of the io access demonstration / extern int io_access_example_main(void) { / Startup message. */ vm_cputs("IO access test, starting up.\n");
vm_file_desc_t fd; P4_e_t p4_result; P4_e_t vm_result = vm_open("prop:psp/driver/IO", VM_O_MAP, &fd);
if (vm_result) { vm_cprintf("vm_open: err code 0x%x\n", vm_result); return 1; }
P4_devid_t dev; vm_result = vm_prop_dev_grant(&fd, NULL, &dev); if (vm_result != P4_E_OK) { vm_cprintf("vm_dev_grant: err code 0x%x\n", vm_result); return 1; }
vm_close(&fd);
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
50 PSPs
vm_cprintf("DEV = 0x%X\n", dev);
/* Are we really talking to the right driver? */
p4_result = p4_dev_call(dev, IO_IDENTITY_FUNCTION, IO_ACCESS_DRIVER_IDENTITY_MAGIC, 0, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: wrong driver 0x%x\n", p4_result);
return 1;
}
vm_cprintf("We are talking to the correct driver.\n");
/*
* Physical address that is going to be accessed. These addresses are
* configured in the board psp component file.
*/
P4_cpureg_t reg_addr = 0x020DC000;
/* Read or written value. */
P4_uint32_t read_value;
/* Read example */
p4_result = p4_dev_call(dev, IO_READ_OPERATION, reg_addr, (P4_cpureg_t) &read_value, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("Read 0x%X\n", read_value);
/* Write example */
p4_result = p4_dev_call(dev, IO_WRITE_OPERATION, reg_addr, 0x00000000, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("Writen 0x%X\n", 0x00000000);
read_value = 0;
p4_result = p4_dev_call(dev, IO_READ_OPERATION, reg_addr, (P4_cpureg_t) &read_value, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("Read 0x%X\n", read_value);
/* OR example */
p4_result = p4_dev_call(dev, IO_OR_OPERATION, reg_addr, 0x00200000, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("ORed 0x%X\n", 0x00200000);
read_value = 0;
p4_result = p4_dev_call(dev, IO_READ_OPERATION, reg_addr, (P4_cpureg_t) &read_value, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP imx6 51
return 1;
}
vm_cprintf("Read 0x%X\n", read_value);
/* AND example */
p4_result = p4_dev_call(dev, IO_AND_OPERATION, reg_addr, 0x00100000, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("ANDed 0x%X\n", 0x00100000);
read_value = 0;
p4_result = p4_dev_call(dev, IO_READ_OPERATION, reg_addr, (P4_cpureg_t) &read_value, 0, 0);
if (p4_result != P4_E_OK) {
vm_cprintf("p4_dev_call: err code 0x%x\n", p4_result);
return 1;
}
vm_cprintf("Read 0x%X\n", read_value);
/* Do the real work */
vm_cprintf("Done.\n");
for (;;) {
p4_sleep(P4_SEC(5));
}
return 0;
}
This is the expected output:
PikeOS System Software up and running. IO access test, starting up. DEV = 0x13 We are talking to the correct driver. Read 0x100000 Writen 0x0 Read 0x0 ORed 0x200000 Read 0x200000 ANDed 0x100000 Read 0x0 Done.
3.7.6 GPIO interrupt configuration
The PSP supports configuration of GPIO interrupt signal mode. The user can configure whether the interrupts will be edge-triggered or level triggered. The default setting is edge-triggered interrupts. The motivation behind these configuration options is that some devices (such as the eGalax touchscreen) need to use the low-level interrupt mode. Otherwise, the interrupts could get lost for this device. The properties for the edge/level settings are located in the property directory board/config in the psp component file. Use the property directory with names from gpio_bank1 to gpio_bank7 to specify the bank you want to
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
52 PSPs
configure. Each bank has two GPIO Interrupt Configuration Registers (properties icr1 and icr2) and one GPIO Edge Select Register (property edge_sel). These registers can be configured by the following example code:
<prop_dir name="board/config">
<prop_dir name="gpio_bank6">
<prop_uint32 name="icr1" data="0x0"/>
<prop_uint32 name="icr2" data="0x0"/>
<prop_uint32 name="edge_sel" data="0xFFFFFEFF"/>
</prop_dir>
</prop_dir>
The edge selection register is provided for compatibility reasons. A set bit in this register causes the corresponding interrupts to be generated on any edge regardless of the icr registers settings. When this bit is cleared the edge/level settings is determined by the icr registers. The icr registers contain 32 pairs of bits where each pair has the following meaning for the corresponding interrupt: ICRn[1:0] Interrupt setting 00 Interrupt n is low-level sensitive. 01 Interrupt n is high-level sensitive. 10 Interrupt n is rising-edge sensitive. 11 Interrupt n is falling-edge sensitive. The ICR0 pair is located in the icr1 register in its two least significant bits. The location of other pairs is directly increasing with the pair number, as one would expect. Refer the i.MX 6Dual/6Quad Applications Processor Reference Manual for a detailed information about these registers.
3.7.7 PCI support
PCI support for the i.MX6 SoC is ensured by the Layerscape PCI PSP driver and PSP PCI driver. Please refer to section 5.5.2, page 107 sections for more information on the configuration of the Layerscape PCI driver.
3.7.7.1 Controller initialization
The PSP PCI controller driver relies on the initialization done by u-boot to setup the controller and initiate link negotiation with devices behind the Root Complex. The standard u-boot build for i.MX6 SoCs usually do not come with PCI support built-in. If that is the case, please refer to the board vendor to get the u-boot sources and procedure to enable the PCI support in the bootloader. As an example, for imx6-sabresd board, the only required configuration is to enable CONFIG_CMD_PCI in the u-boot configuration. To check PCI support is enabled in u-boot, one can have a look at the starting logs. For example, the following extract shows a network card attached in the mini PCIe slot on a i.MX6 SabreSD board:
[...] 00:01.0 - 16c3:abcd - Bridge device 01:00.0 - 10ec:8168 - Network controller [...]
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP imx6 53
3.7.7.2 Configuring the integration project
By default, the controller is not enabled in the PSP configuration, and you need to explicitly enable it for PikeOS to scan devices behind it.
3.7.8 Watchdog support
The imx6 PSP has a basic startup watchdog support. Early during the boot the PSP checks for presence of the IMX WDT driver described in section 5.3.1, page 96. If a configuration of that driver is found, the PSP starts to refresh the watchdog device according to that configuration. The watchdog device is then refreshed until the IMX WDT driver calls the hand off function. This functionality is only intended to prevent the watchdog timeout to expire during startup phase before it’s handed to the watchdog driver. It is not intended for assuring proper PSP startup.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3.8 PSP tegra-k1
3.8.1 The PSP Configuration
The PSP and kernel properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39. The default value of the psp/memory/size property is 0x7C000000.
3.8.1.1 Performance Counters from User
The ARM Cortex A15 contains some performance counters that can be used from user applications to get access to an high resolution counter (up to the cycle) in order to do some benchmarks for example. For security reasons, those counters are by default not accessible from user mode. To make them usable you will have to enable Performance from user parameter of the PSP. This parameter is setting a property retrieved by the psp on startup:
<prop_dir name="board/config"> <prop_bool name="user_perf" data="true"/> </prop_dir>
The following gives some function example that you can copy to use the performance counters.
static inline unsigned int get_cyclecount (void) { unsigned int value; // Read CCNT Register asm __volatile("MRC p15, 0, %0, c9, c13, 0\t\n": "=r"(value)); return value; }
static inline void init_perfcounters (P4_sint32_t do_reset, P4_sint32_t enable_divider) { // in general enable all counters (including cycle counter) P4_sint32_t value = 1;
// perform reset: if (do_reset) { value |= 2; // reset all counters to zero. value |= 4; // reset cycle counter to zero. }
if (enable_divider) value |= 8; // enable "by 64" divider for CCNT.
value |= 16;
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP tegra-k1 55
// program the performance-counter control-register:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 0\t\n" :: "r"(value));
// enable all counters:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 1\t\n" :: "r"(0x8000000f));
// clear overflows:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 3\t\n" :: "r"(0x8000000f));
}
3.8.2 PSP Specific Properties
None present.
3.8.3 Limitations
For the PikeOS kernel ARM related architecture limitations see section A.15, page 138.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3.9 PSP zynq
3.9.1 The PSP Configuration
The PSP and properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39. By default, the PikeOS PSPs uses serial channel 1 as system console. The default value of psp/memory/size property is 256 MiB.
3.9.1.1 Cache L2 Support
A specific configuration parameter allows you to enable or disable the L2 cache support. This parameter is setting a boolean in the property filesystem retrieved by the PSP on startup:
<prop_dir name="board/config"> <prop_bool name="l2c_support" data="true"/> </prop_dir>
Enabling L2 cache will improve performance but will require some manual cache flushing on drivers to maintain coherency between data in the cache and what could be modified by hardware in the memory through DMA operations. When the L2 cache is enabled, and the flags P4_CACHE_FLAG_DMA or P4_CACHE_FLAG_ALL are used in cache operation with p4_cache(), additional cache clean/invalidate operations are performed on the L2 cache as described in section A.9.1, page 135 in the PikeOS Platform Manual. Also, the PSP does not flush the L2 cache on time partition switches.
3.9.1.2 Performance Counters from User
The ARM Cortex A9 contains some performance counters that can be used from user applications to get access to an high resolution counter (up to the cycle) in order to do some benchmarks for example. For security reasons, those counters are by default not accessible from user mode. To make them usable you will have to enable Performance from user parameter of the PSP. This parameter is setting a property retrieved by the psp on startup:
<prop_dir name="board/config"> <prop_bool name="user_perf" data="true"/> </prop_dir>
The following gives some function example that you can copy to use the performance counters.
static inline unsigned int get_cyclecount (void) { unsigned int value; // Read CCNT Register asm __volatile("MRC p15, 0, %0, c9, c13, 0\t\n": "=r"(value)); return value;
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP zynq 57
}
static inline void init_perfcounters (P4_sint32_t do_reset, P4_sint32_t enable_divider) { // in general enable all counters (including cycle counter) P4_sint32_t value = 1;
// perform reset:
if (do_reset)
{
value |= 2; // reset all counters to zero.
value |= 4; // reset cycle counter to zero.
}
if (enable_divider)
value |= 8; // enable "by 64" divider for CCNT.
value |= 16;
// program the performance-counter control-register:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 0\t\n" :: "r"(value));
// enable all counters:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 1\t\n" :: "r"(0x8000000f));
// clear overflows:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 3\t\n" :: "r"(0x8000000f));
}
3.9.2 PSP Specific Properties
Table 4 lists ZYNQ PSP specific properties.
Path Type Default
psp/console/port uint32 1
This property specifies the console output port. The value 0 disables the console output, a value of 1 or 2
cause the console output to be directed to the first or second UART channel. Any other value disables the
console output.
psp/clock/pll_ref uint32 33333333 Hz
This property specifies the frequency of the PLL reference clock in Hertz. All the clocks in the system are
derived from this frequency.
Table 4: ZYNQ PSP specific properties
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
58 PSPs
3.9.3 Limitations
For the PikeOS kernel ARM related architecture limitations see section A.15, page 138.
3.9.4 GPIO Interrupts
The PSP supports interrupts generated by GPIO pins (MIO and EMIO signals). The GPIO interrupts must be en- abled in the PSP configuration inside the integration project. When enabled, the properties prop:psp/int/MIO0..53 and prop:psp/int/EMIO0..63 will appear in the resulting project4.rbx and GPIO interrupt controller is initialized during PSP startup. The user can configure via mode argument in p4_int_attach_syscall() whether the interrupts will be falling/ris- ing/both edge-triggered or low/high level triggered. The default setting is falling edge-triggered interrupts. The p4_int_wait() can be used for the waiting for the expected event on the GPIO pin. The PSP always handles the GPIO interrupt on CPU 0. Interrupt affinity is not supported.
Note: Since the code modifies the following GPIO registers: INT_MASK, INT_EN, INT_DIS, INT_STAT,INT_TYPE, INT_POLARITY, INT_ANY it shall not be enabled concurrently with GPIO driver.
3.9.5 IO Sequencer
This PSP has one IO Sequencer configurable through the property tree directory board/config/io_seq. The IO actions defined here are executed before initialization of other devices, including the serial console. Wrong IO actions may therefore cause the board to halt without any error output. For more details about IO Sequencers, consult subsection 3.3.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3.10 PSP ls102xa
3.10.1 The PSP Configuration
The PSP and kernel properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39. By default, the PikeOS PSPs uses serial channel 1 as system console.
Warning: Concurrent use of serial interface as system console and 8250 driver may result in unexpected behavior.
The PikeOS system console is configured to use the communication parameters 115200,8N1 (115200 baud, 8 data bits, 1 stop bit and no parity bit). The default value of psp/memory/size property is 0x3BC00000.
3.10.2 PSP Specific Properties
None present.
3.10.3 PCI support
PCI support for the LS102xA SoC is ensured by the Layerscape PCI PSP driver. Please refer to section 5.5.2, page 107 section for more information on the configuration.
3.10.3.1 Controllers identification and initialization
The PSP PCI controller driver relies on the initialization done by u-boot to setup the controller and initiate link negotiation with devices behind the Root Complex. The standard u-boot build for LS102x boards comes with PCI support enabled. To know which controllers the PCI cards are attached to, and make sure the PCI support is enabled, one can have a look at u-boot starting logs. For example, the following extract from a LS1021A-iot board shows controllers 1 and 2 enabled, with controller 2 having a network card attached:
[...] PCIe1: Root Complex x1 gen1, regs @ 0x3400000 01:00.0 - 10ec:8168 - Network controller PCIe1: Bus 00 - 01 PCIe2: Root Complex no link, regs @ 0x3500000 [...]
The controllers in the PSP’s configuration are using the same numbering as in u-boot and the Reference Man- uals. Thus, if you need to use the controller labeled ”PCIe1” in u-boot, you should refer to the ”Controller 1 configuration” section of the PSP component.
3.10.3.2 Configuring the integration project
By default, no controller is enabled in the PSP configuration, and you need to select which one(s) will be scanned during startup.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
60 PSPs
3.10.4 MSI support
Support for MSI is provided for this PSP. Refer to section 5.5.3, page 108 section for more information on the configuration and usage.
3.10.5 Limitations
For the PikeOS kernel ARM related architecture limitations see section A.15, page 138.
Warning: The ls102xa PSP does only support secure boot.
This means you must ensure the bootloader does not start the image as non-secure. This action can be done on-boot in two ways:
• use bootstrategy raw as u-boot starts on secure and will remain in secure mode if “go” command is used
• on compatible u-boot version, force bootm command to remain in secure:
> setenv bootm_boot_mode sec
> saveenv
See section A.14, page 137 for limitations when rebuilding the PSP from source.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
3.11 PSP cyclone-v
3.11.1 The PSP Configuration
The PSP and kernel properties can be set within the PikeOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in the section 3.2, page 39. By default, the PikeOS PSPs uses serial channel 1 as system console. The default value of psp/memory/size property is 256 MiB.
3.11.1.1 Cache L2 Support
A specific configuration parameter allows you to enable or disable the L2 cache support. This parameter is setting a boolean in the property filesystem retrieved by the PSP on startup:
<prop_dir name="board/config"> <prop_bool name="l2c_support" data="true"/> </prop_dir>
Enabling L2 cache will improve performance but will require some manual cache flushing on drivers to maintain coherency between data in the cache and what could be modified by hardware in the memory through DMA operations. When the L2 cache is enabled, and the flags P4_CACHE_FLAG_DMA or P4_CACHE_FLAG_ALL are used in cache operation with p4_cache(), additional cache clean/invalidate operations are performed on the L2 cache as described in section A.9.1, page 135 in the PikeOS Platform Manual. Also, the PSP does not flush the L2 cache on time partition switches.
3.11.1.2 Performance Counters from User
The ARM Cortex A9 contains some performance counters that can be used from user applications to get access to an high resolution counter (up to the cycle) in order to do some benchmarks for example. For security reasons, those counters are by default not accessible from user mode. To make them usable you will have to enable Performance from user parameter of the PSP. This parameter is setting a property retrieved by the psp on startup:
<prop_dir name="board/config"> <prop_bool name="user_perf" data="true"/> </prop_dir>
The following gives some function example that you can copy to use the performance counters.
static inline unsigned int get_cyclecount (void) { unsigned int value; // Read CCNT Register asm __volatile("MRC p15, 0, %0, c9, c13, 0\t\n": "=r"(value)); return value;
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
62 PSPs
}
static inline void init_perfcounters (P4_sint32_t do_reset, P4_sint32_t enable_divider) { // in general enable all counters (including cycle counter) P4_sint32_t value = 1;
// perform reset:
if (do_reset)
{
value |= 2; // reset all counters to zero.
value |= 4; // reset cycle counter to zero.
}
if (enable_divider)
value |= 8; // enable "by 64" divider for CCNT.
value |= 16;
// program the performance-counter control-register:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 0\t\n" :: "r"(value));
// enable all counters:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 1\t\n" :: "r"(0x8000000f));
// clear overflows:
__asm__ __volatile("MCR p15, 0, %0, c9, c12, 3\t\n" :: "r"(0x8000000f));
}
3.11.2 PSP Specific Properties
The path of the PSP specific properties is prop:psp/. The type of the psp properties is prop_uint32.
Path Type Default
psp/console/port uint32 1
This property specifies the console output port. The value 0 disables the console output, a value of 1 and 2
cause the console output to be directed to the selected UART channel. Any other value disables the console
output.
psp/freq_eosc1 uint32 25000000 Hz
This property specifies the frequency of the PLL reference clock in Hertz. All the clocks based on eosc1_clk
in the system are derived from this frequency.
psp/freq_eosc2 uint32 25000000 Hz
This property specifies the frequency of the PLL reference clock in Hertz. All the clocks based on eosc2_clk
in the system are derived from this frequency.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PSP cyclone-v 63
Path Type Default psp/freq_perrefclk uint32 0 Hz This property specifies the frequency of the PLL reference clock in Hertz. All the clocks based on f2s_pe- riph_ref_clk in the system are derived from this frequency.
Table 5: PSP Specific Properties
3.11.3 Limitations
For the PikeOS kernel ARM related architecture limitations see section A.15, page 138.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
4 Boot Strategies
Most ARM boards use U-Boot as boot loader. This boot loader allows booting of images from onboard media (flash, disk, etc.) as well as from network. PikeOS supports this by providing the so called U-Boot boot strategy, by which a U-Boot style image will be created.
uboot: Bootstrap image for U-Boot, the PikeOS image is compressed (gzip).
uboot_unc: Bootstrap image for U-Boot, the PikeOS image is not compressed.
uboot_dtb: Bootstrap image for U-Boot, the PikeOS image is compressed (gzip) and an additional fake image is attached to match the needs of newer U-Boot versions.
uboot_dtb_unc: Like uboot_dtb, but the PikeOS image is uncompressed (gzip).
elf: This creates an ELF file. This can be used mainly with hardware debuggers.
raw: This creates a raw binary image. This can be used with U-Boot and the go command or when using Hardware virtualization for a guest.
fastboot: This is the usual firmware used by Android boards. It is creating an image compliant with this firmware that can be loaded using fastboot.
fastboot_dtb: This is the fastboot strategy but adapted to some boards like Qualcomm’s adding a DTB directly in the image with a protocol added to the standard one coming from Android. This requires a DTB image generated using dtbtool and packing several DTBs inside one image. When a board requires one, it is provided with the BSP and is set using the variable FASTBOOT_DT_IMG.
qemu: Boot strategy generating an image suitable to be executed by QEMU.
Note: As the U-Boot bootloader is only able to handle compressed bootimages whose uncompressed size is not larger than 8MB, you should use the uncompressed strategy when your image exceeds this limit.
Note: The usage of a fake DTB image might be not sufficient to satisfy the needs of the boot loader. In that case it is possible to provide your own DTS file, which will be converted to a DTB image during the make boot command. The DTS file must reside in the integration project and its name must be uboot.dts.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
5 Drivers
5.1 Serial drivers
5.1.1 Serial IMX
PikeOS provides a serial driver which allows usage of the on-chip IMX UART controller. The imx_uart serial driver uses the driver development environment with the Serial Driver High Level Module (see PikeOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the PikeOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and PikeOS Device Driver Programming Reference Manual, section 8.4, page 395 for description of the interface between driver and client. The imx_uart driver is provided in two versions - user level (external file provider) and kernel level.
5.1.1.1 User Level Driver
The user level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/imx_uart.elf
and the corresponding configuration file is:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/imx_uart.dom
The dom file adds the driver to the service partition, instantiates a single serial port, associating it with the UART1 I/O device. The port communication parameters are defaulted to 115200,8N1, no handshake. It has no dependencies. In CODEO, the imx_uart driver can be added to an integration project using the Add... button. Browse to PIKEOS_POOL->driver->serial and select iMX6 Serial User Level Driver. In a configuration script, the imx_uart driver can be added to an integration project with the line
add PIKEOS_POOL driver/serial/imx_uart.dom
5.1.1.2 Kernel Level Driver
To use the kernel level version of the imx_uart driver, the following steps are needed:
• Using a kernel fusion project, create a new kernel linked with the driver
• Configure the integration project to use this new kernel
• Add the driver configuration to the integration project
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
66 Drivers
5.1.1.2.1 Kernel Fusion Project
The kernel level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/object/kerneldriver/ imx_uart/kerneldriver_noassert.kdev
and the corresponding configuration file is
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/kerneldriver.cmp
To add the driver to a kernel fusion project using CODEO:
• Create a new PikeOS project, of type Kernel Fusion. From the list of demo projects, select the kernel
corresponding to the board used in the integration project. Please refer to Appendix B for the list of kernels.
• Set the custom pool. The kernel fusion project should use the same pool as the integration project.
• Select the base component and click the Add... button.
• Browse to PIKEOS_POOL->fusion-kernel->kerneldriver. Click OK, Finish. Save the project.
• Execute the all and install Make targets.
The new kernel should now be installed under the object/bsp directory in the custom pool.
5.1.1.2.2 Configuring the Integration Project
The new kernel created in the fusion project and the kernel driver configuration must be added to the integration project. The kernel driver property based configuration is provided by the file
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/imx_uart_kdev.dom
Alternatively, it is possible to use the binary configuration file
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/imx_uart/imx_uart-prov_kdev.cmp
Using CODEO:
• Open the integration project in the project editor (open the project.xml file).
• Set the custom pool. The integration project should use the same pool as the kernel fusion project.
• Select the PikeOS Kernel element inside the board component.
• In the parameter section labelled Kernel Binary, set the location to Custom Pool.
• Select the board component and click the Add... button.
• Browse to PIKEOS_POOL->driver->serial->iMX6 Serial Level Kernel Driver. Click OK, Finish.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Serial drivers 67
• Configure the driver. The driver supports up to four devices. By default, the first device is enabled. Other
devices are enabled by setting the Number of devices parameter. For each device, configure the I/O settings
to match the board.
• Save the project.
• Execute the boot Make target.
5.1.2 Serial XuartPS
PikeOS provides a serial driver which allows usage of the on-chip xuartps controller. The xuartps serial driver uses the driver development environment with the Serial Driver High Level Module (see PikeOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the PikeOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and PikeOS Device Driver Programming Reference Manual, section 8.4, page 395 for description of the interface between driver and client. The serial driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/xuartps.elf
and the corresponding configuration files are:
• The domain file, instantiating and configuring the serial base driver component and a serial port component:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/xuartps.dom
• The serial driver base component file configuring the process instance settings and generic run-time con-
figuration. See PikeOS Device Driver Programming Reference Manual for details:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/xuartps/xuartps-fp_ext.cmp
• The serial port component file configuring file access parameters and specific parameters for an UART link:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/xuartps/xuartps-device.cmp
Note: This component includes a BSP Settings option node allowing to configure BSP specific parame-
ters such as I/O Device Configuration for I/O Memory configuration, IRQ setting, UART Clock Speed and
CPU Affinity. When BSP Settings is enabled, I/O Address Identifier and IRQ Identifier strings configure
link to data included in the PSP.
The serial driver can be added using Add... button. Select serial type and select XUartPs Serial User Level Driver. The default configuration provides a single serial port and it has no dependency. The communication parameters of all channels are defaulted to 115200,8N1, no handshake.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
68 Drivers
5.1.3 Serial PL011
PikeOS provides a serial driver which allows usage of the on-chip PL011 controller.
Warning: The driver does not use the driver development environment described in driver-reference- manual.pdf
The serial driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/pl011_fp
and the corresponding driver configuration file is:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/pl011.dom
The serial driver can be added using Add... button. Select serial type and select PL011 Serial User Level Driver. The default configuration provides a single serial port and it has no dependency.
Note: It is to be noted that the following directory and files also exist in versions for every ARM architecture supported by PikeOS in:
• /opt/pikeos-D5.0/target/arm/v7hf/driver/
• /opt/pikeos-D5.0/target/arm/v8hf/driver/
5.1.3.1 Configuration
The driver’s configuration refers to the following PikeOS properties. Note that some properties dependent on the hardware and are provided by the PSP (Io and Int) and other by the board configuration (RegMultiplier, ClockSpeed, SamplingRate, and AddressSwapMask ).
<!-- serial driver class -->
<prop_dir name="board/drv/ser">
<prop_dir name="ser0">
<prop_dir name="dev">
<prop_dir name="0">
<prop_dir name="Resource">
<prop_link data="psp/io/UART1" name="Io" />
<prop_link data="psp/int/UART1" name="Int" />
</prop_dir>
<prop_dir name="cfg">
<!--Port Settings-->
<prop_uint32 name="Baud" data="38400"/>
<prop_uint32 name="DataBits" data="8"/>
<prop_uint32 name="StartBits" data="0"/>
<prop_uint32 name="StopBits" data="1"/>
<prop_uint32 name="Parity" data="0"/>
<prop_uint32 name="FlowCntl" data="0"/>
<prop_uint32 name="RxFifoTrg" data="0"/>
<!--Hardware Settings-->
<prop_uint32 name="RegMultiplier" data="1"/>
<prop_uint32 name="ClockSpeed" data="1843200"/>
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Serial drivers 69
<prop_uint32 name="SamplingRate" data="16"/>
<prop_uint32 name="AddressSwapMask" data="0"/>
</prop_dir>
</prop_dir>
</prop_dir>
</prop_dir>
</prop_dir>
The communication parameters of all channels are set to 38400,8N1, no handshake.
5.1.4 Serial 8250
PikeOS provides a serial driver for use with 8250 controllers. The 8250 serial driver uses the driver development environment with the Serial Driver High Level Module (see PikeOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the PikeOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and PikeOS Device Driver Programming Reference Manual, section 8.4, page 395 for description of the interface between driver and client. The 8250 driver is provided in two versions - user level (external file provider) and kernel level.
5.1.4.1 Driver Specific Configuration Parameters
In addition to the standard parameters defined for serial drivers by the driver framework, the 8250 serial driver has three specific configuration parameters. The access to the 8250 registers is always 8-bit. However, on some platforms the registers are not located in con- secutive bytes. Instead, there is a certain spacing between the registers. On such platforms, the "reg_multiplier" parameter can be used to select the spacing, in bytes, including the 8-bit register itself. If the "reg_multiplier" is greater than one byte and the system is big-endian, then the correct location of the 8- bit 8250 register can be selected using the "address_swap_mask" parameter, which XORs the intended register address with the mask. The addresses are assumed to be little endian.
Property pathnames are relative to the subdirectory prop:config/provider//priv/io/. The default value is used if the property is not present. If the property is present but cannot be read or is of the wrong type, this is treated as an error. Property Pathname Property Type Description Default Value address_swap_mask prop_uint32 Address swap mask remaps the address of regis- 0 ter location. The value is XORed with the actual register address. reg_multiplier prop_uint32 Register multiplier denotes the size of one 8250 1 register in bytes sampling_rate prop_uint32 Oversampling Rate, depends on particular UART 16 chip
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
70 Drivers
5.1.4.2 Driver IOCTL Commands
The DRV_SER_IOCTL_SET_COMM command is used to set port communication parameters. When calling this command, the 8250 driver resets the UART and the RS232 signals to a default state.
The following signals can be set with the DRV_SER_IOCTL_SET_SIGNAL command and read back with the DRV_SER_IOCTL_GET_SIGNAL command:
• DRV_SER_SIGNAL_LOOP
• DRV_SER_SIGNAL_OUT1
• DRV_SER_SIGNAL_RTS
• DRV_SER_SIGNAL_DTR
Warning: When hardware flow control is enabled it is not possible to set RTS signal.
Note: Since on some platforms is used OUT2 signal for enabling interrupts it is not possible to set this signal.
Additionally the following signals can be read with the DRV_SER_IOCTL_GET_SIGNAL command:
• DRV_SER_SIGNAL_CTS
• DRV_SER_SIGNAL_DCD
• DRV_SER_SIGNAL_RI
• DRV_SER_SIGNAL_DSR
5.1.4.3 Driver Specific Limitations
The 8250 serial driver has the following limitations:
• The driver only supports one logical device per I/O device.
5.1.4.4 User Level Driver
The user level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/8250.elf
and the corresponding configuration file is
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/8250.dom
The dom file adds the driver to the service partition, instantiates a single serial port, associating it with the COM1 I/O device. The port communication parameters are defaulted to 115200,8N1, no handshake. It has no dependencies. In CODEO, the 8250 driver can be added to an integration project using the Add... button. Browse to PIKEOS_POOL->driver->serial and select 8250 Serial User Level Driver. In a configuration script, the 8250 driver can be added to an integration project with the line
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Serial drivers 71
add PIKEOS_POOL driver/serial/8250.dom
5.1.4.5 Kernel Level Driver
The use the kernel lever version of the 8250 driver, the following steps are needed:
• Using a kernel fusion project, create a new kernel linked with the driver
• Configure the integration project to use this new kernel
• Add the driver configuration to the integration project
5.1.4.5.1 Kernel Fusion Project
The kernel level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/object/kerneldriver/8250/8250.kdev
and the corresponding configuration file is
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/kerneldriver.cmp
To add the driver to a kernel fusion project using CODEO:
• Create a new PikeOS project, of type Kernel Fusion. From the list of demo projects, select the kernel
corresponding to the board used in the integration project. Please refer to the Appendix for the list of
kernels.
• Set the custom pool. The kernel fusion project should use the same pool as the integration project.
• Select the base component and click the Add... button.
• Browse to PIKEOS_POOL->fusion-kernel->kerneldriver. Click OK, Finish. Save the project.
• Execute the all and install Make targets.
The new kernel should now be installed under the object/bsp directory in the custom pool.
5.1.4.5.2 Configuring the Integration Project
The new kernel created in the fusion project and the kernel driver configuration must be added to the integration project. The kernel driver property based configuration is provided by the file
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/8250_kdev.dom
Alternatively, it is possible to use the binary configuration file
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/8250/8250_prov_kdev.cmp
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
72 Drivers
Using CODEO:
• Open the integration project in the project editor (open the project.xml file).
• Set the custom pool. The integration project should use the same pool as the kernel fusion project.
• Select the PikeOS Kernel element inside the board component.
• In the parameter section labelled Kernel Binary, set the Kernel Directory to Custom Pool.
• Select the board component and click the Add... button.
• Browse to PIKEOS_POOL->driver->serial->8250 Serial Kernel Level Driver. Click OK, Finish.
• Configure the driver. The driver supports up to four devices. By default, the first device is enabled. Other
devices are enabled by setting the Number of devices parameter. For each device, configure the I/O settings
to match the board.
• Save the project.
• Execute the boot Make target.
5.1.5 Serial LPUART
PikeOS provides a serial driver which allows usage of the on-chip Low Power UART controller. The lpuart serial driver uses the driver development environment with the Serial Driver High Level Module (see PikeOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the PikeOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and PikeOS Device Driver Programming Reference Manual, section 8.4, page 395 for description of the interface between driver and client. The serial driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/lpuart.elf
and the corresponding configuration files are:
• The domain file, instantiating and configuring the serial base driver component and a serial port component:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/lpuart.dom
• The serial driver base component file configuring the process instance settings and generic run-time con-
figuration. See PikeOS Device Driver Programming Reference Manual for details:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/lpuart/lpuart-fp_ext.cmp
• The serial port component file configuring file access parameters and specific parameters for an UART link:
/opt/pikeos-D5.0/target/arm/v7hf/driver/serial/lpuart/lpuart-device.cmp
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 73
Note: This component includes a BSP Settings option node allowing to configure BSP specific param-
eters such as I/O Device Configuration for I/O Memory configuration, IRQ setting, UART Clock Speed,
endianess and eDMA support. When BSP Settings is enabled, I/O Address Identifier and IRQ Identifier
strings configure link to data included in the PSP.
The serial driver can be added using Add... button. Select serial type and select LPUART Serial User Level Driver. The default configuration provides a single serial port and it has no dependency. The communication parameters of all channels are defaulted to 115200,8N1, no handshake.
5.2 Ethernet Drivers
5.2.1 Ethernet IMX FEC
PikeOS provides a multi-channel Ethernet driver which allows usage of the IMX FEC Ethernet controller from different applications simultaneously. The imx_fec Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/imx_fec.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device
component and 4 virtual channel components, and overloading default configuration parameters when
needed:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/imx_fec.dom
• The driver component files giving the driver configuration and data structure:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
74 Drivers
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/imx_fec/imx_fec-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/imx_fec/imx_fec-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select iMX6_FEC Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
5.2.1.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: imx_fec
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device
Driver Programming Reference Manual)
5.2.1.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 75
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware registers. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
5.2.1.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false, 32)
5.2.1.4 Driver Specific Limitations
The imx_fec network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
• The support for Gigabit Ethernet has been disabled due to known issues with some boards.
5.2.2 Ethernet XemacPS
PikeOS provides a multi-channel Ethernet driver which allows usage of the XEMACPS Ethernet controller from different applications simultaneously. The xemacps Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
76 Drivers
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/xemacps.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device
component and 4 virtual channel components, and overloading default configuration parameters when
needed:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/xemacps.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/xemacps/xemacps-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/xemacps/xemacps-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select XEmacPs Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Note: The driver makes use of the hardware MAC address filtering provided by the controller. The controller can be set up to accept a maximum of 4 MAC addresses. The number of supported virtual channels is thus limited to 4. Failure to obey the limit shall lead to an initialization error.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 77
5.2.2.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: xemacps
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device Driver Programming Reference Manual)
5.2.2.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware registers. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
78 Drivers
5.2.2.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file
name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in
terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false,
32)
5.2.2.4 Driver Specific Limitations
The xemacps network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
5.2.3 Ethernet smc91cX
PikeOS provides a multi-channel ethernet driver which allows usage of the on-chip smc91cX ethernet controller from different applications simultaneously.
Warning: The driver does not use the driver development environment described in the PikeOS Device Driver Programming Reference Manual
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/smc91cX_fp
and the corresponding driver configuration files are:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 79
• The domain file, instantiating and configuring a smc91cX_fp component and four virtual channel compo- nents:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/smc91cX_fp.dom
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/smc91cX_fp/smc91cX_fp.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/libdrv/drv_net-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select smc91cX_fp-network- driver. The driver provides a single device and 4 virtual channels which can be independently configured.
5.2.3.1 Configuration
The driver configuration refers to the following PikeOS properties. Note that some properties dependent to the hardware are provided by the PSP (Register address and IRQ number ).
• SMC91CX_FP network driver module
Device Name: Default: eth0.
Register address: Default: 0x0.
IRQ number : Default: 0.
• Virtual Channel Configuration (libdrv):
Channel Name: Default: 0.
MAC Address: Default: 00:00:00:00:00:00. A configured address from the HW will be used if this is
kept in default value.
Channel Name: Default: 1.
MAC Address: Default: 02:04:8f:00:0a:49.
Channel Name: Default: 2.
MAC Address: Default: 02:04:8f:00:0a:50.
Channel Name: Default: 3.
MAC Address: Default: 02:04:8f:00:0a:51.
The default board configuration supports a single device with four virtual Ethernet channels, eth0:0, eth0:1, eth0:2, and eth0:3. The device eth0:0 uses the real MAC address stored in the boards’ EEPROM. Therefore, the MAC address is set to "00:00:00:00:00:00" in the corresponding property node. For all other channels, the MAC address has to be given by the property MAC Address of the corresponding channel.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
80 Drivers
5.2.4 Ethernet Felic
PikeOS provides a multi-channel Ethernet driver which allows usage of the FELIC Ethernet controller from different applications simultaneously. The xemacps Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/felic.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device
component and 4 virtual channel components, and overloading default configuration parameters when
needed:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/felic.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/felic/felic-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/felic/felic-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select feLic Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 81
5.2.4.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: felic
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device Driver Programming Reference Manual)
5.2.4.2 Physical Device Configuration
The device configuration is done in 4 steps, 3 generic steps and an hardware specific step:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware registers. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
• Driver Specific Configuration:
Force Promiscuous: Switch the device to the promiscuous mode. Default: false.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
82 Drivers
5.2.4.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file
name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in
terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false,
32)
5.2.4.4 Driver Specific Limitations
The felic network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
5.2.5 Ethernet CPSW
PikeOS provides a multi-channel Ethernet driver which allows usage of the CPSW Ethernet controller from different applications simultaneously. The cpsw Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 83
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/cpsw.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device component and 4 virtual channel components, and overloading default configuration parameters when needed:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/cpsw.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/cpsw/cpsw-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/cpsw/cpsw-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select CPSW Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
5.2.5.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: cpsw_driver
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device Driver Programming Reference Manual)
5.2.5.2 Physical Device Configuration
The device configuration is done in 4 steps, 3 generic steps and an hardware specific step:
• Generic Device Configuration:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
84 Drivers
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware registers. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
5.2.5.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file
name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in
terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false,
32)
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 85
5.2.5.4 Driver Specific Limitations
The cpsw network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
5.2.6 Ethernet TSEC
PikeOS provides a multi-channel Ethernet driver which allows usage of the TSEC Ethernet controller from different applications simultaneously. The tsec Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/ppc/e500/driver/object/tsec.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device componenent and 4 virtual channel components, and overloading default configuration parameters when needed:
/opt/pikeos-D5.0/target/ppc/e500/driver/ethernet/tsec.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/ppc/e500/driver/ethernet/tsec/tsec-fp_ext.cmp
/opt/pikeos-D5.0/target/ppc/e500/driver/ethernet/tsec/tsec-device.cmp
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
86 Drivers
/opt/pikeos-D5.0/target/ppc/e500/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select TSEC Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
5.2.6.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: tsec_driver
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device
Driver Programming Reference Manual)
5.2.6.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 87
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware registers. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
5.2.6.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false, 32)
Warning: An Ethernet driver will fail to start if the MAC address(es) have been configured in auto-detection mode, but a MAC address has not been set in the hardware (for example by firmware). This may occur if the platform is booted from some other device (USB, Flash), in which case the firmware does not initialize the network controller. The problem can also occur on platforms with multiple network controllers. The firmware may only initialize the one used to boot.
5.2.6.4 Driver Specific Limitations
The tsec network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
88 Drivers
5.2.7 Ethernet DWC GMAC
PikeOS provides a multi-channel Ethernet driver which allows usage of the dwc_gmac Ethernet controller from different applications simultaneously. The dwc_gmac Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/dwc_gmac.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device
component and 4 virtual channel components, and overloading default configuration parameters when
needed:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/dwc_gmac.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/dwc_gmac/dwc_gmac-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/dwc_gmac/dwc_gmac-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select DWC_GMAC Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 89
5.2.7.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: dwc_gmac
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device Driver Programming Reference Manual)
5.2.7.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware registers. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
90 Drivers
5.2.7.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file
name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in
terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false,
32)
5.2.7.4 Driver Specific Limitations
The dwc_gmac network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
5.2.8 Ethernet virtio-net
PikeOS provides a multi-channel Ethernet driver which allows usage of the virtio-net virtual Ethernet controller from different applications simultaneously. The virtio-net Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 91
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/virtio-net.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device componenent and 4 virtual channel components, and overloading default configuration parameters when needed:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/virtio-net.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/virtio-net/virtio-net-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/virtio-net/virtio-net-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
Note: This component includes a BSP Settings option node, allowing to configure BSP specific param-
eters. On ARM architectures, the configuration must be done manually by specifying the memory region
and IRQ used by the device (consult the respective BSP documentation). On other architectures, virtual
PCI is used - BSP Settings allow specifying the PCI device for the device to attach to.
The Ethernet driver can be added using Add... button. Select Ethernet type and select VirtIO Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
5.2.8.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: virtio-net
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE diagnostics parameters (described in PikeOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device Driver Programming Reference Manual)
Note: The Maximum Transfer Size can be increased to support jumbo frames (view section 5.2.8.4).
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
92 Drivers
5.2.8.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
Read Timeout: Timeout mode for read requests. Can be: Non-blockig, User Value or Infinite. Default:
Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the
driver automatically retrieves the MAC address from qemu defaults. If the hardware value is still
00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
5.2.8.3 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file
name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in
terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false,
32)
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 93
5.2.8.4 Maximum Transfer Size Configuration
The value of Maximum Transfer Size supported by the driver is 1522. The driver doesn’t support fragmented frames.
5.2.8.5 Driver Specific Limitations
The virtio-net network driver has the following limitations:
• Only support one Ethernet device per driver module.
• Only available as External File Provider Driver.
• Dependency on PCI Manager on non-ARM boards.
5.2.9 Ethernet e1000
PikeOS provides a multi-channel Ethernet driver which allows usage of the Intel e1000 family Ethernet controller from different applications simultaneously. When available, the driver gives preference to use of MSI-X or MSI over legacy interrupt signaling, with automatic fallback. The e1000 Ethernet driver uses the PikeOS driver development environment with the Network Driver High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 11, page 488 for Network Driver High Level Module documentation
• section 10.5, page 486 for details about the network class driver configuration
• section 10.4, page 466 for description of the interface between driver and client
By default, the driver can be accessed through the following filenames:
• "eth0:dev0" for the physical device
• "eth0:0" for virtual channel 0
• "eth0:1" for virtual channel 1
• "eth0:2" for virtual channel 2
• "eth0:3" for virtual channel 3
The Ethernet driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/e1000.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component,the physical device
componenent and 4 virtual channel components, and overloading default configuration parameters when
needed:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
94 Drivers
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/e1000.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/e1000/e1000-fp_ext.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/ethernet/e1000/e1000-device.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select e1000 Ethernet User Level Driver. The driver provides a single device and 4 virtual channels which can be independently configured.
Note: In order to restore a previously deleted driver group. It is recommended to use Restore Child... function from the BSP group context menu rather then the Add... button. The items will be restored with the BSP configuration preserved.
Warning: Note that the use of the physical device and the use of the virtual channels are exclusive. When using virtual channels, the physical device shall not be used, and vice versa.
5.2.9.1 Driver Base Configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Driver Process:
Process Name: Default: e1000
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in PikeOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in PikeOS Device
Driver Programming Reference Manual)
Note: The Maximum Transfer Size can be increased to support jumbo frames (view section 5.2.9.5).
5.2.9.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• Generic Device Configuration:
Device Name: Device name used to identify the logical device in the configuration. Default:0.
File name: The file name used by client applications to access the logical device. Default: dev0
Access Mode: The access mode supported on the device. Can be: Read Only (RD_ONLY ), Write
Only (WR_ONLY ) or both (RD_WR). Default: RD_WR
Shared Device: If set to true, multiple concurrent opens on the device are supported. Default: false
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Ethernet Drivers 95
Read Timeout: Timeout mode for read requests. Can be: Non-blocking, User Value or Infinite.
Default: Infinite
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for read requests. Default: 1000000
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the PikeOS timeout
value (in nanosecond) for write requests. Default: 1000000
• Ethernet Device Configuration:
MBUF pool size: Number of mbufs in the pool. buffer. Default: 512
MAC Address: Channel MAC address. If set to 00:00:00:00:00:00, the high level layer of the driver
automatically retrieves the MAC address from the hardware EEPROM memory. If the hardware value
is still 00:00:00:00:00:00, the driver raises an error. Default: 00:00:00:00:00:00
Receive queue depth: Number of packets in the receive queue. Default: 64
Send queue depth: Number of packets in the send queue. Default: 64
Enable Multicast Communication: Enable Ethernet multicast communication for this device. Default:
false.
Multicast Table Size: Number of entries in multicast table. One entry in the table equals one multicast
MAC address. Default: 128
5.2.9.3 BSP Configuration / PCI Device Configuration
• PCI Device Location: Selects the PCI device location. For more information about the possible ways how to express the PCI device location please refer to PikeOS User Manual, section 10.7, page 244. Default: byclass/020000/0000 (First instance of Ethernet PCI Class).
• MSI Support: Enables or disables MSI interrupt support. Default: enabled.
• MSI-X Support: Enables or disables MSI-X interrupt support. Default: enabled.
5.2.9.4 Virtual Channel Configuration
The Virtual Channel (VC) configuration is a generic configuration repeating 3 steps of the device configuration:
• Virtual Channel: As for the Device configuration, this configuration group is used to configure properties file name and provided file name.
• Channel Configuration: Used for configuring the VC MAC Address, the Receive/Send queues depth in terms of packet number. Default: (00:00:00:00:00:00, 32, 32).
Warning: The VC MAC Address default value (00:00:00:00:00:00) is used by the high level layer of
the driver as a flag to automatically compute and provide the VC MAC Address, the value of the MAC
Address being accessible by ioctl.
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false, 32)
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
96 Drivers
5.2.9.5 Maximum Transfer Size Configuration
The Maximum Transfer Size can be increased to support jumbo frames. The Maximum Transmission Unit (MTU) is calculated using this value minus the Ethernet frame header and the VLAN encapsulation (18+4 bytes). The default value of Maximum Transfer Size is 1522 (1500+18+4) to support standard Ethernet frames but the driver can support an MTU of up to 8192.
Warning: The supported Maximum Transer Size depends on hardware and driver limitations. Some devices will support 8KB jumbo frames and others will be limited to 4KB or standard 1522 bytes. An health monitor event will be raised during driver initialization if the configured size is not supported for the device.
To support 8KB jumbo frames, the Maximum Transfer Size must be configured to 8192 and the Heap Memory Size must be set to 0x800000 (with the default number of 512 mbufs in the pool).
5.2.9.6 Driver Specific Limitations
The e1000 network driver has the following limitations:
• Only support one Ethernet device per driver module.
• Only available as External File Provider Driver.
• Dependency on PCI Manager
5.3 Watchdog Drivers
The drivers described in this chapter are available only on demand. Please contact sales@sysgo.com for further details.
5.3.1 Watchdog IMX WDT
PikeOS provides a Watchdog Timer (WDT) kernel level driver for use with i.MX SoCs (i.MX2 and later). The imx_wdt driver uses the driver development environment with the Watchdog Timer Class. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 18.5, page 725 for details about the WDT class driver configuration
• section 18.4, page 723 for description of the interface between driver and client.
The driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/object/kerneldriver/imx_wdt.kdev
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component and 1 watchdog
device component.
/opt/pikeos-D5.0/target/arm/v7hf/driver/wdt/imx_wdt_kdev.dom
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Block Device and MTD Drivers 97
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/wdt/imx_wdt/imx_wdt-fp_kdev.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/wdt/imx_wdt/imx_wdt-device_kdev.cmp
5.3.1.1 Driver Specific Limitations
The imx_wdt driver has the following limitations:
• The driver only supports one logical device per I/O device
• Configurable timeouts with a maximum period of 128s and time resolution of 0.5s
• The only pre-timeout reaction supported is maskable interrupts
• The only timeout reaction supported is reset
5.4 Block Device and MTD Drivers
Drivers for Block Devices or Memory Technology Devices (MTD).
5.4.1 Block Device and MTD Simulator blkdrvsim
PikeOS provides a driver for emulating BLK devices in RAM. It can be configured to emulate block devices, such as HDD or SDD, or Memory Technology Devices such as NOR and NAND. Arbitrary device size and block size can be configured for emulated block device. Arbitrary device size, size of erase block, page size and size of out-of-band area can be configured for emulated NOR and NAND devices. Driver also provides bad block API for these devices. ECC is not emulated. The blkdrvsim BLK driver uses the driver development environment with the BLK Driver High Level Module (see PikeOS Device Driver Programming Reference Manual, section 17, page 687). Please refer to the PikeOS Device Driver Programming Reference Manual, section 16.4, page 665 for description of the interface between driver and client. The blkdrvsim driver is provided in two variants - user level (external file provider), and kernel level.
5.4.1.1 Driver Specific Configuration Parameters
5.4.1.1.1 blkdrvsim Base Component
The driver can be executed in multiple instances. Each instance can provide BLK devices on configured Provider Prefix. This prefix is set by default to blk0 in a base component of driver. The base component file defines blkdrvsim BLK driver instance. In addition to the standard parameters defined for BLK drivers by the driver framework, the blkdrvsim BLK driver has additional configuration parameters.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
98 Drivers
Following parameters can be configured in the blkdrvsim_-base component. Default value is used if component instance does not override parameter value. Parameter Name Type Description Default Value PROVIDER string Device Prefix of provider blk0 MAX_FD_COUNT integer A count of the PikeOS file descriptors provided by 4 this driver. One descriptor is required for every client connected to some device or some partition. MAX_TRANSFER_- integer The maximum transfer size is the number of bytes 8192 SIZE that can be transferred in a single read or write operation.
5.4.1.1.2 blkdrvsim Device Component
Multiple emulated devices can be attached to user level blkdrvsim driver. For the kernel level driver only single device is supported and it can be configured in the base component.
Following parameters can be configured in blkdrvsim_ext-device and blkdrvsim_kdev-base components. Default value is used if component instance does not override parameter value. Property Pathname Property Type Description Default Value DEVICE_TYPE option Emulated Device Type (block, nand, nor) block TOTAL_SIZE integer Device Size in bytes; data area only 4194304 BLOCK_SIZE integer (block only) Block Size in bytes 512 ERASE_SIZE integer (nand and nor only) Erase Size in bytes 131072 PAGE_SIZE integer (nand and nor only) Page Size in bytes 512 OOB_SIZE integer (nand only) Out-of-Band Page Area Size in bytes 16 MAX_PAGES integer Maximum Pages Transfered in single operation 1 Following parameters can be configured in blkdrvsim_ext-device component only. Default value is used if component instance does not override parameter value. The PikeOS path for device will have the form PROVIDER:FILE_NAME, for example a blk0:0. Each BLK device can be opened by single client only. FILE_NAME string The file name used by client applications to ac- 0 cess the logical device. MEM_SOURCE option Source of device memory (shm or pool) pool SHM_SIZE integer Size of SHM requirement in bytes; it has to be 4329472 aligned to page size and it shall include the OOB area if configured and 4 bytes for each erase block KEEP_SHM boolean Do not clean SHM content on start; can be used false for pre-loading SHM with filesystem data Following parameters can be configured in the blkdrvsim_kdev-base component only. Default value is used if component instance does not override parameter value. The PikeOS path for device will have the form PROVIDER:DEV0_FILE_NAME, for example a blk0:0. Each device can be opened up to the MAX_CLIENT_COUNT clients. DEV0_FILE_NAME string The file name used by client applications to ac- 0 cess the logical device. MAX_CLIENT_COUNT integer Maximum number of concurrently connected 1 clients to device.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Block Device and MTD Drivers 99
5.4.1.2 Driver Specific Limitations
The blkdrvsim BLK driver has the following limitations:
• User level driver does not support multiple connected clients on single device due to the limitation in the BLK High Level Module.
• Kernel level driver component does not support defining multiple devices within single instance. Multiple instances with different Provider Prefix can be used instead.
5.4.1.3 Usage of the User Level Driver
This paragraph explains integration of the user level variant of the blkdrvsim driver. The user level driver runs are regular PikeOS process with the adjustable process priority and CPU affinity. These can be adjusted in the VMIT. Number of executed driver threads depends on the settings of the THREAD_MODEL property.
5.4.1.3.1 Integration Project for the User Level Driver
The user level driver configuration must be added to the integration project. The user level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/blkdrvsim.elf
and the corresponding configuration files are
/opt/pikeos-D5.0/target/arm/v7hf/driver/blk/blkdrvsim/blkdrvsim_ext-base.cmp /opt/pikeos-D5.0/target/arm/v7hf/driver/blk/blkdrvsim/blkdrvsim_ext-device.cmp
Using CODEO:
• Open the integration project in the project editor (open the project.xml file).
• Select any Group component and click the Add... button.
• Browse to PIKEOS_POOL->driver->blk->blkdrvsim->blkdrvsim_ext-base. Click OK, Finish.
• Browse to PIKEOS_POOL->driver->blk->blkdrvsim->blkdrvsim_ext-device. Click OK, Finish. Repeat multi- ple times for multiple devices.
• Assign PROVIDER dependency of created devices to the associated base component of driver.
• Configure parameters of created components.
A pre-configured integration snippet demonstration can be found in
/opt/pikeos-D5.0/target/arm/v7hf/driver/blk/blkdrvsim_ext-demo.dom
The dom file adds the driver to the service partition, instantiates the blkdrvsim driver with prefix blk0 and adds BLK device blk0:0. In CODEO, the blkdrvsim driver can be added to an integration project using the Add... button. Browse to PIKEOS_POOL->driver->blk and select blkdrvsim Block User Level Driver.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
100 Drivers
5.4.1.4 Usage of the Kernel Level Driver
This paragraph explains integration of the kernel level variant of the blkdrvsim driver. It runs in the kernel space at the same priority and the task switching time is the shortest of all other driver variants. The use the kernel level version of the blkdrvsim driver, the following steps are needed:
• Using a kernel fusion project, create a new kernel linked with the driver.
• Configure the integration project to use this new kernel.
• Add the driver configuration to the integration project.
5.4.1.4.1 Fusion Project for the Kernel Level Driver
The kernel level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/object/kerneldriver/blkdrvsim.kdev
and the corresponding configuration file is
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/kerneldriver.cmp
To add the driver to a kernel fusion project using CODEO:
• Create a new PikeOS project, of type Kernel Fusion. From the list of demo projects, select the kernel
corresponding to the board used in the integration project.
• Set the custom pool. The kernel fusion project should use the same pool as the integration project.
• Select a Group element and click the Add... button.
• Browse to PIKEOS_POOL->fusion-kernel->kerneldriver. Click OK, Finish. Save the project.
• Execute the all and install Make targets.
The new kernel is now installed under the object/bsp directory in the custom pool.
5.4.1.4.2 Integration Project for the Kernel Level Driver
The new kernel created in the fusion project and the kernel driver configuration must be added to the integration project. The kernel driver configuration is provided by the file
/opt/pikeos-D5.0/target/arm/v7hf/driver/blk/blkdrvsim/blkdrvsim_kdev-base.cmp
Using CODEO:
• Open the integration project in the project editor (open the project.xml file).
• Set the custom pool. The integration project should use the same pool as the kernel fusion project.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Block Device and MTD Drivers 101
• Select the PikeOS Kernel element inside the board component.
• In the parameter section labelled Kernel Binary, set the Kernel Directory parameter to Custom Pool.
• Select the board component and click the Add... button.
• Browse to PIKEOS_POOL->driver->blk->blkdrvsim->blkdrvsim_kdev-base. Click OK, Finish.
• Configure parameters of created components.
5.4.1.5 Demonstration Projects
Following demo project can be used for the querying (and testing) of the simulated devices:
/opt/pikeos-D5.0/demo/pikeos-native/blk-client/
These demonstration projects are using the blkdrvsim driver:
/opt/pikeos-D5.0/integration/blk-sim/project.xml /opt/pikeos-D5.0/integration/volume-provider-pikeos-native/project.xml /opt/pikeos-D5.0/integration/volume-provider-posix/project.xml /opt/pikeos-D5.0/integration/volume-provider-apex/project.xml /opt/pikeos-D5.0/integration/volume-provider-cfs-apex/project.xml /opt/pikeos-D5.0/integration/volume-provider-cfs-pikeos-native/project.xml /opt/pikeos-D5.0/integration/volume-provider-cfs-posix/project.xml /opt/pikeos-D5.0/integration/libhttpd-posix/project.xml /opt/pikeos-D5.0/integration/libmicrohttpd-posix/project.xml
5.4.1.6 Driver Source Code
A full source code of this driver is available in the DDK demos:
/opt/pikeos-D5.0/demo/ddk-user-level/hlblk-driver/ /opt/pikeos-D5.0/demo/ddk-kerneldriver/hlblk-driver/
5.4.2 Block uSDHC Driver
Note: The driver described in this chapter is available only on demand. Please contact sales@sysgo.com for further details. PikeOS provides an access to SD or MicroSD cards connected to an SD Host controler via the USDHC driver. The driver supports controllers based on the “SD Host Controller Specification” from the SD Association. However, not all host controllers implement this interface correctly, so compatiblity can be guaranteed only with the tested controllers. To support the different controllers, the driver comes in multiple variants, each for one controller family. The configuration files for the driver also come in these variants, each variant is in a directory named usdhc-ctrl, where ctrl is the controller variant name. The table below lists the tested SoCs and what driver version to use with them and a DOM file with example configuration for a concrete board.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
102 Drivers
SoC Name Driver variant DOM
Zynq Ultrascale xsdps usdhc_ext-xsdps-blk0.dom
Zynq 7000 xsdps usdhc_ext-xsdps-blk0.dom
T1040 fsl usdhc_ext-fsl-blk0.dom
iMX.6 imx usdhc_ext-imx-blk0.dom
The USDHC driver uses the driver development environment with the BLK Driver High Level Module (see PikeOS Device Driver Programming Reference Manual, section 17, page 687). Please refer to the PikeOS Device Driver Programming Reference Manual, section 16.4, page 665 for description of the interface between driver and client. The USDHC driver is provided as user level driver (external file provider).
5.4.2.1 Driver Specific Configuration Parameters
5.4.2.1.1 SDHC Base Component
The driver can be executed in multiple instances. Each instance serves one or more SDHC controllers and provides BLK devices on configured prefix. This prefix is set to default value blk0 in the driver component. The base component file defines SDHC BLK driver instance. The base component file is named usdhc-ctrl-ext-base, where ctrl must be replaced by the driver variant, as defined in the table above. In addition to the standard parameters defined for BLK drivers by the driver framework, the SDHC BLK driver has additional configuration parameters.
These parameters can be configured in the usdhc-ctrl-ext-base component. Default value is used if compo- nent instance does not override parameter value. Parameter Name Type Description Default Value PROVIDER string Device Prefix of provider blk0 MAX_FD_COUNT integer A count of the PikeOS file descriptors provided by 4 this driver. One descriptor is required for every client connected to some device or some partition. MAX_FILE_COUNT integer A count of device partitions that can be loaded. 2 MAX_TRANS- integer The maximum transfer size is the number of bytes 8192 FER_SIZE that can be transferred in a single read or write operation. DIAG_VERBOSITY quiet, normal, The verbosity level determines which diagnostic normal verbose message will be displayed. DIAG_CONFIG boolean Display diagnostic messages for configuration and false initialization phase. In the verbose mode it also re- ports SD card information registers and supported options. DIAG_IO boolean Display run-time reporting of the I/O. false DIAG_TRACE boolean Display IO communication. In the verbose mode false it also reports DMA transfers and issued com- mands.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Block Device and MTD Drivers 103
5.4.2.1.2 USDHC Device Component
Multiple controllers can be driven by a single driver instance. This is common if your SoC has multiple SD card slots – each slot has its own controller. DOM files for boards with multiple slots (like i.MX6) come pre-configured with multiple controllers.
These parameters can be configured in the usdhc_ext-device component. Default value is used if component instance does not override parameter value. Property Pathname Property Type Description Default Value OPERATION_MODE Buffered or Di- Access mode from SDHC controller and driver to Buffered rect user I/O buffers. More info bellow. IO_BLOCK_SIZE integer Size of request I/O buffer used for Buffered oper- 4096 ation mode. It limits the maximum size of trans- action. The amount of allocated memory will de- pend on the number of configured concurrently ex- ecuted requests; one buffer is needed for each re- quest. FILE_NAME string The file name used by client applications to ac- 0 cess the logical device. PTABLE_TYPE none or DOS This option selects a partition table type on the none device. If the table type is specified, the driver tries to load partition table before the BLK devices for partitions are configured. ENABLE_DMA boolean Enable DMA transfers (required for Direct mode). true The controller must support ADMA2 and must be able to use 64-bit addresses on 64-bit platforms. Disabling DMA means that the driver will work in PIO mode. BOARD_1V8 boolean Inform the driver that the board has working 1.8V false voltage converter (most boards do not). This is prerequisite for using UHS-I speeds. However, this feature is experimental.
The PikeOS path of configured BLK device for SDHC device will have the form PROVIDER:FILE_NAME, for example a blk0:0 for a device on SDHC controller 0. Each BLK device can be opened by single client only.
5.4.2.1.3 Operation Mode
• Buffered: The driver uses an internal buffer for the DMA transfers. This mode causes an overhead for copying data from/to the user buffers.
• Direct: The driver uses the buffer provided by the user for DMA transfers. It has to be aligned to P4_ARCH_ALIGN otherwise operation fails with P4_E_ALIGN error.
5.4.2.1.4 BLK Devices for disk drive partitions
The SDHC driver can provide access to disk drive partitions defined in the DOS Partition Table via translation from a BLK Device of partition to its area on the disk device.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
104 Drivers
The Partition Table loading can be enabled on device via PTABLE_TYPE. If the Partition Table type is specified, the driver tries to load it before the BLK devices for partitions are configured. The PikeOS path of configured BLK device for partition on SDHC device will have the form PROVIDER:FILE_NAME:PARTITION, for example the a blk0:2:1 for the first partition on a device on SDHC con- troller 2. The partition number will match the index in the DOS Partition Table, so the first partition will have number 1 and the last one will have number 4. Logical partitions will be assigned numbers 5 to 8. This means that only 7 actual partitions can be used at a time. If a configured partition is not found in the partition table, the partition is ignored and can not be opened. Each BLK device of partition can be opened by multiple clients only if this behavior is enabled by the SHARED_DEVICE configuration parameter. Concurrent read/write access to partitions and underlying device is allowed, however the result of operation will depend on execution order of these operations. Notice: A partition table for a device can be created using mkblkimage tool, see 5.4.3.
5.4.2.1.5 SDHC Device Partition Component
This component allows defining BLK device for SD partitions.
These parameters can be configured in the usdhc_ext-device-partition component. Default value is used if component instance does not override parameter value. Property Pathname Property Type Description Default Value PARTITION integer Partition Number (1-8) 1 SHARED_DEVICE boolean Allow concurrent access by multiple client. false MAX_CLIENT_COUNT integer Maximum number of concurrent clients, if 2 SHARED_DEVICE is enabled. ACCESS RD_WR, RD or Allowed operations on the partition. RD_WR WR
5.4.3 Partitioned Image Creation Tool mkblkimage
mkblkimage is a tool that helps with preparation of a partitioned disk drive or a partitioned disk image file for usage with PikeOS BLK drivers. It can generates partition table data and shell script for initializing a disk drive or a file image. The layout of the disk drive image is defined in the configuration file by number of partitions, partition indexes, partition sizes, partition type and optionally with partition content data file. The partition sizes are specified in the units of sector size and they can be aligned to the larger physical sector boundaries via the size align parameter. The mkblkimage tool generates DOS partition table data by following rules:
• Partitions will be created and allocated in the following order: (1) 1st primary, (2) 2nd primary, (3) 3rd
primary, (4) 4th primary, (5) 1st logical, (6) 2nd logical, (7) 3rd logical, (8) 4th logical.
• The partition entry will be stored into the partition table on the index specified in the parenthesis above. For
example, the 2nd logical partition will have index 6.
• A partition will be not be generated if it has zero size.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Block Device and MTD Drivers 105
• The first partition with non-zero size will start on the first aligned sector after the partition table.
• Further processed partitions with non-zero size will start on the aligned sector right after the end of the
previous partition.
• If logical partitions are created then 4th primary partition must not be used and it should have set size to 0.
On execution without arguments the mkblkimage tool prints brief help:
$ /opt/pikeos-D5.0/bin/mkblkimage --help Usage: mkblkimage CONFIG_FILE OUTPUT_PREFIX A new configuration file will be created if CONFIG_FILE is not existing file. Check the Platform Manual,chapter Partitioned Image Creation Tool mkblkimage for a detailed documentation.
An empty configuration file will be generated if the file specified as the first argument does not exist:
$ /opt/pikeos-D5.0/bin/mkblkimage test.conf Notice: new configuration file test.conf has been created $ cat test.conf #MKBLKIMAGE_CONFIG_BEGIN#
Notice:
This file is interpreted by bash,you can use arithmetic evaluation.
Example: SIZE_PART1_SEC=$(((64<<20)/$SIZE_SEC)) will be evaluated as 64MiB.
type of partition table
TYPE=dos
size of one sector in bytes
SIZE_SEC=512
partition alignment size in bytes
SIZE_ALIGN=4096
1st primary partition
size of partition in sectors
SIZE_PART1_SEC=0
partition type (use ćf́or FAT,otherwise keep empty)
TYPE_PART1=
path to partition image file; used for image initialization via script
IMAGE_PART1=
2nd primary partition
SIZE_PART2_SEC=0 TYPE_PART2= IMAGE_PART2=
3rd primary partition
SIZE_PART3_SEC=0 TYPE_PART3= IMAGE_PART3=
4th primary partition
size of 4th partition in sectors (set to 0 if using logical partitions)
SIZE_PART4_SEC=0 TYPE_PART4= IMAGE_PART4=
1st logical partition
SIZE_LOGPART1_SEC=0 TYPE_LOGPART1= IMAGE_LOGPART1=
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
106 Drivers
2nd logical partition
SIZE_LOGPART2_SEC=0 TYPE_LOGPART2= IMAGE_LOGPART2=
3rd logical partition
SIZE_LOGPART3_SEC=0 TYPE_LOGPART3= IMAGE_LOGPART3=
4th logical partition
SIZE_LOGPART4_SEC=0 TYPE_LOGPART4= IMAGE_LOGPART4= #MKBLKIMAGE_CONFIG_END#
Executing the mkblkimage tool with valid configuration file results in generation of partition table data, script and information file:
$ /opt/pikeos-D5.0/bin/mkblkimage
/opt/pikeos-D5.0/share/mkblkimage/blkdemoimage_fat.conf demoimage
Completed. Output is stored into demoimage_ptable* files.
$ ls
demoimage_ptable_0x00000000.bin demoimage_ptable.create.sh demoimage_ptable.info
The ptable.create.sh script can be used for generating partitioned disk image or device:
$ ./demoimage_ptable.create.sh demo.image $ /sbin/fdisk demo.image Command (m for help): p Disk demo.image: 64 MiB, 67112960 bytes, 131080 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type demo.image1 8 65543 65536 32M c W95 FAT32 (LBA) demo.image2 65544 131079 65536 32M c W95 FAT32 (LBA)
5.5 PCI Controller Drivers
The drivers described in this chapter are available only on demand. Please contact sales@sysgo.com for further details.
5.5.1 PSP PCI
The PSP PCI is a PSP level driver providing the low level functionality for the PCI and MSI drivers. This driver provides functions like reading and writing PCI configuration or device enumeration that is common for all PCI drivers. If there is a PCI Manager driver provided for the board this driver is an integral part of the PSP and is always present, even if the PCI manager is not actually compiled in.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PCI Controller Drivers 107
5.5.2 PCI Layerscape
The Layerscape PCI driver provides a PSP level driver to support Layerscape and compatible SoC PCI implemen- tation (such as LS1021A, LS1043A, LS1046A, i.MX6), enabling the use of the PCI manager.
Note: This section describes the Layerscape PCI driver configuration, for more information on the PCI man- ager usage, please refer to the PikeOS User Manual, section 10.7, page 244.
For PSPs which are built with this driver, the configuration is made available as an option through the PSP com- ponent, either as PCI for PSPs supporting only this driver, or PCI Layerscape Driver for PSPs supporting multiple PCI drivers.
5.5.2.1 General configuration
Table 13 below summarizes the general parameters available for the SoC and the corresponding property;
Parameter Corresponding property LUT offset lut-addr LUT debug offset lut-dbg LUT LTSSM state shift lut-ltssm LUT endianness lut-big-endian
Table 13: PCI general configuration
5.5.2.2 Component configuration
Table 14 summarizes the parameters available for each controller and the corresponding property; see section 5.5.2.3, page 107 for more details on the corresponding properties and their effect on the driver’s behavior.
Parameter Corresponding property Enable PCI controller None. If true, this will embed the configuration for this controller, making the driver aware of this controller. PCI controller address ctrl-addr PCI INTx IRQ number int(a|b|c|d)
Table 14: PCI component configuration
5.5.2.3 Properties
The parameters described above are embedded in the property file system and are used to dynamically determine which controller the driver will initialize. They are scattered under various directories located in prop:board/pci/, and split into numbered directories for each controller: for example, ”prop:board/pci/io/1/” contains the IO zones used for PCI controller 1. Table 15 summarizes the usage of the properties for the driver, with ’X’ in the path denoting the controller number (all paths described are relative to ”prop:board/pci/” ):
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
108 Drivers
Property path Usage
io/X/ctrl-addr Physical address of the PCI controller, as addressed by the CPU.
int/X/int(a|b|c|d) Legacy INTx interrupt identifier on the interrupt controller.
Table 15: PCI driver properties
Example of properties used to initialize a single controller:
<prop_dir name="board"> <prop_dir name="pci"> <prop_dir name="io"> <prop_dir name="1"> <prop_addr data="0x1ffc000" name="ctrl-addr"/> </prop_dir> </prop_dir> <prop_dir name="int"> <prop_dir name="1"> <prop_interrupt data="155" name="inta"/> <prop_interrupt data="154" name="intb"/> <prop_interrupt data="153" name="intc"/> <prop_interrupt data="152" name="intd"/> </prop_dir> </prop_dir> </prop_dir> </prop_dir>
5.5.3 MSI Layerscape
MSI and MSI-X support is provided for the LS1021A, LS1043A and LS1046A SoCs, with support for up to 64 different interrupts (32 MSI + 32 MSI-X). The number of MSI interrupts per PCI device/function is limited to single MSI interrupt due to the limitations of the SoC hardware. In general if the hardware supports MSI-X it should be used. The MSI does not support the interrupt masking which is not acceptable for safety critical applications (some hardware may support optional MSI masking extension, but it seems this is rare case). There are also MSI/MSI-X IRQ CPU affinity limitations. For more details about MSI interrupt CPU affinity please refer to section 5.5.3.3, page 109.
Note: This section describes the configuration for the Layerscape MSI PSP driver. For more information on requesting and using MSI interrupts in device drivers, please refer to the PikeOS Device Driver Programming Reference Manual, section 19.5.8, page 768
5.5.3.1 Component configuration
MSI configuration is available under the PCI Layerscape Driver option of the PSP component. The table below summarizes the link between those parameters and the properties which are embedded in the final image. Please refer to section 5.5.3.2, page 109 for their actual effect on the MSI driver. See table 16 for details.
Parameter Corresponding property
Enable MSI support msi_enable
MSI group MSIIR address msiir
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
PCI Controller Drivers 109
Parameter Corresponding property
MSI group interrupt number int
Table 16: MSI component configuration
5.5.3.2 Properties
The parameters described above are embedded in the property file system. Table 17 below shows the path (relative to prop:board/pci/ ) of each property and its use.
Property path Usage
msi_enable If true, MSI will be initialized and available for us-
age, otherwise MSI will not be available for device
drivers.
io/msi/X/msiir Physical address of the MSIIR register, to be used
by devices to trigger MSI interrupts. No translation
is done on this register, thus it is expected that in-
bound PCI transactions are not translated and de-
vices can access the MSIIR at this address.
int/msi/X/int Interrupt identifier on the interrupt controller for MSI
group X interrupts. This is the actual interrupt which
will be triggered when a device writes to MSIR reg-
ister.
Table 17: MSI Property Path
Here is an example of a full configuration for 1 group of MSI interrupts:
<prop_dir name="board"> <prop_dir name="pci"> <prop_bool data="true" name="msi_enable"/> <prop_dir name="io/msi/0"> <prop_addr data="0x1570e00" name="msiir"/> </prop_dir> <prop_dir name="int/msi/0"> <prop_interrupt data="211" name="int"/> </prop_dir> </prop_dir> </prop_dir>
5.5.3.3 Affinity support
In general, the current CPU on which the userspace thread waits for an MSI interrupt is also the CPU on which the low level servicing routine runs. Due to the SoC hardware restrictions the low level handler might run on a different CPU if following conditions are not met. The numbers presented in the next paragraph account for 1 MSI per PCI device/function and any number of currently used MSI-X interrupts per PCI device/function. If for example an AHCI device uses 1 MSI and 2 MSI-X are used with an Ethernet Card, there are 3 MSI used in total in the system (1/32 of MSI and 2/32 of MSI-X being used). As noted, the IRQ CPU affinity is selected based on the
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
110 Drivers
information on which CPU the thread currently waits for an interrupt. The presented numbers are the worst case scenarios. It is assumed that threads do not migrate from its CPU after they were blocked waiting on interrupt. The LS1021A is a dual CPU SoC and supports up to 64 MSI/MSI-X routed to a single CPU and up to a total of 32 MSI/MSI-X routed to any CPU. LS1043A and LS1046A are a quad CPU SoC and the MSI/MSI-X interrupts may be routed to at most 3 different CPUs. For any 3 or 2 CPUs, the total number of MSI/MSI-X is also 32. For a single CPU there can be up to 64 MSI/MSI-X. If CPU affinity is not an issue, LS1021A/LS1043A/LS1046A can handle up to 64 MSI/MSI-X (maximum of 32 MSI and maximum of 32 MSI-X).
5.6 Clock Manager Drivers
The drivers described in this chapter are available only on demand. Please contact sales@sysgo.com for further details. The Clock Manager is a kernel level driver responsible for managing the platform’s clock tree. It assigns clocks to drivers and implements the requested operations on the clock hardware. This driver uses the PikeOS driver development environment with the Clock Manager High Level Module. Please refer to the PikeOS Device Driver Programming Reference Manual, section 21.4, page 807 for Clock Manager High Level Module documentation, section 21.3, page 801 for File API documentation and section 21.2, page 791 for CLK services.
5.6.1 i.MX6 Clock Manager
5.6.1.1 Clock types
The clock tree is composed by nodes, and each node as a special type, depending on its function. Table 18 summarizes the different clock types for i.MX6 Clock Manager:
Clock Type Properties
IMX_CLOCK_FIXED_CLOCK Quartz Oscillator clock
IMX_CLOCK_PLL PLL Reference clock
IMX_CLOCK_PFD Phase Fractional Divider clock
IMX_CLOCK_FIXED_FACTOR Multiplier clock
IMX_CLOCK_MUX Multiplexer clock
IMX_CLOCK_DIV Divider clock
IMX_CLOCK_GATE Gate to enable or disable clock
Table 18: i.MX6 Clock Manager clock types
5.6.1.2 List of clocks
Table 19 summarizes all the clocks in the i.MX6 clock tree:
Clock Name Type Comments osc_clk IMX_CLOCK_FIXED_CLOCK Read from property psp/clock/pll_ref
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Clock Manager Drivers 111
Clock Name Type Comments pll1_main_clk IMX_CLOCK_PLL pll2_bus IMX_CLOCK_PLL pll3_usb1 IMX_CLOCK_PLL pll4_audio IMX_CLOCK_PLL pll5_video IMX_CLOCK_PLL pll6_enet IMX_CLOCK_PLL pll7_usb2 IMX_CLOCK_PLL pfd0_352mhz_clk IMX_CLOCK_PFD pfd1_594mhz_clk IMX_CLOCK_PFD pfd2_396mhz_clk IMX_CLOCK_PFD pfd0_720mhz_clk IMX_CLOCK_PFD pfd1_540mhz_clk IMX_CLOCK_PFD pfd2_508mhz_clk IMX_CLOCK_PFD pfd3_454mhz_clk IMX_CLOCK_PFD sata_ref IMX_CLOCK_FIXED_FACTOR pcie_ref IMX_CLOCK_FIXED_FACTOR pll2_198m IMX_CLOCK_FIXED_FACTOR pll3_120m IMX_CLOCK_FIXED_FACTOR pll3_80m IMX_CLOCK_FIXED_FACTOR pll3_60m IMX_CLOCK_FIXED_FACTOR twd IMX_CLOCK_FIXED_FACTOR gpt_3m IMX_CLOCK_FIXED_FACTOR video_27m IMX_CLOCK_FIXED_FACTOR ldb_di0_div_3_5 IMX_CLOCK_FIXED_FACTOR ldb_di0_div_7 IMX_CLOCK_FIXED_FACTOR ldb_di1_div_3_5 IMX_CLOCK_FIXED_FACTOR ldb_di1_div_7 IMX_CLOCK_FIXED_FACTOR asrc_ipg IMX_CLOCK_FIXED_FACTOR asrc_mem IMX_CLOCK_FIXED_FACTOR pll1_sw_clk_mux IMX_CLOCK_MUX pll2_sw_clk_mux IMX_CLOCK_MUX step_clk_mux IMX_CLOCK_MUX periph2_clk_mux IMX_CLOCK_MUX periph_clk_mux IMX_CLOCK_MUX axi_alt_mux IMX_CLOCK_MUX axi_mux IMX_CLOCK_MUX pre_periph2_clk_mux IMX_CLOCK_MUX periph2_clk2_mux IMX_CLOCK_MUX pre_periph_clk_mux IMX_CLOCK_MUX gpu2d_core_clk_mux IMX_CLOCK_MUX vpu_axi_clk_mux IMX_CLOCK_MUX periph_clk2_mux IMX_CLOCK_MUX vdoaxi_clk_mux IMX_CLOCK_MUX pcie_axi_clk_mux IMX_CLOCK_MUX gpu3d_shader_clk_mux IMX_CLOCK_MUX
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
112 Drivers
Clock Name Type Comments gpu3d_core_clk_mux IMX_CLOCK_MUX gpu3d_axi_clk_mux IMX_CLOCK_MUX gpu2d_axi_clk_mux IMX_CLOCK_MUX aclk_eim_slow_mux IMX_CLOCK_MUX aclk_mux IMX_CLOCK_MUX usdhc4_clk_mux IMX_CLOCK_MUX usdhc3_clk_mux IMX_CLOCK_MUX usdhc2_clk_mux IMX_CLOCK_MUX usdhc1_clk_mux IMX_CLOCK_MUX ssi3_clk_mux IMX_CLOCK_MUX ssi2_clk_mux IMX_CLOCK_MUX ssi1_clk_mux IMX_CLOCK_MUX esai_clk_mux IMX_CLOCK_MUX ldb_di1_div_mux IMX_CLOCK_MUX ldb_di0_div_mux IMX_CLOCK_MUX enfc_clk_mux IMX_CLOCK_MUX ldb_di1_clk_mux IMX_CLOCK_MUX ldb_di0_clk_mux IMX_CLOCK_MUX hsi_tx_clk_mux IMX_CLOCK_MUX spdif0_clk_mux IMX_CLOCK_MUX spdif1_clk_mux IMX_CLOCK_MUX ipu1_di1_pre_clk_mux IMX_CLOCK_MUX ipu1_di1_clk_mux IMX_CLOCK_MUX ipu1_di0_pre_clk_mux IMX_CLOCK_MUX ipu1_di0_clk_mux IMX_CLOCK_MUX ipu2_di1_pre_clk_mux IMX_CLOCK_MUX ipu2_di1_clk_mux IMX_CLOCK_MUX ipu2_di0_pre_clk_mux IMX_CLOCK_MUX ipu2_di0_clk_mux IMX_CLOCK_MUX ipu2_hsp_clk_mux IMX_CLOCK_MUX ipu1_hsp_clk_mux IMX_CLOCK_MUX cko1_clk_mux IMX_CLOCK_MUX cko2_clk_mux IMX_CLOCK_MUX cko_clk_mux IMX_CLOCK_MUX arm_podf IMX_CLOCK_DIV mmdc_ch1_axi_podf IMX_CLOCK_DIV mmdc_ch0_axi_podf IMX_CLOCK_DIV ahb_podf IMX_CLOCK_DIV ipg_podf IMX_CLOCK_DIV usdhc1_podf IMX_CLOCK_DIV usdhc2_podf IMX_CLOCK_DIV usdhc3_podf IMX_CLOCK_DIV usdhc4_podf IMX_CLOCK_DIV perclk_podf IMX_CLOCK_DIV ipu1_hsp_podf IMX_CLOCK_DIV
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Clock Manager Drivers 113
Clock Name Type Comments axi_podf IMX_CLOCK_DIV ssi1_clk_podf IMX_CLOCK_DIV ssi2_clk_podf IMX_CLOCK_DIV ssi3_clk_podf IMX_CLOCK_DIV ipu2_hsp_podf IMX_CLOCK_DIV gpu2d_core_clk_podf IMX_CLOCK_DIV aclk_podf IMX_CLOCK_DIV aclk_eim_slow_podf IMX_CLOCK_DIV enfc_clk_podf IMX_CLOCK_DIV gpu3d_core_podf IMX_CLOCK_DIV gpu3d_shader_podf IMX_CLOCK_DIV vpu_axi_podf IMX_CLOCK_DIV ipu1_di0_podf IMX_CLOCK_DIV ipu1_di1_podf IMX_CLOCK_DIV ipu2_di0_podf IMX_CLOCK_DIV ipu2_di1_podf IMX_CLOCK_DIV hsi_tx_podf IMX_CLOCK_DIV spdif0_clk_podf IMX_CLOCK_DIV spdif1_clk_podf IMX_CLOCK_DIV esai_clk_podf IMX_CLOCK_DIV ecspi_clk_podf IMX_CLOCK_DIV can_clk_podf IMX_CLOCK_DIV uart_clk_podf IMX_CLOCK_DIV periph2_clk2_podf IMX_CLOCK_DIV periph_clk2_podf IMX_CLOCK_DIV cko1_podf IMX_CLOCK_DIV cko2_podf IMX_CLOCK_DIV enfc_clk_pred IMX_CLOCK_DIV esai_clk_pred IMX_CLOCK_DIV spdif0_clk_pred IMX_CLOCK_DIV spdif1_clk_pred IMX_CLOCK_DIV ssi1_clk_pred IMX_CLOCK_DIV ssi2_clk_pred IMX_CLOCK_DIV ssi3_clk_pred IMX_CLOCK_DIV pll4_audio_post_div IMX_CLOCK_DIV pll4_audio_div IMX_CLOCK_DIV pll5_video_post_div IMX_CLOCK_DIV pll5_video_div IMX_CLOCK_DIV pll6_enet_div IMX_CLOCK_DIV cko1_clk_gate IMX_CLOCK_GATE cko2_clk_gate IMX_CLOCK_GATE dtcp_clk_gate IMX_CLOCK_GATE dcic2_clk_gate IMX_CLOCK_GATE dcic1_clk_gate IMX_CLOCK_GATE arm_dbg_clk_gate IMX_CLOCK_GATE
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
114 Drivers
Clock Name Type Comments can2_serial_clk_gate IMX_CLOCK_GATE can2_clk_gate IMX_CLOCK_GATE can1_serial_clk_gate IMX_CLOCK_GATE can1_clk_gate IMX_CLOCK_GATE caam_wraper_ipg_gate IMX_CLOCK_GATE caam_wraper_aclk_gate IMX_CLOCK_GATE caam_secure_mem_clk_gate IMX_CLOCK_GATE asrc_clk_gate IMX_CLOCK_GATE apbhdma_clk_gate IMX_CLOCK_GATE aips_tz2_clk_gate IMX_CLOCK_GATE aips_tz1_clk_gate IMX_CLOCK_GATE gpu3d_clk_gate IMX_CLOCK_GATE gpu2d_clk_gate IMX_CLOCK_GATE gpt_serial_clk_gate IMX_CLOCK_GATE gpt_clk_gate IMX_CLOCK_GATE esai_clk_gate IMX_CLOCK_GATE epit2_clk_gate IMX_CLOCK_GATE epit1_clk_gate IMX_CLOCK_GATE enet_clk_gate IMX_CLOCK_GATE ecspi5_clk_gate IMX_CLOCK_GATE ecspi4_clk_gate IMX_CLOCK_GATE ecspi3_clk_gate IMX_CLOCK_GATE ecspi2_clk_gate IMX_CLOCK_GATE ecspi1_clk_gate IMX_CLOCK_GATE ipsync_vdoa_ipg_master_clk_gate IMX_CLOCK_GATE ipsync_ip2apb_tzasc2_clk_gate IMX_CLOCK_GATE ipsync_ip2apb_tzasc1_clk_gate IMX_CLOCK_GATE ipmux3_clk_gate IMX_CLOCK_GATE ipmux2_clk_gate IMX_CLOCK_GATE ipmux1_clk_gate IMX_CLOCK_GATE iomux_ipt_clk_io_gate IMX_CLOCK_GATE iim_clk_gate IMX_CLOCK_GATE i2c3_clk_gate IMX_CLOCK_GATE i2c2_clk_gate IMX_CLOCK_GATE i2c1_clk_gate IMX_CLOCK_GATE hdmi_tx_isfrclk_gate IMX_CLOCK_GATE hdmi_tx_gate IMX_CLOCK_GATE openvgaxiclk_clk_root_gate IMX_CLOCK_GATE ocram_clk_gate IMX_CLOCK_GATE mmdc_core_ipg_clk_p0_gate IMX_CLOCK_GATE mmdc_core_aclk_p0_gate IMX_CLOCK_GATE mlb_clk_gate IMX_CLOCK_GATE mipi_core_cfg_clk_gate IMX_CLOCK_GATE ldb_di1_clk_gate IMX_CLOCK_GATE ldb_di0_clk_gate IMX_CLOCK_GATE
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Clock Manager Drivers 115
Clock Name Type Comments ipu2_ipu_di1_clk_gate IMX_CLOCK_GATE ipu2_ipu_di0_clk_gate IMX_CLOCK_GATE ipu2_ipu_clk_gate IMX_CLOCK_GATE ipu1_ipu_di1_clk_gate IMX_CLOCK_GATE ipu1_ipu_di0_clk_gate IMX_CLOCK_GATE ipu1_ipu_clk_gate IMX_CLOCK_GATE gpmi_input_apb_clk_gate IMX_CLOCK_GATE bch_input_gpmi_io_clk_gate IMX_CLOCK_GATE bch_input_bch_clk_gate IMX_CLOCK_GATE input_apb_clk_gate IMX_CLOCK_GATE pwm4_clk_gate IMX_CLOCK_GATE pwm3_clk_gate IMX_CLOCK_GATE pwm2_clk_gate IMX_CLOCK_GATE pwm1_clk_gate IMX_CLOCK_GATE pl301_mx6qper2_mainclk_gate IMX_CLOCK_GATE pl301_mx6qper1_bchclk_gate IMX_CLOCK_GATE pl301_mx6qfast1_s133clk_gate IMX_CLOCK_GATE pcie_root_gate IMX_CLOCK_GATE uart_serial_clk_gate IMX_CLOCK_GATE uart_clk_gate IMX_CLOCK_GATE ssi3_clk_gate IMX_CLOCK_GATE ssi2_clk_gate IMX_CLOCK_GATE ssi1_clk_gate IMX_CLOCK_GATE spdif_clk_gate IMX_CLOCK_GATE spba_clk_gate IMX_CLOCK_GATE sdma_clk_gate IMX_CLOCK_GATE sata_clk_gate IMX_CLOCK_GATE rom_clk_gate IMX_CLOCK_GATE vpu_clk_gate IMX_CLOCK_GATE vdoaxiclk_clk_gate IMX_CLOCK_GATE eim_slow_clk_gate IMX_CLOCK_GATE usdhc4_clk_gate IMX_CLOCK_GATE usdhc3_clk_gate IMX_CLOCK_GATE usdhc2_clk_gate IMX_CLOCK_GATE usdhc1_clk_gate IMX_CLOCK_GATE usboh3_clk_gate IMX_CLOCK_GATE usbphy1_clk_gate IMX_CLOCK_GATE usbphy2_clk_gate IMX_CLOCK_GATE dummy_clk IMX_CLOCK_FIXED_CLOCK Table 19: i.MX6 clock tree
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
116 Drivers
5.6.2 ZYNQ Clock Manager
5.6.2.1 Clock types
The clock tree is composed by nodes, and each node as a special type, depending on its function. Table 20 summarizes the different clock types for ZYNQ Clock Manager:
Clock Type Properties
ZYNQ_CLOCK_SYSTEM Quartz Oscillator clock
ZYNQ_CLOCK_PLL PLL Reference clock
ZYNQ_CLOCK_SRCSEL Source Selector (multiplexer)
ZYNQ_CLOCK_DIV Divider clock
ZYNQ_CLOCK_RATIO Select Ratio operating mode
ZYNQ_CLOCK_CONTROL Enable or disable clock
Table 20: ZYNQ Clock Manager clock types
5.6.2.2 List of clocks
Table 21 summarizes all the clocks in the ZYNQ clock tree:
Clock Name Type Comments ps ZYNQ_CLOCK_SYSTEM Read from property psp/clock/pll_ref arm ZYNQ_CLOCK_PLL io ZYNQ_CLOCK_PLL ddr ZYNQ_CLOCK_PLL arm_srcsel ZYNQ_CLOCK_SRCSEL arm_div ZYNQ_CLOCK_DIV cpu_1x_ratio ZYNQ_CLOCK_RATIO cpu_2x_ratio ZYNQ_CLOCK_RATIO cpu_3x2x_ratio ZYNQ_CLOCK_RATIO cpu_6x4x_ratio ZYNQ_CLOCK_RATIO cpu_1x_ctrl ZYNQ_CLOCK_CONTROL cpu_2x_ctrl ZYNQ_CLOCK_CONTROL cpu_3x2x_ctrl ZYNQ_CLOCK_CONTROL cpu_6x4x_ctrl ZYNQ_CLOCK_CONTROL gem0_srcsel ZYNQ_CLOCK_SRCSEL gem1_srcsel ZYNQ_CLOCK_SRCSEL smc_srcsel ZYNQ_CLOCK_SRCSEL lqspi_srcsel ZYNQ_CLOCK_SRCSEL sdio_srcsel ZYNQ_CLOCK_SRCSEL uart_srcsel ZYNQ_CLOCK_SRCSEL spi_srcsel ZYNQ_CLOCK_SRCSEL can_srcsel ZYNQ_CLOCK_SRCSEL dbg_srcsel ZYNQ_CLOCK_SRCSEL pcap_srcsel ZYNQ_CLOCK_SRCSEL
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Clock Manager Drivers 117
Clock Name Type Comments fpga0_srcsel ZYNQ_CLOCK_SRCSEL fpga1_srcsel ZYNQ_CLOCK_SRCSEL fpga2_srcsel ZYNQ_CLOCK_SRCSEL fpga3_srcsel ZYNQ_CLOCK_SRCSEL amba_dmac_ctrl ZYNQ_CLOCK_CONTROL amba_usb0_ctrl ZYNQ_CLOCK_CONTROL amba_usb1_ctrl ZYNQ_CLOCK_CONTROL amba_gige0_ctrl ZYNQ_CLOCK_CONTROL amba_gige1_ctrl ZYNQ_CLOCK_CONTROL amba_sdio0_ctrl ZYNQ_CLOCK_CONTROL amba_sdio1_ctrl ZYNQ_CLOCK_CONTROL amba_spi0_ctrl ZYNQ_CLOCK_CONTROL amba_spi1_ctrl ZYNQ_CLOCK_CONTROL amba_can0_ctrl ZYNQ_CLOCK_CONTROL amba_can1_ctrl ZYNQ_CLOCK_CONTROL amba_i2c0_ctrl ZYNQ_CLOCK_CONTROL amba_i2c1_ctrl ZYNQ_CLOCK_CONTROL amba_uart0_ctrl ZYNQ_CLOCK_CONTROL amba_uart1_ctrl ZYNQ_CLOCK_CONTROL amba_gpio_ctrl ZYNQ_CLOCK_CONTROL amba_qspi_ctrl ZYNQ_CLOCK_CONTROL amba_smc_ctrl ZYNQ_CLOCK_CONTROL ddr_2x_div ZYNQ_CLOCK_DIV ddr_3x_div ZYNQ_CLOCK_DIV ddr_2x_ctrl ZYNQ_CLOCK_CONTROL ddr_3x_ctrl ZYNQ_CLOCK_CONTROL gem0_div0 ZYNQ_CLOCK_DIV gem0_div1 ZYNQ_CLOCK_DIV gem1_div0 ZYNQ_CLOCK_DIV gem1_div1 ZYNQ_CLOCK_DIV gem0_tx_emio_srcsel ZYNQ_CLOCK_SRCSEL gem1_tx_emio_srcsel ZYNQ_CLOCK_SRCSEL gem0_tx_ctrl ZYNQ_CLOCK_CONTROL gem1_tx_ctrl ZYNQ_CLOCK_CONTROL gem0_rx_ext_srcsel ZYNQ_CLOCK_SRCSEL gem1_rx_ext_srcsel ZYNQ_CLOCK_SRCSEL gem0_rx_ctrl ZYNQ_CLOCK_CONTROL gem1_rx_ctrl ZYNQ_CLOCK_CONTROL sdio_div ZYNQ_CLOCK_DIV smc_div ZYNQ_CLOCK_DIV spi_div ZYNQ_CLOCK_DIV lqspi_div ZYNQ_CLOCK_DIV uart_div ZYNQ_CLOCK_DIV sdio0_ctrl ZYNQ_CLOCK_CONTROL sdio1_ctrl ZYNQ_CLOCK_CONTROL
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
118 Drivers
Clock Name Type Comments smc_ctrl ZYNQ_CLOCK_CONTROL spi0_ctrl ZYNQ_CLOCK_CONTROL spi1_ctrl ZYNQ_CLOCK_CONTROL lqspi_ctrl ZYNQ_CLOCK_CONTROL uart0_ctrl ZYNQ_CLOCK_CONTROL uart1_ctrl ZYNQ_CLOCK_CONTROL can_div0 ZYNQ_CLOCK_DIV can_div1 ZYNQ_CLOCK_DIV can0_ctrl ZYNQ_CLOCK_CONTROL can1_ctrl ZYNQ_CLOCK_CONTROL can0_pll_mio_srcsel ZYNQ_CLOCK_SRCSEL can1_pll_mio_srcsel ZYNQ_CLOCK_SRCSEL fpga0_div0 ZYNQ_CLOCK_DIV fpga1_div0 ZYNQ_CLOCK_DIV fpga2_div0 ZYNQ_CLOCK_DIV fpga3_div0 ZYNQ_CLOCK_DIV fpga0_div1 ZYNQ_CLOCK_DIV fpga1_div1 ZYNQ_CLOCK_DIV fpga2_div1 ZYNQ_CLOCK_DIV fpga3_div1 ZYNQ_CLOCK_DIV trace_srcsel ZYNQ_CLOCK_SRCSEL trace_div ZYNQ_CLOCK_DIV trace_emio_srcsel ZYNQ_CLOCK_SRCSEL trace_ctrl ZYNQ_CLOCK_CONTROL ext_mio_enet0_rx ZYNQ_CLOCK_SYSTEM ext_mio_enet1_rx ZYNQ_CLOCK_SYSTEM ext_emio_enet0_rx ZYNQ_CLOCK_SYSTEM ext_emio_enet1_rx ZYNQ_CLOCK_SYSTEM gem0_rx_loopback_srcsel ZYNQ_CLOCK_SRCSEL gem1_rx_loopback_srcsel ZYNQ_CLOCK_SRCSEL ext_emio_enet0_tx ZYNQ_CLOCK_SYSTEM ext_emio_enet1_tx ZYNQ_CLOCK_SYSTEM can0_mio_srcsel ZYNQ_CLOCK_SRCSEL can1_mio_srcsel ZYNQ_CLOCK_SRCSEL ext_mio_can0-53 ZYNQ_CLOCK_SYSTEM
Table 21: ZYNQ clock tree
5.7 GPIO Driver
The drivers described in this chapter are available only on demand. Please contact sales@sysgo.com for further details.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
CAN Drivers 119
5.7.1 GPIO IMX
PikeOS provides a GPIO kernel level driver for use with i.MX SoCs (i.MX2 and later). The imx_gpio driver uses the driver development environment with the DIO Class. Please refer to the PikeOS Device Driver Programming Reference Manual
• section 14.5, page 622 for details about the DIO class driver configuration
• section 14.4, page 614 for description of the interface between driver and client.
The driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/object/kerneldriver/imx_gpio.kdev
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component and 1 GPIO device
component.
/opt/pikeos-D5.0/target/arm/v7hf/driver/dio/imx_gpio_kdev.dom
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/dio/imx_gpio/imx_gpio-fp_kdev.cmp
/opt/pikeos-D5.0/target/arm/v7hf/driver/dio/imx_gpio/imx_gpio-device_kdev.cmp
5.7.1.1 Driver Specific Limitations
The imx_gpio driver has the following limitations:
• The Interrupt Mode "Any Edge" is not supported.
• Disabling "Output Enable" is not supported. The OE is always enabled for output pins due to HW limitation.
5.8 CAN Drivers
The drivers described in this chapter are available only on demand. Please contact sales@sysgo.com for further details.
5.8.1 FlexCAN
PikeOS provides a CAN driver which allows usage of the on-chip FlexCAN controllers found in Used in Pow- erQUICC, QorIQ and i.MX SOCs. The flexcan2 CAN driver uses the driver development environment with the CAN High Level Module (see PikeOS Device Driver Programming Reference Manual, section 13, page 576). Please refer to the PikeOS Device Driver Programming Reference Manual, section 12.5, page 573 for details about the CAN class driver configuration and PikeOS Device Driver Programming Reference Manual, section 12.4, page 558 for description of the interface between driver and client. The flexcan2 driver is provided as user level driver (external file provider).
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
120 Drivers
5.8.1.1 User Level Driver
The user level version of the driver is provided by the module
/opt/pikeos-D5.0/target/arm/v7hf/driver/object/flexcan2.elf
and the corresponding dom file for a CAN0 or CAN1 interface is:
/opt/pikeos-D5.0/target/arm/v7hf/driver/can/flexcan2_can0.dom /opt/pikeos-D5.0/target/arm/v7hf/driver/can/flexcan2_can1.dom
The dom file adds the driver to the service partition, instantiates the chosen CAN port, associating it with the flexcan0 respectively flexcan1 I/O device. The CAN virtual channels are kept on default values. In CODEO, the flexcan2 driver can be added to an integration project using the Add... button. Browse to PIKEOS_POOL->driver->can and select desired FlexCAN driver for a chosen CAN port. In a configuration script, the flexcan2 driver for CAN0 interface can be added to an integration project with the line
add PIKEOS_POOL driver/can/flexcan2_can0.dom
or for CAN1 interface with:
add PIKEOS_POOL driver/can/flexcan2_can1.dom
5.9 IOMMU Drivers
5.9.1 SMMU
PikeOS provides a System Memory Management Unit driver The SMMU driver uses Kernel Driver Framework Interface.
• Kernel Driver Framework Interface for description of the interface. Please refer to the PikeOS Device Driver
Programming Reference Manual
The driver is provided by the module:
/opt/pikeos-D5.0/target/arm/v7hf/fusion-kernel/object/kerneldriver/smmu.kdev
The corresponding driver configuration files are:
• The driver component files giving the driver configuration and data structure:
/opt/pikeos-D5.0/target/arm/v7hf/driver/iommu/smmu/smmu.cmp
5.9.1.1 System Memory Management Unit driver configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Diagnostics:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
IOMMU Drivers 121
Verbosity Level: Verbosity level Default: normal
• Parameters:
Model: SMMU model (400, 401 or 500)Default: MMU-400
Number : SMMU number Default: 0
Base address: SMMU base address Default: 0x00000000
Interrupt: SMMU Interrupt (IRQ number) non secure mode Default: 0
ID size: SMMU ID size (number of bits) Default: 8
Enable default bypass mode: Enable bypass (pass through). If no context/configuration found, bypass
transaction Default: true
• Devices Global configuration:
Provide all devices: Enable all devices Default: false
• Devices Detailed configuration:
ID register address: Device configuration define ID (0 = unused). If false, ID is value defined by
hardware, else ID register address. For example, on NXP layascape boards, ID registers are ICID
registers. Default: true
ID register swapped: ID register is swapped. If true, ID register is swappped. Default: false
Device 1 name: Device 1 name Default: dev1
ID device 1: ID (or ID address register) device 1 Default: 0x00000000
Device 2 name: Device 2 name Default: dev2
ID device 2: ID (or ID address register) device 2 Default: 0x00000000
Device 3 name: Device 3 name Default: dev3
ID device 3: ID (or ID address register) device 3 Default: 0x00000000
Device 4 name: Device 4 name Default: dev4
ID device 4: ID (or ID address register) device 4 Default: 0x00000000
Device 5 name: Device 5 name Default: dev5
ID device 5: ID (or ID address register) device 5 Default: 0x00000000
Device 6 name: Device 6 name Default: dev6
ID device 6: ID (or ID address register) device 6 Default: 0x00000000
Device 7 name: Device 7 name Default: dev7
ID device 7 : ID (or ID address register) device 7 Default: 0x00000000
Device 8 name: Device 8 name Default: dev8
ID device 8: ID (or ID address register) device 8 Default: 0x00000000
Device 9 name: Device 9 name Default: dev9
ID device 9: ID (or ID address register) device 9 Default: 0x00000000
Device 10 name: Device 10 name Default: dev10
ID device 10: ID (or ID address register) device 10 Default: 0x00000000
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
122 Drivers
5.9.1.2 Driver Specific Limitations
The SMMU driver has the following limitations:
• Only supports SMMU version 2 (model MMU 400, 401 and 500).
• U-Boot (or specific code in psp) must configure ID before PikeOS boot.
• Only supports a minimal granularity of 4 Kilobytes.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
6 The PikeOS CDK
The PikeOS CDK will be installed under
/opt/pikeos-D5.0/cdk/arm/v7hf/bin
for ARMv7 systems where the floating point operations are done by the hardware coprocessor. To avoid conflicts with other utilities installed on the host, all binaries provided by the CDK are prefixed arm_v7hf- like arm_v7hf-gcc.
Note: Every code that shall execute under PikeOS on an ARM processor must be compiled with the PikeOS CDK (cross development toolchain) for the ARM family. At first glance binaries compiled with an other toolchain may also run, but slight differences in the generated code may cause problems which are very hard to debug.
The PikeOS ARM cross development toolchain uses Linux EABI. This is important if routines compiled with the C compiler shall be called from an assembly language function or vice versa. Detailed PDF documentation can be found in:
/opt/pikeos-D5.0/documentation/cdk/arm_
6.1 Target binaries v7hf
With the installation of the PikeOS Package: Base, all the processor family dependent binary modules, libraries, header files, BSPs and PSPs will be installed into the directory
/opt/pikeos-D5.0/target/arm/v7hf/
The PikeOS architecture name is arm_v7hf.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Chipset Area Timer IRQ Cortex A9 Secure MPCore Global Timer 27 Cortex A9 Any MPCore Local Timer 29 Cortex A15 Secure CPU Generic Timer Secure 29 Cortex A15 Normal CPU Generic Timer Physical 30 Cortex A15 Virtualized CPU Generic Timer Virtual 27
Table 22: Timer on Cortex boards
Chipset Boards Cortex A9 i.MX6, Zynq ZC702, Zynq Zed Board Cortex A9 Vayu, Fastmodel a15
Table 23: Cortex A9 board variants
7 Interrupt Setup on ARM Platforms
7.1 Periodic Timer Interrupt
The PikeOS ARM PSPs are using different kind of timers depending on the board or depending on the chipset. This chapter will detail which timer is used by the PikeOS PSPs and which interrupt is reserved for it. An application attempting to attach to a interrupt used by the kernel will receive a ’P4_E_NOENT’ error.
7.1.1 Cortex A9 and A15 Based Board
On Cortex Family boards, timers on the chipset are used to provide the ticker interrupt. Depending on where PikeOS is actually running (Secure or Normal area in Trustzone, hardware virtualized guest when supported) a different timer might be used like table 22
Table 23 details which boards are based on those chipsets.
7.1.2 Other Boards
Table 24 details which interrupt sources are used by the respective PSPs as ticker interrupt.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
GPIO Interrupt Multiplexing 125
Board Timer IRQ qemu-arm Timer 1 6
Table 24: Interrupt ticker on non Cortex boards
Board Interrupt Sources (Reserved) GPIO Interrupts Banks (Index) Pins per bank (Index) max. Interrupts i.MX6 160 (256) 224 7 (0-6) 32 (0-31) 480
Table 25: Mapping of interrupt sources
7.2 GPIO Interrupt Multiplexing
The i.MX 6 boards multiplex several GPIO interrupts over a single interrupt source. To allow the user to attach directly to a single PIN as a interrupt source, the PSPs implement a set of virtual interrupts that are mapped to the multiplexed interrupt sources and demultiplexed on occurrence. This extends the possible interrupts source by the amount of general purpose input/output pins available for each device. Please see the listing below for detailed information. The feature has a side-effect regarding the interrupt source of the GPIO bank (eg. interrupt 50 (MXC_INT_GPIO1_LOW) on i.MX51 psp). The user cannot attach directly to such an interrupt. The virtual inter- rupt of the individual pin has to be used. If the full bank is needed one can attach a single handler to every pin interrupt of this bank. See table 25
The "Interrupt Sources" column shows the number of interrupt sources available on the platform. Most interrupt controllers support more sources than actually occupied by devices. The value in parentheses shows the range of interrupts that are reserved, including the ones that are occupied by devices. The IDs of the virtual GPIO interrupts start after the range reserved by the interrupt controller. The virtual interrupt source of a pin can be calculated with this formula:
VIRQ = (Reserved Interrupt Sources) + (Bank Index) * 32 + (Pin Index)
The following interrupt sources are not available due to the interrupt demultiplexing:
• i.MX6:
GPIO1_LOW 98
GPIO1_HIGH 99
GPIO2_LOW 100
GPIO2_HIGH 101
GPIO3_LOW 102
GPIO3_HIGH 103
GPIO4_LOW 104
GPIO4_HIGH 105
GPIO5_LOW 106
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
126 Interrupt Setup on ARM Platforms
GPIO5_HIGH 107
GPIO6_LOW 108
GPIO6_HIGH 109
GPIO7_LOW 110
GPIO7_HIGH 111
The real GPIO interrupts of the GPIO banks are always handled by the PSP on CPU 0. Interrupt affinity is not supported.
7.3 MSI and MSI-X interrupts
MSI and MSI-x interrupts are currently supported for LS1021A based boards. When enabled, the MSI interrupt configured for group 0 (see section 5.5.3, page 108) is kept private to the PSP (i.e. no driver can attach to it), and virtual interrupts are available for device drivers like listed in table 26.
Interrupt type Virtual interrupt range
MSI [956-987]
MSI-X [988-1019]
Table 26: MSI and MSI-X interrupts
Note: These interrupts cannot be attached directly, it’s needed to use the appropriate drv_msi* services to request them. For more information, please refer to the PikeOS Device Driver Programming Reference Manual, section 19.5.8, page 768
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
A Architecture Dependencies
A.1 Supported Architectures
The ARM ASP supports ARMv7 cores with MMU. See table 27 for details.
A.2 ASP Variants
This ASP is provided in two variants, depending on the used processor core:
Variant Architecture Description v7 ARMv7 Cortex A5, A8 and A9, additional SMP support v7-lpae ARMv7 Cortex A7 and A15, additional SMP support
Table 27: ASP Variants
A.3 Address Layout
The user accessible part of the address space covers the address range from address 0 to 0x7fffffff, inclusive. The page size is 4096 bytes. The physical address space covers 32-bit or 40-bit with LPAE.
A.4 Basic Data Types
PikeOS Type Size in Bytes Description P4_cpureg_t 4 Size of a processor register P4_address_t 4 Virtual memory address P4_size_t 4 Size of objects in virtual memory P4_phys_addr_t 8 Physical address space type P4_cpumask_t 4 Up to 32 processors are supported in the API
Table 28: Size of basic data types
A.5 User Mode Context
The user mode context contains all registers necessary to save the state of a thread on a thread switch or an exception.
A.5.1 Register Set
The order of the registers is defined in the following structure. The size of a complete user mode context is 352 bytes.
typedef struct P4_regs_str {
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
128 Architecture Dependencies
P4_cpureg_t regs[16]; /* General purpose registers R0 to R15 */
P4_cpureg_t cpsr; /* Status register, see note 1 */
P4_cpureg_t tls; /* Thread local storage pointer, see note 2 */
P4_cpureg_t fault; /* Page fault address register, see note 3 */
P4_cpureg_t ex_code; /* Exception status/reply code, see note 4 */
/* VFP / Advanced SIMD registers */
P4_uint32_t fpexc; /* FPEXC, see note 5 */
P4_uint32_t fpscr; /* FPSCR, see note 6 */
P4_uint32_t fpinst; /* FPINST, see note 7 */
P4_uint32_t fpinst2; /* FPINST2, see note 7 */
P4_uint64_t fpregs[32]; /* VFP registers, see note 8 */
} P4_regs_t;
• Note 1: Not all bit combinations are allowed in this register. The user is allowed to change in all ARM
versions: CPSR_N (bit 31), CPSR_Z (bit 30), CPSR_C (bit 29), CPSR_V (bit 28), and CPSR_T (bit 5). On
ARMv7, the user can change the following additional flags: CPSR_Q (bit 27), CPSR_IT (bits 10 to 15 and
25 to 26) and CPSR_GE (bits 16 to 19).
• Note 2: Register tls contains the thread local storage pointer and can be freely modified. The TLS pointer
can be obtained by invoking a routine placed at memory address 0xffff0fe0, see example below.
• Note 3: fault contains the fault address in a P4_TRAP_SEG exception, and exception causing instructions
in P4_TRAP_SYS and P4_TRAP_ILL exceptions. It is a read only entry and ignored on exception reply.
• Note 4: ex_code is not a CPU register. It contains the exception message status code and must be set to
a valid reply code by the exception handler.
• Note 5: fpexc is the FPEXC register of the VFP. VFP can be enabled and disabled by setting and clearing
bit 30.
• Note 6: fpscr is the FPSCR register of the VFP. The user can modify all bits.
• Note 7: fpinst and fpinst2 may be used during VFP exception handling. If bit 31 is set in fpexc,
fpinst contains the faulting VFP operation. If both bits 31 and 28 are set in fpexc, fpinst2 contains
the next non-executed VFP operation. These registers are not available on all ARM platforms.
• Note 8: fpregs represent the data registers of the VFP unit. Depending on the VFP version, either
registers d0 to d15 or d0 to d31 are available.
A.5.2 Short Context
The short context is used in the short exception message and defines only a subset of all registers. Registers ex_code and fault contain the exception status code and fault address, regs[15] and regs[13] represent program counter and stack pointer, and cpsr and regs[14] are used as architecture specific registers 1 and 2.
A.5.3 FPU Support
PikeOS supports the VFP style FPU on ARM processors. The kernel detects if VFP is available on the used platform and configures access to VFP properly. Support for VFP can be checked at runtime:
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
User Mode Context 129
int vfp_mode = p4_kinfo_arch()->has_fpu;
Table 29 explains the possible integer values of vfp_mode.
vfp_mode Description
0 VFP not available.
1 VFP with registers d0 to d15 available.
2 VFP with registers d0 to d31 available.
Table 29: Possible values on calling p4_kinfo_arch()->has_fpu.
PikeOS userspace thread context contains parts for FPU and vector units. The ARM VFP context is controlled by the FPU part of the userspace context only. There is no vector support on ARM. Thus, if the thread is going to perform VFP operations, one needs to set the P4_THREAD_ARG_FPU argument when calling p4_thread_arg() or modify the context of the thread with p4_thread_fpu_on(). Please consult the PikeOS Kernel Reference Manual for further details. When using the PikeOS Native API Extensions, set the P4_THREAD_ARG_FPU in the context_flags of the thread attribute object. Internally, the FPU context is controlled via bit 30 in the FPEXC register of the thread userspace context. If the bit is set, VFP is accessible in user space, and saved and restored upon thread switches and exception handling.
A.5.4 Thumb Support
PikeOS supports the ARM Thumb instruction set: Thumb is either explicitly enabled by CPSR_T (bit 5) or implicitly by passing in an instruction address with bit 1 set on all PikeOS system calls which accept a register context.
A.5.5 ThumbEE Support
The ARM ThumbEE instruction state defined for ARMv7 and newer is not supported: Access to the ThumbEE Handler Base Register (TEEHBR) is denied and the register state of a thread in ThumbEE mode cannot be restored correctly on exceptions.
A.5.6 Jazelle Support
The ARM Jazelle instruction state is not supported by PikeOS.
A.5.7 TLS Support
TLS (thread local storage) support is binary compatible to the Linux AEABI implemented Linux 3.1 or newer when using the Linux Native POSIX Thread Library (NPTL) threading library. The high vector page at 0xffff0000 is mapped read-only to the user. Table 30 shows accessing that mapped memory using stubs.
Address Stub Description 0xffff0f60 cmpxchg64() Compare exchange instruction, 64-bit. 0xffff0fa0 barrier() Memory barrier. 0xffff0fc0 cmpxchg() Compare exchange instruction, 32-bit.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
130 Architecture Dependencies
Address Stub Description 0xffff0fe0 get_tls() Read thread specific TLS value. 0xffff0ffc version() Version identifier, set to 3.
Table 30: Accessing TLS mapped memory using stubs.
PikeOS itself does not provide bindings to these stubs, however, the following example code shows how to call them:
typedef int (stub_cmpxchg64_t)(int64_t *oldptr, int64_t *newptr, int64_t *ptr);
#define cmpxchg64 (*(stub_cmpxchg64_t *)0xffff0f60)
typedef void (stub_barrier_t)(void);
#define barrier (*(stub_barrier_t *)0xffff0fa0)
typedef int (stub_cmpxchg_t)(int oldval, int newval, int *ptr);
#define cmpxchg (*(stub_cmpxchg_t *)0xffff0fc0)
typedef int (stub_get_tls_t)(void);
#define get_tls (*(stub_get_tls_t *)0xffff0fe0)
All four stubs are implemented. The TLS pointer is always kept in CP15, register C13, C0, 3.
A.5.8 Linux Signal Handling Helper Support
The PikeOS kernel provides Linux 2.6.32 compatible sigreturn(), rt_sigreturn() and restart_syscall() handlers located in the high vector page at address 0xffff0500.
A.6 Mapping Translations
A.6.1 Translation of PikeOS Access Permissions to Architecture Specific Access Permissions
The mapping attributes P4_M_READ, P4_M_WRITE, and P4_M_EXEC on the left of table 31 are translated to the following effective architecture specific attributes on the right.
P4_M_READ P4_M_WRITE P4_M_EXEC Read Write Execute 0 0 0 0 0 0 0 0 1 1 0 1 0 1 0 1 1 0 0 1 1 1 1 1 1 0 0 1 0 0 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1
Table 31: Translation of mapping attributes
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Mapping Translations 131
Execution permissions are supported on a per-page level, but this implies P4_M_READ for these page as well. Furthermore, P4_M_WRITE always implies P4_M_READ, because there is no concept of write only pages.
A.6.2 Translation of Architecture Specific Access Permissions to PikeOS Access Permissions
The architecture specific mapping attributes stored in the page tables in the kernel are translated to the following generic attributes as table 32 shows.
Read Write Execute P4_M_READ P4_M_WRITE P4_M_EXEC 0 0 0 0 0 0 1 0 0 1 0 0 1 0 1 1 0 1 1 1 0 1 1 0 1 1 1 1 1 1
Table 32: Translation of access permissions
The five supported combinations are:
• 0: no access at all,
• P4_M_READ : read only,
• P4_M_READ | P4_M_EXEC: read only and executable,
• P4_M_READ | P4_M_WRITE : read and write, and
• P4_M_READ | P4_M_WRITE | P4_M_EXEC: read, write and executable.
A.6.3 Supported Caching Attributes
The ARMv7 architecture defines six bits. Three TEX bits, B and C, and the S bit for memory sharing as table 33 shows.
P4_M_C_ P4_M_C_ P4_M_C_ TEX CB Description ENABLE WRITEBACK PREFETCH 0 0 0 000 00 Uncached strongly ordered 0 1 0 000 01 Memory type device 0 x 1 001 00 Uncached RAM 1 0 x 000 10 Cached write through 1 1 0 000 11 Cached write back without write allocate 1 1 1 001 11 Cached write back with write allocate
Table 33: Caching attributes
Note: When using LPAE, a compatible memory attribute scheme is enforced.
The shared bit is controlled by P4_M_C_COHERENCY and only modifiable on SMP systems like table 34 shows.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
132 Architecture Dependencies
Type P4_M_C_COHERENCY S Description
UP x 0 Shared bit always cleared
SMP 0 0 Shared bit cleared
SMP 1 1 Shared bit set
Table 34: Effekt of setting the P4_M_C_COHERENCY bit
Note: Most ARM processors treat uncached strongly ordered memory accesses as implicitly shared.
The MMU bits translate to PikeOS memory settings like listed in table 35.
ARM PikeOS Cache Settings
TEX 00x P4_M_C_PREFETCH
C P4_M_C_ENABLE
B P4_M_C_WRITEBACK
S P4_M_C_COHERENCY
Table 35: MMU bits
The attributes P4_M_C_PLATFORM1 and P4_M_C_PLATFORM2 are not supported and ignored.
Note: The default memory attribute is P4_M_C_WB which is supported on all current ARM processors. In mappings with this cache attribute, all atomic operations are supported. When using mappings with different cache attributes, atomic operations are not guaranteed to work. Check the ARM Cortex family manual and your SoC manual for further restrictions on supported cache attributes.
A.6.4 VMIT Cache Modes
The VMIT cache modes map to the settings listed in table 36.
VMIT cache mode Kernel cache TEX CB Description
attributes
VM_MEM_CACHE_CB P4_M_C_WB 001 11 write-back cacheable
VM_MEM_CACHE_WT P4_M_C_WT 000 10 write-through cacheable
VM_MEM_CACHE_INHIBIT P4_M_C_UC 000 00 uncached strongly-ordered
VM_MEM_CACHE_WC P4_M_C_WC 001 00 uncached RAM
VM_MEM_CACHE_DEV P4_M_C_DEV 000 01 Memory type device
Table 36: VMIT cache modes
A.7 Translation of Architecture Specific Exceptions to PikeOS Trap Codes
Table 37 describes specific exception class and gives the reported PikeOS trap code.
Offset / Exception Trapcode Description 0x00 / Reset - Reset Exception 0x04 / Undef P4_TRAP_FP_UNAVAIL VFP instruction and FPU disabled
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Kernel Resources 133
Offset / Exception Trapcode Description 0x04 / Undef P4_TRAP_FP VFP instruction and FPU enabled 0x04 / Undef P4_TRAP_ILL Undefined instruction 0x08 / Software interrupt P4_TRAP_SYS Software interrupt 0x0c / Prefetch abort P4_TRAP_BUS Bus error 0x0c / Prefetch abort P4_TRAP_SEG Page faults or access violations 0x0c / Prefetch abort P4_TRAP_BRK Breakpoint instruction 0x10 / Data abort P4_TRAP_BUS Bus error 0x10 / Data abort P4_TRAP_SEG Page faults or access violations 0x14 / Reserved - - 0x18 / IRQ - routed to PSP intdispatch() handler 0x1c / FIQ - routed to PSP machinecheck() handler
Table 37: Trap codes of architecture specific exceptions
A.8 Kernel Resources
Kernel memory is allocated in units whose size depend on the thrinfo_size property (configurable through kernel parameter). The maximum configurable thrinfo_size for the architecture is 4 pages (0x4000). The default is one page (0x1000 bytes). There are no special alignment requirements for kernel resources. A maximum of 1024 interrupts are supported on ARMv7. One idle thread is allocated on each CPU. A unit-sized stack is allocated for the management of FIQ interrupts on each CPU. The required amount of kernel memory differs between normal and LPAE kernels.
A.8.1 Non-LPAE Kernels
Table 38 show the allocated pagecount for certain kernel resources.
Resource Size in Units Description Task 1 Task descriptor (1 per task, mandatory) Thread 1 Thread control block (1 per thread) Pgtable 1 Page table (1 per 4 MB mapping)
Table 38: Kernel memory allocate resources (Non-LPAE)
A freshly activated task without any threads consumes two units, one for the task descriptor, the other one for the page directory. Page directories of 8 or 16 KB size are allocated at boot time for all configured tasks (p4/kernel/num_task kernel property). A user space mapping created in an untouched 4 MB area needs one unit for the page table.
A.8.2 LPAE Kernels
Table 39 show the allocated pagecount for certain kernel resources.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
134 Architecture Dependencies
Resource Size in Units Description Task 1 Task descriptor (1 per task, mandatory) Pgdir 2 Page directories (2 per task, mandatory) Thread 1 Thread control block (1 per thread) Pgtable 1 Page table (1 per 2 MB mapping)
Table 39: Kernel memory allocate resources (Non-LPAE)
A freshly activated task without any threads consumes three units, one for the task descriptor, and two for page directories. A user space mapping created in an untouched 2 MB area needs one unit for the page table.
A.9 Cache Handling
With split first level instruction and data caches, an ARM PSP implements the cache operations exported in the p4_cache() kernel API as follows:
Cache Operation Description
P4_INVAL_ICACHE_RANGE Write-back data cache with DCCMVAU and invalidate instruction
cache with ICIMVAU.
P4_FLUSH_DCACHE_RANGE Flush data cache with DCCIMVAC.
P4_SYNC_DCACHE_RANGE Write-back data cache with DCCMVAC.
P4_INVAL_DCACHE_RANGE Invalidate data cache with DCIMVAC. Unaligned beginning or end
are flushed with DCCIMVAC.
Table 40: Tp4_cache() kernel API operations
The P4_INVAL_ICACHE_RANGE operation also invalidates branch prediction with BPIALLIS on SMP or BPIALL on UP systems. To handle aliases in virtually-indexed, physically-tagged or ASID-tagged virtually-indexed, virtually-tagged in- struction caches, the alias parameter of p4_cache() should refer to the start address of the affected memory region, which can reside in the same or a different address space. The implementation takes care of the aliases either by invalidating the aliases using a dedicated mapping with the same cache color, or by invalidating the whole instruction cache using an ICIALLU instruction on single core or an ICIALLUIS instruction on multi core systems. When an ARM processor supports more than one level of caches, both the used processor family and SoC implementation and the flags parameter in p4_cache() define the behavior on other levels in the cache hierarchy during operations on the data caches. Typically, cache instructions like DCCIMVAC affect all levels of processor family defined caches (e.g. L1 and L2 caches on Cortex A15), but not SoC provided last-level caches (e.g. L2 cache on Cortex A9). In the former case (i.e. all caches in the cache hierarchy are defined by the processor family), the flags parameter in p4_cache() is ignored and all levels in the cache hierarchy are affected. In the latter case (i.e. SoC specific caches), the flags parameter defines the affected levels in the cache hierarchy and P4_CACHE_FLAG_DMA should be used for cache coherency to DMA busmasters. Whether an actual CPU requires explicit handling of last level caches or a PSP implements further operations on SoC provided last-level caches is described in the according PSP section of the PikeOS Platform Manual.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Cache Attributes Security 135
On a time partition switch, the behavior depends on the window flags configured in VMIT and the PSP implemen- tation. Typically, the PSP performs actions depending on the window flags:
• VM_SCF_INVAL_ICACHE: Invalidate the whole L1 instruction cache on the current processor using
ICIALLU.
• VM_SCF_FLUSH_DCACHE: Flush the whole L1 data cache on the current processor using DCCISW.
Whether a PSP implements further cache flushes on L2 caches or other SoC provided last-level caches is described in the according PSP section of the PikeOS Platform Manual. The p4_inval_icache_range(), p4_flush_dcache_range(), p4_sync_dcache_range(), and p4_inval_dcache_range() functions call p4_cache() internally.
A.9.1 Data Cache Operations With a PL310 or L2C-310 Cache Controller
If the L2 cache is enabled, the P4_FLUSH_DCACHE_RANGE, P4_SYNC_DCACHE_RANGE, and P4_INVAL_DCACHE_RANGE functions have to clean/invalidate the external cache as well. At first, any data of the specified memory region is first cleaned/invalidated from internal caches. Then, for each affected MVA, the physical address is computed, and then the physical address is written either to register reg7_clean_inv_pa at offset 0x7F0, to register reg7_clean_pa at offset 0x7B0, or to register reg7_inv_pa at offset 0x770 of the cache controller, depending on the requested cache operation (flush, sync/clean or invalidation). The addresses are written from the start, with step equal to the L2 cache line size. If an error occurs during the MVA -> PA translation, further addresses are not flushed. Note that cache invalidation requires write access to the memory region. Finally, all buffers are flushed by a write to the reg7_cache_sync register at offset 0x730 in the PL310 or L2C-310. The register at offset 0x740 is used as a workaround for ARM erratum 753970.
A.10 Cache Attributes Security
ARM multicore processors might encounter an external abort exception when an atomic operation or a regular read/write access is performed on a memory area that is mapped with custom caching attributes. Due to this, the P4_AB_CACHE_CHANGE ability must not be granted to any partition running an untrusted code.
A.10.1 ARM Erratum 782772 on Cortex A9
Due to ARM erratum 782772, Cortex A9 processors might deadlock the processor if a write is followed by a condition-failed LDREX instruction when using an uncached strongly ordered memory mapping. To mitigate this erratum, untrusted partitions should not set custom caching attributes. Due to this, the P4_AB_CACHE_CHANGE ability must not be granted to any partition running an untrusted code.
A.11 Integer division-by-zero
Depending on the supported instruction set on a given System-on-Chip (SoC) the compiler will either emit UDIV or IDIV instructions or use software based division via libgcc. This has implications for the handling of division- by-zero errors. The architecture does not support exceptions for this case and thus integer division by zero is not trapped by default.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
136 Architecture Dependencies
A.11.1 Behavior of division-by-zero when using UDIV/IDIV
The compiler emits UDIV (unsigned divsion) or IDIV (signed division) in place to handle divisions done in the code. These instructions are defined by the ARM architecture reference manual to return 0 in case a division-by-zero happens. No exception is raised. By default the provided arm_v7hf tool-chain does not generate the assembler instruction, as these instructions are only supported starting with the Cortex-A15 family of SoCs. In case the code should use the hardware based division the compiler needs to be instructed to compile code specific for a certain SoC. This can be done by providing the -mcpu= option during compilation. Eg. for Cortex-A15 this can be done like this (makefile.defs of an application project):
CPPFLAGS += -mcpu=cortex-a15
A.11.2 Behavior of division-by-zero when using software division
In case software division is used the compiler utilizes code provided from libgcc (__aeabi_idiv, __aeabi_uidiv, etc.). This code behaves slightly different than the hardware based counterpart.
-
The GCC implementation of the software functions return INT_MAX or LONG_MAX for unsigned integer divisions by zero and SINT_MAX or SLINT_MAX for signed integer divisions by zero.
-
The provided functions utilize checker code for devisions by zero and allow the user to implement custom handler code for these situations.
A.11.2.1 Provide division-by-zero handlers
The code can provide the following two functions to act as handlers for this error condition.
/* Integer division by zero handler (signed+unsigned) */
extern int __aeabi_idiv0(void); int __aeabi_idiv0(void) { /* default return value (equivalent to UDIV/IDIV) */ return 0; }
/* Long-integer division by zero handler (signed+unsigned) / extern long long __aeabi_ldiv0(void); long long __aeabi_ldiv0(void) { / default return value (equivalent to UDIV/IDIV) */ return 0; }
This code could be extended to eg. raise application specific health-monitoring exceptions.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
Speculative Execution Side Channels Mitigations - Meltdown and Spectre 137
A.12 Speculative Execution Side Channels Mitigations - Meltdown and Spectre
PikeOS contains mitigations against the CVE-2017-5753 Spectre "Bounds Check Bypass" (Variant 1) processor vulnerability. Here, a new C macro is introduced to stop the Spectre Variant 1 speculation attack. The C macro P4_FENCE_INDEX() is described in PikeOS Kernel Reference Manual, section 1.40.1, page 567. The usage of this C macro in the application code depends on the results of the vulnerability analysis of your particular application or KDEV driver. The kernel always uses P4_FENCE_INDEX() to stop speculation for user-provided index values, e.g. task or thread IDs and file descriptors. For the CVE-2017-5715 Spectre "Branch Target Injection" (Variant 2) processor vulnerability, no specific mitiga- tions to invalidate the branch predictor are implemented. On Cortex-A8 and Cortex-A9 processors, the branch predictor is invalidated by the BPIALL instruction as part of an address space switch in PikeOS. For Cortex-A15 processors, no mitigation is currently available. A mitigation against CVE-2017-5754 Meltdown "Rogue Data Cache Load" is not available in PikeOS. This issue only affects Cortex-A75 processors, which are 64-bit processors not supported by this ASP. A mitigation against Meltdown "Speculative Read of System Registers" (Variant 3a) is not available. ARM be- lieves that software mitigations for this processor vulnerability are not necessary, see https://developer. arm.com/support/security-update/download-the-whitepaper. This issue only affects Cortex-A15 processors. ARM provides documenation and suggested mitigation techniques for the processor vulnerabilities. Please check https://developer.arm.com/support/security-update for details.
A.13 Detection of Heterogeneous Processor Cores
For heterogeneous processor configurations, such as ARM big.LITTLE, PikeOS shows the content of the archi- tecture defined Main ID register (MIDR) register of all processors in the system. in the kernel info page. This allows an application to check the current processor core type, e.g. Cortex-A15 versus Cortex-A7. The content of the MIDR register of the current processor can be read at runtime:
P4_cpuid_t cpuid = p4_my_cpuid();
P4_uint32_t midr = p4_kinfo_arch()->midr[cpuid];
The encoding of this register is described in the ARM architecture reference manual.
A.14 Building PSP for Cortex-A7 from source
ARM Cortex-A15 and A7 are very similar, yielding that both are using the same PSP code. However, there is a difference in the L1 instruction cache line size between these processors. In order to support optimal code for both CPU types for cache operations while still using the same codebase, a define PSP_CORTEX_A7 has been created. It is mandatory to set this define for Cortex-A7 processors when rebuilding the PSP from source. This define can be put e.g. in a board-specific file, i.e. board.mk. See section 3.10, page 59 for one of the affected boards.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
138 Architecture Dependencies
A.15 Known Limitations
The "User Read/Write Thread and Process ID Register" accessible through CP15, register C13, C0, 2 is cleared on context switches and should not be used in user applications. On non-LPAE kernels, the number of available PikeOS tasks is restricted to 256 due to the limitation of 256 distinctive address spaces in the MMU implementation.
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
B Boards Fusion/PSP Projects
This chapter gives a table referencing for each available board the corresponding example projects. The example projects can be used as starting points for creating modified fusion and PSP projects. The example fusion projects are located in the /opt/pikeos-D5.0/demo/fusion-kernel and /opt/pikeos-D5.0/demo/fusion-pssw directories. The example PSP projects are located in the /opt/pikeos-D5.0/demo/psp directory.
Board Name Kernel Fusion PSSW Fusion PSP cyclone-v-sockit cyclone-v standard cyclone-v fastmodel-a15-hwvirt fastmodel-a15-hwvirt standard fastmodel-a15 fastmodel-a15 fastmodel-a15 standard fastmodel-a15 imx6q_sabreauto imx6 standard imx6 imx6q_sabrelite imx6 standard imx6 imx6q_sabresd imx6 standard imx6 ls1021a-iot-hwvirt ls102xa-hwvirt standard ls102xa ls1021a-iot ls102xa standard ls102xa pikeos-hwvirt-v7hf pikeos-hwvirt- standard pikeos-hwvirt arm_v7hf qemu-arm-v7hf qemu-arm standard qemu-arm tegra-jetson-tk1-hwvirt tegra-k1-hwvirt standard tegra-k1 tegra-jetson-tk1 tegra-k1 standard tegra-k1 ti-keystone2-hwvirt ti-keystone2-hwvirt standard ti-keystone2 ti-keystone2 ti-keystone2 standard ti-keystone2 vpx3-1701 ls102xa standard ls102xa zynq-zc702 zynq standard zynq zynq-zed zynq standard zynq
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.
C Glossary
BASE Service Library: The BASE service library provides general purpose data types and services for devel- oping device drivers.
BLK Class: The BLK class defines client and configuration interfaces for drivers for mass storage devices, such as computer drives or flash memories.
BLK Service Library: The BLK service library provides data types and services for developing drivers for mass storage devices, such as computer drives or flash memories.
Block Device: A block device can be a hard disk or a solid state disk but e.g. also a USB flash drive. Block devices always allow a block of any size (including single characters/bytes) and any alignment to be read or written.
CAN Class: The CAN class defines client and configuration interfaces for CAN bus device drivers.
CAN Service Library: The CAN service library provides data types and services for developing CAN bus device drivers.
CHAR Class: The CHAR class defines client and configuration interfaces for generic I/O device drivers.
CHAR Service Library: The CHAR service library provides data types and services for developing generic I/O device drivers.
DIO Class: The DIO class defines client and configuration interfaces for digital I/O device drivers.
DIO Service Library: The DIO service library provides data types and services for developing digital I/O device drivers.
MTD: Memory Technology Device, a type of device file interacting with flash memory (NOR, NAND), not to be confused with non-raw flash devices, e.g. USB flash drives.
NET Class: The NET class defines client and configuration interfaces for Ethernet device drivers.
NET Service Library: The NET service library provides data types and services for developing Ethernet device drivers.
PCI Service Library: The PCI service library provides data types and services for accessing devices on the PCI bus.
SER Class: The SER class defines client and configuration interfaces for serial UART device drivers.
SER Service Library: The SER service library provides data types and services for developing serial UART device drivers.
SYS Service Library: The SYS service library provides data types and services for accessing devices on the system bus (non-PCI).
c Copyright 2005 – 2019 SYSGO GmbH, all rights reserved.