Automotive Whitepapers: Difference between revisions
From Xen
Jump to navigationJump to search
No edit summary |
Lars.kurth (talk | contribs) mNo edit summary |
||
(6 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
* [[:File:Co-processor_management_under_xen.pdf|Managing coprocessors for Linux PV domains by running a Xen hypervisor on ARM platforms]] by Andrii Tseglytskyi ''2015-01-14, GlobalLogic'' |
|||
⚫ | {{Quote|As modern ARM SoCs become faster and faster, they are now capable of performing the same highload tasks that desktop PCs were performing a few years ago, such as HD video playback and highspeed graphic rendering. The structure of an ARM SoC is also now quite complicated. In addition to containing a CPU module or modules, it also includes several peripheral modules (e.g., UARTs, Wireless, HDMI ports, etc.) and coprocessors that are designed to help with highload tasks like Graphic Processor Unit (GPU) or Video Processor Unit (VPU) are assembled together with the main CPU on almost all modern ARM SoCs that are designed for mobile and automotive markets. The article will cover few aspects of sharing such coprocessors when running Xen on embedded SoC.}} |
||
* [[:File:AGL_software_defined_car_jun18.pdf|The Automotive Grade Linux Software Defined Connected Car Architecture]] ''2018-06-18, multiple contributors'' |
|||
{{Quote|AGL Virtualization Expert Group (EG-VIRT), a team of virtualization professionals active in the AGL community, presents the AGL virtualized software defined vehicle architecture. The objectives of this white paper are: |
|||
● Disseminate automotive virtualization inside and outside AGL |
|||
● Identify virtualization use cases, requirements and solutions for AGL |
|||
● Define the AGL virtualized software defined vehicle architecture |
|||
EG-VIRT desires to build, connect and combine together open source virtualization solutions around AGL to provide a modular virtualization infrastructure which boosts the creation of innovative advanced driver-assistance systems (ADAS), in-vehicle Infotainment (IVI) and telematics products.}} |
|||
* [[:File:DriverDomainonARM01.pdf|Driver Domain on ARM]] by Andrii Tseglytskyi ''2015-08-06, GlobalLogic'' |
|||
{{Quote|In the following article I want to describe GlobalLogic’s team experience of bring-up a driver domain on ARM platform. The results that we have achieved with a driver domain were introduced at CES 2015 show and GENIVI event.}} |
|||
* [[:File:RT-Xen on ARM.pdf|RT-Xen on ARM]] by Denys Drozdov ''2015-03-10, GlobalLogic'' |
|||
⚫ | {{Quote|The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.}} |
||
* [[:File:Device_passthrough_xen.pdf|Device Passthrough to Driver Domain in Xen]] by Yurii Konovalenko ''2015-02-25, GlobalLogic'' |
* [[:File:Device_passthrough_xen.pdf|Device Passthrough to Driver Domain in Xen]] by Yurii Konovalenko ''2015-02-25, GlobalLogic'' |
||
{{Quote|As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.}} |
{{Quote|As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.}} |
||
* [[:File: |
* [[:File:Co-processor_management_under_xen.pdf|Managing coprocessors for Linux PV domains by running a Xen hypervisor on ARM platforms]] by Andrii Tseglytskyi ''2015-01-14, GlobalLogic'' |
||
⚫ | {{Quote|As modern ARM SoCs become faster and faster, they are now capable of performing the same highload tasks that desktop PCs were performing a few years ago, such as HD video playback and highspeed graphic rendering. The structure of an ARM SoC is also now quite complicated. In addition to containing a CPU module or modules, it also includes several peripheral modules (e.g., UARTs, Wireless, HDMI ports, etc.) and coprocessors that are designed to help with highload tasks like Graphic Processor Unit (GPU) or Video Processor Unit (VPU) are assembled together with the main CPU on almost all modern ARM SoCs that are designed for mobile and automotive markets. The article will cover few aspects of sharing such coprocessors when running Xen on embedded SoC.}} |
||
⚫ | {{Quote|The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.}} |
||
[[Category:Embedded and Automotive |
[[Category:Embedded and Automotive]] |
||
[[Category:OpenEmbedded]] |
|||
[[Category:XenARM]] |
[[Category:XenARM]] |
||
[[Category:Whitepapers]] |
Latest revision as of 16:52, 14 May 2019
- The Automotive Grade Linux Software Defined Connected Car Architecture 2018-06-18, multiple contributors
AGL Virtualization Expert Group (EG-VIRT), a team of virtualization professionals active in the AGL community, presents the AGL virtualized software defined vehicle architecture. The objectives of this white paper are:● Disseminate automotive virtualization inside and outside AGL ● Identify virtualization use cases, requirements and solutions for AGL ● Define the AGL virtualized software defined vehicle architecture
EG-VIRT desires to build, connect and combine together open source virtualization solutions around AGL to provide a modular virtualization infrastructure which boosts the creation of innovative advanced driver-assistance systems (ADAS), in-vehicle Infotainment (IVI) and telematics products.
- Driver Domain on ARM by Andrii Tseglytskyi 2015-08-06, GlobalLogic
In the following article I want to describe GlobalLogic’s team experience of bring-up a driver domain on ARM platform. The results that we have achieved with a driver domain were introduced at CES 2015 show and GENIVI event.
- RT-Xen on ARM by Denys Drozdov 2015-03-10, GlobalLogic
The paper analyzes the latency of OS scheduling for symmetric and asymmetric multi-processing support cases – as well as incoming packet handling in Xen – using default credit and real-time schedulers. It also demonstrates how the real-time scheduler affects latency. With RT-Xen support, most of the incoming packets are predictably handled within 1 millisecond with a small overhead at the destined guest OS, which is a feasible time bound for most soft real-time applications.
- Device Passthrough to Driver Domain in Xen by Yurii Konovalenko 2015-02-25, GlobalLogic
As we all know, one of the most common sources of OS crashes are hardware drivers and the issues with them. On systems with visualization, it seems logical to create a separate domain and place hardware drivers (or at least the buggiest of them) there. One of the most significant tasks of creating a system with such a driver domain is to correctly provide it with resources (e.g., IO memory, IRQs). The main idea of passthrough described in the paper is to grant access for DomD through Dom0.
- Managing coprocessors for Linux PV domains by running a Xen hypervisor on ARM platforms by Andrii Tseglytskyi 2015-01-14, GlobalLogic
As modern ARM SoCs become faster and faster, they are now capable of performing the same highload tasks that desktop PCs were performing a few years ago, such as HD video playback and highspeed graphic rendering. The structure of an ARM SoC is also now quite complicated. In addition to containing a CPU module or modules, it also includes several peripheral modules (e.g., UARTs, Wireless, HDMI ports, etc.) and coprocessors that are designed to help with highload tasks like Graphic Processor Unit (GPU) or Video Processor Unit (VPU) are assembled together with the main CPU on almost all modern ARM SoCs that are designed for mobile and automotive markets. The article will cover few aspects of sharing such coprocessors when running Xen on embedded SoC.