 Thanks everyone for joining to speak about kernel migration from 2.6 to 5.10 and the story about it and probably might be already having the provoking wondering question why on earth somebody has to do such a huge migration from 2.6 to 5.10 on earth. So that's what the question to answer as part of this presentation. So quick a bit about myself, so Parthi and myself working for Linux and we primarily work on embedded Linux and Zephyr in terms of supporting both supported packages drivers and various low level stuffs in there and we deliver solutions and build solutions like Yocto projects. So as part of this today's discussion, so the agenda itself is basically split into three different parts. The first thing is just to say why we really need that such migration in requirement from the customer perspective and the second part explains about how we actually did it and then the last part explains about like what are all the key factors you consider for your product if it's really applicable for your product. So wherein the how part like how do we actually did is not explaining every inch and every pieces of the migration issues and what all the drivers which he tried to migrate and the whole thing. So I just gave a brief about kernel and as well as the bootloader perspective like that's the idea here. So I did assume few things like say when we try to migrate this hardware source is from companies, customer companies. So the IP blocks were not complete. So we had to add drivers in like pin control changes in GPIO and other stuffs as well. But those part of it has not covered in this presentation. We just assume, I just assume at least the IP blocks are completely supported in U boot and as well as the Linux kernel. So we are not going to add a new driver or migrated driver from specific things. So the code changes are super minimalistic and then like we are not going to discuss about some external kernel drivers kept for the customized let's say vendors like automotive specifically we speak about that. So and then like the knowledge about device tree is assumed please do. So we cannot we are not going to explain about what's going to device tree and how we're going to handle that and things like that. So why migration? So this is the first place in things which comes in place like say customers are really excited about let's say the in terms of telematics domain in terms of automotive domain specifically what resulted in this migration. So we're really excited about artificial intelligence, machine learning and all these new technologies and then they excited about the new hardware which is actually capable of doing such things like IMAX 8, NVIDIA Jetson and so on. But then like when it really turns out what it really turns out is like when we look for making such hardware in reality in the PCB. So one way or another you end up doing getting this result from your supplier or vendor whatsoever. So this particular screenshot is directly taken from Mauser. I'm not like editing that particular picture. It's directly taken. So 2059. So specifically I assume myself like this particular IC is like probably they are taking the silicon from Mars or another planet and trying to produce it. So this particular part like say what results in the chip shortage? Let me just quickly check how to move this presentation. So chip shortages like in terms of automotive domain like they get the SOC from a specific vendor SOAM or group of components from a specific component like vendor and then like for example Qualcomm and provider of its Qualcomm SOAMs. So those are in completely available like meaning when you try to plan for new hardware platforms in the upcoming days like upcoming years. So at least for automotive domain they've been planning for like five, ten years advance and then like producing the same hardware for maybe 15 years or so. So such availability was difficult and then like that's why they did it. And then also there is like up the lanes of like various SOCs specifically IMX6 going to be and then like let's say NAND and NOR other chipsets and so on like those things where the one resulting in chip shortage and like for example if you assume a specific SOC even though let's say migration I meant say from one platform to another one generation to another. So you use the same SOC but then like you cannot use other components as part of the hardware. So because those are either obsolete or not available then like you need to create a new hardware platform based on it. So that's about the issues. So to come to a common ground again the same question lives like say why we need a migration of this kind or is this really valid for your product portfolio in specifically. So that's what the question we are going to answer and then like there is another question like say how long it will take. So assuming this is let's say it's okay I wanted to do it but then how long it will take in reality. So that's the latest part of the presentation where we speak like what are the caveats and what are the problems which we faced and so on. So this is just a quick example in terms of the product lifecycle which is planned for a telematics unit from our customer. So they have a generation generation three which is currently being produced and it's okay and it's currently available and it is planned for at least like 20 to 25 or something and then like there is another next generation let's say generation four which is going to be available let's say the production plan is from 2025 or so. So that's like not an overlap but still they're trying to match up with the production lineup for the real telematics units or real infotainment unit in this case. So the development timeline wherein before the production like let's say we have five years or eight years of development timeline with various vendors involved in terms of software and as well as hardware. So that's the actual plan in the product lifecycle but then what exactly happened by 2018 and then 2022 by this timeline is basically because of the chip shortage and the availability of the hardware they couldn't produce it. The development time just lapsed elapsed lapsed and then like they tried to change things and then but still they couldn't produce the real hardware meaning the software for the generation four is completely ready meaning you have the base platform is latest and everything is perfect and they migrated the whole middle and application side of it and everything is good in terms of telematics let's say every modem firmware and all these things are perfectly ready but then it is not ready for the market so it couldn't be produced. So that's one case and another case is like there is an X or Y customer which is already doing the generation three but they wanted to do an additional different like excitement like let's say the excitement which we spoke they wanted to do at us or specific use cases wherein they wanted to do the new hardware but then it is not available and then like they wanted to go something intermediate which is capable of doing the software capability as in generation four but then like not with not like as in the hardware is not available like they just need another intermediate things. So that's when the new customers comes in place for their telematics systems when then like they wanted to migrate to something new in terms of software maybe retaining the same hardware in there. So what are all the customer use cases primarily considered in there in that in this particular scenario so retain the middleware and application software which is actually developed for the generation four and then it can be directly used for the generation three hardware and then create an evolution hardware like intermediate hardware called generation three plus so that was the prime thing and then like retaining the software. So we probably already know that like the connectivity mechanism connectivity technology 3G is obsolete and then like couple of companies a couple of countries and the unions already close their network in terms of 3G. So the platform which is based on Gen 3 is like generation three which I mentioned is based out of the modem from Qualcomm which is primarily working on Gen 3 but when like based on 3G so assuming 3G is closed and then it fall back to 3G so which is not nice in terms of going into the telematics emergency SOA system which needs to work faster. So that's when they wanted to migrate to something super latest which is 5G whereas in the chipset is not available but then like they wanted to have something intermediate with the same generation of hardware. So in scenarios like this they migrated from to 3G technology to 4G in terms of LTE from the modem provider like Qualcomm and then you retaining the same middleware and software. So the one other major point of market here is like what is the cost involved in producing this and the timeline which is involved in producing this. So when we go for generation four the hardware is not available you cannot produce it. When you go for generation three which is super super old let's say the hardware is okay but then the software side we cannot run generation four related things. So that's where the intermediate platform comes in place and then like we create a platform called generation three plus that is a completely decision from I mean not us meaning the customer decision. So to create an intermediate platform and go with it so that the development timeline is super short in a way to bring everything from generation four into generation three plus. So and then like we have every software based on generation four running on generation three and then which will create a new platform to explore their market and keep the market until the next generation comes in place really like when the hardware is really available. So now that we spoke about okay the real scenarios which we faced in our customer's cases why we really do the migrate then like how we really do where in the like what components we really need to consider in this case. So as I said before the middleware and all the application aspects of let's say the specific use case about telemetrics or infotainment systems they have been kept directly developed or inherited or retained directly from the generation four platform but then the other pieces which is of the core components which is Linux kernel U boot and other base systems has to be considered. So that's the core component which we want to speak about not extensively in all the set all set of it but then this base about kernel and so on. So in terms of bringing to new hardware that's like the generation three plus so that there are cases like the network ICs has been changed from generation three and then it is not available they will have to change something new and then bring to as I said before the 4G network instead of 3G network. So then we have to change certain pieces and software which helped in us to explore new possibilities in terms of over the air software update and things like that. So in terms of how we can migrate from let's say the keep the same gen 3 hardware platform and run the gen 4 software like using Linux 5.10 using latest U boot and so on. So I feel like okay adding a new hardware platform to your Linux kernel or U boot it's exactly we're going to do the exact thing like even though the IP block support is completely available we do not want it to break the whole system in there. So that's why I recommended and then like started with like adding the basic blocks like UART the or before before coming into the UART like we have to bring in the clock driver trimer driver even though the IP blocks are available bring the device tree working functional and then you add all the peripherals into it. So add stepwise or one step at a time in there. So and then like adding the features wise like when we migrate from 2.6 to 5.10 there are like nx number of things which are needed or x number of things which is not needed as part of the K config Dev config features of the Linux kernel. So that's what we're going to discuss a little detail in here. So what's when it comes to kernel like what really changed or widely changed from 2.6 to 5.10 the first point which comes to thing is like we migrated the whole thing from machine code the implementation of the whole board definition and as well as the driver definition how the platform devices has been created. So the whole thing is migrated from the machine code into the device tree. So that's when how the hardware platform has been identified and what has been changed that's the first point which I wanted to say about in the next slide also and then like we created the device tree and the purpose of the device tree and how we purpose this particular device tree for the new hardware platforms. Let's say we have for example board A, B, C and then like A, B, C will carry over different display systems like x, y and z. So when you combine these two there will be x number of combinations combining the hardware platform and together with the display systems. So that's when you wanted to create multiple device trees and then how do you want to use it really in the systems. So we also had scenarios like memory configuration which is like say we have a custom driver which takes a reserved amount of memory and then previously we've been dealing this like specifically with allocating the memory in the kernel, passing the kernel in 2.6 and then how do you do this in right now with 5.10. So we do things with device tree that's what we're going to see in a moment. So the whole idea about migrating the kernel from 2.6 to 5.10 in this scenario is basically super less changes in the code because we removed most part of the implementation in the machine definition and then moved into the device tree approach. So there is no last set of code changes, very less amount in terms of like say adding the new IP blocks or the customized IP blocks which is not available in the mainline kernel or something like that. So that's the main thing of advantages which we've faced and then like migrating the disk config which we will see step wise. So as has the first thing like say the first important thing I would say like moving the kernel from the machine code part to the device tree part. So the 2.6 implementation of the whole hardware like let's say the IMAX platform or the NVIDIA platform or I mean NVIDIA is not but like assuming this current example support NVIDIA or let's say Qualcomm examples where it was currently it was based on 2.6 and then the whole board categories like say they produce like 10 or 15 variants of the same hardware for different vendors of the automotive domain. So the whole definition was into the part of machine code and then we had to migrate them completely into the device tree part. So how what exactly or what really changed in this particular aspect. So the machine start part or defining the whole machine side of it is completely moved into the device tree. So this slide just depicts like what how do we actually do like the machine type actually comes from the boot loader and then the kernel takes care of it by reading this machine type and then we were using the machine definition directly from the architectural part of the code in 2.6 but then with latest 510 the whole thing is passed via device tree block loaded by the U boot and then it will be functional or passed and created or consumed by the kernel. So that's just the depiction of this particular picture but then the whole definition okay so the example which we here so shown as basically based out of the Atmell platform so because I cannot show a platform which is used or the code which is really customized and used by the automotive domain due to the appropriate reasons. So the one which is here which we migrated for another platform for an IoT device is taken from the different hardware. So from 2.6 we have this machine definitions directly. So you have machine start and machine end which is carry over the unit function of the whole platform SOC and then peripheral blocks and then initialization of the old and age. So the 2.6 way of doing it at least 3.0 until 3.1 or something like that. So these whole part of implementation which kept for years in this particular domain on telematics has to be completely removed because we had to completely move to a different approach called device tree. So we already know this part. So we just need to create device tree for every specific hardware and then like it can be overlaid if there is a difference on top of it and so on. So that's one prime difference we just create device tree and then like as many number of device tree nodes or as many number of device tree files like based on the number of boards which we have. That's the first change which we had I think I skipped it yeah. So and then there were custom peripheral connections like I am not speaking about the serial interfaces which is going to give you a console or which is going to be used for specific purposes which is defaulted but I am not speaking about it. So in this case there were cases where there is an MCU which is on the board which is doing another operation probably communicate with the modem in terms of telematics systems. So which will be connected over UART but then the whole definition of this implementation let's say the UART communication and how you communicate and what you do with the user space application and the middleware. So the whole purpose of the whole usage of 2.3 I mean 2.6 kernel in the generation 3 is basically implemented in the machine definition. So we had to again scrap the whole thing and remove every part of the code and come back to the device tree approach in terms of migrating from 2.6 to 5.10. So in this here like as we can I mean most people can already recognize the device tree part here. So we've been just using the whole like let's say there are X number of files implemented in the machine code and then like using the customized driver in our external driver as well as in the mainline 2.6 and so on. So the whole patching is completely dead and then completely removed and then just there is only one adaptation which is done just creating the device tree node for the UART that made the life easier in terms of migrating the whole UART driver even though it is a custom implementation for a custom hardware. And this is just another example about like say how do you add your device tree. So once you create the device tree for X number of hardware platforms let's say from board A to board C and then like you create X number of device tree overlays for your device tree overlays or device to include files for your display systems for infotainment systems or telematic systems. So those can be added just like you just go in adding into the make well system of the kernel and then like you just have the device tree file in there. So once you do this you enable this particular K config platform for this particular SOC then the compile system completes this. So the example shown here is basically on the 1891 platform from HTML but then the real scenario is basically we did this for like say IMAX platform or telematics platform which is based on Qualcomm SOC or so. So there are other pieces which also need that migration for example in 2.6 or 2.6 end or 3.0 the most I square C operations like say we have laid out that the actual PCB was laid out with set of sensors and also it laid out with set of audio codex which exposes the configuration over I square C and then the actual audio is exposed to over I square S. So those pieces of hardware were maintained I mean the software part of this whole customized or codex and things were not in the main line in 2.6. So it were completely maintained as an external driver which is like maybe an out of tree custom driver or even though it is entry in 2.6 it is all custom actually it is implemented only for this particular purpose. When migrating from this part there are also drivers which is in the user space which does the I octal call to set the device address on the I square C and communicate over read write systems. So and then the whole implementation is in also user space or not just in the out of the kernel driver but also in the user space. So migrating from that perspective to 5.10 helped us in a way that like we can use features from 5.10 something like industry IO sub system and so on. So that is just a quick easy migration in terms of adding new sensors using the IO sub system exposing sister space based interfaces and also like in terms of audio as well. So the last part of the kernel where we need keen time or more time is about the deaf config migration. So when then like wherein like 2.6 kernel had X number of features let us say we had a large set of deaf config enabled but then those deaf config weren't completely relevant anymore in fighter. So we had to review each and every point or every single step and then migrate the whole deaf config from 2.6 to 5.10. So meaning we had to do a fresh creation but then we haven't created with like all no deaf config or all S config either. So we started with something intermediate with basic board and SOC support then we had to add features gradually. So the major point about us like maintaining the same platform let's say the same SOC or SOM platform the memory layout of this particular storage medium is let's say we have 5 or 6 partition and the kernel is allocated with 4 megabyte or so we cannot explode this one because we wanted to retain the same thing with the new generation 3 plus as well. So in this particular scenario we face like limitations in terms of size. So we had to compromise between compression and as well as disabling features in a way that like we have to do we have to keep the loading time super fast the booting time super fast so that the telematic system starts immediately or quickly. So such scenario of things where like a compromise or trade-off which we discussed and then like we had played around with the deaf config like say we have we can enable this compression with squad surface with LGO or so or we may not be able to enable compression and so. So those were the things which we have been dealing with in terms of deaf config migration from 2.6 to 5 just because there is like impact in terms of size change in terms of feature changes and so on. That's about the kernel part even though we did the migration of the uboot-boot loader from 2009 to 2020 version and we are not going to discuss about the whole part about how we did it even though we did something like say the 2009 version doesn't have any device support from the uboot perspective we did the uboot perspective of device tree adding the new board definition or moving the mode definition board definition and also the custom power sequences in terms of telematic systems and so on. So suspend to RAM and all these background so everything is implemented but then we migrated in a way but then we are not going to discuss all the points about uboot in this case. So what we are going to discuss now is about like so on behalf of the Linux kernel changes let's say we moved from 2.6 to 5.10 so what exactly the file sizes and file formators and then like how compression changed it and how we actually moved from the device tree world how to move to the device tree world from the machine code definition. So this particular snippet explains like say the basics about we had as I said before three different hardware three different displays will create an x number of combination so then like in this particular x number of combination how do you select a specific device tree in terms of load time or from the bootloader perspective. So we had an board identification mechanism which is based out of let's say a register sets or a GPIO sequence in a hardware with this under telematics we use the same mechanism but then based on the same mechanism we select a specific device tree or even apply an overlay on top of it. So we make use of fit image at this point of time previously it was like see image concept so that's what the next thing which I'm going to speak about. So apart from the board definition identification and then loading part there are a couple of things which we also had to consider in this scenario because the kernel has been migrated so one thing is we don't have we didn't have fit image by the time in 2009 so 2010 based hardware but then like we had to move to boot Z to boot M and boot the fit image support and add up all the DTB blocks together into that's a single fit image and then load them in like use the use a mechanism something like this to load a device tree in there. So and then like loading the kernel itself from a different storage medium or different mechanism because we've been using JFFS2 and a different file system approach but then it is changed because we migrated to the latest one like either we use class of us UBFS or better mechanisms in the latest kernel even using the NAN. So there is a change in storage file system approach so we had to change based on which let's say we had a boot SCR based loading in 2009 but then like we moved to read only based approach so that it cannot be corrupted in security perspective and so on like that's another thing which is loading the based on the file system approach. Okay so that's mostly it like I'm not as I said before I haven't discussed like extensively in terms of what is the migration perspective in kernel let's say we can speak about IP blocks how do you migrate and a specific driver how do you migrate and then like so on like what are all the things which we faced but then like in a big picture what we did is specifically changing in the kernel perspective and then what the impacts that like say we changed x number of things in kernel migration and what is impacted in the kernel perspective UBOOT perspective. So these things were being like discussed and then like we did this migration for this let's say the kernel migration and then the impacted part in the UBOOT site. Now that we saw about okay so what are the things which we did so now if you feel this particular product you have a product something similar and then you have a problem statement something similar in terms of migrating or you need it migration just pick up the hardware is not available or you may have an accept let's say the development time even though if you have a hardware production is available but then like you have a development timeline issues and then like you keep the existing customer with the hardware so if you consider this particular migration for your perspective so what should we consider so probably these are the key factors in terms of unexpected deviations and things like this which we faced in reality. So let's go in detail about how much amount of software deviation which we consider but like let's say you have a hardware deviation because chip unavailability but then you address it with another platform intermediate platform like Gen 3 plus. So how do you address this software time deviation what exactly it is let's discuss that in a moment and then like there are things where in like the hardware itself changed as I said like Gen 3 is okay but then like Gen 3 plus when you try to create you cannot create the same exact platform because let's say the microphone is not no more having the same NAND flash for your Gen 3 plus so you had to use a different NAND flash which is pin to pin compatible everything exactly same except for the fact there are changes in the hardware itself. So how do you address and what do you face in terms of time deviation and caveats with this particular cases. So there are things like so the couple of cases where as I said before the kernel partition itself let's say 4 megabytes and we don't want to change it because the customer sticks with the exact partition layout of this whole system let's say you boot kernel and then root file system and then the basic layout they don't want to change it but then when we migrate to the kernel 5.10 we have a large set of size which needs compression which needs stripping down the whole thing so the main thing which we did is like move most part of the kernel configuration into a module so the base kernel lives and the base SOC lives and then the base initialization lives so all the rest goes to the kernel module and then when we have what technically we faced is like at some point we had to do compromise in such a way that like we have to disable or the file system itself has to go into a module. So this resulted in let's say kernel cannot directly load the root file system because it doesn't have the kernel built in support for the file system because we had to disable because of the size and so on and loading time as well. So then we introduced another concept called unit ramfs but it was init-audi ramdisk and then like ramfs file system now and then like with ramfs we have enabled many other features together with loading the file system from the unit ramfs and then loading the kernel system sorry root file system so that's when it is like we had to change things in root ramfs and ram0 because okay so when it comes to systems like telematics changing certain things of boot argument or read only partitions of this form as you know enormous amount of impact in terms of production timelines as well. So that's when like boot args and things were changed to adapt and probably you have to consider in such a way like if you have a strict partition layout which we cannot change in scenarios like this. So this is another caveat or an exception unexpected deviation which we faced as well wherein like say we get the som from vendor from Qualcomm or supplier of Qualcomm and then like they when we do a migration from our existing platform on a new new platform for an example as I said before 3G to 4G as an intermediate solution wherein we have a set of partitions which is newly introduced by the vendor by itself which cannot which cannot be changed because that is not used by the Linux side of the system but then actually modem side of the system they have the dedicated memory and then the actual side of the system. So such scenarios resulted in you know changes in R and as well let's say partition layout changes actually changes back to the boot boot system of the U boot configuration and then back into how do you read the NAND and where from where exactly you read the NAND from so that changed it. So the other point which I mentioned is about change of the NAND ship itself like when Micron doesn't have enough supply for or they stop production for that particular IC for that matter when we change one NAND IC to another even though it is incompatible. So this where like the board itself is produced and that we have the board and we have functional system with the same layout on things like that but then when it comes to the NAND the initial one the existing one was based about the 2K page size and then the new one was based out of 4K page size. So this is resulting in what so let's say in the first case scenario it's like an existing platform Gen 3 so where we have 2K page size where the first stage boot loader is basically allocated to the 10 kilobytes of size in the memory layout and then which is basically 5 pages altogether 2 into 5. So in there in the later scenario this actually overlaps or needs perhaps the other part of the memory so this is like we had to strip down back to just 2K this extra overlap in terms of this other memory layout has to be stripped down because we have 4K pages which results in 3 pages in there. So those part resulted in the image stripping part or the partition size adjustment in there so not the partition layout change but just the partition size adjustments in there. So apart from these things like we had also as I said before we had also drivers which is custom built for this particular customer cases where it used for error logging telematic systems. So when the system abruptly resets or scenarios wherein the system needs to keep the error logging system and then send back to back server back and server and figure out what really happened in scenarios like this. So these memory reservation has been completely done in the Linux kernel in terms of not initializing this particular set of memory and then a whole patching and things like this. So this is changed completely to a new thing like say previously we've been creating the platform device manually in terms of kernel but then this is migrated back to a newer approach which is device tree and then with device tree we have a flexibility to use reserved memory. When we do reserved memory approach we have memory reservation automatically done by the kernel and then like we just need to consume this particular thing so the device is automatically created for the user space to function with it. So there are also things which we move from ABI custom compatibility and then ABI compatibility those part has also been changed. So one last thing about before closing this migration part so we deliver solutions as part of the octo system so that's what the whole thing is covered underlying with the octo system and then we deliver a solution in octo so that's like just a layout about how the SOC or the architecture until the board things laid out say and then like in in terms of this we have a board on top of it and then like how exactly it laid out it based out of an SOC and then which is based out of an SOC series and then like SOC family and then which is based out of a specific architecture so how exactly this laid out in octo build system. So when it comes to octo latest a curve stone or the latest version of it we already had I mean not just the support for any latest SOCs like A72, A78 or something it also we also have support for the older architecture until v4 as well. So this helped us or quickly helped us in migration from let's say the older build system which is like not really build root but it's a customizable root they had but we migrated from that perspective to the latest octo version here. So as you can already see in this particular picture so the first we had the SOC series and then the specific SOC and then which points out back to the architecture specific let's say arm v5 until so the whole definition is customized like easy or in terms of porting the whole thing when we come to octo in scenarios like you can cross compare the whole thing with from the board until the architecture perspective here jumped in there okay so with that what other benefits which we also get apart from the whole migration part is like we had features like specifically on a telecommunication system where we had a features like distributed switch architecture which we can employ with to achieve the use cases instead of writing the whole network switch driver in a user space site so we enabled and used out the distributed switch architecture and then like we also had basic support in terms of the power management when it comes to 2.6 and then like we had an enormous extensive support in terms of PM runtime system runtime and so on like those helped us in saving a lot of amount of power when it comes to the telematic system it needs to run even though the car is not really running in scenarios so those helped us in terms of reducing the power optimization there so we also had virtualization support which we're trying currently trying to consume in a way to establish an enable run embedded containers which meaning x number of containers can even run in a low memory footprint and so on so that's also one another enablement and also like in terms of over the air software update and things where we had capability to do partition layout changes and which helped us in terms of enabling over the air software update using Rao and then established it together with the Hockpit systems and so on so that's another aspect and there are also other aspects which we need to say like say we were using config fs when we tried to connect an iPod into an infotainment infotainment systems and then enumerating and functioning with the USB system so in width here we migrated using config fs because with latest kernel we have this feature on the like using a user space respective libraries like libios pg or so so that's where changes like which or helped us adding more positive features in here apart from that so we also had squasafes read only file system compression and enabling various other security possibilities with fit image and so on so that's mostly yet from my end so as you can see like this is just the basic overview about how we did the migration for the whole thing from 2.6 to 5.10 for a couple of use cases I would say three four use cases which was based on like the older hardware so you can read about the device tree part and as well as the board porting which was another talk from bootlin the other different conference actually so with that thank you so much I'm open for questions if any maybe you have a couple of months yeah sure well the development time it takes like couple of months I would say is initial porting with successful running of three months timeline but for the real production and testing for the end customer because it's automotive it take another like three to four months of testing and coming back to the production line actually but like considering other use cases like iot domain which is let's say basic simply simple network and enablement from 2.6 to 5.10 that's okay because iot doesn't exist at the time but like we speak in different terminology like wireless insert networks and then from like 2010 to 11 side of it yeah thank you so much