 Hello everyone. Welcome to today's talk on the topic of Contributing to Automotive Service as part of Google Summer of Code. I am Sankho Voron-Gos and along with my course speaker Anmol, we are going to present this topic. My Google Summer of Code project dealt with integrating the Metaraus layer with Automotive Great Linux to support robot operating system. A little bit about me. I am an electronics and communication engineering undergraduate student at Thapa Institute of Engineering and Technology, Patiala. I am currently in my final year. My interest varies a lot from robotics to embedded system and autonomous vehicles. I have been associated with Automotive Great Linux since the past two years. I was a Google Season of Dogs student last year and I recently completed Google Summer of Code this year. A little bit about my G-sub project, a brief about it. So the main two tasks of my Google Summer of Code project was to integrate the Metaraus layer with ATL to support ROS. And the second was to port the VID LiDAR to driver for it to be compatible with my integration. And there was a third task which is currently a work in progress that was to develop a LiDAR visualization application. I was mentored by the very supportive Jan Simon Moller and Walt Minor from the Linux Foundation via this project. I currently lead the data visualization team at the Formula Student team for the of my university. I joined this team as a sophomore and they really did provide me with the relevant background. For those of you who don't know what Formula Student is, it is an undergraduate design competition, engineering design competition. This competition happened worldwide over many locations, many countries and we are judged on making a prototype open cockpit formula style racing vehicle. For the same, we required a robust platform that could handle new latency data communication currently and concurrently build the level enough for automotive data acquisition. We did our experimentation on the Raspberry Pi road driving board and the ultimate goal of our team is to develop autonomous electric vehicles for the same Formula Student competitions. Now here are some clips that shows the fun time that we had during the V-Speed sensor testing and you know we also prepared a makeshift rig testing rig using the disk policy as you can see here and here I am checking out the Canvas interface. So working with Formula Student team was a very hands-on experience and it intrigued me and during the research I came across Automotive Grid Linux. That was my starting point of my journey towards eventually getting into the goals of course. So like in 2020, at the start of 2020, I was repeat with Automotive Grid Linux and eventually I started attending the weekly developer calls and talking with the mentors, talking with the contributors and I saw this opportunity of global seasonal dogs and so I thought let's try this right and so I talked with the mentor Jan Simon and he instructed me that the current problem that they're facing at that time was that the documentation was very hard to maintain and it was kind of a mess and so my GSOD project was to rework the documentation hosting and generation. So the new documentation side is generated using MkDogs and we are using Garrett for storing our for repositories and read the docs for hosting our site and the main aim of the Unideveloped Documentation website is to be developer friendly. That was the main thing that we had in our mind. The second task was for me to restructure documentation content and rewrite getting started and developer guides. So this experience provided me with a very hands-on and relevant background to actually contribute to EGL in a meaningful and systematic way and you know this was the earlier setup documentation. So we have multiple repositories and a lot of things are going on here kind of complicated for a new for a newcomer to you know for a new contributor to get a job and this was the setup that I proposed in my GSOD proposal and so now this is supposed to don't get it and it has a single repository different branches for different releases of the distribution and yeah so my main job was to simplify this and rewrite the documentation. Now coming back to my whole somewhat of code project I would like to talk a bit about the fundamental technological stacks that we use for you know building EGL and how they are relevant to my project. The first technology that I would like to talk about is the Yocto project. EGL is being built using Yocto and the Yocto project is a project maintained by the Linux foundation and it consists of the open embedded core and the pokey reference distribution and pokey itself consists of the open embedded build system and plus meta data and meta data as you can see are set some instruction that you know define how exactly can we build an image you know how the build system can parse the image and it consists of various recipes, configuration files and instruction to build the image. Okay now coming to the open embedded build system right we have you know it consists of BitBake and open embedded code right now BitBake is the main task scheduler, execution scheduler, it is the main engine that works with our recipes that have to be written in a specific format right and they perform the set of tasks and the open embedded code is a common layer across all the open embedded derived systems including the Yocto project and consists of meta data like recipe classes and associated files and these are meant to be common across different open embedded systems. So the particular use of using Yocto is that you know packages are grouped into layers and recipes are part of layer right so there is a great deal of modularity with this project and so these layers are nothing but you know individual pieces of software and they are a different kind of repository of folder and multiple recipes can be presented within each layer so you know so the modularity helps and you know we can just plug and play and with a little debugging you can get different packages installed in the operating system from to get on right and so there are different components of the Yocto project you know we have four types of files that we have to edit and play around with data relevant features in the operating system so the first one is the configuration files you know it defines the global definition variable and you know the type of machine that we want the global variables the across the build system the build parts the compiler flags and then we have the bb class the classes file and it is basically encapsulation inheritance of the build logic that how can we build the next generation of dark end packages and whatever packages that we need and how to create the root of this image next we have the recipes also the bb flags and these are the logical unit of the software you know the images to be built the individual pieces of software to be built and so they consist of the what packages would be included in the final system image right and the last is the layers the bb layers and these just contain them well deleted metadata and these are just you know sets of recipes so yeah these are just the longest of this we call the monthly system as per our liking now coming to automotive Linux how does it connect with the optimal management right the automotive Linux is an open source operating system right this project is being hosted at the Linux foundation and it is a framework for automotive application which is being developed using the york to build it right so it's a framework for automotive applications and so it provides 70 to 80 percent of the starting point for a car manufacturer to be involved to actually make their own flavor of operating system yeah and so the benefits are using york to amend right so we can develop using common Linux operating system for all major architecture and ports it's a really you know convenient for the developer as you can build across major architectures and ports and the flexible and the modular framework allows for using a software right there are number of n number of collection of layers and recipes right as i mentioned that you know across major across different boards so changing the hardware platform is also very easy due to the presence of board support packages and these board support packages are being provided by the manufacturer of the boards so the developer has to you know just add the layers and just get it working so it's a very convenient way now coming to the meta loss layer yeah so the loss development team added the support for the meta loss layer for it to be relevant to the york to build up yeah so the meta loss layer consists of over 400 recipes for different packages these packages are dependent on the open embedded layers right and this is the link where you can go and check out the meta loss package and the meta loss layer was split into multiple different layers right you know they consisted of loss one and loss two distributions and these with the three main layers which the meta loss layer consisted of and the meta loss common dealt with the common recipes for both the loss and loss two the meta loss layer dealt with recipes regarding the melodic and the neutral distributor so these are the loss one distributions the meta loss two they are dealt with the recipes for loss two distribution like dashing eloquent foxy and galactic so my objective was to integrate the meta loss to foxy layer into the automotive grid and linux layers the gel layers so talking about the meta loss to foxy it was a long term support release released on 5 june 2020 like there was a near there was a latest release of the galactic but it's end of life possibly than foxy so we chose who will foxy right right and we needed something to test out or integrate is it even working so we used LiDAR and I think everyone knows that LiDAR is one of the fundamental technologies that is being used by the you know autonomous vehicles and the whole robotics industry and it is basically a technique to use a laser and triangle and use time of flight based concept for distance measurement and triangulation based measurement and yeah so we can you know generally get an output of point cloud carrying range and distance specific information okay so the LiDAR which I received from you know the linux foundation I mean they were very helpful with me and they provided me with this yd LiDAR x4 which is a low cost pretty LiDAR and which is a great which is a great gadget gizmo to get actually started with the development yeah it really provides you with the handsome experience that you need and it was really interesting yeah right and so basically x4 is a triangular principally principal base LiDAR it has a rotating platform that carries laser emitter and receive lenses and yeah so the output from the yd LiDAR are very suitable to build maps do slam simultaneous localization and mapping and build 3d models and very relevant with respect to low cost robot type so yeah so this yd LiDAR x4 I received that and this is my bit chumbled set up with many wires and I have the Raspberry Pi here and it was a very interesting thing so this was one of the things that I do did when the LiDAR I tested out the ROS drivers the normal ROS driver in the Ubuntu system and yeah so I was getting the map of the room in which I was setting it and this is a 2D map as you can see right so the second objective was to port this yd LiDAR and be it compatible with the digital and metal os integration right so let me check if even if the integration is working or not so now I'll talk about what exactly happened in the project and you know here is my timeline right so yeah so you know in week one and zero I received the LiDAR and you know I worked on you know in all on normal operating system like Ubuntu and you know Raspbian which is the default operating system for Raspberry Pi right and worked on using them first I worked on you you know you getting yd LiDAR started with ROS and then I moved on to ROS 2 right yeah so that was just me getting my hands dirty with the yd LiDAR ecosystem and the ROS ecosystem right so eventually in week two you know I built I built I was successful I was successful in building and running the meta ROS layer with the agile image minimal right so this is just the minimal image of the agile distribution and yeah so I was successful in building it for both Qmo and Raspberry Pi so yeah there was a big win you know in week two itself right so eventually I tried why not let's you know go full-fledged in week three and just get this over done you know build it on agile demo platform but no that didn't work right I tried it on the Raspberry Pi you know as we were boots of a package and that didn't work that field so yeah so my mentor advised me to first try it using the agile you know western image so this is uh you know this doesn't contain the f-frame work and everything else so this is this just contains an affluent interface and I thought and my mentor and we agreed that this is a good starting point to get started so we built the image you know the meta ROS layer using that and it was a really fun time and yeah I was successful in building that yeah so eventually so now we have the we have the ROS support in the agile image western right so now the now the time was to you know add support for YD Lider and yeah so I was successful in doing that too right I had to write up some codes uh some recipe and yeah it was a good deal right and yeah and then I focused on you know trimming the meta ROS right I removed some layers which were not seen necessary and which were just boating out software stairs so yeah so I removed some I trimmed the meta ROS layer and which you know and we were just a bare bone meta ROS layer and it had contained the YD Lider support right eventually we you know we tested this this core support with YD Lider core dependencies and yeah so the next two weeks we are mainly focused on that you know to getting the uh streamlined meta ROS layer working with the driver for YD Lider and I had to do some modification here and there and we were able to do that the last weeks focused focused on packaging them and you know presenting our work documenting them and this led to the creation of EGL ROS to YD Lider feature template and that contained you know meta ROS easily major western and YD Lider support right and eventually we also made the package group EGL ROS to Lider to simplify embedding your meta ROS on YD Lider so now it's just a template and it consists of package group you can just go in there and you know edit out some features and it reads directly and in the last week you know get it changed request was submitted and eventually it was accepted and it's now a part of the EGL framework right and currently we are also planning to develop the Lider visualization application with YD Lider as well as embed right now here is the image of the final product that I submitted for review and get it and you know this is basically the meta ROS to layer and it provides support for ROS to minimal and YD Lider and you know after multiple weeks of review and multiple changes this was finally merged in the EGL get a repository and to sum it up it was a great learning experience it was a great experiential experience and I would like to thank my mentors Jan Simon Moeller and Walt Milo for all the support that they have provided me and it was a good summer for me and here are some of the resources and references that you can refer to here to know more about the project and to get a good idea especially you know the page and the proposal are a good starting point if you want to know a bit about more about this and thanks for joining my talk and I would like to pass over on to one more. Hello everyone so today's topic is integrating and porting of vertio block over iVision in EGL with JL house so this topic falls under the main topic which is contributing to automotive software as a part of EGL summer of code so previous talk was of Boron's talk about his contributions to the EGL summer of code and the automotive rail limits and this talk will be about my contributions to this for the same okay so about me so I am a final year engineering undergraduate student and information technology and my interests are low-level programming operating systems and Linux kernel and I was a Google summer of code 2021 student at the Linux foundation and under the automotive grid linux okay so my GSOC project was based on the vertio block over iVision in the EGL with JL house right and my mentors were Mr. Jan Simon Muller from the Linux foundation and Marco solidly from University of Modena and Reggio Emilia right okay so why this project so the main motivation for picking up this project is that I was searching for a project similar to the JL house and its extensions and I found a project listing on the GSOC page of the Linux foundation and found that this project's aligned very best with my interest because at that time I was also working at the similar kind of project at University of Modena and Reggio Emilia so that was the main motivation for getting started with this particular project okay initial plans and extensions so initially we have listed down some plans to be worked on in the coming months and these are the some gist of those plans and so I will discuss it one by one so at first we decided to pick the kernel tree which has all the patches required for the JL house enablings and the vertio patches so JL house enabling kernel is the kernel which has patches required for running the JL house properly and vertio applications and so we decided to first work on that part and then we decided to configure configuration of the root cell and guest cell files because that was the crucial part for the whole implementation and integration part next was the improvement of the JL house as JL house support was recently added so improvement is very necessary for it and next was improve the JL house root cell and non-root cell configurations for the cumulation with it because at end we need target image to be cumulated and so that we can test our setup and communication protocols with the help of this particular target image and cumulated image and then the support for the vertio that is the main part which is the configuring and added support for the vertio over IVSM in the root cell and the guest cell part so that communication can be established and finally we planned to document everything from changes made to how to reproduce the whole setup so that anyone who is new to this particular thing can easily reproduce that particular setup and also customize it according to their needs. Okay so Automotive Linux so as Boran already discussed that what is Automotive Linux as you already know this is the Automotive Linux Summit and so this is basically an operating system open source operating system which is used in a variety of vehicles for their core OS and managing their functionalities and this particular operating system is developed using the YAKTO project YAKTO slash open embedded project because some parts are there in the YAKTO for the open embedded part so yeah and benefits of using YAKTO are because it's available for the all major Linux OS and all major architectures and very flexible and it's very intuitive to do YAKTO project in comparison to other build tools available in the market. Okay so the next part is Jailhouse so Jailhouse as the main we can say the base of this full project because Jailhouse is a hypervisor which is developed by Siemens and it's a static partitioning hypervisor that is which can I will explain more about static partitioning later so for now it can run bare metal binaries and real-time or safety critical task on AMP systems and it's cooperated closely with Linux because if you have already read about Jailhouse or know about Jailhouse or new to Jailhouse let me explain it basically is a static partitioning hypervisor which loads its stuff on top on beneath the Linux and it works in between that is first comes Linux then Jailhouse after loading and then beneath the Jailhouse there is a hardware part or resources which needs to be allocated and next point is split existing hardware resources into isolated cell compartment called isolated compartments called cells so it basically isolates all the cells and cells basically here is virtual machine right so at first it has it loads itself into the Linux and then after when we load try to load the guest cells or well guest virtual machines it will separate some resources or allocate some resources to that particular guest and then from there it again then isolates from the root cell Linux right it provides bare metal like performance and latency that's the reason why AGL also shifted to shifting to this hypervisor because of its performance and latency is for that the for the hardware assisted virtualization and other cell borrow CPUs and devices from the root cell as they are created so this I already discussed it borrow CPUs and devices from the root cell as they created accordingly right you can find more about the Jailhouse in that link because it's available it's open source yeah whatever I explained is explained in this picture because first linux then CPU then Jailhouse hypervisor loaded and after that if we try to run the guest cell it will look like that that is a half one is the root cell and another half of this cell is it will change it can change according to the CPUs available that is CPU 1 0 1 2 up to n CPUs and according to that it will allocate the its resources right yeah Jailhouse integration with AGL that's the that's the history I listed whatever the things added in the Jailhouse and how it initiated so it it was first initiated in the Gsoc2 that is the previous version of the Gsoc and the things which were added was added the Meta-AGL Jailhouse layer into the Meta-AGL double layer of the AGL and the support for higher memory variant for Raspberry Pi that is support for the memory variant greater than one GB for the Raspberry Pi versions and some other things which are added were Jailhouse root cell configurations according to the AGL setup and in mid configuration files for the ARM and X86 based modes and architectures and in Gsoc 2021 I worked on adding the inter-cell communication via Word.io with IVshem for the implemented by the Jailhouse guys and I voted all of these and added some extra patches on top of it to get it working okay okay so what is Word.io so Word.io basically is standard for network and disk device in which the guest device driver knows that it's running in a virtual environment it's if you know about full virtualization and para virtualization you will get understanding that how full virtualization and para virtualization works that is in para virtualization there is a need for some code to let it know that yeah it's working on some this particular environment and full virtualization is totally native right rather than have a variety of device emulation yeah it's the main point that rather than have a variety of emulation mechanism for network block devices where to provide a common frontend so that code can be usable usability can be maintained right yeah okay so next is what is IVshem so in Word.io and IVshem right so what is Word.io block and IVshem what I already discussed and let's move to IVshem so IVshem is a basically intro VM shared memory device right and designed to share between the multiple QM processes running different guests and hosts that is let's say we have a common memory region which are shared between different processes so that particular shared region can be accessed by different guest cells with the help of some transporter let's say with the help of some middleman device which here we can see as PCI device which can create some mapping to that particular device and every guest cell can access to that particular region with the help of some help from a middleman device right here I there is a PCI bar there are different types of bar 0 bar 1 and here bar to match the shared memory object that is the whatever the shared memory object is present it maps to that particular object so that communication can be possible okay the device can use a shared memory object on host directly or it can obtain from one from an IVshem server so the device which needs a shared memory which can it can access from that from the host directly or it can obtain from an IVshem server present in the Q emulating device like QMO etc right next thing is yeah so vertio over IVshem so this is the part which we which I worked on so basically it's it's totally implemented by the jailhouse guys and it's currently experimental but it has some things which we can I have we have added to so that we can have a good understanding of how it its development will undergo in future so that's why we picked this particular particular one for the communication part so let me explain one by one so there are three parts to it right the one is front end part then there is a transport part then there is a back end part right so vertio IVshem at center front end part which provides the transport through the back end part that is your IVshem and we can access the back end service with the help of vertio IVshem block and console right so it's basically a user space application linux application we can say which can you can find in the qslashjailhouse qslashjailhouse.14 in the git.kisga.org or liankisga's kernel tree and you can find those both of them you can just compile it and use it accordingly so these are the applications of that and for more details I know for time constraint I have explained very little but for more details you can refer to these below links which is meta agile jilhouse markdown and jilhouse manual config markdown and jilhouse manual config markdown is for custom usage and meta agile jilhouse is I have defined everything from scratch so that new user can pick up easily this is the initial diagram as you can understand that there is a root cell then block back end then shared device and then shared memory region whatever request we pass it through then it will goes through a queue and then block back end then jilhouse hypervisor then yeah it can rework back accordingly according to the request made right and clear the queue and then again fill the queue okay so RAM reservation part so RAM reservation part based on the thing that how your configuration file should how much RAM your configuration file should be allocated right this memory this layout you can see that RAM for Linux hypervisor code and data RAM for non-cells these are all we have to pre-mention so that it can easily access those because as you know jilhouse static part in the hypervisor we have to mention things that this much amount of RAM is required this much amount of this is required so that can actually leave from there right and for x86 systems we have memmap and size dollar address and for ARM systems we have physical size minus reservation part and extra devices we can add this in device trees this is for if you know ARM and ARM system for boards only and for graph we have to escape the dollar sign with the help of these slashes right and this is the basically summary of that whatever I have discussed that is escape the drop to with the help of if you want to add this particular command line option in the drop to then you have to escape this particular okay so this is my weekly timeline for whatever I have did and whatever I have done in the TSOC period and from week zero one two three four and five I have listed whatever things I have done starting with the build errors and a lot of build errors my mentor Jan Salman helped me a lot with those build errors and providing me the machine capable of doing all these builds and at starting I was started with building a deal with jailhouse then progressed up to testing the particular images and then testing the kernel for the with the jailhouse in my enabling plus IV sham which is now merged in the Q-slide jailhouse and creating separate recipes for the kernel so that only that particular kernel should can fetch should be fetched so these are all the things which I did at the starting and then again after completing all these tasks I moved to the main part that is integrated devices to the root cell and non-root cell configuration so that what the IV sham communication can be established right so as you can see these are all my timelines for the V0 to V5 okay so for week six to week 11 I focused mostly on the improving the cumulation for the agile target image so I improved the networking part and memory addressing part and also starting working on the integration of the devices for in the root cell configuration and the main non-root cell configuration or guest cells and after resolving all these errors some things were working and I tested it properly and after testing and everything I upstreamed all the code and yeah it's not available on the agile repositories you can check it out and just test it out and yeah okay so these are the patches if you want to get some reference I have also included the documentation part for it so that you can get easy access to whatever I have done and also give me some suggestions on how I could improve those so that it can be usable more usable and more efficient in future and I'm yeah I'm open to suggestions for that because yeah and these are some patches and this one is the patch for the updating the JLOS configuration in this patch I have done the initial outlines like required for integrating the actual implementation part that is as you can already see that I have just updated the previous files previous configuration files which were added in the previous result just updated and corrected some things and and added more things to be more robust and good added some documentations for easy understanding of everything so yeah this patch was for that and next patch as you can see it adds support for what I mean what I over I wish I'm part that is adding the PCI devices for the exposure of that particular shared region and then added documentations and the recipe files package groups for the Linux applications for for accessing the backend part so everything was in this patch you can just go and see all these patches and yeah so just some changes there is some mistakes and some things required to make it more good with the current versions learnings this is the most important part I learned a lot in the whole process I learned a lot about the Agile Instructure Agile applications I'm fascinated with the Agile applications very much because yeah it's very broad and its development workflows review process everything was very good I learned so much about I feel I felt like professional I felt like in the professional environment working with some serious software development stuff and due to this particular thing I also improved my research abilities and also covered some different applications of the what I wish I'm and what I or in general and got exposed to may various hypervisor gem aka ACR, ICR and DPDK etc and a lot more also again some knowledge about virtualization build systems in general that is YAKTO specific requirements would relate to an Indian host and I was primarily working on the x86 so mostly learned about those things as well so it was a great learning experience for me this challenges yeah a lot of challenges at first I was struggling with builders but Mr. Yalzano helped me to remove all those and focused on the main stuff so very thank you to him and I was also fortunate to get it workflow because before that I was mostly in the kernel and github's development workflow but yeah get it workflow was similar so it was it was a worth learning experience and due to mentors I was able to make a balance between academics GSOC and a visa career and project mentored by Mr. Professor Marco Sololi which was also a due to jailhouse so I was able to manage between the project I was working at the hyper lab at Unimor and also this particular GSOC project so yeah it was a very good learning experience. Future work was related to the RTOS and one because I was also mentioned that RTOS would be should be there but yeah next GSOC will able to catch that up as well and next was Jailhouse as I already explained that Jailhouse is the main branch but yeah they are now shifting to a more stable branch for the upcoming so about GSOC. GSOC is basically open source program which helps developers to get open up into the community open source community and help establish the communication between the new developers and old developers so that they can be stay long in particular organization so GSOC create a program to bring all those developers new developers into same area and assign them projects and make them work on them some projects along with this type and so that they get some motivation and as well as some real world exposure to the software development and serious software development so it was a very good program if you are new to the development or already working in development you should definitely try mentoring it or just you can advertise a mentee as well. So for more about GSOC and you can already for more about GSOC you can go to that particular link and due to time constraint I cannot explain very much but yes you can go to this particular link and you will get everything you know you have to know about you should know about the GSOC but I would say GSOC was a very worthy experience for me and I would recommend everyone yeah these are the some resources and references and yeah thank you very much thank you everyone for joining and this was my first talk in this huge conference so if I have done any mistakes please bear with me and I hope this session is some helpful to you as well and I hope to produce some similar type of talks in future in this similar open-source conferences thank you