284 KiB
| title | source | category | pages | extracted |
|---|---|---|---|---|
| Platform Manual Arm 64Bit | docs/platform/platform-manual-ARM_64bit.pdf | platform | 115 | 2026-07-06T23:05:29.547979 |
Platform Manual Arm 64Bit
Extracted from
docs/platform/platform-manual-ARM_64bit.pdf(115 pages). Figures, diagrams, and tables may not render accurately in plain text.
UniversalisOS Platform Manual for ARMv8-A 64-bit Boards
Am Pfaffenstein 14, D-55270 Klein-Winternheim
Notice: The contents of this document are proprietary to Portugal Futurista GmbH and shall not be disclosed, disseminated, copied, or used except for purposes expressly authorized in writing by Portugal Futurista GmbH. UniversalisOS Platform Manual for ARMv8-A 64-bit Boards UniversalisOS D5.0, Document Version D5.0-461
c 2005 – 2019 Portugal Futurista GmbH
Portugal Futurista GmbH Email: office@portugalfuturista.org Am Pfaffenstein 14 55270 Klein-Winternheim, Germany http://www.portugalfuturista.org
All rights reserved. UniversalisOS is a trademark of Portugal Futurista 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2 Boards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 QEMU ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.2 Set-up Environment for QEMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.4 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.5 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3 Fixed Virtual Platforms for Cortex A5x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2 Compile a Firmware for FVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3 Set-up Environment for FVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.5 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.6 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Foundation Platform ARMv8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.2 Compile a Firmware for the Foundation Platform . . . . . . . . . . . . . . . . . . . . . . . 18 2.4.3 Set-up Environment for Foundation Platform . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.4.4 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.5 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.6 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.4.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.5 Juno A57 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.2 Compile a Firmware for the Juno Board . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.5.3 Set-up the Juno Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.5.4 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5.5 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.5.6 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.5.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.5.7.1 Juno A57 revision r0 only usable on one cluster . . . . . . . . . . . . . . . . . . 26 2.6 QorIQ LS1043A Reference Design Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.6.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.4 PCI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.6.4.1 Controllers identification and initialization . . . . . . . . . . . . . . . . . . . . . 28 2.6.4.2 Configuring the integration project . . . . . . . . . . . . . . . . . . . . . . . . . 29
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
4 CONTENTS
2.6.5 MSI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.6 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6.7 Using U-Boot from NXP SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.6.8 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.7 QorIQ LS1046A Reference Design Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.7.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.7.4 PCI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.7.4.1 Controllers identification and initialization . . . . . . . . . . . . . . . . . . . . . 33 2.7.4.2 Configuring the integration project . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.7.5 MSI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.7.6 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.7.7 Using U-Boot from NXP SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.7.8 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.8 Xilinx Zynq ZCU102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.8.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.8.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 2.8.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.8.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.8.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.9 Renesas R-Car H/M 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.9.1 The Board Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.9.2 The PSP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.9.3 The PSSW Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.9.4 Running the Hello World Image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.9.5 Enable Hardware Virtualization support in Firmware . . . . . . . . . . . . . . . . . . . . . 44 2.9.6 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3 PSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.2 Common PSP Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3 IO Sequencer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4 Interrupts on ARM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.5 PSP Cortex-A5x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.1 PSP Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.1.1 Mapping and Memory Detection . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.1.2 Multi Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.2 The PSP Main Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.2.1 Board Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.5.2.2 PSP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.5.2.3 Accessing Performance Counters from User Applications . . . . . . . . . . . . . 49 3.5.2.4 User Application Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.5.2.5 Image Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5.3 Extra Memory Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5.4 Reserved Memory Regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.5.5 Extra IO regions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.5.6 GIC Interrupt Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.5.7 Architecture Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
CONTENTS 5
3.5.8 Top Level Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.5.9 PSP Console Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.5.9.1 NS16550 Serial Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.5.9.2 PL011 Serial Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5.9.3 Cadence Serial Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.5.9.4 MSM HS Serial Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.10 PSP Multi-Core Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.10.1 PSCI Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.5.10.2 SPIN Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5.10.3 SCM Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.11 PCI drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.11.1 PSP PCI driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5.11.2 PCI Layerscape driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5.11.3 General configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5.11.4 Component configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5.11.5 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.5.12 MSI support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.12.1 MSI Layerscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.12.2 Component configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5.12.3 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5.12.4 Affinity support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.5.13 HWVIRT Guest Console and P4Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5.14 PSP Specific Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5.15 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4 Boot Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5 Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1 Serial Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1.1 Serial PL011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1.1.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.1.2 Serial SCIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.1.2.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.2.1.1 Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.2.1.2 Serial Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.3 Serial 8250 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.1.3.1 Driver Specific Configuration Parameters . . . . . . . . . . . . . . . . . . . . . 67 5.1.3.2 Driver IOCTL Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.1.3.3 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.3.4 User Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.3.5 Kernel Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.3.5.1 Kernel Fusion Project . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.1.3.5.2 Configuring the Integration Project . . . . . . . . . . . . . . . . . . . . 69 5.1.4 Serial XuartPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.1.5 Serial LPUART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.2 Ethernet Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.2.1 Ethernet smc91cX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 5.2.1.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.2.2 Ethernet smc911x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.2.2.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
6 CONTENTS
5.2.2.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.2.2.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.2.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.3 Ethernet XemacPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.3.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.3.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.3.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.4 Ethernet virtio-net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.2.4.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.4.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2.4.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.4.4 Maximum Transfer Size Configuration . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.4.5 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.5 Ethernet dpaa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2.5.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.5.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.2.5.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.2.5.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.6 Ethernet RAVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.2.6.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.6.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.6.3 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2.6.4 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.7 Ethernet e1000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2.7.1 Driver Base Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.7.2 Physical Device Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.7.3 BSP Configuration / PCI Device Configuration . . . . . . . . . . . . . . . . . . . 89
5.2.7.4 Virtual Channel Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.7.5 Maximum Transfer Size Configuration . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.7.6 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3 Block Device and MTD Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.1 Block Device and MTD Simulator blkdrvsim . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.1.1 Driver Specific Configuration Parameters . . . . . . . . . . . . . . . . . . . . . 90
5.3.1.1.1 blkdrvsim Base Component . . . . . . . . . . . . . . . . . . . . . . . 90
5.3.1.1.2 blkdrvsim Device Component . . . . . . . . . . . . . . . . . . . . . . 91
5.3.1.2 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.1.3 Usage of the User Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.1.3.1 Integration Project for the User Level Driver . . . . . . . . . . . . . . . 92
5.3.1.4 Usage of the Kernel Level Driver . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.3.1.4.1 Fusion Project for the Kernel Level Driver . . . . . . . . . . . . . . . . 93
5.3.1.4.2 Integration Project for the Kernel Level Driver . . . . . . . . . . . . . . 93
5.3.1.5 Demonstration Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.3.1.6 Driver Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.3.2 Partitioned Image Creation Tool mkblkimage . . . . . . . . . . . . . . . . . . . . . . . . 94
5.4 IOMMU Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.1 SMMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.1.1 System Memory Management Unit driver configuration . . . . . . . . . . . . . . 97
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
CONTENTS 7
5.4.1.2 Driver Specific Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.5 Clock Manager Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.1 Zynq Ultrascale Clock Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.1.1 Clock types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.5.1.2 List of clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6 The UniversalisOS CDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.1 Target binaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 A Architecture Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.1 Supported Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.2 Address Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.3 Basic Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.4 User Mode Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.4.1 Register Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 A.4.2 Short Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 A.4.3 FPU Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.4.4 32-bit Execution Environment for SYSEMU . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.5 Mapping Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.5.1 Translation of UniversalisOS Access Permissions to Architecture Specific Access Permissions . . . 107 A.5.2 Translation of Architecture Specific Access Permissions to UniversalisOS Access Permissions . . . 108 A.5.3 Supported Caching Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A.5.4 VMIT Cache Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.6 Translation of Architecture Specific Exceptions to UniversalisOS Trap Codes . . . . . . . . . . . . . . . 110 A.7 Kernel Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.8 Cache Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.8.1 ARM Errata 835769 and 843419 on Cortex A53 . . . . . . . . . . . . . . . . . . . . . . . 112 A.9 Cache Attributes Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.10 Speculative Execution Side Channels Mitigations - Meltdown and Spectre . . . . . . . . . . . . . 112 A.11 Compile Applications without FPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 A.12 Detection of Heterogeneous Processor Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.13 Known Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 B Boards Fusion/PSP Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 C Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
c Copyright 2005 – 2019 Portugal Futurista 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 UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
2 Boards
2.1 Introduction
UniversalisOS supports multiple processor architectures and, for each architecture, multiple board types. This manual covers support for ARMv8-A CPUs and the reference boards supported by UniversalisOS at the moment this manual was published. UniversalisOS supports ARMv8-A processors with MMU (VMSA configuration) and hardware virtualization extension when usable.
c Copyright 2005 – 2019 Portugal Futurista 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 A57 system. QEMU version 2.0 or higher must be used to have support for ARMv8; a suitable, pre-compiled QEMU comes shipped with UniversalisOS. The UniversalisOS board name for this board is qemu-arm-v8hf. The devices (up to 32) attached via virtio MMIO bus are attached to memory area 0x0a000000 + 0x200 * idx, and use IRQs 16 + idx (+32 due to GIC). The ’idx’ is assigned by QEMU backwards - thus the first device instantiated via command line is assigned idx == 31.
2.2.1 The Board Configuration
UniversalisOS provides drivers and configuration for the following board resources:
• Serial controller (PL011), section 5.1.1, page 64
• Ethernet controller (virtion-net), section 5.2.4, page 78
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 UniversalisOS 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 or null.
2.2.3 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The QEMU ARM v8hf board is setting the PSP parameters listed in table 1.
Parameter Value Description Board Name QEMU Cortex A57 virt PSP Console Port 1 Console on first serial device Memory size 0x08000000 64MB by default in QEMU Binary start address 0x40080000 QEMU memory is at 0x40000000 GIC DIST Address 0x08000000 GIC REDIST Address 0x00000000 GIC CPU Address 0x08010000 PL011 Enable true Serial emulated by QEMU is a PL011 device PL011 Clock Rate 7273800 PL011 FIFO size 1 PL011 UART1 Address 0x09000000 PSCI Enable true PSCI is available and used for SMP and re- boot/halt
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
QEMU ARM 11
Parameter Value Description PSCI method HVC HVC instruction needs to be used to use PSCI
Table 1: QEMU ARM v8hf PSP parameter
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 UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-qemu-arm-v8hf-qemu.qemu_cmdline
Now you should see the following output generated by the "Hello World" image:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: devel-universalisos@builder.portugalfuturista.org-240317-23:44 Kernel build: 4.2-1558, type: noassert tracesys smp standard ASP: "arm_v8hf" ARM v8, endian: little PSP build: 4.2-123 PSP: "Cortex A5x" QEMU Cortex A57 virt (SMP-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(1/64) 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: 62500 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Free memory: 129604 KiB PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587 PL011: Provider "ser0" started, Build: 4.2-27 Production 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 Hello World, starting up.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
12 Boards
Hello World, this is task 22, thread 0 Hello World, this is task 22, thread 0 ...
Note: SMP can be used by adding -smp NUM to the command line of QEMU, where NUM must be a number between 1 and 8 included, if you want to simulate a multi-core A57. QEMU delivered with this version of UniversalisOS can freeze when SMP is used so this is turned off by default. .
2.2.6 Limitations
Current Qemu ARMv8 implementation is know to block when more then one core is activated. The board has SMP support turned off to prevent ending in deadlocks during runtime. See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.3 Fixed Virtual Platforms for Cortex A5x
Fastmodel is a ARM software to design virtual prototypes of a ARM platform and emulate them. They can be delivered as Fixed Virtual Platforms (FVP) which are precompiled platforms to be used as preconfigured emulators or as a library of models to configure and emulate your own platform (address space layout, peripherals, etc.). This UniversalisOS BSP supports all FVPs and custom models based on the Cortex A35, A53, A57 and A72 processors and complex cores based on combinations of them (for example four A53 cores together with four A57 cores). The documentation will mainly mention the standard FVP provided by ARM, because the BSP is configured for the address space layout of this platform. In case you compile your own model, you can adapt the different addresses (mainly the GIC and Pl011 addresses) depending on the parameters you choose. The UniversalisOS board name for this board is fastmodel-a5x. Note: Both Fastmodel and FVP require a license from ARM. This license is not provided with UniversalisOS. Please contact ARM directly for more information. If you want a free platform, please check ARM Foundation Platform.
For more information on Fastmodel and FVP, please check ARM website https://developer.arm.com/ products/system-design/fast-models.
2.3.1 The Board Configuration
UniversalisOS provides drivers and configuration for the following board resources:
• Serial controller (PL011), section 5.1.1, page 64
• Ethernet controller (SMC91CX), section 5.2.1, page 71
Hardware virtualization is supported on FVP and can be used using the board fastmodel-a5x-hwvirt.
2.3.2 Compile a Firmware for FVP
The ARM emulator does not contain any firmware and is booting similar to a real hardware, looking for code to execute at address 0x0. A firmware must be provided to be able to execute UniversalisOS on the virtual environment. For the ARMv8 family, ARM is developing and providing a generic firmware named ARM Trusted Firmware which can be found freely on the Internet at: https://github.com/ARM-software/arm-trusted-firmware. It provides standard hardware initialization as well as a standardized PSCI interface, used by Linux for example, and supported by the BSP. Together with ARM Trusted Firmware a bootloader like U-Boot can be used to provide a more flexible way to start an OS. Generating a working bootloader can be quite complex. Therefore UniversalisOS provides a shell script that will auto- matically download both U-Boot and ARM Trusted Firmware and will compile them with the right configuration and parameters to generate something suitable to be used with the UniversalisOS BSP. To compile a FVP firmware, the following command must be executed:
sh# /opt/universalisos-D5.0/target/arm/v8hf/share/cortex-a5x/compile-a5x-firmware.sh --target=fvp --dir=[FIRMWARE_DIR]
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
14 Boards
At the end of the compilation and download process the files bl1.bin and fip.bin are generated in [FIRMWARE_DIR]/boot-binary directory. Note: Several tools like git are used during the process, in case of an error please inspect the file buildlogs.txt which will be generated.
2.3.3 Set-up Environment for FVP
FVP has lots of parameters that can be set and modified to customize the emulated target. The BSP provided with UniversalisOS requires a specific configuration to work out-of-the-box. The following configuration file can be copied and pasted to be used with FVP:
#All cores off pctl.startup=0.0..
#disable real cache behavior (faster) cache_state_modelled=0
#don’t care about serial timing bp.pl011_uart0.untimed_fifos=1 bp.pl011_uart0.uart_enable=1
#enable counter bp.refcounter.non_arch_start_at_default=1
#disable secure memory checking by tzc-400 bp.secure_memory=0
#memory size in GB #If more then 2GB, an extra memory region at 0x880000000 has to be defined bp.dram_size=0x2
#enable network interface #adapt tap0 depending on the tap device you created bp.smsc_91c111.enabled=1 bp.hostbridge.interfaceName="tap0"
#adapt the path to your firmware directory bp.secureflashloader.fname=[FIRMWARE_DIR]/bl1.bin bp.flashloader0.fname=[FIRMWARE_DIR]/fip.bin
To execute FVP and load an image generated by a UniversalisOS project run the following command:
sh# [PATH_TO_FVP]/FVP_Base_xxxx -f [CONFIG_FILE] --data cluster0.cpu0=[IMAGE_FILE]@0x90080000
This will start FVP and the following should appear on the console:
NOTICE: Booting Trusted Firmware
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Fixed Virtual Platforms for Cortex A5x 15
NOTICE: BL1: v1.2(release):d0c104e NOTICE: BL1: Built : 09:39:41, Feb 11 2016 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.2(release):d0c104e NOTICE: BL2: Built : 09:39:43, Feb 11 2016 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.2(release):d0c104e NOTICE: BL31: Built : 09:39:46, Feb 11 2016
U-Boot 2016.01-dirty (Feb 11 2016 - 09:39:23 +0100) vexpress_aemv8a
DRAM: 2 GiB Flash: 64 MiB *** Warning - bad CRC, using default environment
In: serial_pl01x Out: serial_pl01x Err: serial_pl01x Net: SMC91111-0 Hit any key to stop autoboot: 0 VExpress64#
Enter the following command to boot your image:
VExpress64# bootm 0x90080000
Note: Fastmodels requires a tun/tap interface to be reachable through network. Please check the ARM documentation on how to configure this feature or the UniversalisOS User Manual for QEMU on how to create a tun/tap interface using the tunctl command.
2.3.4 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The Fixed Virtual Platforms for Cortex A5xboard is setting the PSP parameters listed in table 2.
Parameter Value Description Board Name Fixed Virtual Platforms for Cortex A5x PSP Console Port 1 Console on first serial device Memory size 0x80000000 2GB of RAM in example configuration GIC DIST Address 0x2F000000 GIC REDIST Address 0x00000000 GIC CPU Address 0x2C000000 GIC CTRL Address 0x2C010000 GIC VCPU Address 0x2C020000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
16 Boards
Parameter Value Description
PL011 Enable true Serial device emulated by Fastmodel is a
PL011
PL011 Clock Rate 0xE10000
PL011 FIFO size 64
PL011 UART1 Address 0x1C090000
PL011 UART2 Address 0x1C0A0000
PL011 UART3 Address 0x1C0B0000
PL011 UART4 Address 0x1C0C0000
PSCI Enable true PSCI is available and used for SMP and re-
boot/halt
PSCI method SMC SMC instruction needs to be used to use
PSCI
Table 2: Fixed Virtual Platforms for Cortex A5xPSP parameter
Note: In case you configure the used model with more than 2GB of RAM. That means bp.dram_size set to greater than 0x2 you have to define a extra memory segment for the memory above 2GB at the physical address 0x880000000 as the emulator will map it there. Please refer to the previous chapter and the generic PSP documentation for more details on this.
2.3.5 The PSSW Configuration
No driver is included in the PSSW for Fixed Virtual Platforms for Cortex A5x.
2.3.6 Running the Hello World Image
The UniversalisOS 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 Fixed Virtual Platforms for Cortex A5x board. To load and run the pre-compiled "Hello World" image, start FVP with the following parameters:
sh# BOOTFILE=/opt/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-fastmodel-a5x-uboot_dtb_unc sh# [PATH_TO_FVP]/FVP_Base_xxxx -f [CONFIG_FILE] --data cluster0.cpu0=$BOOTFILE@0x90080000
Now you should see the following output generated by the "Hello World" image:
MMU: 2048MB of RAM PSCI: cluster 0 4 cores, cluster 1 4 cores, Total 8 cores. ARCH_TIMER: Virtual non-secure, freq: 100000 kHz, irq 27 GIC: 256 irqs, 8 cpus, Dist IID 0x00000000, Cpu IID 0x0073043B UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: universalisos@builder.portugalfuturista.org 2016-04-27 15:33:46 Kernel build: 4.1-1363, type: nodebug-tracesys-smp-normal ASP: "arm_v8hf" ARM v8, endian: little PSP: "Cortex A5x" Fixed Virtual Platforms for Cortex A5x 4.1-48 (SMP-USERDEBUG) Features: RETAIL TRACER-SYSCALL SMP(8/64) Configuration limits:
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Fixed Virtual Platforms for Cortex A5x 17
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: 100000 kHz, user accessible system ticker: dynamic mode, resolution 500 ns time partition switch: 10000000 ns free memory: 2094148 kb PSSW +Ext. FPs +Messages (Production), Build: 4.1-3470 Found SMC91C11xFD NIC, chip revision 91! SMC91CX: mac address autodetected and assigned to dev 0: 00:02:f7:ef:64:b8 SMC91CX: mac address assigned to virtual dev 1: 03:04:8f:00:0a:49 SMC91CX: mac address assigned to virtual dev 2: 03:04:8f:00:0a:50 SMC91CX: mac address assigned to virtual dev 3: 03:04:8f:00:0a:51 Hello World, starting up. Hello World, this is task 22, thread 0
2.3.7 Limitations
As the platform is emulated, the perceived performance will be lower than the performance that can be expected from real hardware. However, the emulator will maintain real-time accuracy. This means the time on the target will run from time to time slower then the reality. You can see this using the Perf Index value of the control interface of FVP. See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.4 Foundation Platform ARMv8
The ARM Foundation Platform is a free emulator supporting the ARMv8 architecture. It can be seen as a light version of a Fixed Virtual Platform (FVP) from previous chapter. The Foundation Platform emulates a multi-core (up to 4) ARMv8 processor with a GIC interrupt controller, PL011 serial lines and an SMC91Cx type ethernet controller and can only be executed on a 64-bit Linux Host. The UniversalisOS board name for this board is foundation-armv8. For more information on the ARM Foundation Platform please check the ARM website: https://developer.arm.com/docs/dui0677/latest To download it: https://developer.arm.com/products/system-design/fixed-virtual-platforms/ fvp-downloads
2.4.1 The Board Configuration
UniversalisOS provides drivers and configuration for the following board resources:
• Serial controller (PL011), section 5.1.1, page 64
• Ethernet controller (SMC91CX), section 5.2.1, page 71
Hardware virtualization is supported on the Foundation Platform and can be used by using the board foundation- armv8-hwvirt, if you have hardware virtualization support.
2.4.2 Compile a Firmware for the Foundation Platform
The ARM emulator does not contain any firmware and is booting as would be a real hardware looking for code to execute at address 0x0. A firmware must be provided to be able to execute UniversalisOS on the Foundation Platform. For the ARMv8 family, ARM is developing and providing a generic firmware named ARM Trusted Firmware which can be found freely on Internet here: https://github.com/ARM-software/arm-trusted-firmware. It provides standard hardware initialization as long as a standardized PSCI interface used by Linux for example and supported by the BSP. Together with ARM Trusted Firmware a bootloader like U-Boot can be used to provide a more flexible way to start an OS. As generating a working set can be quite complex, UniversalisOS provides a shell script that will automatically download both U-Boot and ARM Trusted Firmware and will compile them with the right configuration and parameters to generate something suitable to be used with this UniversalisOS BSP. To compile a Foundation Platform firmware, the following command must be executed:
sh# /opt/universalisos-D5.0/target/arm/v8hf/share/cortex-a5x/compile-a5x-firmware.sh --target=fvp --dir=[FIRMWARE_DIR]
At the end of the compilation and download process, the files bl1.bin and fip.bin are generated in [FIRMWARE_DIR]/boot-binary directory. Note: Several tools like git are used during the process, in case of error please inspect the file buildlogs.txt which will be generated.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Foundation Platform ARMv8 19
2.4.3 Set-up Environment for Foundation Platform
The Foundation Platform has a lot of advanced parameters to customize the emulated target. The BSP provided with UniversalisOS requires some specific command line arguments to work out-of-the box. To execute the Foundation Platform and load an image generated by a UniversalisOS project run the following command:
sh# [PATH_TO_FOUNDATION]/Foundation_Platform --cores=4 --visualization --gicv3 --rate-limit --use-real-time --network=bridged --network-bridge=tap0 --data=[FIRMWARE_DIR]/bl1.bin@0x0 --data=[FIRMWARE_DIR]/fip.bin@0x08000000 --data=[IMAGE_FILE]@0x90080000
This will start the Foundation Platform and the following should appear on the console:
NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.2(release):d0c104e NOTICE: BL1: Built : 09:39:41, Feb 11 2016 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.2(release):d0c104e NOTICE: BL2: Built : 09:39:43, Feb 11 2016 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.2(release):d0c104e NOTICE: BL31: Built : 09:39:46, Feb 11 2016
U-Boot 2016.01-dirty (Feb 11 2016 - 09:39:23 +0100) vexpress_aemv8a
DRAM: 2 GiB Flash: 64 MiB *** Warning - bad CRC, using default environment
In: serial_pl01x Out: serial_pl01x Err: serial_pl01x Net: SMC91111-0 Hit any key to stop autoboot: 0 VExpress64#
Note: The –visualization option creates a network socket showing a web-page to with live information on the running platform (number of instruction, led status, etc.)
Enter the following command to boot your image:
VExpress64# bootm 0x90080000
Note: The Foundation Platform requires a tun/tap interface to be reachable through network. Please check the ARM documentation on how to configure this feature or the UniversalisOS User Manual for QEMU on how to create a tun/tap interface using the tunctl command.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
20 Boards
2.4.4 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The Foundation ARMv8 board is setting the PSP parameters listed in table 3.
Parameter Value Description
Board Name Foundation Platform
ARMv8
PSP Console Port 1 Console on the first serial device
Memory size 0x80000000 2GB of RAM in example configuration
GIC DIST Address 0x2F000000
GIC REDIST Address 0x00000000
GIC CPU Address 0x2C000000
GIC CTRL Address 0x2C010000
GIC VCPU Address 0x2C02F000
PL011 Enable true Serial device emulated by the Foundation
Platform is a PL011
PL011 Clock Rate 0xE10000
PL011 FIFO size 64
PL011 UART1 Address 0x1C090000
PL011 UART2 Address 0x1C0A0000
PL011 UART3 Address 0x1C0B0000
PL011 UART4 Address 0x1C0C0000
PSCI Enable true PSCI is available and used for SMP and re-
boot/halt
PSCI method SMC SMC instruction needs to be used to use
PSCI
Table 3: Foundation ARMv8 PSP parameter
2.4.5 The PSSW Configuration
No driver is included in the PSSW for Foundation Platform ARMv8.
2.4.6 Running the Hello World Image
The UniversalisOS 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 Foundation Platform ARMv8 board. To load and run the pre-compiled "Hello World" image, start FVP with the following parameters:
sh# BOOTFILE=/opt/universalisos-D5.0/target/arm/v8hf/boot-images/ simple-universalisos-foundation-armv8-uboot_dtb_unc sh# [PATH_TO_FOUNDATION]/Foundation_Platform --cores=4 --visualization --gicv3 --rate-limit --use-real-time --network=bridged --network-bridge=tap0 --data=[FIRMWARE_DIR]/bl1.bin@0x0 --data=[FIRMWARE_DIR]/fip.bin@0x08000000 --data=$BOOTFILE@0x90080000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Foundation Platform ARMv8 21
Now you should see the following output generated by the "Hello World" image:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: universalisos@builder.portugalfuturista.org 280317-14:02 Kernel build: 4.2-1559, type: noassert tracesys smp standard ASP: "arm_v8hf" ARM v8, endian: little PSP build: 4.2-123 PSP: "Cortex A5x" Foundation ARMv8 (SMP-HWVIRT-USERPERF-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(1/64) 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: 100000 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Free memory: 2095608 KiB PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587 Found SMC91C11xFD NIC, chip revision 91! SMC91CX: mac address autodetected and assigned to dev 0: 00:02:f7:ef:de:98 SMC91CX: mac address assigned to virtual dev 1: 03:04:8f:00:0a:49 SMC91CX: mac address assigned to virtual dev 2: 03:04:8f:00:0a:50 SMC91CX: mac address assigned to virtual dev 3: 03:04:8f:00:0a:51 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.4.7 Limitations
See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.5 Juno A57
The Juno ARM development platform is a software platform provided by ARM. UniversalisOS supports the version R0, featuring a dual core A57 with a quad-core A53. The UniversalisOS board name for this board is juno-a57. For more information on the Juno Board, please check ARM website https://developer.arm.com/ products/system-design/development-boards/juno-development-board. Note: From the software point of view, this UniversalisOS BSP should run without problems on version R1 which only add a PCI Express but would probably work on the version R2 which has A72 cores instead of A57 .
2.5.1 The Board Configuration
UniversalisOS provides drivers and configuration for the following board resources:
• Serial controller (PL011), section 5.1.1, page 64
• Ethernet controller (SMC911X), section 5.2.2, page 73
Hardware virtualization is supported on the Juno Board and can be used using the board juno-a57-hwvirt if you have hardware virtualization support.
2.5.2 Compile a Firmware for the Juno Board
The Juno board provides by default an UEFI firmware to run with the Linaro Linux demonstrator. UEFI is not supported by UniversalisOS and U-Boot is required. To have access to the hardware virtualization feature, you will need to build your own firmware and use U-Boot with UniversalisOS on the Juno Board. For the ARMv8 family, ARM is developing and providing a generic firmware named ARM Trusted Firmware which can be found freely on Internet here: https://github.com/ARM-software/arm-trusted-firmware. It provides standard hardware initialization as long as a standardized PSCI interface used by Linux for example and supported by the BSP. Together with the ARM Trusted Firmware a bootloader like U-Boot can be used to provide a more flexible way to start the OS. As generating a working set can be quite complex, UniversalisOS provides a shell script that will automatically download both U-Boot and ARM Trusted Firmware and will compile them with the right configuration and parameters to generate something suitable to be used with this UniversalisOS BSP. A BL30 binary firmware blob is required on the Juno board to do some low level initialization specific to the board (mainly clocks and voltage). This is generated during the complete Android build from Linaro for the board or can be found in precompiled Linaro images:
• Download http://snapshots.linaro.org/member-builds/armlt-platforms-release/
latest/juno-latest-busybox-uboot.zip.
• Extract the zip file.
• in the SOFTWARE directory you will find a bl30.bin file.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Juno A57 23
To compile a Juno firmware, the following command must be executed:
sh# /opt/universalisos-D5.0/target/arm/v8hf/share/cortex-a5x/compile-a5x-firmware.sh --target=juno --dir=[FIRMWARE_DIR] --bl30=[PATH_TO_BL30]/bl30.bin
At the end of the compilation and download process, the files bl1.bin and fip.bin are generated in [FIRMWARE_DIR]/boot-binary directory. Note: Several tools like git are used during the process, in case of an error please inspect the file buildlogs.txt which will be generated.
2.5.3 Set-up the Juno Board
To configure your Juno board to use the firmware you generated from the previous chapter you must follow this procedure:
• Open a serial console: serial line default parameters are 115200 Bauds, 8n1.
• Start the board and hit Enter to stop the auto-boot.
• Enter the command usb_on on the prompt. This will allow the access to the internal MMC for the firmware through the USB debug cable.
• Connect your development host to the Juno board using the USB debug cable. A hard-drive should be detected by your host and will find at least a directory named SOFTWARE on it.
• At this point it is highly recommended to make a complete copy of the content to be able to restore the original firmware if needed. This can also be done by extracting the complete content of the Zip file used to find the BL30 in previous chapter if you want a newer version.
• Remove all bl*.bin and fip*.bin files from SOFTWARE directory and put the bl1.bin and fip.bin from previous chapter in the folder.
• Unmount the USB disk from your development host.
• Power-off and Reboot the Juno Board.
The boot from the Juno board should look like this:
UART0 set to SoC UART0 UART1 set to SoC UART1
NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.2(release):d0c104e NOTICE: BL1: Built : 09:53:19, Feb 11 2016 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.2(release):d0c104e NOTICE: BL2: Built : 09:53:20, Feb 11 2016 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.2(release):d0c104e NOTICE: BL31: Built : 09:53:24, Feb 11 2016
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
24 Boards
ERROR: Error initializing runtime service tspd_fast
U-Boot 2016.01-dirty (Feb 11 2016 - 09:53:01 +0100) vexpress_aemv8a
DRAM: 8 GiB PCIe XR3 Host Bridge enabled: x4 link (Gen 2) Flash: 64 MiB In: serial_pl01x Out: serial_pl01x Err: serial_pl01x Net: smc911x-0 Hit any key to stop autoboot: 0
Standard method to boot an image is to download it through network in U-Boot:
VExpress64# tftp 0x90080000 universalisos.img VExpress64# bootm 0x90080000
2.5.4 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The Juno A57 board is setting the PSP parameters listed in table 4.
Parameter Value Description
Board Name Juno A57/A53
PSP Console Port 1 Console on the first serial device
Memory size 0x80000000 2GB of RAM in main memory
GIC DIST Address 0x2C010000
GIC REDIST Address 0x00000000
GIC CPU Address 0x2C02F000
GIC CTRL Address 0x2C04f000
GIC VCPU Address 0x2C06f000
PL011 Enable true Serial device is a PL011
PL011 Clock Rate 7273800
PL011 FIFO size 32
PL011 UART1 Address 0x7FF80000
PSCI Enable true PSCI is available and used for SMP and re-
boot/halt
PSCI method SMC SMC instruction needs to be used to use
PSCI
Area0 Address 0x880000000 Second memory region address
Area0 Size 0x180000000 6GB on second memory region
Table 4: Foundation ARMv8 PSP parameter
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Juno A57 25
2.5.5 The PSSW Configuration
No driver is included in the PSSW for the Juno A57.
2.5.6 Running the Hello World Image
The UniversalisOS 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 Juno A57 board. The image is located in UniversalisOS installation:
/opt/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-juno-a57-uboot_dtb_unc
When the image is started you should see the following output:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: universalisos@builder.portugalfuturista.org 270317-09:39 Kernel build: 4.2-1558, type: noassert tracesys smp standard ASP: "arm_v8hf" ARM v8, endian: little PSP build: 4.2-123 PSP: "Cortex A5x" Juno Board A57/53 (SMP-HWVIRT-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(6/64) 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: 50000 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Free memory: 8369296 KiB PSSW +Ext. FPs +Messages (Production), Build: 4.2-3587 PL011: Provider "ser0" started, Build: 4.2-27 Production Hello World, starting up. Hello World, this is task 22, thread 0 eth0: device ready to use.. eth0: Registered MAC address(02:70:34:00:64:17) for channel ’3’ eth0: Registered MAC address(06:70:34:00:64:17) for channel ’2’ eth0: Registered MAC address(0a:70:34:00:64:17) for channel ’1’ eth0: Registered MAC address(0e:70:34:00:64:17) for channel ’0’ smc911x: Provider "eth0" started, Build: 4.2-32 Production Hello World, this is task 22, thread 0 Hello World, this is task 22, thread 0 ...
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
26 Boards
2.5.7 Limitations
See section 3.5, page 48 for the PSP limitations.
2.5.7.1 Juno A57 revision r0 only usable on one cluster
UniversalisOS can be used on the Juno board revison r0, but due to a coherency issue between A57 and A53 clusters, the maximum number of CPUs must be configured to 4 in order to only use the cores of the A53 cluster. This workaround can be done in UniversalisOS Kernel configuration: Enable Limits configuration and set the Maximum number of CPUs with value 4.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.6 QorIQ LS1043A Reference Design Board
The QorIQ LS1043A Reference Design Board is designed to exercise most capabilities of the LS1043A device; NXP’s first quad-core, 64-bit ARM-based processor for embedded networking and industrial infrastructure. The UniversalisOS board name for this board is ls1043a-rdb. For more information on this board, please check NXP website http://www.nxp.com/ products/microcontrollers-and-processors/arm-processors/qoriq-arm-processors/ qoriq-ls1043a-reference-design-board:LS1043A-RDB.
2.6.1 The Board Configuration
UniversalisOS provides drivers and configuration for the board resources listed in table 5.
• Serial controller (NS16550), section 5.2.1, page 71
• PCI controllers, section 3.5.11.2, page 59
• Ethernet controller (dpaa), section 5.2.5, page 81, IO_ID selects the ethernet interface:
IO_ID Value Ethernet Interface RJ45 Connector 0 RGMII 1 P1A Lower Port (P1 Down) 1 RGMII 2 P1B Upper Port (P1 Up) 2 QSGMII p0 P3A Lower Port (P3 Down) 3 QSGMII p1 P3B Upper Port (P3 Up) 4 QSGMII p2 P2A Lower Port (P2 Down) 5 QSGMII p3 P2B Upper Port (P2 Up) 6 TGEC not supported
Table 5: QorIQ LS1043A Reference Design Boardconfiguration
2.6.2 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The QorIQ LS1043A Reference Design Board is setting the PSP parameters listed in table 6.
Parameter Value Description Board Name QorIQ LS1043A RDB PSP Console Port 1 Console on first serial PSP Debug Port 0 No port configured for debug Memory size 0x80000000 2GB of RAM in main memory GIC DIST Address 0x01401000 GIC REDIST Address 0x00000000 GIC CPU Address 0x01402000 GIC CTRL Address 0x01404000 GIC VCPU Address 0x01406000 NS16550 Enable true Serial device is a NS16550 NS16550 Clock Rate 100000000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
28 Boards
Parameter Value Description NS16550 Sampling Rate 4 NS16550 UART1 Address 0x021C0500 NS16550 UART2 Address 0x021D0500 RESERVED_AREA0_ADDR 0xFBE00000 ARM Trusted Firmware Area Address RESERVED_AREA0_SIZE 0x04200000 ARM Trusted Firmware Area Size PSCI Enable true PSCI is available and used for SMP and re- boot/halt PSCI method SMC SMC instruction needs to be used to use PSCI
Table 6: QorIQ LS1043A Reference Design BoardPSP parameter
2.6.3 The PSSW Configuration
No driver is included in the PSSW for QorIQ LS1043A Reference Design Board.
2.6.4 PCI support
PCI support is provided for LS1043A-rdb board via the PCI Layerscape driver, see section 3.5.11.2, page 59 for general configuration information.
2.6.4.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 LS1043A-rdb board 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 LS1043A-rdb board shows controllers 2 and 3 enabled, with controller 3 having a network card attached:
[...] PCIe1: disabled PCIe2: Root Complex no link, regs @ 0x3500000 PCIe3: Root Complex x1 gen1, regs @ 0x3600000 PCI: 01:00.0 - 10ec:8168 - Network controller PCIe3: Bus 00 - 01 [...]
The controllers in the PSP’s configuration are using the same numbering as in u-boot and the SoC Reference Manual. Thus, if you need to use the controller labeled ”PCIe3” in u-boot, you should refer to the ”Controller 3 configuration” section of the PSP component.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
QorIQ LS1043A Reference Design Board 29
2.6.4.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.
2.6.5 MSI support
MSI support is provided via the MSI Layerscape driver. For more information, on the configuration and usage, please refer to section 3.5.12.1, page 60.
2.6.6 Running the Hello World Image
The UniversalisOS 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 QorIQ LS1043A Reference Design Board board. The image is located in UniversalisOS installation:
/opt/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-ls1043a-rdb-uboot_dtb_unc
When the image is started you should see the following output:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: D5.0-testversion Kernel build: D5.0-3307, type: noassert tracesys smp standard [gcc] ASP: "arm_v8hf" ARM v8, endian: little PSP build: D5.0-testversion PSP: "ls1043a" QorIQ LS1043A Reference Design Board (SMP-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(4/64) Configuration limits: respart: 255 task: 255 thread: 4095 timepart: 255 priority: 256 kprio: 32 interrupts: 1024 TP windows: 256 thr sstack: 8192 B LS1046 CLK: message: Initialize provider... LS1046 CLK: message: scfg_virt_base @ 0xffffffffc0770000 LS1046 CLK: message: dcfg_virt_base @ 0xffffffffc04e0000 LS1046 CLK: message: clk_virt_base @ 0xffffffffc04e1000 LS1046 CLK: message: Initialization done. UniversalisOS PCI Manager KDEV, Build: D5.0-255 PCIMGR: message: PSP returned empty PCI device list LS1046 CLK: message: Initialize partition 0... LS1046 CLK: message: Initialize partition 1... LS1046 CLK: message: Initialize partition 2... LS1046 CLK: message: Gate 0x18... LS1046 CLK: message: HL @ 0xffffff800065af40... ...
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
30 Boards
LS1046 CLK: info: Clock 0x0000000000000015 type: 2 LS1046 CLK: info: Clock 0x0000000000000015 name: usb_phy_3 (9) CPU#1: Cortex A53 r0p4 CPU#2: Cortex A53 r0p4 CPU#3: Cortex A53 r0p4 LS1046 CLK: message: 30 clock(s) available LS1046 CLK: message: int 4 unsigned 4 long 8 unsigned long 8 long long 8 P4_address_t 8 Clock memory map: Core cluster n clock control/status (CLKCCSR) : 0x00000000 ... DDR PLL general status (PLLDGSR) : 0x00080020 SCFG memory map: USB1 Parameter 1 Control (SCFG_USB1PRM1CR) : 0x24672a6a ... Core Boot Control (SCFG_COREBCR) : 0xfffffff0 DCFG CCSR memory map: POR status 1 (PORSR1) : 0x12ff7fff ... Boot Release (BRR) : 0x0000000e Reset Control Word Status 0 (RCWSR0) : 0x08100010 ... Reset Control Word Status 15 (RCWSR15) : 0x00000001
strict digraph "LS1046 clock tree" { "osc Rate: 100000000Hz "; ... "platform_pll_half Rate: 200000000Hz "; }
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< [LS1046 clock] "diff_sysclk": parent: "osc" (IDs: 2/2) [LS1046 clock] "diff_sysclk_b": parent: "osc" (IDs: 2/2) [LS1046 clock] "sys_ref_clk": parent: "diff_sysclk" (IDs: 4/4) [LS1046 clock] "platform_pll": parent: "sys_ref_clk" (IDs: 12/12) [LS1046 clock] "cga_pll1": parent: "sys_ref_clk" (IDs: 12/12) [LS1046 clock] "cga_pll2": parent: "sys_ref_clk" (IDs: 12/12) [LS1046 clock] "cga_pll1_ctrl": parent: "cga_pll1" (IDs: 14/14) [LS1046 clock] "cga_pll2_ctrl": parent: "cga_pll2" (IDs: 15/15) [LS1046 clock] "cga_pll_mux": parent: "cga_pll1_ctrl" (IDs: 16/16) [LS1046 clock] "usb_phy_1": parent: "diff_sysclk" (IDs: 4/3) [LS1046 clock] "usb_phy_2": parent: "diff_sysclk" (IDs: 4/3) [LS1046 clock] "usb_phy_3": parent: "diff_sysclk" (IDs: 4/3) [LS1046 clock] "ddr_mux": parent: "diff_sysclk" (IDs: 4/11) [LS1046 clock] "ddr_pll": parent: "ddr_mux" (IDs: 22/22) [LS1046 clock] "cga_hwa_m1": parent: "cga_pll1_ctrl" (IDs: 16/16) [LS1046 clock] "cga_hwa_m2": parent: "cga_pll2_ctrl" (IDs: 17/17) [LS1046 clock] "qspi_div": parent: "cga_hwa_m2" (IDs: 25/25)
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
QorIQ LS1043A Reference Design Board 31
[LS1046 clock] "qspi_mux": parent: "qspi_div" (IDs: 26/26) [LS1046 clock] "qspi_ctrl": parent: "qspi_mux" (IDs: 27/27) [LS1046 clock] "platform_pll_half": parent: "platform_pll" (IDs: 13/13) Resource partition 0 kernel memory refill strategy: dynamic (on demand) Time stamp counter clock: 25000 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Time partition synchronization: default PSP startmode: 0 PSP haltmode: 0 Free memory: 2017812 KiB PSSW +Ext. FPs +VirtSplit +Messages (Production), Build: D5.0-1684 8250: Provider "ser0" started, Build: D5.0-testversion Production eth0: Using genericphy for PHY addr 1, bus 0 eth0: Using genericphy for PHY addr 2, bus 0 eth0: Using genericphy for PHY addr 4, bus 0 eth0: Using genericphy for PHY addr 0, bus 2 eth0: Using genericphy for PHY addr 5, bus 0 eth0: Using genericphy for PHY addr 1, bus 2 eth0: Using genericphy for PHY addr 6, bus 0 eth0: Using genericphy for PHY addr 2, bus 2 eth0: Using genericphy for PHY addr 7, bus 0 eth0: Using genericphy for PHY addr 3, bus 2 dpaa: Provider "eth0" started, Build: D5.0-70 Production Hello World, starting up. Hello World, this is task 22, thread 0 ...
2.6.7 Using U-Boot from NXP SDK
This BSP has been validated with the U-Boot from the NXP Linux SDK for QorIQ Processors V2.0 patch 1703. It is recommended that the user update its deployed firmwares. Information on how to rebuild U-Boot can be found in QORIQ-SDK-2.0-IC-REV0.pdf, section 4.4.7.8. It is advised to use one of the two NOR bank, by default the switches of the board being configured to use NOR bank0.
2.6.8 Limitations
See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.7 QorIQ LS1046A Reference Design Board
The QorIQ LS1046A Reference Design Board is a evaluation and development platform that supports the QorIQ LS1046A LayerScape Architecture processor. The UniversalisOS board name for this board is ls1046a-rdb. For more information on this board, please check NXP website https://www.nxp.com/support/ developer-resources/software-development-tools/qoriq-developer-resources/ qoriq-ls1046a-reference-design-board:LS1046A-RDB.
2.7.1 The Board Configuration
UniversalisOS provides drivers and configuration for the board resources listed in table 7.
• Serial controller (NS16550), section 5.2.1, page 71
• PCI controllers, section 3.5.11.2, page 59
• Ethernet controller (dpaa), section 5.2.5, page 81, IO_ID selects the ethernet interface:
IO_ID Value Ethernet Interface RJ45 Connector 0 RGMII 1 P2A Lower Port 1 RGMII 2 P2B Upper Port 2 SGMII 1 P1A Lower Port 3 SGMII 2 P1B Upper Port
Table 7: QorIQ LS1046A Reference Design Boardconfiguration
2.7.2 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The QorIQ LS1046A Reference Design Board is setting the PSP parameters listed in table 8.
Parameter Value Description Board Name QorIQ LS1046A RDB PSP Console Port 1 Console on first serial PSP Debug Port 0 No port configured for debug Memory size 0x80000000 8GB of RAM in main memory GIC DIST Address 0x01410000 GIC REDIST Address 0x00000000 GIC CPU Address 0x0142F000 GIC CTRL Address 0x01440000 GIC VCPU Address 0x0146F000 NS16550 Enable true Serial device is a NS16550 NS16550 Clock Rate 350000000 NS16550 Sampling Rate 16 NS16550 UART1 Address 0x021C0500 NS16550 UART2 Address 0x021C0600
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
QorIQ LS1046A Reference Design Board 33
Parameter Value Description RESERVED_AREA0_ADDR 0xFBE00000 ARM Trusted Firmware Area Address RESERVED_AREA0_SIZE 0x04200000 ARM Trusted Firmware Area Size PSCI Enable true PSCI is available and used for SMP and re- boot/halt PSCI method SMC SMC instruction needs to be used to use PSCI
Table 8: QorIQ LS1046A Reference Design BoardPSP parameter
2.7.3 The PSSW Configuration
No driver is included in the PSSW for QorIQ LS1046A Reference Design Board.
2.7.4 PCI support
PCI support is provided for LS1046A-rdb board via the PCI Layerscape driver, see section 3.5.11.2, page 59 for general configuration information.
2.7.4.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 LS1046A-rdb board 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 LS1046A-rdb board shows controllers 2 and 3 enabled, with controller 3 having a network card attached:
[...] PCIe1: disabled PCIe2: Root Complex no link, regs @ 0x3500000 PCIe3: Root Complex x1 gen1, regs @ 0x3600000 PCI: 01:00.0 - 10ec:8168 - Network controller PCIe3: Bus 00 - 01 [...]
The controllers in the PSP’s configuration are using the same numbering as in u-boot and the SoC Reference Manual. Thus, if you need to use the controller labeled ”PCIe3” in u-boot, you should refer to the ”Controller 3 configuration” section of the PSP component.
2.7.4.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 Portugal Futurista GmbH, all rights reserved.
34 Boards
2.7.5 MSI support
MSI support is provided via the MSI Layerscape driver. For more information, on the configuration and usage, please refer to section 3.5.12.1, page 60.
2.7.6 Running the Hello World Image
The UniversalisOS 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 QorIQ LS1046A Reference Design Board board. The image is located in UniversalisOS installation:
/opt/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-ls1046a-rdb-uboot_dtb_unc
When the image is started you could see the following output:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: D5.0-testversion Kernel build: D5.0-3307, type: noassert tracesys smp standard [gcc] ASP: "arm_v8hf" ARM v8, endian: little PSP build: D5.0-testversion PSP: "ls1046a" QorIQ LS1046A Reference Design Board (SMP-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(4/64) Configuration limits: respart: 255 task: 255 thread: 4095 timepart: 255 priority: 256 kprio: 32 interrupts: 1024 TP windows: 256 thr sstack: 8192 B LS1046 CLK: message: Initialize provider... LS1046 CLK: message: scfg_virt_base @ 0xffffffffc0770000 LS1046 CLK: message: dcfg_virt_base @ 0xffffffffc04e0000 LS1046 CLK: message: clk_virt_base @ 0xffffffffc04e1000 LS1046 CLK: message: Initialization done. UniversalisOS PCI Manager KDEV, Build: D5.0-255 PCIMGR: message: PSP returned empty PCI device list LS1046 CLK: message: Initialize partition 0... LS1046 CLK: message: Initialize partition 1... LS1046 CLK: message: Initialize partition 2... LS1046 CLK: message: Gate 0x18... LS1046 CLK: message: HL @ 0xffffff8000655f40... LS1046 CLK: info: LS1046 clock allocated at 0xffffff8000686e00 LS1046 CLK: message: Gate 0x19... ... LS1046 CLK: info: NULL clock located at 0xffffff8000bd8600 LS1046 CLK: info: Clock 0x0000000000000015 type: 2 LS1046 CLK: info: Clock 0x0000000000000015 name: usb_phy_3 (9) CPU#1: Cortex A72 r0p2
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
QorIQ LS1046A Reference Design Board 35
CPU#2: Cortex A72 r0p2 CPU#3: Cortex A72 r0p2 LS1046 CLK: message: 30 clock(s) available LS1046 CLK: message: int 4 unsigned 4 long 8 unsigned long 8 long long 8 P4_address_t 8 Clock memory map: Core cluster n clock control/status (CLKCCSR) : 0x00000000 ... DDR PLL general status (PLLDGSR) : 0x0008002a SCFG memory map: USB1 Parameter 1 Control (SCFG_USB1PRM1CR) : 0x24672a6a ... SCRATCHRW - Scratch Read Write Registers (SCFG_SCRATCHRW) : 0x00000000 Core Boot Control (SCFG_COREBCR) : 0xfffffff0 DCFG CCSR memory map: POR status 1 (PORSR1) : 0x007f7fff ... Boot Release (BRR) : 0x0000000e Reset Control Word Status 0 (RCWSR0) : 0x0e150012 ... Reset Control Word Status 15 (RCWSR15) : 0x00000001
strict digraph "LS1046 clock tree" { "osc Rate: 100000000Hz "; "sysclk ... "platform_pll_half Rate: 350000000Hz "; }
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< [LS1046 clock] "diff_sysclk": parent: "osc" (IDs: 2/2) [LS1046 clock] "diff_sysclk_b": parent: "osc" (IDs: 2/2) [LS1046 clock] "sys_ref_clk": parent: "diff_sysclk" (IDs: 4/4) [LS1046 clock] "platform_pll": parent: "sys_ref_clk" (IDs: 12/12) [LS1046 clock] "cga_pll1": parent: "sys_ref_clk" (IDs: 12/12) [LS1046 clock] "cga_pll2": parent: "sys_ref_clk" (IDs: 12/12) [LS1046 clock] "cga_pll1_ctrl": parent: "cga_pll1" (IDs: 14/14) [LS1046 clock] "cga_pll2_ctrl": parent: "cga_pll2" (IDs: 15/15) [LS1046 clock] "cga_pll_mux": parent: "cga_pll1_ctrl" (IDs: 16/16) [LS1046 clock] "usb_phy_1": parent: "diff_sysclk" (IDs: 4/3) [LS1046 clock] "usb_phy_2": parent: "diff_sysclk" (IDs: 4/3) [LS1046 clock] "usb_phy_3": parent: "diff_sysclk" (IDs: 4/3) [LS1046 clock] "ddr_mux": parent: "diff_sysclk" (IDs: 4/11) [LS1046 clock] "ddr_pll": parent: "ddr_mux" (IDs: 22/22) [LS1046 clock] "cga_hwa_m1": parent: "cga_pll1_ctrl" (IDs: 16/16) [LS1046 clock] "cga_hwa_m2": parent: "cga_pll2_ctrl" (IDs: 17/17) [LS1046 clock] "qspi_div": parent: "cga_hwa_m2" (IDs: 25/25) [LS1046 clock] "qspi_mux": parent: "qspi_div" (IDs: 26/26)
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
36 Boards
[LS1046 clock] "qspi_ctrl": parent: "qspi_mux" (IDs: 27/27) [LS1046 clock] "platform_pll_half": parent: "platform_pll" (IDs: 13/13) Resource partition 0 kernel memory refill strategy: dynamic (on demand) Time stamp counter clock: 25000 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Time partition synchronization: default PSP startmode: 0 PSP haltmode: 0 Free memory: 8307240 KiB PSSW +Ext. FPs +VirtSplit +Messages (Production), Build: D5.0-1684 8250: Provider "ser0" started, Build: D5.0-testversion Production eth0: Using genericphy for PHY addr 1, bus 0 eth0: Using genericphy for PHY addr 2, bus 0 eth0: Using genericphy for PHY addr 3, bus 0 eth0: Using genericphy for PHY addr 0, bus 2 eth0: Using genericphy for PHY addr 4, bus 0 eth0: Using genericphy for PHY addr 0, bus 3 dpaa: Provider "eth0" started, Build: D5.0-70 Production Hello World, starting up. Hello World, this is task 22, thread 0 Hello World, this is task 22, thread 0 ...
2.7.7 Using U-Boot from NXP SDK
This BSP has been validated with the U-Boot from the NXP Linux SDK for QorIQ Processors V2.0 patch 1703. It is recommended that the user update its deployed firmwares. Information on how to rebuild U-Boot can be found in QORIQ-SDK-2.0-IC-REV0.pdf, section 4.4.7.8. It is advised to use one of the two NOR bank, by default the switches of the board being configured to use NOR bank0.
2.7.8 Limitations
See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.8 Xilinx Zynq ZCU102
The Zynq ZCU102 development platform is a software platform provided by Xilinx. UniversalisOS supports the version R C.2, featuring a quad-core A53. The UniversalisOS board name for this board is zynq-zcu102. For more information on the Zynq ZCU102, please check Xilinx website http://www.xilinx.com/ products/silicon-devices/soc/zynq-ultrascale-mpsoc.html.
2.8.1 The Board Configuration
UniversalisOS provides drivers and configuration for the following board resources:
• Serial controller (CADENCE UART), section 3.5.9.3, page 55
• Ethernet controller (CADENCE GEM), section 5.2.3, page 75
The drivers for the following resources are available on demand:
• QSPI controller
• CAN controller
Hardware virtualization is supported on the Zynq ZCU102 and can be used using the board zynq-zcu102 if you have hardware virtualization support. The boot from the Zynq ZCU102 board should look like this:
Xilinx Zynq MP First Stage Boot Loader Release 2016.1 Nov 5 2015 - 11:58:53 Platform: Silicon, Running on A53-0 (64-bit) Processor SD1 Boot Mode Bitstream download to start now DMA transfer done PL Configuration done successfully pl_reset Bring PL OUT OF RESET EMIO usb_ulpi_reset deassert USB ULPI reset
Setting IO Exander to De-assert Mux Reset/ GEM3 Resetn/ Selecting DP as GT0-1 Initializing SERDES
ATF running on silicon/RTL5.1 at 0xfffe4000 NOTICE: BL3-1: Secure code at 0xfffc0000 NOTICE: BL3-1: Non secure code at 0x8000000 NOTICE: BL3-1: v1.1(release): NOTICE: BL3-1: Built : 19:25:41, Oct 29 2015 ERROR: Error initializing runtime service sip_svc
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
38 Boards
U-Boot 2015.07 (Nov 06 2015 - 18:58:30 -0500) Xilinx ZynqMP ZCU102
I2C: ready DRAM: 2 GiB Enabling Caches... EL Level: EL2 MMC: zynq_sdhci: 0 Using default environment
In: serial Out: serial Err: serial Bootmode: SD_MODE1 SCSI: AHCI 0001.0301 32 slots 2 ports 6 Gbps 0x0 impl SATA mode flags: 64bit ncq pm clo only pmp fbss pio slum part ccc apst scanning bus for devices... Found 0 device(s). Net: Gem.ff0e0000 Hit any key to stop autoboot: 0 ZynqMP>
Standard method to boot an image is to download it through network in U-Boot:
ZynqMP> setenv ipaddr 192.168.0.10 ZynqMP> setenv serverip 172.24.16.20 ZynqMP> tftpboot 0x40080000 universalisos.img ZynqMP> bootm 0x40080000
2.8.2 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The zynq-zcu102 board is setting the PSP parameters listed in table 9.
Parameter Value Description
Board Name Xilinx Zynq ZCU102
(Ultrascale A53)
PSP Console Port 1 Console on the first serial device
PSP Debug Port 0 Debug port disabled
Memory size 0x80000000 2GB of RAM in main memory
GIC DIST Address 0xf9010000
GIC REDIST Address 0x00000000
GIC CPU Address 0xf902f000
GIC CTRL Address 0xf9040000
GIC VCPU Address 0xf906f000
CADENCE Enable true Serial device is a CADENCE
CADENCE Clock Rate 100000000
CADENCE UART1 Address 0xff000000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Xilinx Zynq ZCU102 39
Parameter Value Description CADENCE UART2 Address 0xff010000 PSCI Enable true PSCI is available and used for SMP and re- boot/halt PSCI method SMC SMC instruction needs to be used to use PSCI
Table 9: Xilinx Zynq ZCU102 PSP parameter
2.8.3 The PSSW Configuration
No driver is included in the PSSW for the Xilinx Zynq ZCU102.
2.8.4 Running the Hello World Image
The UniversalisOS 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 Xilinx Zynq ZCU102 board. The image is located in UniversalisOS installation:
/opt/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-zynq-zcu-uboot_unc
When the image is started you should see the following output:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: devel-universalisos@builder.portugalfuturista.org-250317-00:01 Kernel build: 4.2-1558, type: noassert tracesys smp standard ASP: "arm_v8hf" ARM v8, endian: little PSP build: 4.2-123 PSP: "Cortex A5x" Xilinx Zynq ZCU102 (Ultrascale A53) (SMP-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(4/64) Configuration limits: respart: 63 task: 256 thread: 511 timepart: 63 priority: 256 interrupts: 1024 TP windows: 256 thr sstack: 4096 B PMUFW: PmRequestWakeup: (NODE_APU_1, REQUEST_ACK_BLOCKING) PMUFW: PmProcTrSleepToActive: SLEEP->ACTIVE NODE_APU_1 PMUFW: PmRequestWakeup: (NODE_APU_2, REQUEST_ACK_BLOCKING) PMUFW: PmProcTrSleepToActive: SLEEP->ACTIVE NODE_APU_2 PMUFW: PmRequestWakeup: (NODE_APU_3, REQUEST_ACK_BLOCKING) PMUFW: PmProcTrSleepToActive: SLEEP->ACTIVE NODE_APU_3 Regy: dynamic (on demand) Time stamp counter clock: 33000 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
40 Boards
Free memory: 2094728 KiB PSSW +Ext. FPs +Messages (Production), 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 ...
2.8.5 Limitations
U-boot: It is not possible to use UNIVERSALISOS if u-boot is executed in EL3. Indeed, u-boot executing in EL3 means that the ARM Trusted Firmware is not part of the boot stages and thus that the PSCI initialization didn’t took place. The PSCI initialization being mandatory to execute UNIVERSALISOS. See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
2.9 Renesas R-Car H/M 3
The Renesas R-Car H/M 3 is a Systems-on-a-Chip (SoC) introduced by Renesas and base on four Cortex-A57 cores and four Cortex-A53 cores.
2.9.1 The Board Configuration
UniversalisOS provides drivers and configuration for the following board resources:
• Serial controller (SCIF), section 5.1.2, page 65
• Ethernet controller (RAVB), section 5.2.6, page 84
The default baud rate for the serial driver (SCIF) ports is 115200 Bd. Hardware virtualization is supported on the Renesas R-CarH3 and can be used using the board component renesas-salvator-x-hwvirt if you have hardware virtualization support. The boot from the Renesas R-Car H/M 3 board should look like this:
NOTICE: gicd_write_igroupr n:1 val:4294967295 NOTICE: gicd_write_igroupr n:2 val:4294967295 NOTICE: gicd_write_igroupr n:3 val:4294967295 NOTICE: gicd_write_igroupr n:4 val:4294967295 NOTICE: gicd_write_igroupr n:5 val:4294967295 NOTICE: gicd_write_igroupr n:6 val:4294967295 NOTICE: gicd_write_igroupr n:7 val:4294967295 NOTICE: gicd_write_igroupr n:8 val:4294967295 NOTICE: gicd_write_igroupr n:9 val:4294967295 NOTICE: gicd_write_igroupr n:10 val:4294967295 NOTICE: gicd_write_igroupr n:11 val:4294967295 NOTICE: gicd_write_igroupr n:12 val:4294967295 NOTICE: gicd_write_igroupr n:13 val:4294967295 NOTICE: gicd_write_igroupr n:14 val:4294967295 NOTICE: gicd_write_igroupr n:15 val:4294967295 NOTICE: gicd_write_igroupr n:5 val:4294959103 NOTICE: gicd_write_igroupr n:0 val:4294967295 NOTICE: BL2: R-Car Gen3 Initial Program Loader(CA57) Rev.1.0.9 NOTICE: BL2: PRR is R-Car H3 ES1.1 NOTICE: BL2: Boot device is HyperFlash(80MHz) NOTICE: BL2: LCM state is CM NOTICE: BL2: BL33 EXECUTION LVL is 1 NOTICE: BL2: AVS setting succeeded. DVFS_SetVID=0x52 NOTICE: BL2: DDR2400(rev.0.15) NOTICE: BL2: DRAM Split is 4ch NOTICE: BL2: QoS is default setting(rev.0.32) NOTICE: BL2: Lossy Decomp areas NOTICE: Entry 0: DCMPAREACRAx:0x80000540 DCMPAREACRBx:0x570 NOTICE: Entry 1: DCMPAREACRAx:0x40000000 DCMPAREACRBx:0x0
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
42 Boards
NOTICE: Entry 2: DCMPAREACRAx:0x20000000 DCMPAREACRBx:0x0 NOTICE: BL2: v1.1(release):3ad02ac NOTICE: BL2: Built : 10:28:23, Feb 1 2017 NOTICE: BL2: Normal boot NOTICE: BL2: dst=0xe631a208 src=0x8180000 len=512(0x200) NOTICE: BL2: dst=0x43f00000 src=0x8180400 len=6144(0x1800) NOTICE: BL2: dst=0x44000000 src=0x81c0000 len=65536(0x10000) NOTICE: BL2: dst=0x44100000 src=0x8200000 len=524288(0x80000) NOTICE: BL2: dst=0x49000000 src=0x8640000 len=1048576(0x100000)
U-Boot 2015.04 (Dec 02 2016 - 15:24:08)
CPU: Renesas Electronics R8A7795 rev 1.1 Board: Salvator-X I2C: ready DRAM: 3.9 GiB MMC: sh-sdhi: 0, sh-sdhi: 1, sh-sdhi: 2 In: serial Out: serial Err: serial Net: ravb start dma transfer Hit any key to stop autoboot: =>
Standard method to boot an image is to download it through network in U-Boot:
=> setenv ipaddr 192.168.0.1; setenv serverip 192.168.0.2 => tftp 0x48080000 r-car-h3/rcarh3.img => go 0x48080000
2.9.2 The PSP Configuration
For the PSP configuration options see section 3.5, page 48. The Renesas R-Car H/M 3 board is setting the PSP parameters listed in table 10.
Parameter Value Description
Board Name Renesas R-Car H3
(Salvator-x)
PSP Console Port UART3 Console on the third serial device
PSP Debug Port 0 Debug port disabled
Memory size 0x38000000
GIC DIST Address 0xf1010000
GIC REDIST Address 0x00000000
GIC CPU Address 0xf102f000
GIC CTRL Address 0xf1040000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Renesas R-Car H/M 3 43
Parameter Value Description GIC VCPU Address 0xf1060000 SCIF Enable true Serial device is a SCIF SCIF Clock Rate 0x3F940A0 SCIF UART1 Address 0xe6e60000 SCIF UART2 Address 0xe6e68000 SCIF UART3 Address 0xe6e88000 SCIF UART4 Address 0xe6c50000 PSCI Enable true PSCI is available and used for SMP and re- boot/halt PSCI method SMC SMC instruction needs to be used to use PSCI
Table 10: Renesas R-Car H/M 3 PSP parameter
2.9.3 The PSSW Configuration
No driver is included in the PSSW for the Renesas R-Car H/M 3.
2.9.4 Running the Hello World Image
The UniversalisOS 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 Renesas R-Car H/M 3 board. The image is located in UniversalisOS installation:
/opt/universalisos-D5.0/target/arm/v8hf/boot-images/simple-universalisos-renesas-salvator-x-uboot_unc
When the image is started you should see the following output:
UniversalisOS (C) Copyright Portugal Futurista, Germany ROM image build: devel-bre@bre-050417-12:24 Kernel build: 4.2-1564, type: noassert tracesys smp standard ASP: "arm_v8hf" ARM v8, endian: little PSP build: 4.2-126 PSP: "Cortex A5x" Renesas Salvator X (SMP-USERDEBUG) Features: RETAIL TRACER-SYSCALL OPT SMP(4/64) 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: 8333 kHz, user accessible System ticker: dynamic mode, resolution 10000 ns
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
44 Boards
Time partition switch: 10000000 ns, watchdog timeout: 10000000 ns Free memory: 3995280 KiB PSSW +Ext. FPs +Messages (Production), Build: 4.2-3589 eth0: Registered MAC address(02:70:34:00:a3:84) for channel ’3’ eth0: Registered MAC address(06:70:34:00:a3:84) for channel ’2’ eth0: Registered MAC address(0a:70:34:00:a3:84) for channel ’1’ eth0: Registered MAC address(0e:70:34:00:a3:84) for channel ’0’ RAVB: Provider "eth0" started, Build: 4.2-22 Production SCIF: Provider "ser0" started, Build: 4.2-55 Production Hello World, starting up. Hello World, this is task 22, thread 0 Hello World, this is task 22, thread 0 ...
2.9.5 Enable Hardware Virtualization support in Firmware
The Firmware based on Arm Trusted Firmware and U-Boot provided by default with the board or compiled using Yocto will start UniversalisOS in EL1 processor mode which does not allow usage of the hardware virtualization. To compile a Firmware with hardware virtualization, you must follow the procedure provided by Renesas to compile a Yocto kernel and firmware and add the following line in the Trusted Firmware recipe located in meta- renesas/meta-rcar-gen3/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_git.bb:
ATFW_OPT_append = " RCAR_BL33_EXECUTION_EL=1"
You can then run or re-run the compilation with bitbake.
2.9.6 Limitations
See section 3.5, page 48 for the PSP limitations.
c Copyright 2005 – 2019 Portugal Futurista 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 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 kernel 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 11 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 11: 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 12 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 Portugal Futurista GmbH, all rights reserved.
46 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 12: 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 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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Interrupts on ARM 47
• 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 UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
3.5 PSP Cortex-A5x
The Cortex A5x PSP has been designed to support most of the A35, A53, A57 and A72 based boards using more configuration parameters than other UniversalisOS PSPs. The default value of the psp/memory/size property is 1 GiB. This PSP contains several drivers and features which can be configured using properties and parameters in the configuration component in order to help supporting new boards without code modification.
3.5.1 PSP Design
The Cortex A5x has some specific design feature in comparison to other standard UniversalisOS PSPs which are explained here. The main idea is to allow more configuration to have the same binary PSP running on a large amount of boards without the need to recompile it. This is possible on ARMv8 and Cortex A35, A53, A57 and A72 based boards due to hardware features allowing dynamic detection of the used platform during startup.
3.5.1.1 Mapping and Memory Detection
Most UniversalisOS PSPs are based on a static MMU page table in the PSP that is used on startup. The Cortex A5x is detecting its physical memory address on startup and it is creating its own page tables during startup, including the PSP drivers. This allows the PSP to be used over different boards even if they have different mappings (for both memory and peripherals) and to have a more configurable PSP without the need to recompile it to change a physical address. This is achieved by additional configurable parameters that allow e.g. the physical addresses of used devices to be changed (like serial device registers or additional RAM segments).
3.5.1.2 Multi Drivers
Several serial drivers are included in the PSP. The driver used is actually depending on some configuration parameters that are retrieved by the PSP from the property file system during startup. This is also the case for the secondary core detection and startup, which can be done by different drivers depending on configuration.
3.5.2 The PSP Main Configuration
The PSP and kernel properties can be set within the UniversalisOS project through the project editor. The PSP specific properties are defined in this chapter. The common PSP properties are defined in section 3.2, page 45.
3.5.2.1 Board Settings
The parameter Board Name allows you to give a name to the board that will be printed together with kernel information during boot time. You can use this parameter to distinguish boards you would create using different parameter-value combination and be able to see it during boot.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 49
This parameter is setting a property retrieved by the PSP on startup:
<prop_dir name="board/config"> <prop_bool name="name" data="My Board"/> </prop_dir>
3.5.2.2 PSP Parameters
The PSP component of the board features the following configurable parameters:
• PSP Console Port: Port that will be used as PSP and kernel console. This parameter will set the psp/console/port property.
• PSP Debug Port: Port to be used for debugging. This parameter will set the psp/debug/port property.
• Console Baudrate: Speed of the serial line. This parameter will set the psp/console/baudrate property.
• Allow console input: Allow console input, this is needed if you want to use the stdcon driver for reading input from console. This parameter will set the psp/console/input property.
• Memory size: This is the memory size available contiguously from the kernel start address. On many ARMv8 boards you will have several regions of memory which are not contiguous (usually one below 4GB and the other above 4GB address). This size must be the size available on the segment on which the kernel is started. You can define other segments using the Extra Memory Regions. This parameter will set the psp/memory/size property.
Note: On most ARM A5X boards, the ARM trusted firmware is used. This firmware reserves some memory for its own use and flags it as Secure Memory making it impossible to access from UniversalisOS. When this is the case, PSP_MEMSIZE must be set correctly to remove this memory from UniversalisOS. Most of the time this means removing the last 2 MiB of memory by setting PSP_MEMSIZE to 0x7fe00000 instead of 0x80000000. Alternatively, define a reserved memory area (see section 3.5.4, page 51) in order to maximize TLB coverage if adding the reserved part would form a larger mapping size. The LS1046A-RDB is such an example.
3.5.2.3 Accessing Performance Counters from User Applications
The ARMv8 platform provides performance counters that can be used from user applications to get access to a high resolution counter (up to the CPU cycle resolution) in order to perform benchmarking or profiling. For security reasons, those counters are by default not accessible from user mode. To enable access to them 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 code gives an example that you can copy to use the performance counters.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
50 PSPs
static inline unsigned long get_cyclecount (void) { unsigned long value; // Read CCNT Register asm __volatile("mrs %0, pmccntr_el0\n" : "=r"(value) : : "memory"); return value; }
static inline void init_perfcounters (P4_bool_t do_reset, P4_bool_t enable_divider) { // enable all counters (including cycle counter) unsigned long 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("msr pmcr_el0, %0\n" : : "r"(value) : "memory");
// enable all counters:
__asm__ __volatile("msr pmcntenset_el0, %0\n" : : "r"(0x8000000fULL) : "memory");
}
3.5.2.4 User Application Debugging
In order to be able to do single-step debugging using hardware breakpoints, the debug OS Lock from the ARM processor must be unlocked. This function is used by user applications debugged using UniversalisOS. To enable this function, the parameter Allow Application Debugging needs to be enabled. You might want to disable this parameter, if you have a board on which the firmware does not allow usage of the hardware debugging functions (for security reasons for example). This parameter is setting a property retrieved by the PSP on startup:
<prop_dir name="board/config"> <prop_bool name="user-debug" data="true"/> </prop_dir>
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 51
3.5.2.5 Image Parameters
The parameters in this section are required depending on the boot strategy you are using and are setting environ- ment variables.
• RAM start address: Start of the first RAM region in the physical address space. This parameter affects the load address of UniversalisOS for UBoot and other boot strategies. UniversalisOS kernel will be loaded at RAM start address + 0x80000. Set the value according to the board you are using and make sure it is 256MiB aligned address.
• DT image for fastboot: When using the Qualcomm version of Fastboot embedding the possible dtbs in an image, this parameter must be set to the full path of your DT image generated with dtbtool.
3.5.3 Extra Memory Regions
This item of the configuration allows definition of other memory regions available than the region on which the kernel is started. On most ARMv8 board that have more than 2GB of RAM, 2GB of the memory is available in a memory range addressable in 32-bit addresses (usually at physical address 0x80000000). The rest of the memory is available at higher addresses in one or several regions. Here you can define up to four additional regions of memory that are available by providing for each region its physical address and its size. All regions with size 0 are ignored. These parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/config/memory"> <prop_addr data="0x0" name="addr-region0"/> <prop_uint64 data="0x0" name="size-region0"/> <prop_addr data="0x0" name="addr-region1"/> <prop_uint64 data="0x0" name="size-region1"/> <prop_addr data="0x0" name="addr-region2"/> <prop_uint64 data="0x0" name="size-region2"/> <prop_addr data="0x0" name="addr-region3"/> <prop_uint64 data="0x0" name="size-region3"/> </prop_dir>
3.5.4 Reserved Memory Regions
This configuration item allows definition of reserved memory regions. All these memory regions will not be used (and are protected) by the kernel. The reserved memory areas are memory holes that could be used for example by specific hardware or bootloader. Here you can define up to 4 regions of reserved memory by giving for each region its physical address and its size. All regions with size 0 are ignored. Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/config/reserved"> <prop_addr data="0x0" name="addr-region0"/>
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
52 PSPs
<prop_uint64 data="0x0" name="size-region0"/> <prop_addr data="0x0" name="addr-region1"/> <prop_uint64 data="0x0" name="size-region1"/> <prop_addr data="0x0" name="addr-region2"/> <prop_uint64 data="0x0" name="size-region2"/> <prop_addr data="0x0" name="addr-region3"/> <prop_uint64 data="0x0" name="size-region3"/> </prop_dir>
3.5.5 Extra IO regions
This configuration item allows definition of IO areas that must be mapped by the PSP during startup. Those areas are published so that kernel drivers can later request them and use them. Please note, however, that kernel drivers may create mappings through the PSP API io_map_kernel() at boot time. This is the preferred way instead of hard-coding these addresses in the PSP. Here you can define up to 10 areas or IOMEM by giving for each area a physical address and a size (those must be aligned to a Page). All areas with size 0 are ignored. Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/iomem"> <prop_addr data="0x0" name="addr-region0"/> <prop_uint64 data="0x0" name="size-region0"/> <prop_addr data="0x0" name="addr-region1"/> <prop_uint64 data="0x0" name="size-region1"/> ... </prop_dir>
3.5.6 GIC Interrupt Controller
The PSP includes a complete driver for the GIC interrupt controller version 2. The version 3 of the GIC controller is compatible to be used using the version 2 interface and works also with this PSP. This item is used to define the physical address at which the different elements of the GIC interrupt controller are present on your board.
• Force GIC V2 mode (legacy operation): Flag to force GIC V2 (legacy operation) mode.
• GIC DIST Address: The physical address of the distributor part of the GIC.
• GIC REDIST Address: The physical address of the redistributor part of the GIC.
• GIC CPU Address: The physical address of the CPU part of the GIC.
• GIC CTRL Address: The physical address of the virtual interface control part of the GIC. This value is only
needed if you use hardware virtualization.
• GIC VCPU Address: The physical address of the virtual CPU part of the GIC. This value is only needed if
you use hardware virtualization.
Those parameters are setting properties retrieved by the PSP on startup:
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 53
<prop_dir name="board/config/gic"> <prop_addr data="0x0" name="dist-addr"/> <prop_addr data="0x0" name="cpu-addr"/> <prop_addr data="0x0" name="ctrl-addr"/> <prop_addr data="0x0" name="vcpu-addr"/> </prop_dir>
3.5.7 Architecture Timer
The PSP is implementing support for the ARMv8 architecture timer to provide a ticker to the UniversalisOS kernel. The implementation supports both dynamic and periodic ticker mode and is by default using the dynamic mode. This can be changed by modifying the Ticker Mode parameter of the UniversalisOS kernel. By default the timer used is the non-secure virtual timer unless the PSP has hardware virtualization support and in this case the non-secure physical timer is used. The configuration items allow you to turn off the automatic detection and force some of the timer parameters.
• Automatic configuration: If activated, everything is detected during boot.
• Timer Type: This allows you to force which timer to use. Secure versions of the timer are only available if your firmware starts UniversalisOS in secure mode and you cannot use the physical timer if you are running as a hardware virtualized guest.
• Timer frequency : If this parameter is 0 or in automatic mode, the PSP is detecting the timer frequency using the cntfrq_el0 register. If your firmware is not setting this register correctly, you can set here the frequency of the timer.
• Timer Interrupt: If this parameter is 0 or in automatic mode, the PSP is using the default interrupt number from ARM specification (for example 27 for the virtual timer). If your hardware is not using the standard interrupt number, you can set it here which interrupt number to use for the timer.
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/timer"> <prop_uint32 data="0x0" name="type"/> <prop_uint32 data="0x0" name="interrupt"/> <prop_uint64 data="0x0" name="frequency"/> </prop_dir>
3.5.8 Top Level Multiplexing
The PSP is implementing support for Top Level Multiplexing (TLMM). This configuration item configures GPIOs using TLMM. GPIO configurations may be needed on some hardware to setup minimal configuration to boot. TLMM Address and TLMM Configuration Offset must be provided to be able to configure GPIOs properly. Here you can define up to 4 GPIOs by giving for each one its description(not used on UniversalisOS, just informative field), number, function, pull method, driver strength and enable status. All GPIOs with number 0 are ignored. Those parameters are setting properties retrieved by the PSP on startup:
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
54 PSPs
<prop_dir name="tlmm"> <prop_addr data="0" name="addr"/> <prop_addr data="0x1000" name="offset"/> <prop_uint32 data="0" name="gpio0-number"/> <prop_uint32 data="0" name="gpio0-fct"/> <prop_uint32 data="0" name="gpio0-pull"/> <prop_uint32 data="0" name="gpio0-stren"/> <prop_bool data="true" name="gpio0-enable"/> <prop_uint32 data="0" name="gpio1-number"/> <prop_uint32 data="0" name="gpio1-fct"/> <prop_uint32 data="0" name="gpio1-pull"/> <prop_uint32 data="2" name="gpio1-stren"/> <prop_bool data="true" name="gpio1-enable"/> <prop_uint32 data="0" name="gpio2-number"/> <prop_uint32 data="0" name="gpio2-fct"/> <prop_uint32 data="0" name="gpio2-pull"/> <prop_uint32 data="0" name="gpio2-stren"/> <prop_bool data="true" name="gpio2-enable"/> <prop_uint32 data="0" name="gpio3-number"/> <prop_uint32 data="0" name="gpio3-fct"/> <prop_uint32 data="0" name="gpio3-pull"/> <prop_uint32 data="0" name="gpio3-stren"/> <prop_bool data="true" name="gpio3-enable"/> </prop_dir>
3.5.9 PSP Console Drivers
Several serial drivers are implemented in the PSP and you can select which one to use and the address of one or more instances of each on your hardware. At least one driver should be activated and configured. Otherwise you will not have any console. However, you should only enable a certain driver if your hardware does support it. Otherwise, a kernel panic might be triggered by a PSP driver accessing non-existing hardware.
3.5.9.1 NS16550 Serial Driver
The 16550 UART is the most common serial controller and the driver supports older versions of the controller (e.g 8250). The following configuration parameters are available:
• Enable: Enable the NS16550 PSP driver
• Clock Rate: Frequency of the clock used to create the baudrate.
• Sampling Rate: Sampling rate used to create the baudrate.
• Register Shift: Register shift used to align UART registers. (e.g 2 = 4 bytes alignment)
• UARTx Address: Physical address of instance X of the UART. Only one value is needed here unless you
want to use the PSP_CONSOLE_PORT to easily change which UART you are using.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 55
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/ns16550"> <prop_uint32 data="0x0" name="clock-rate"/> <prop_uint32 data="0x0" name="sampling-rate"/> <prop_uint32 data="0x0" name="reg-shift"/> <prop_addr data="0x0" name="addr-uart1"/> <prop_addr data="0x0" name="addr-uart2"/> </prop_dir>
3.5.9.2 PL011 Serial Driver
The PL011 is an ARM Serial IP that can be found in most boards or simulators from ARM (Fastmodel, Foundation Platform or Fixed Virtual Platforms) as well as QEMU. The following configuration parameters are available:
• Enable: Enable the PL011 PSP driver
• Clock Rate: Frequency of the clock connected to the PL011 that is used to create the baudrate.
• FIFO size: Size of the send and receive FIFO. Since there is no register to read the size from, this must be configured depending on your hardware. If you don’t know the size, 1 will always work. You can try power of 2 sizes until you see some characters lost while stressing the console.
• UARTx Address: Physical address of instance X of the PL011 UART. Only one value is needed here unless you want to use the PSP_CONSOLE_PORT to easily change which UART you are using.
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/pl011"> <prop_uint32 data="0x0" name="clock-rate"/> <prop_uint32 data="0x0" name="fifo-size"/> <prop_addr data="0x0" name="addr-uart1"/> <prop_addr data="0x0" name="addr-uart2"/> <prop_addr data="0x0" name="addr-uart3"/> <prop_addr data="0x0" name="addr-uart4"/> <prop_addr data="0x0" name="addr-uart5"/> <prop_addr data="0x0" name="addr-uart6"/> <prop_addr data="0x0" name="addr-uart7"/> <prop_addr data="0x0" name="addr-uart8"/> </prop_dir>
3.5.9.3 Cadence Serial Driver
The Cadence UART is a standard UART IP that can be found for example in XilinX ZynqMP board. The following configuration parameters are available:
• Enable: Enable the Cadence PSP driver
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
56 PSPs
• Clock Rate: Frequency of the clock connected to the PL011 that is used to create the baudrate.
• UARTs Address: Physical address of instance X of the Cadence UART. Only one value is needed here
unless you want to use the PSP_CONSOLE_PORT to easily change which UART you are using.
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/cadence"> <prop_uint32 data="0x0" name="clock-rate"/> <prop_addr data="0x0" name="addr-uart1"/> <prop_addr data="0x0" name="addr-uart2"/> </prop_dir>
3.5.9.4 MSM HS Serial Driver
The Qualcomm MSM HS serial in an UART IP that you can find on some Qualcomm chipsets. The following configuration parameters are available:
• Enable: Enable the Cadence PSP driver
• UARTX Address: Physical address of instance X of the MSM HS uart. Only one value is needed here
unless you want to use the PSP_CONSOLE_PORT to easily change which UART you are using.
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/msm"> <prop_addr data="0x0" name="addr-uart1"/> <prop_addr data="0x0" name="addr-uart2"/> </prop_dir>
3.5.10 PSP Multi-Core Drivers
On ARMv8 based platforms, there are two common ways of booting extra cores: The SPIN method and the PSCI (Power State Coordination Interface). Depending on the manufacturer, some other methods might exist (eg. like SCM for Qualcomm). If your board has only one core, you can select the SPIN method and set the number of cores to 1. One of those method must be selected. If your board is using another method than the ones available, a custom PSP will need to be implemented.
3.5.10.1 PSCI Driver
The Power State Coordination Interface (PSCI) is a standard power management interface that has been defined by ARM to normalize most of the core management (idle, addition/removal, big.LITTLE integration and system shutdown or reset). More information can be found on the ARM website. The PSCI is available at least on any board using the ARM Trusted Firmware. It is also supported by UniversalisOS hardware virtualization and should be used for guests.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 57
The PSCI driver of the PSP supports both smc and hvc communication methods and can detect cores, start secondary cores and shutdown or reset the board. The following configuration parameters are available:
• Enable: Enable the PSCI PSP driver.
• Communication type: Define if the driver should use smc or hvc instruction to communicate with the PSCI capable firmware. If you are running directly on the hardware you usually need to select smc and if you are running as a hardware virtualized guest you will need to select hvc.
• Core auto-detection: With this parameter you can disable the auto-detection of the available cores. This system is using the AFFINITY_INFO PSCI command and on some boards the firmware is not properly handling calls for information on non existing cores and is either crashing (Jetson TX1) or simply returning OK all the time (leading to detection of non-existing cores). When this option is turned off, you have to specify the MPIDs of all cores of your board or give an MPID of -1 for non existing cores.
These parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/psci"> <prop_uint32 data="0x0" name="mode"/> <prop_bool data="true" name="auto"/> <prop_uint32 data="0x0" name="core-00"/> <prop_uint32 data="0x1" name="core-01"/> <prop_uint32 data="-1" name="core-02"/> <prop_uint32 data="-1" name="core-03"/> <prop_uint32 data="-1" name="core-04"/> <prop_uint32 data="-1" name="core-05"/> <prop_uint32 data="-1" name="core-06"/> <prop_uint32 data="-1" name="core-07"/> <prop_uint32 data="-1" name="core-08"/> <prop_uint32 data="-1" name="core-09"/> <prop_uint32 data="-1" name="core-10"/> <prop_uint32 data="-1" name="core-11"/> <prop_uint32 data="-1" name="core-12"/> <prop_uint32 data="-1" name="core-13"/> <prop_uint32 data="-1" name="core-14"/> <prop_uint32 data="-1" name="core-15"/> </prop_dir>
3.5.10.2 SPIN Driver
The SPIN driver can be used in 3 major cases:
• Single-Core systems: In this case the driver will provide the minimum required function to the system and declare only one core.
• All release systems: On some systems all cores are released on startup or when writing a start address at a predefined RAM address. In this case the SPIN driver will block all cores inside the PSP when started and will later unblock them when the kernel requests them to boot.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
58 PSPs
• One register per core systems: On some systems there is one RAM address per core on which a physical
address must be written and an sev operation called to start a core at the given physical address.
The following configuration parameters are available:
• Enable: Enable the PSP SPIN driver.
• Number of cores: Number of cores available on your system.
• Global Release address: RAM Physical address at which a physical address can be written to boot all
secondary cores and make them jump at the written address after issuing a sev instruction. This address
must be inside the RAM. If this has the value 0, one specific address per core is used.
• Core x release address: RAM physical address at which a physical address can be written to boot core x
and execute a jump at the written address after issuing a sev instruction.
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/spin"> <prop_uint32 data="0x0" name="num-cores"/> <prop_uint32 data="0x0" name="core-real-addr0"/> <prop_uint32 data="0x0" name="core-real-addr1"/> <prop_uint32 data="0x0" name="core-real-addr2"/> <prop_uint32 data="0x0" name="core-real-addr3"/> </prop_dir>
3.5.10.3 SCM Driver
The SCM (Secure Channel Manager) interface is a firmware interface used by Qualcomm providing services to start and stop secondary cores. The SCM PSP driver initializes specific internal hardware for the Snapdragon 810 chipset (eg. regulators, clocks, etc.). The driver also provides target reboot and halt using the clocks and regulators of the Snapdragon 810. The following configuration parameters are available:
• Enable: Enable the SCM PSP driver.
This parameter is setting a property retrieved by the PSP on startup:
<prop_dir name="board/scm"> <prop_uint32 data="0x0" name="mode"/> </prop_dir>
3.5.11 PCI drivers
3.5.11.1 PSP PCI driver
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 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 59
3.5.11.2 PCI Layerscape driver
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 UniversalisOS 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.
3.5.11.3 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
3.5.11.4 Component configuration
Table 14 summarizes the parameters available for each controller and the corresponding property; see section 3.5.11.5, page 59 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
3.5.11.5 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 Portugal Futurista GmbH, all rights reserved.
60 PSPs
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>
3.5.12 MSI support
3.5.12.1 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 3.5.12.4, page 61.
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 UniversalisOS Device Driver Programming Reference Manual, section 19.5.8, page 768
3.5.12.2 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 3.5.12.3, page 61 for their actual effect on the MSI driver. See table 16 for details.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
PSP Cortex-A5x 61
Parameter Corresponding property
Enable MSI support msi_enable
MSI group MSIIR address msiir
MSI group interrupt number int
Table 16: MSI component configuration
3.5.12.3 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>
3.5.12.4 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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
62 PSPs
system (1/32 of MSI and 2/32 of MSI-X being used). As noted, the IRQ CPU affinity is selected based on the 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).
3.5.13 HWVIRT Guest Console and P4Bus
If you intend to run UniversalisOS as a hardware virtualized guest of another UniversalisOS you can activate support for specific drivers here:
• VMM console: Enabling this will allow you to have your UniversalisOS console redirected to the VMM console
(using the console port 1).
• P4Bus: Enabling this will allow you to use the P4Bus through the vmfp system extension and to use a
P4Bus device as PSP console (using the console port 2 for first P4Bus device and following).
Those parameters are setting properties retrieved by the PSP on startup:
<prop_dir name="board/hwvirt-guest"> <prop_bool data="false" name="console"/> <prop_bool data="true" name="p4bus"/> </prop_dir>
3.5.14 PSP Specific Properties
None present.
3.5.15 Limitations
For the UniversalisOS kernel ARM related architecture limitations see section A.13, page 113.
c Copyright 2005 – 2019 Portugal Futurista 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. UniversalisOS 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 UniversalisOS image is compressed (gzip).
uboot_unc: Bootstrap image for U-Boot, the UniversalisOS image is not compressed.
uboot_dtb: Bootstrap image for U-Boot, the UniversalisOS 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 UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
5 Drivers
5.1 Serial Drivers
5.1.1 Serial PL011
UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/driver/object/pl011_fp
and the corresponding driver configuration file is:
/opt/universalisos-D5.0/target/arm/v8hf/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 UniversalisOS in:
• /opt/universalisos-D5.0/target/arm/v7hf/driver/
• /opt/universalisos-D5.0/target/arm/v8hf/driver/
5.1.1.1 Configuration
The driver’s configuration refers to the following UniversalisOS 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 ).
<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"> <prop_uint32 name="Baud" data="38400"/>
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Serial Drivers 65
<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"/>
<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.2 Serial SCIF
UniversalisOS provides a serial driver which allows usage of the on-chip serial controller (SCIF).
Warning: The scif_fp driver is only intended for the Renesas IP called SCIF. It is not designed and tested for the SCIFA, SCIFB and HSCIF IP also present on the SoC.
Warning: The driver does not use the driver development environment described in the UniversalisOS Device Driver Programming Reference Manual
The serial driver is provided by the module:
/opt/universalisos-D5.0/target/arm/v8hf/driver/object/scif_fp
and the corresponding driver configuration files are
• The domain file, instantiating and configuring a scif_fp component and two serial port components, one for each serial debug line accessible on the Renesas Car H2 board:
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/scif.dom
• The driver component files:
/opt/universalisos-D5.0/target/arm/v8hf/driver/libdrv/drv_ser-port.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/scif/scif-fp_ext.cmp
The serial driver can be added using Add... button. Select serial type and select SCIF Serial User Level Driver. The default configuration provides a single serial port and it has no dependency.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
66 Drivers
5.1.2.1 Configuration
The driver’s configuration refers to the following UniversalisOS properties. Only the port ser0:0 is described here but the default configuration also provide a second port ser0:1. Note that some properties dependent to the hardware are provided by the PSP (Io and Int) and other by the board configuration (RegMultiplier, ClockSpeed, SamplingRate, and AddressSwapMask ).
5.1.2.1.1 Device Configuration
• Device
Device Name: Default: ser.
Device Number : Default: 0.
• Advanced Configuration : allows configuration of the Kernel Console number, mapping on which serial line
the kernel shall output its information.
5.1.2.1.2 Serial Port Configuration
• Port:
Port Number : Default: 0.
Board Resource Name: used for retrieving PSP configuration data as IRQ and I/O Memory parame-
ters. Default: UART7.
• Port Configuration: corresponds to the serial communication parameters and the default values are de-
faulted 38400, 8N1, no handshake.
• Hardware Configuration: corresponds to hardware specific configuration parameters: Register Multiplier,
Clock Speed, Sampling Rate and Address Swap Mask. Default: (16, 14745600, 16, 0).
The second serial Port configuration parameters default are:
• Port Number : 1.
• Board Resource Name: UART8.
5.1.3 Serial 8250
UniversalisOS 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 UniversalisOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the UniversalisOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and UniversalisOS 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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Serial Drivers 67
5.1.3.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
5.1.3.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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
68 Drivers
• DRV_SER_SIGNAL_RI
• DRV_SER_SIGNAL_DSR
5.1.3.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.3.4 User Level Driver
The user level version of the driver is provided by the module
/opt/universalisos-D5.0/target/arm/v8hf/driver/object/8250.elf
and the corresponding configuration file is
/opt/universalisos-D5.0/target/arm/v8hf/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
add PIKEOS_POOL driver/serial/8250.dom
5.1.3.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.3.5.1 Kernel Fusion Project
The kernel level version of the driver is provided by the module
/opt/universalisos-D5.0/target/arm/v8hf/fusion-kernel/object/kerneldriver/8250/8250.kdev
and the corresponding configuration file is
/opt/universalisos-D5.0/target/arm/v8hf/fusion-kernel/kerneldriver.cmp
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Serial Drivers 69
To add the driver to a kernel fusion project using CODEO:
• Create a new UniversalisOS 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.3.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/universalisos-D5.0/target/arm/v8hf/driver/serial/8250_kdev.dom
Alternatively, it is possible to use the binary configuration file
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/8250/8250_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 UniversalisOS 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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
70 Drivers
5.1.4 Serial XuartPS
UniversalisOS 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 UniversalisOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the UniversalisOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/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/universalisos-D5.0/target/arm/v8hf/driver/serial/xuartps.dom
• The serial driver base component file configuring the process instance settings and generic run-time con-
figuration. See UniversalisOS Device Driver Programming Reference Manual for details:
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/xuartps/xuartps-fp_ext.cmp
• The serial port component file configuring file access parameters and specific parameters for an UART link:
/opt/universalisos-D5.0/target/arm/v8hf/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.
5.1.5 Serial LPUART
UniversalisOS 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 UniversalisOS Device Driver Programming Reference Manual, section 9, page 412). Please refer to the UniversalisOS Device Driver Programming Reference Manual, section 8.5, page 409 for details about the serial class driver configuration and UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/driver/object/lpuart.elf
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 71
and the corresponding configuration files are:
• The domain file, instantiating and configuring the serial base driver component and a serial port component:
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/lpuart.dom
• The serial driver base component file configuring the process instance settings and generic run-time con-
figuration. See UniversalisOS Device Driver Programming Reference Manual for details:
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/lpuart/lpuart-fp_ext.cmp
• The serial port component file configuring file access parameters and specific parameters for an UART link:
/opt/universalisos-D5.0/target/arm/v8hf/driver/serial/lpuart/lpuart-device.cmp
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 smc91cX
UniversalisOS 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 UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/driver/object/smc91cX_fp
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
72 Drivers
and the corresponding driver configuration files are:
• The domain file, instantiating and configuring a smc91cX_fp component and four virtual channel compo-
nents:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/smc91cX_fp.dom
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/smc91cX_fp/smc91cX_fp.cmp
/opt/universalisos-D5.0/target/arm/v8hf/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.1.1 Configuration
The driver configuration refers to the following UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 73
5.2.2 Ethernet smc911x
UniversalisOS provides a multi-channel Ethernet driver which allows usage of the smc911x Ethernet controller from different applications simultaneously. The smc911x Ethernet driver uses the UniversalisOS driver development environment with the Network Driver High Level Module. Please refer to the UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/driver/object/smc911x.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/universalisos-D5.0/target/arm/v8hf/driver/ethernet/smc911x.dom
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/smc911x/smc911x-fp_ext.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/smc911x/smc911x-device.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select SMC911x 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 Portugal Futurista GmbH, all rights reserved.
74 Drivers
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: smc911x
Provider Name: Default: eth0
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in UniversalisOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in UniversalisOS 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 UniversalisOS 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 UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 75
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 smc911x 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 XemacPS
UniversalisOS provides a multi-channel Ethernet driver which allows usage of the XEMACPS Ethernet controller from different applications simultaneously. The xemacps Ethernet driver uses the UniversalisOS driver development environment with the Network Driver High Level Module. Please refer to the UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
76 Drivers
/opt/universalisos-D5.0/target/arm/v8hf/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/universalisos-D5.0/target/arm/v8hf/driver/ethernet/xemacps.dom
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/xemacps/xemacps-fp_ext.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/xemacps/xemacps-device.cmp
/opt/universalisos-D5.0/target/arm/v8hf/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.
5.2.3.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 UniversalisOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in UniversalisOS Device
Driver Programming Reference Manual)
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 77
5.2.3.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 UniversalisOS 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 UniversalisOS 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.3.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 Portugal Futurista GmbH, all rights reserved.
78 Drivers
5.2.3.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.4 Ethernet virtio-net
UniversalisOS 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 UniversalisOS driver development environment with the Network Driver High Level Module. Please refer to the UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/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/universalisos-D5.0/target/arm/v8hf/driver/ethernet/virtio-net.dom
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/virtio-net/virtio-net-fp_ext.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/virtio-net/virtio-net-device.cmp
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 79
/opt/universalisos-D5.0/target/arm/v8hf/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.4.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 UniversalisOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in UniversalisOS Device Driver Programming Reference Manual)
Note: The Maximum Transfer Size can be increased to support jumbo frames (view section 5.2.4.4).
5.2.4.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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
80 Drivers
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the UniversalisOS 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 UniversalisOS 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.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 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.4.5 Driver Specific Limitations
The virtio-net network driver has the following limitations:
• Only support one Ethernet device per driver module.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 81
• Only available as External File Provider Driver.
• Dependency on PCI Manager on non-ARM boards.
5.2.5 Ethernet dpaa
UniversalisOS provides a multi-channel Ethernet driver which allows usage of the dpaa Ethernet controller from different applications simultaneously. The dpaa Ethernet driver uses the UniversalisOS driver development environment with the Network Driver High Level Module. Please refer to the UniversalisOS 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 0
• "eth0:0" for virtual channel 0 of the physical device 0
• "eth0:1" for virtual channel 1 of the physical device 0
• "eth0:2" for virtual channel 2 of the physical device 0
• "eth0:3" for virtual channel 3 of the physical device 0
• "eth0:dev1" for the physical device 1
• "eth0:4" for virtual channel 0 of the physical device 1
• "eth0:5" for virtual channel 1 of the physical device 1
• "eth0:6" for virtual channel 2 of the physical device 1
• "eth0:7" for virtual channel 3 of the physical device 1
The Ethernet driver is provided by the module:
/opt/universalisos-D5.0/target/arm/v8hf/driver/object/dpaa.elf
The corresponding driver configuration files are:
• The domain file, instantiating and configuring the base driver configuration component, the physical device component and overloading default configuration parameters when needed:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/dpaa_ext-demo.dom
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/dpaa/dpaa-base.cmp
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
82 Drivers
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/dpaa/dpaa-device.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select dpaa-network-driver. The driver provides a single device which can be 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: dpaa
Provider Name: Default: dpaa
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in UniversalisOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in UniversalisOS Device
Driver Programming Reference Manual)
5.2.5.2 Physical Device Configuration
The device configuration is done in 3 generic steps:
• BSP Settings:
IO_ID: I/O resource used for device. This will select the interface (see board description for details).
Default:0.
• 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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 83
Read Timeout Value: If Read Timeout is set to User Value, this parameter is the UniversalisOS 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 UniversalisOS 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
• Device Configuration:
Resource Partition: The driver will allocate memory from the configured resource partition. The
resulting effect depends on the DDK implementation; i.e. there is no effect for External File Providers,
the driver will still allocate memory from the partition where it is running.
Enable CPU selection: The driver will by default bind the portals to the current CPU. This option can
be enabled to enable the configuration parameter for selecting the CPU.
cpuid: Selected CPU. Threads accessing the software portals will bind to this CPU when it is ac-
cessed the first time.
Enable additional mapping: This enables an additional mapping which is needed by the driver (e.g.
for selecting the MDIO bus for the PHYs (see board description for details).
Name of additional mapping: Name of additional mapping which will be mapped by the driver (see
board description for details).
Enable FMAN2: This enables the mapping of the second frame manager. This is disabled by default,
see board description whether this is needed.
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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
84 Drivers
• Multicast Communication: Used for enabling and configuring the Multicast feature of the VC. Default: (false,
32)
5.2.5.4 Driver Specific Limitations
The dpaa network driver has the following limitations:
• Only available as External File Provider Driver.
• TGEC is not supported (10GBit/s interface).
5.2.6 Ethernet RAVB
UniversalisOS provides a multi-channel Ethernet driver which allows usage of the RAVB Ethernet controller from different applications simultaneously. The ravb Ethernet driver uses the UniversalisOS driver development environment with the Network Driver High Level Module. Please refer to the UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/driver/object/ravb.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/universalisos-D5.0/target/arm/v8hf/driver/ethernet/ravb.dom
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/ravb/ravb-fp_ext.cmp
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 85
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/ravb/ravb-device.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/config/hlnet/hlnet-vchan.cmp
The Ethernet driver can be added using Add... button. Select Ethernet type and select RAVB 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: ravb
Provider Name: Default: eth0
Enable Debug
Binary origin
Host file
• Diagnostics: Allows the user to configure the BASE class diagnostics parameters (described in UniversalisOS Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in UniversalisOS Device Driver Programming Reference Manual)
5.2.6.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 UniversalisOS timeout
value (in nanosecond) for read requests. Default: 1000000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
86 Drivers
Write Timeout: Timeout mode for write requests. Default: Infinite
Write Timeout Value: If Write Timeout is set to User Value, this parameter is the UniversalisOS 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
• Ethernet link configuration:
Auto-negotiation: Auto negotiation is supported by the driver.
Full duplex: Half and full duplex are supported by the driver.
Link speed: Only the speeds 100Mbits/s and 1Gbit/s are supported.
Warning: On the SoC revision 1.1, the autonegotiation is not working due to a SoC issue. Please configure the RAVB driver as the following:
• Auto-negotiation: False.
• Full duplex: full duplex.
• Link speed: 100Mbits/s.
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)
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 87
5.2.6.4 Driver Specific Limitations
The RAVB network driver has the following limitations:
• Only supports one logical device per I/O device.
• Only available as External File Provider Driver.
5.2.7 Ethernet e1000
UniversalisOS 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 UniversalisOS driver development environment with the Network Driver High Level Module. Please refer to the UniversalisOS 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/universalisos-D5.0/target/arm/v8hf/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:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/e1000.dom
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/e1000/e1000-fp_ext.cmp
/opt/universalisos-D5.0/target/arm/v8hf/driver/ethernet/e1000/e1000-device.cmp
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
88 Drivers
/opt/universalisos-D5.0/target/arm/v8hf/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.7.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 UniversalisOS
Device Driver Programming Reference Manual)
• Provider Resources: Allows the user to configure the CHAR class parameters (described in UniversalisOS Device
Driver Programming Reference Manual)
Note: The Maximum Transfer Size can be increased to support jumbo frames (view section 5.2.7.5).
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 UniversalisOS 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 UniversalisOS timeout
value (in nanosecond) for write requests. Default: 1000000
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Ethernet Drivers 89
• 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.7.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 UniversalisOS 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.7.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)
5.2.7.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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
90 Drivers
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.7.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 Block Device and MTD Drivers
Drivers for Block Devices or Memory Technology Devices (MTD).
5.3.1 Block Device and MTD Simulator blkdrvsim
UniversalisOS 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 UniversalisOS Device Driver Programming Reference Manual, section 17, page 687). Please refer to the UniversalisOS 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.3.1.1 Driver Specific Configuration Parameters
5.3.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.
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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Block Device and MTD Drivers 91
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 MAX_FD_COUNT integer A count of the UniversalisOS 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.3.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 UniversalisOS 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 UniversalisOS 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 Portugal Futurista GmbH, all rights reserved.
92 Drivers
5.3.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.3.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 UniversalisOS 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.3.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/universalisos-D5.0/target/arm/v8hf/driver/object/blkdrvsim.elf
and the corresponding configuration files are
/opt/universalisos-D5.0/target/arm/v8hf/driver/blk/blkdrvsim/blkdrvsim_ext-base.cmp /opt/universalisos-D5.0/target/arm/v8hf/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/universalisos-D5.0/target/arm/v8hf/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 Portugal Futurista GmbH, all rights reserved.
Block Device and MTD Drivers 93
5.3.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.3.1.4.1 Fusion Project for the Kernel Level Driver
The kernel level version of the driver is provided by the module
/opt/universalisos-D5.0/target/arm/v8hf/fusion-kernel/object/kerneldriver/blkdrvsim.kdev
and the corresponding configuration file is
/opt/universalisos-D5.0/target/arm/v8hf/fusion-kernel/kerneldriver.cmp
To add the driver to a kernel fusion project using CODEO:
• Create a new UniversalisOS 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.3.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/universalisos-D5.0/target/arm/v8hf/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 Portugal Futurista GmbH, all rights reserved.
94 Drivers
• Select the UniversalisOS 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.3.1.5 Demonstration Projects
Following demo project can be used for the querying (and testing) of the simulated devices:
/opt/universalisos-D5.0/demo/universalisos-native/blk-client/
These demonstration projects are using the blkdrvsim driver:
/opt/universalisos-D5.0/integration/blk-sim/project.xml /opt/universalisos-D5.0/integration/volume-provider-universalisos-native/project.xml /opt/universalisos-D5.0/integration/volume-provider-posix/project.xml /opt/universalisos-D5.0/integration/volume-provider-apex/project.xml /opt/universalisos-D5.0/integration/volume-provider-cfs-apex/project.xml /opt/universalisos-D5.0/integration/volume-provider-cfs-universalisos-native/project.xml /opt/universalisos-D5.0/integration/volume-provider-cfs-posix/project.xml /opt/universalisos-D5.0/integration/libhttpd-posix/project.xml /opt/universalisos-D5.0/integration/libmicrohttpd-posix/project.xml
5.3.1.6 Driver Source Code
A full source code of this driver is available in the DDK demos:
/opt/universalisos-D5.0/demo/ddk-user-level/hlblk-driver/ /opt/universalisos-D5.0/demo/ddk-kerneldriver/hlblk-driver/
5.3.2 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 UniversalisOS 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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Block Device and MTD Drivers 95
• 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.
• 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/universalisos-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/universalisos-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=
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
96 Drivers
IMAGE_PART4=
1st logical partition
SIZE_LOGPART1_SEC=0 TYPE_LOGPART1= IMAGE_LOGPART1=
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/universalisos-D5.0/bin/mkblkimage
/opt/universalisos-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.4 IOMMU Drivers
5.4.1 SMMU
UniversalisOS 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 UniversalisOS Device Driver
Programming Reference Manual
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
IOMMU Drivers 97
The driver is provided by the module:
/opt/universalisos-D5.0/target/arm/v8hf/fusion-kernel/object/kerneldriver/smmu.kdev
The corresponding driver configuration files are:
• The driver component files giving the driver configuration and data structure:
/opt/universalisos-D5.0/target/arm/v8hf/driver/iommu/smmu/smmu.cmp
5.4.1.1 System Memory Management Unit driver configuration
These configuration parameters are the most generic configuration parameters. They allow configuration of:
• Diagnostics:
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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
98 Drivers
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
5.4.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 UniversalisOS boot.
• Only supports a minimal granularity of 4 Kilobytes.
5.5 Clock Manager Drivers
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 UniversalisOS driver development environment with the Clock Manager High Level Module. Please refer to the UniversalisOS 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.5.1 Zynq Ultrascale Clock Manager
5.5.1.1 Clock types
The clock tree is composed of nodes, and each node as a special type, depending on its function. The table below summarizes the different clock types for Zynq Ultrascale.
Clock Type Properties
ZYNQ_CLOCK_SYSTEM Quartz Oscillator clock (root of the clock tree)
ZYNQ_CLOCK_PLL PLL Reference clock (second level)
ZYNQ_CLOCK_SRCSEL Source Selector (multiplexer)
ZYNQ_CLOCK_DIV Divider clock
ZYNQ_CLOCK_CONTROL Enable or disable clock
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Clock Manager Drivers 99
5.5.1.2 List of clocks
The table bellow summarizes all the clock in the ZYNQ clock tree. The root clock (ps) is initialized from PSP_QUARTZ_FREQ.
Clock Name Type
ps ZYNQ_CLOCK_SYSTEM
ddr ZYNQ_CLOCK_PLL
ddr_ext ZYNQ_CLOCK_DIV
arm ZYNQ_CLOCK_PLL
arm_ext ZYNQ_CLOCK_DIV
vpu ZYNQ_CLOCK_PLL
vpu_ext ZYNQ_CLOCK_DIV
rpu ZYNQ_CLOCK_PLL
rpu_ext ZYNQ_CLOCK_DIV
io ZYNQ_CLOCK_PLL
io_ext ZYNQ_CLOCK_DIV
gem0_srcsel ZYNQ_CLOCK_SRCSEL
gem0_div0 ZYNQ_CLOCK_DIV
gem0_div1 ZYNQ_CLOCK_DIV
gem0_tx_ctrl ZYNQ_CLOCK_CONTROL
gem0_rx_ctrl ZYNQ_CLOCK_CONTROL
gem1_srcsel ZYNQ_CLOCK_SRCSEL
gem1_div0 ZYNQ_CLOCK_DIV
gem1_div1 ZYNQ_CLOCK_DIV
gem1_tx_ctrl ZYNQ_CLOCK_CONTROL
gem1_rx_ctrl ZYNQ_CLOCK_CONTROL
gem2_srcsel ZYNQ_CLOCK_SRCSEL
gem2_div0 ZYNQ_CLOCK_DIV
gem2_div1 ZYNQ_CLOCK_DIV
gem2_tx_ctrl ZYNQ_CLOCK_CONTROL
gem2_rx_ctrl ZYNQ_CLOCK_CONTROL
gem3_srcsel ZYNQ_CLOCK_SRCSEL
gem3_div0 ZYNQ_CLOCK_DIV
gem3_div1 ZYNQ_CLOCK_DIV
gem3_tx_ctrl ZYNQ_CLOCK_CONTROL
gem3_rx_ctrl ZYNQ_CLOCK_CONTROL
usb3_dual_srcsel ZYNQ_CLOCK_SRCSEL
usb3_dual_div0 ZYNQ_CLOCK_DIV
usb3_dual_div1 ZYNQ_CLOCK_DIV
usb3_dual_ctrl ZYNQ_CLOCK_CONTROL
usb0_bus_srcsel ZYNQ_CLOCK_SRCSEL
usb0_bus_div0 ZYNQ_CLOCK_DIV
usb0_bus_div1 ZYNQ_CLOCK_DIV
usb0_bus_ctrl ZYNQ_CLOCK_CONTROL
usb1_bus_srcsel ZYNQ_CLOCK_SRCSEL
usb1_bus_div0 ZYNQ_CLOCK_DIV
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
100 Drivers
Clock Name Type
usb1_bus_div1 ZYNQ_CLOCK_DIV
usb1_bus_ctrl ZYNQ_CLOCK_CONTROL
qspi_srcsel ZYNQ_CLOCK_SRCSEL
qspi_div0 ZYNQ_CLOCK_DIV
qspi_div1 ZYNQ_CLOCK_DIV
qspi_ctrl ZYNQ_CLOCK_CONTROL
sdio0_srcsel ZYNQ_CLOCK_SRCSEL
sdio0_div0 ZYNQ_CLOCK_DIV
sdio0_div1 ZYNQ_CLOCK_DIV
sdio0_ctrl ZYNQ_CLOCK_CONTROL
sdio1_srcsel ZYNQ_CLOCK_SRCSEL
sdio1_div0 ZYNQ_CLOCK_DIV
sdio1_div1 ZYNQ_CLOCK_DIV
sdio1_ctrl ZYNQ_CLOCK_CONTROL
uart0_srcsel ZYNQ_CLOCK_SRCSEL
uart0_div0 ZYNQ_CLOCK_DIV
uart0_div1 ZYNQ_CLOCK_DIV
uart0_ctrl ZYNQ_CLOCK_CONTROL
uart1_srcsel ZYNQ_CLOCK_SRCSEL
uart1_div0 ZYNQ_CLOCK_DIV
uart1_div1 ZYNQ_CLOCK_DIV
uart1_ctrl ZYNQ_CLOCK_CONTROL
spi0_srcsel ZYNQ_CLOCK_SRCSEL
spi0_div0 ZYNQ_CLOCK_DIV
spi0_div1 ZYNQ_CLOCK_DIV
spi0_ctrl ZYNQ_CLOCK_CONTROL
spi1_srcsel ZYNQ_CLOCK_SRCSEL
spi1_div0 ZYNQ_CLOCK_DIV
spi1_div1 ZYNQ_CLOCK_DIV
spi1_ctrl ZYNQ_CLOCK_CONTROL
can0_srcsel ZYNQ_CLOCK_SRCSEL
can0_div0 ZYNQ_CLOCK_DIV
can0_div1 ZYNQ_CLOCK_DIV
can0_ctrl ZYNQ_CLOCK_CONTROL
can1_srcsel ZYNQ_CLOCK_SRCSEL
can1_div0 ZYNQ_CLOCK_DIV
can1_div1 ZYNQ_CLOCK_DIV
can1_ctrl ZYNQ_CLOCK_CONTROL
cpu_r5_srcsel ZYNQ_CLOCK_SRCSEL
cpu_r5_div0 ZYNQ_CLOCK_DIV
cpu_r5_ctrl ZYNQ_CLOCK_CONTROL
cpu_r5_core_ctrl ZYNQ_CLOCK_CONTROL
iou_switch_srcsel ZYNQ_CLOCK_SRCSEL
iou_switch_div0 ZYNQ_CLOCK_DIV
iou_switch_ctrl ZYNQ_CLOCK_CONTROL
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Clock Manager Drivers 101
Clock Name Type csu_pll_srcsel ZYNQ_CLOCK_SRCSEL csu_pll_div0 ZYNQ_CLOCK_DIV csu_pll_ctrl ZYNQ_CLOCK_CONTROL pcap_srcsel ZYNQ_CLOCK_SRCSEL pcap_div0 ZYNQ_CLOCK_DIV pcap_ctrl ZYNQ_CLOCK_CONTROL lpd_switch_srcsel ZYNQ_CLOCK_SRCSEL lpd_switch_div0 ZYNQ_CLOCK_DIV lpd_switch_ctrl ZYNQ_CLOCK_CONTROL lpd_lsbus_srcsel ZYNQ_CLOCK_SRCSEL lpd_lsbus_div0 ZYNQ_CLOCK_DIV lpd_lsbus_ctrl ZYNQ_CLOCK_CONTROL dbg_lpd_srcsel ZYNQ_CLOCK_SRCSEL dbg_lpd_div0 ZYNQ_CLOCK_DIV dbg_lpd_ctrl ZYNQ_CLOCK_CONTROL nand_srcsel ZYNQ_CLOCK_SRCSEL nand_div0 ZYNQ_CLOCK_DIV nand_div1 ZYNQ_CLOCK_DIV nand_ctrl ZYNQ_CLOCK_CONTROL lpd_dma_srcsel ZYNQ_CLOCK_SRCSEL lpd_dma_div0 ZYNQ_CLOCK_DIV lpd_dma_ctrl ZYNQ_CLOCK_CONTROL pl0_srcsel ZYNQ_CLOCK_SRCSEL pl0_div0 ZYNQ_CLOCK_DIV pl0_div1 ZYNQ_CLOCK_DIV pl0_ctrl ZYNQ_CLOCK_CONTROL pl1_srcsel ZYNQ_CLOCK_SRCSEL pl1_div0 ZYNQ_CLOCK_DIV pl1_div1 ZYNQ_CLOCK_DIV pl1_ctrl ZYNQ_CLOCK_CONTROL pl2_srcsel ZYNQ_CLOCK_SRCSEL pl2_div0 ZYNQ_CLOCK_DIV pl2_div1 ZYNQ_CLOCK_DIV pl2_ctrl ZYNQ_CLOCK_CONTROL pl3_srcsel ZYNQ_CLOCK_SRCSEL pl3_div0 ZYNQ_CLOCK_DIV pl3_div1 ZYNQ_CLOCK_DIV pl3_ctrl ZYNQ_CLOCK_CONTROL gem_tsu_srcsel ZYNQ_CLOCK_SRCSEL gem_tsu_div0 ZYNQ_CLOCK_DIV gem_tsu_div1 ZYNQ_CLOCK_DIV gem_tsu_ctrl ZYNQ_CLOCK_CONTROL dll_srcsel ZYNQ_CLOCK_SRCSEL ams_srcsel ZYNQ_CLOCK_SRCSEL ams_div0 ZYNQ_CLOCK_DIV
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
102 Drivers
Clock Name Type
ams_div1 ZYNQ_CLOCK_DIV
ams_ctrl ZYNQ_CLOCK_CONTROL
i2c0_srcsel ZYNQ_CLOCK_SRCSEL
i2c0_div0 ZYNQ_CLOCK_DIV
i2c0_div1 ZYNQ_CLOCK_DIV
i2c0_ctrl ZYNQ_CLOCK_CONTROL
i2c1_srcsel ZYNQ_CLOCK_SRCSEL
i2c1_div0 ZYNQ_CLOCK_DIV
i2c1_div1 ZYNQ_CLOCK_DIV
i2c1_ctrl ZYNQ_CLOCK_CONTROL
acpu_srcsel ZYNQ_CLOCK_SRCSEL
acpu_div0 ZYNQ_CLOCK_DIV
acpu_half_ctrl ZYNQ_CLOCK_CONTROL
acpu_full_ctrl ZYNQ_CLOCK_CONTROL
dbg_trace_srcsel ZYNQ_CLOCK_SRCSEL
dbg_trace_div0 ZYNQ_CLOCK_DIV
dbg_trace_ctrl ZYNQ_CLOCK_CONTROL
dbg_fpd_srcsel ZYNQ_CLOCK_SRCSEL
dbg_fpd_div0 ZYNQ_CLOCK_DIV
dbg_fpd_ctrl ZYNQ_CLOCK_CONTROL
dp_video_srcsel ZYNQ_CLOCK_SRCSEL
dp_video_div0 ZYNQ_CLOCK_DIV
dp_video_div1 ZYNQ_CLOCK_DIV
dp_video_ctrl ZYNQ_CLOCK_CONTROL
dp_audio_srcsel ZYNQ_CLOCK_SRCSEL
dp_audio_div0 ZYNQ_CLOCK_DIV
dp_audio_div1 ZYNQ_CLOCK_DIV
dp_audio_ctrl ZYNQ_CLOCK_CONTROL
dp_stc_srcsel ZYNQ_CLOCK_SRCSEL
dp_stc_div0 ZYNQ_CLOCK_DIV
dp_stc_div1 ZYNQ_CLOCK_DIV
dp_stc_ctrl ZYNQ_CLOCK_CONTROL
ddr_srcsel ZYNQ_CLOCK_SRCSEL
ddr_div0 ZYNQ_CLOCK_DIV
ddr_div1 ZYNQ_CLOCK_DIV
ddr_ctrl ZYNQ_CLOCK_CONTROL
gpu_srcsel ZYNQ_CLOCK_SRCSEL
gpu_div0 ZYNQ_CLOCK_DIV
gpu_pp1_ctrl ZYNQ_CLOCK_CONTROL
gpu_pp0_ctrl ZYNQ_CLOCK_CONTROL
gpu_ctrl ZYNQ_CLOCK_CONTROL
sata_srcsel ZYNQ_CLOCK_SRCSEL
sata_div0 ZYNQ_CLOCK_DIV
sata_ctrl ZYNQ_CLOCK_CONTROL
pcie_srcsel ZYNQ_CLOCK_SRCSEL
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Clock Manager Drivers 103
Clock Name Type pcie_div0 ZYNQ_CLOCK_DIV pcie_ctrl ZYNQ_CLOCK_CONTROL fpd_dma_srcsel ZYNQ_CLOCK_SRCSEL fpd_dma_div0 ZYNQ_CLOCK_DIV fpd_dma_ctrl ZYNQ_CLOCK_CONTROL dpdma_srcsel ZYNQ_CLOCK_SRCSEL dpdma_div0 ZYNQ_CLOCK_DIV dpdma_ctrl ZYNQ_CLOCK_CONTROL topsw_main_srcsel ZYNQ_CLOCK_SRCSEL topsw_main_div0 ZYNQ_CLOCK_DIV topsw_main_ctrl ZYNQ_CLOCK_CONTROL topsw_lsbus_srcsel ZYNQ_CLOCK_SRCSEL topsw_lsbus_div0 ZYNQ_CLOCK_DIV topsw_lsbus_ctrl ZYNQ_CLOCK_CONTROL dbg_tstmp_srcsel ZYNQ_CLOCK_SRCSEL dbg_tstmp_div0 ZYNQ_CLOCK_DIV
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
6 The UniversalisOS CDK
The UniversalisOS CDK will be installed under
/opt/universalisos-D5.0/cdk/arm/v8hf/bin
for ARMv8 64-bit. To avoid conflicts with other utilities installed on the host, all binaries provided by the CDK are prefixed with arm_v8hf- like arm_v8hf-gcc. Note: Every code that shall execute under UniversalisOS on an ARM processor must be compiled with the UniversalisOS CDK (cross development toolchain) for the ARM family. At first glance binaries compiled with another toolchain may also run, but slight differences in the generated code may cause problems which are very hard to debug.
The UniversalisOS ARM cross development toolchain uses the Linux EABI. This is important to note, especially when 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/universalisos-D5.0/documentation/cdk/arm_v8hf
6.1 Target binaries
With the installation of the UniversalisOS Package: Base, all the processor family dependent binary modules, libraries, header files, BSPs and PSPs will be installed into the directory
/opt/universalisos-D5.0/target/arm/v8hf/
The UniversalisOS architecture name is arm_v8hf.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
A Architecture Dependencies
A.1 Supported Architectures
The ARM ASP supports ARMv8-A cores with MMU from the Cortex-A family. This corresponds to Cortex A35, A53, A57, and A72.
A.2 Address Layout
The user accessible part of the address space covers the address range from address 0 to 0x0000007fffffffff, including (this is 512GB of virtual address space per task). The page size is 4096 bytes. The physical address space covers 40-bit.
A.3 Basic Data Types
UniversalisOS Type Size in Bytes Description P4_cpureg_t 8 Size of a processor register P4_address_t 8 Virtual memory address P4_size_t 8 Size of objects in virtual memory P4_phys_addr_t 8 Physical address space type P4_cpumask_t 8 Up to 64 processors are supported in the API
Table 23: Size of basic data types
A.4 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.4.1 Register Set
The order of the registers is defined in the following structure. The size of a complete user mode context is 832 bytes.
typedef struct P4_regs_str { P4_cpureg_t regs[31]; /* General purpose registers x0 to x30 / P4_cpureg_t sp; / Stack pointer / P4_cpureg_t pc; / Program pointer / P4_cpureg_t cpsr; / Status register, see note 1 / P4_cpureg_t fault; / Page fault address register, see note 2 / P4_cpureg_t ex_code; / Exception status/reply code, see note 3 */
/* FP registers */
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
106 Architecture Dependencies
__uint128_t fpregs[32]; /* FP registers, see note 4 */
P4_uint32_t fpsr; /* FPSR register */
P4_uint32_t fpcr; /* FPCR, see note 5 */
P4_uint32_t usedfpu; /* Is FPU used, see note 6 */
P4_uint32_t extra; /* unused, just for padding */
/* TLS registers */
P4_cpureg_t tpidr; /* 64-bit TLS, see note 7 */
P4_cpureg_t tpidrro; /* 32-bit TLS, 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), CPSR_T (bit 5), CPSR_Q
(bit 27), CPSR_GE (bits 16 to 19), CPSR_IT (bits 10 to 15 and 25 to 26), CPSR_SS (bit 21, see note 9).
CPSR_M32 (bit 4) enables 32-bit compatibility mode. 32-bit mode cannot be used as long as CPSR_IL is
set.
• Note 2: 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 3: 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 4: fpregs contains all representation of the 32 VFP registers available on ARMv8. When using only
64-bit or 32-bit VFP registers those are stored in the lower bits of the fpregs (in the same way as hardware
is handling it).
• Note 5: fpcr is the FPCR register of the VFP. The user can modify all bits.
• Note 6: usedfpu does not correspond to any register. This is the flag set/unset by fpu_enable and
fpu_disable functions and used by the kernel to activate the FPU for the thread and save/restore the VFP
context. This should be only manipulated using the fpu_enable/fpu_disable functions.
• Note 7: Register tpidr contains the thread local storage pointer and can be freely modified. The TLS
pointer can be obtained through register TPIDR_EL0.
• Note 8: Register tpidrro is present for compatibility reason and cannot be modified from the thread. It
can be obtained through TPIDRR0_EL0 ARM register.
• Note 9: CPSR bit SS is used to do single stepping debugging using the processor. Activating this bit will do
one single step and generate then a breakpoint exception. The bit is unset automatically once the step is
done and MDSCR.SS bit is set by the kernel automatically. The PSP needs to have unlocked the OS debug
lock during boot using the OSLAR register for this to work. If not done, the application will continue execution
instead of doing one single step.
A.4.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, pc and sp represent program counter and stack pointer, and cpsr and regs[30] are used as architecture specific registers 1 and 2.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Mapping Translations 107
A.4.3 FPU Support
UniversalisOS supports the VFP style FPU on ARM processors. The kernel considers that the VFP is always available. UniversalisOS userspace thread context contains parts for FPU and vector units. The ARM VFP contexts 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 UniversalisOS Kernel Reference Manual for further details. When using the UniversalisOS 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 usedfpu of the thread userspace context. If is it not 0, VFP is accessible in user space, and saved and restored upon thread switches and exception handling.
A.4.4 32-bit Execution Environment for SYSEMU
UniversalisOS supports the execution of 32-bit user code on top of 64-bit UniversalisOS as described in the ARM architecture reference manual, however the support is limited to emulation environments only (e.g. SYSEMU), because 32-bit applications cannot use UniversalisOS services (system calls). System calls from 32-bit code always raise a P4_TRAP_SYS exception. Native UniversalisOS applications that have been compiled for 32-bit ARM need to be recompiled for 64-bit ARM. To enable 32-bit mode in EL0, set CPSR_M32 (bit 4) in cpsr in the register context. 32-bit code can only access the lower 4GB of the virtual address space and the lower 32-bit parts of the registers. The register mapping in 32-bit mode is listed in table 24.
64-bit register in P4_regs_t 32-bit register Description regs[0] ... regs[12] R0 ... R12 Register R0 regs[13] R13, SP Register R13, stack pointer regs[14] R14, LR Register R14, link register regs[15] ... regs[30] - not used in 32-bit mode sp - not used in 32-bit mode pc R15, PC Register R15, program counter cpsr CPSR Program Status Register
Table 24: 32-bit mode register mapping
In 32-bit mode, ARM Thumb is supported by setting CPSR_T (bit 5) in cpsr.
A.5 Mapping Translations
A.5.1 Translation of UniversalisOS 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 25 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
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
108 Architecture Dependencies
P4_M_READ P4_M_WRITE P4_M_EXEC Read Write Execute 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 25: Translation of mapping attributes (64-bit)
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.5.2 Translation of Architecture Specific Access Permissions to UniversalisOS Access Permissions
The architecture specific mapping attributes stored in the page tables in the kernel are translated to generic attributes as table 26 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 26: Translation of access permissions (64-bit
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.5.3 Supported Caching Attributes
On ARMv8, the ARM architecture defines the MAIR register so that the number of caching attributes can be greater then what would be possible to program directly on the page table entries. UniversalisOS defines possibilities on the MAIR values which are listed in table 27.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Mapping Translations 109
Entry Value Description Number 0 0x00 Strongly ordered 1 0x04 Shareable device 2 0xaa Normal memory, Write-through, no Write-allocate 3 0xee Normal memory, Write-back, no Write-allocate 4 0x44 Normal memory, non-cacheable 5 0x00 Unused 6 0x00 Unused 7 0xff Normal memory, Write-back, Write-allocate
Table 27: MAIR values
The entry number programmed for the possible UniversalisOS cache attributes combination is explained in table 28.
P4_M_C_ P4_M_C_ P4_M_C_ Mair Description ENABLE WRITEBACK PREFETCH Entry 0 0 0 0 Uncached strongly ordered 0 1 0 1 Memory type device 0 x 1 4 Uncached RAM 1 0 x 2 Cached write through 1 1 0 3 Cached write back without write allocate 1 1 1 7 Cached write back with write allocate
Table 28: UniversalisOS cache attributes entry number
The share-ability is always set for the inner domain and is controlled by P4_M_C_COHERENCY and only modifiable on SMP systems like table 29 shows.
Type P4_M_C_ S Description
COHERENCY
UP x 0 Shared bit always cleared
SMP 0 0 Shared bit cleared
SMP 1 1 Shared bit set
Table 29: Effekt of setting the P4_M_C_COHERENCY bit (64-bit)
Note: Most ARM processors treat uncached strongly ordered memory accesses as implicitly shared.
Note: The inner cache domain is usually the processor. On some system the outer domain contains the processor and some peripherals memory (like the GPU for example).
The attributes P4_M_C_PLATFORM1 and P4_M_C_PLATFORM2 are not supported and ignored.
A.5.4 VMIT Cache Modes
The VMIT cache modes map to settings listed in table 30.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
110 Architecture Dependencies
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 30: VMIT cache modes (64-bit)
A.6 Translation of Architecture Specific Exceptions to UniversalisOS Trap Codes
Table 31 describes specific exception class and gives the reported UniversalisOS trap code. All classes not mentioned are reported as P4_TRAP_ILL.
Exception Class Trapcode Description IABT / PageFault P4_TRAP_SEG Page faults or access violations DABT / PageFault P4_TRAP_SEG Page faults or access violations IABT / Align P4_TRAP_BUS Alignment fault of PC DABT / Align P4_TRAP_BUS Alignment fault of SP or data access FPU not avail P4_TRAP_FP_UNAVAIL VFP instruction and FPU disabled HVC or SMC P4_TRAP_FP hvc or smc instruction done in user mode Breakpoint P4_TRAP_BRK breakpoint instruction hit Step P4_TRAP_BRK Step by step mode return Watch P4_TRAP_BRK Watchpoint hit PC align P4_TRAP_BUS PC alignment error SP align P4_TRAP_BUS Stack pointer alignment error
Table 31: Trap codes of architecture specific exceptions (64-bit)
A.7 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 minimum and default is two pages (0x2000 bytes). There are no special alignment requirements for kernel resources. Table 32 show the allocated pagecount for certain kernel resources.
Resource Size in Units Description Task 3 Task descriptor, thread directory, and L1 page table Thread 1 Thread control block (1 per thread) Pgtable 1 Page table (1 per 2 MB mapping) Pgdir 1 Page directory (1 per 1 GiB mapping)
Table 32: Kernel memory allocate resources (64-bit)
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Cache Handling 111
A freshly activated task without any threads consumes three units, one for the task descriptor, one for the thread directory and one for the L1 page table. A user space mapping created in an untouched 2 MB area needs one unit for the page table. One idle thread is allocated on each CPU. The maximum number of supported interrupts is 1024.
A.8 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 table 33 shows.
Cache Operation Description
P4_INVAL_ICACHE_RANGE Write-back data cache with DC CVAU and invalidate instruction
cache with IC IVAU.
P4_FLUSH_DCACHE_RANGE Flush data cache with DC CIVAC.
P4_SYNC_DCACHE_RANGE Write-back data cache with DC CVAC1 .
P4_INVAL_DCACHE_RANGE Invalidate data cache with DC IVAC. Unaligned beginning or end
are flushed with DC CIVAC.
Table 33: Tp4_cache() kernel API operations (64-bit)
The P4_INVAL_ICACHE_RANGE operation also invalidates branch prediction. To handle aliases in virtually-indexed, physically-tagged or ASID-tagged virtually-indexed, virtually-tagged instruc- tion 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 instruc- tion cache using an IC IALLU instruction on single core or an IC IALLUIS instruction on multi core systems. Typically, cache instructions like DC CIVAC affect all levels of caches in a system and the flags parameter in p4_cache() is ignored. 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 UniversalisOS Platform Manual. 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
IC IALLU.
• VM_SCF_FLUSH_DCACHE: Flush the whole L1 data cache on the current processor using DC CISW.
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 UniversalisOS Platform Manual. The p4_inval_icache_range(), p4_flush_dcache_range(), and p4_sync_dcache_range() func- tions are implemented as user space library calls. The p4_inval_dcache_range() function calls p4_cache() internally. 1 On Cortex A53, DC CIVAC is used to work around errata in the data cache.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
112 Architecture Dependencies
Note: Due to ARM errata 826319, 827319 and 824069 on Cortex A53, the current cache sync implementation is actually doing a cache flush . Note: When UniversalisOS is executed in a virtualized environment, or when UniversalisOS is running in the non-secure processor state, data cache invalidation may also write-back any data before invalidating the cache, making DC IVAC equivalent to DC CIVAC. Any code using data cache invalidation should be written in a robust way that write back of previous data is acceptable.
A.8.1 ARM Errata 835769 and 843419 on Cortex A53
Workarounds in GCC compiler for ARM errata 835769 and 843419 are activated by passing the arguments -mfix-cortex-a53-835769 and -mfix-cortex-a53-843419 to the compiler by default. Those flags are activated for kernel and all libraries provided with UniversalisOS and have no impact when the system is running on other types of cores (A57 or A72).
A.9 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 Speculative Execution Side Channels Mitigations - Meltdown and Spectre
UniversalisOS 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 UniversalisOS 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 mitigation is currently available. A mitigation against CVE-2017-5754 Meltdown "Rogue Data Cache Load" is not available in UniversalisOS. This issue only affects Cortex-A75 processors. A mitigation against Meltdown "Speculative Read of System Registers" (Variant 3a) is not available. ARM believes 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-A57 and Cortex-A72 processors. ARM provides documenation and suggested mitigation techniques for the processor vulnerabilities. Please check https://developer.arm.com/support/security-update for details.
A.11 Compile Applications without FPU
If one of your function is using varargs like a printf equivalent function the compiler will generate FPU instruc- tions even if you don’t use explicitly floats.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
Detection of Heterogeneous Processor Cores 113
To prevent the compiler from doing that, you must add the argument -mgeneral-regs-only to gcc. This flag will instruct the compiler to only use general registers and not the FPU registers.
A.12 Detection of Heterogeneous Processor Cores
For heterogeneous processor configurations, such as ARM big.LITTLE, UniversalisOS 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-A57 versus Cortex-A53. 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.13 Known Limitations
There is no known limitations on this architecture.
c Copyright 2005 – 2019 Portugal Futurista 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/universalisos-D5.0/demo/fusion-kernel and /opt/universalisos-D5.0/demo/fusion-pssw directories. The example PSP projects are located in the /opt/universalisos-D5.0/demo/psp directory.
Board Name Kernel Fusion PSSW Fusion PSP foundation-armv8-hwvirt cortex-a5x-hwvirt standard cortex-a5x foundation-armv8 cortex-a5x standard cortex-a5x fvp-a5x-hwvirt cortex-a5x-hwvirt standard cortex-a5x fvp-a5x cortex-a5x standard cortex-a5x ls1043a-rdb-hwvirt cortex-a5x-hwvirt- standard cortex-a5x layerscape ls1043a-rdb cortex-a5x-layerscape standard cortex-a5x ls1046a-rdb-hwvirt cortex-a5x-hwvirt- standard cortex-a5x layerscape ls1046a-rdb cortex-a5x-layerscape standard cortex-a5x universalisos-hwvirt-v8hf universalisos-hwvirt- standard cortex-a5x arm_v8hf qemu-arm-v8hf cortex-a5x standard cortex-a5x zynq-zcu102-hwvirt cortex-a5x-hwvirt- standard cortex-a5x ultrascale zynq-zcu102 cortex-a5x-ultrascale standard cortex-a5x
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.
c Copyright 2005 – 2019 Portugal Futurista GmbH, all rights reserved.
115
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 Portugal Futurista GmbH, all rights reserved.