 Okay, thank you for joining us. This is the last session of today. So after this session, so we will have a reception party at the sponsor booth. So I have prepared the demo related to this session at the AGL sponsor booth. So thank you, thank you very much AGL sponsor community. So if you are interested, I would be happy to come to the AGL booth. So anyway, now let's begin the session. So I would like to introduce myself. My name is Hirotaka Motai. I have about 20 years of experience in embedded Linux and real-time operating systems. I specialize in time sensitive software, performance tuning, and interested in automated testing. So in my company, I'm in charge of the leading project with technical expertise. The department I belong to is IoT Engineering Business Unit. We had some Linux kernel and distro developers and make a commercial embedded Linux with technical services. We also work with many customers to apply Linux to the products. And I'm also the CIP representative of my company. So anyway, what I would like to talk about here. First, I will introduce CIP, Civil Infrastructure Platform Project and AGL, Automotive Grade Linux as a relevant OSS project. Next is I will explain the challenges faced in this context and present the proposed solutions. After that, I will show the feasibility study to add CIP kernel into AGL because AGL is a code first. And I would be greatly happy to hear any feedback of my activity. So finally, I will summarize of this session. First, I'd like to introduce CIP and AGL as a bridge version. So CIP is again, I say again, CIP is Civil Infrastructure Platform Project. CIP aims to establish an open source based layer for software used in industrial applications. That enables the real eyes of software components that can be used in industrial infrastructure systems. And CIP is open source Linux based contribution project and it's hosted by the Linux Foundation. So Civil Infrastructure has a very unique program. In this example of power plant control, it's an example of power plant control. Development time is 3 to 5 years and customer facing changes takes 1 to 4 years roughly. There are supply period of 68 years. After that, there is 15 years of hardware maintenance. Product lifetime range from 20 to 60s. It is not enough to survive for a long time. Industrial grade quality is always requested, such as robust, secure, and reliable. To achieve this industrial grade quality, CIP has several collaborative activities. So I'd like to introduce some activities. One is a super long-term supported kernel development. The CIP kernel team works on a three-in-first policy. The current team added feature and bug fixes to mainline and LTS kernel. These commits are included in the LTS kernel. So the LTS is used as a base of super long-term support kernel, so SLTS. Any bug, additional drivers, for example, if CIP members want, that bug port from the latest upstream. So it's working. We work on the policy of polystyrene first. So another activity is testing. The test working group uses Lava and kernel CI to test the CIP kernel around the user land. So we published the result of our test on the kernel CI website. CIP has other activities. Please visit CIP website if you want to know. Okay. So all of the CIP activities make a layered Linux distribution for industrial products. So we contribute the related open source project. So CIP developers under the policy of upstream first. So the result development with upstream used to create an open source space layer. So CIP knows that working together with a related community is very important for a long time. So change the topics. I'd like to introduce AGL. But I know the main topics of AGL was already talked in today's second keynote. Maybe you know. I'm not sure it remains to explain again. But let me introduce AGL quickly. So AGL is a leading open source automotive software project. And the first target as IVI. And now it's also covered SBB and IC. Sorry, IC. Same as CIP, it is also, sorry, it is also an open source Linux based contribution project hosted by Linux Foundation. So AGL consists of layer structure to keep isolation and easy to expand the functions. So and AGL project uses the LTS version of the Linux project to create the UCB unified code base. So UCB board support package consists of various meta layers provided by OSS community or SOC vendors. And if some changes are needed and they create other layer and include the changes to the new layer. So I have introduced CIP and AGL. So next is I would like to explain the challenges I have to I have in mind. So requirements for the car software in vehicle software OS as well. So first, real time capability. So in vehicle software requires high real time responsive. It needs to be able to response immediately to input. For example, the brake light should eliminate it instantly when the brake pushed. So safety, next is safety. In vehicle software, it plays a critical role in driving safety. So it needs to be high reliability. For example, it must ensure the ensure the ensure sorry ensure correct timing of airbag development and accurate brake control to prevent malfunctions. So after that, reliability. In vehicle software should operate reliability for extended periods. Malfunctions or crashes can cause significant issues while driving. So stability is critical. So next is scaleability. In vehicle software, it needs to be able to adapt to evolving automotive functionalities. It should support the additional of new features and easy accumulated hardware changes. So security is also important in vehicle software must be protected against malfunction attack and unauthorized access. Proper security security measures are essential to prevent unauthorized control to access to vehicle system and data. A lot of requires here and to meet these requirements in vehicle software OS needed to have high performance robust design and optimization for special hardware configuration. So both AG and CRP use Linux based operating system specifically designed for use in the in different industries. Both AG and CRP are built on the Linux, which means that they are from the open source and have access to wide range of open source software and development tools. And also both project focuses on providing robust and reliable operating system that can meet the specific requirements of their industries. HL platform is all for automotive applications and sorry HL platform is for automotive application sorry. It is designed for CRP is designed for industry system. So what's happened? Can I continue? So both take two. Both prioritize safety, security and stability to enjoy the smooth and reliable operation of the systems. So they incorporate features and protocol to protect against it. Sorry. Where is my pointer? No. It's my private pointer. Sorry. So where am I? Sorry. They incorporate features and protocol to protect against the interaction, prevent system failures and enjoy data integrity. Overall, the common goal of AG and CRP is to provide industry specific Linux based operating systems that are secure, reliable and able to meet the strengths requirements of their respective industries. So I believe that combining the strengths of both sites may be possible to collaborate. However, I think it is important to assess the feasibility study of such collaboration before moving forward. So next section is feasibility study. I'd like to show what I have done, a simple feasibility study. So at the first step, I did a feasibility study of porting the CRP kernel into AG-UCB. I would also like to show the detail how to integrate it. Feedback on this activity will be happy to me if possible. So the software and hardware used for this feasibility study are shown on the slide. UCB is version 16th, latest stable. CRP is 66.1.59, CRP 8. So the latest version is CRP 10, so it's a little bit old. And CPU, hardware CPU is X8664, AMD Ryzen 7. So I used USB storage devices to simplify the development process. And just simple. So as I mentioned before, AGL is based on Yacht projects. We followed the Yacht project practice, and sorry, I followed the Yacht process project, project CC, sorry, and added layer accordingly. So I think since I'm working with the kernel, my first consideration was to make change in the BSP layer. AGL-BSP layers import community-based meta layer directly, such as meta Raspberry Pi. So if modification needed, the JL members made another meta layer specifically for AGL-UCB, such as meta Raspberry Pi AGL. So there are separate BSP layers for each board. Change in kernel is all of them was not practical. Therefore, I decided to prepare the CRP layer as another meta layer. So to prepare the meta CRP kernel layer for CRP kernel, I used command bit bake layers. This command creates a template meta layer named and renamed meta CRP kernel. So I removed unnecessary sample recipes. After that, I registered the created layer. It's been a meta CRP kernel layer by the bit bake command. And next is the recipe. So Yacht project Pocky has a template layer called meta skeleton that make it easy to write a recipe. For this case, I used the kernel recipe in the skeleton. So first I copied the kernel recipe from meta skeleton to meta CRP kernel. Then I renamed the, sorry, I removed the hello mode. It's an example of kernel module recipe because I didn't need it. So finally, I renamed the recipe name from index Yacht custom point bb to index Yacht CIP dot bb. It's for CRP. So as part of the feasibility study, I enjoyed the meta CRP kernel layer is not affected by changes in other layers of EGL. To achieve this, I increased the priorities of meta CRP layers. Priority 60 was affected because it's overlapped with another layer. So to increase it, to increase is needed, but that number 61 is not fixing in this case. So I changed the kernel download URL in the template and Linux kernel recipe. So I changed the version as well. So I set the kernel recipe and the version to be used in local conf in the build directories. So generally, it is recommended to set the kernel recipe to, sorry, set the kernel recipe and the version to be used in machine.conf file or the, such as a BSP layer. But in this case, it's feasibility. So due to the test feasibility, so I set this information in local conf file as shown in this slide. So in EGL, for the x8664 architectures, it was necessary to modify the kernel configuration to support AMD CPU as it might be originally designed with maybe Intel CPU specifically. So I needed to enable configure, sorry, it's type, AMD CPU, sorry, it's type. So to, my script is type, so, sorry. To accomplish this, I used the big break command to modify the kernel configuration by using the config option with big break command. Fragment config file is generated, then I renamed this file, fragment config file and added it to the CRP kernel layer. So finally, I learned EGL UCB on the CRP kernel successfully. Great. I have prepared a demo, a demo set at EGL sponsor booth. So if you would like to see it, please stop by the booth during the upcoming sponsor reception. So additionally, the Meta-CIP layer, it's a sample I created for this activity has been published as a foreign URL. So I've already uploaded my slide on this presentation, so could you check it? Please check it. So it's a, I'd like to, I would be happy if you give me a feedback. So if the CRP kernel or CRP kernel recipes are imported, what could be the best approach? Is it better to replace individually each community-based kernel in the BSP layer? So, or I should discuss with Yacht project community, whether Pocky has CRP kernel recipe or I'm not sure. So next slide about BSP layer. So BSP layer such as SOC vendors layer provides the special, special downstream kernel for the target board. So the kernel is included, local patches not in upstream, right? So if we use kernel in long term, the best approach maybe would be the to merge then to upstream. To be honest, maintain downstream kernel individually by each community or some kind of vendors has its limitation eventually. So how much, how much walking together with the CRP kernel chain to correlate on contribute upstream? Is it good solution? So anyway, it's a last slide I'd like to wrap up. So I introduced the CRP CBL infrastructure platform project and the AGL automotive grade Linux project. The CRP project provides an open source based layer, base layer for industrial equipment. So the AGL project is a leading open source project for in-bake system. Although the application area may differ both projects, but both projects has a technical common area such as robustness, security and reliability. So considering the potential for collaboration between AGL and the CRP, I took the initial step as I ported the CRP kernel to AGL UCB. So demo is being showcased at AGL booth. So last is my outlook. So I'm going to run the CRP kernel on the ARM architecture reference board. And also I'm going to try to port the base layer to confirm the CRP base layer to confirm the potential, make the potential clear. So that's all. Thank you very much for your attention. Anyway, any questions? Any questions? Thank you. Thank you for the presentation. So I have a little question about the CRP kernel itself. So currently it's 6.1.something and the same 6.1 is supported currently as long-term kernel from kernel.org, right? So at this point, is it the same kernel or it's already differs? I see the point of the difference of the CRP kernel and the LTS kernel, right? So it's a little different because the CRP member wants some kind of specific device or device. So we have already ported the drivers from upstream into the CRP because the CRP project member needs a driver. So we have a little difference. Thank you. So, okay. No, no, no, no, no. Yes, please. It's related to this question. There's a difference with the upstream LTS kernel and the CRP kernel, right? Yeah. And such difference is already upstreamed or not? Of course, upstreamed. Already? Already. Yes, thank you. Because can the team work on upstream fast policy? Yeah, I have another question about the CRP kernel. So does CRP kernel support architectures other than x86? For example, some SOCs for evidence use or not? CRP use the reference board. I mean, reference board has nqlcpu, sorry, x86 and 64. Okay. So is it your? Yeah. So CRP does not support, for example, SOCs? No, no, no, no, no. CRP has also ARM-based reference board. Supports the best reference board. So if you want to do the detail, please visit our website because the information is listed on the website. Yeah, okay. So my question is, so if you support some SOCs or something, then there would be the vendor kernel problem, I think I thought. So how does CRP project manage such kind of? CRP project maintains its own kernel. It means the scope is created from a member's request. Okay. So if your, I'm not sure that your thought you want to use the SOC, kind of SOC, but some members also request it as same as your kind of SOC. It will list it on the website maybe. So if you want support your request, please become a CRP member. It's easy. It's the best way. Thank you. Is it easy? Is it easy to become the CRP member? Really? I think so. Thank you. I'm a CRP member and an agile member. I know. I have a question about does CRP have original VV file to create the CRP kernel from YOKUT? Not yet. Correctly not yet. But some member, CRP member has a CRP recipe. They have a CRP recipe in YOKUT, for YOKUT, to adopt the YOKUT project. That means for example, if SOC vendor or CRP member has original YOKUT layer, then they have the YOKUT file to adopt the CRP kernel from YOKUT. So that means the questions are in agile view point, SOC vendor provides their own BSP, and agile pull the app story from YOKUT vendor, and includes a Raspberry Pi. Only Pukki, Pukki means QEM, pull from Pukki. And Meta-AGL core is supported and applied to the VV append file to kernel support. Then one of the ideas is located here to widely support the CRP kernel file. But it depends on the fragment, not fragment, but each core is affect. Difficult to support the original kernel, haven't you? Then one of the ideas is just Meta-AGL layer is good to discuss, but good support. So a lot of solutions, there are a lot of solutions, I think. So we need to discuss what the approach is best. So I think we need to discuss for the best practice. It's my answer. Any comment or question? At this moment, CRP do not provide YOKUT layer ourselves, but some SOC vendors such as Renesas provides YOKUT layer that uses CRP kernel. So maybe you can integrate CRP kernel by referring to the SOC vendors YOKUT layer. Maybe CRP should consider to provide YOKUT layer as well. This is just my opinion, but good start. To be honest, I have. My company has. So cyber trust provides YOKUT layer for using CRP kernel already. Thank you. Thank you for my, thank you for comment. No. Okay. Next is a sponsor session. So if you have any secret question, I would be happy to hear at around the AGL booth with, around my demo. Thank you for coming today. Thank you. That's all.