 Okay, the slides are up. So just random fact, you know, in 1936, Russians actually made a computer that ran on water. Anybody heard about the fact? I also didn't know. That's what you do basically when you're jet lagged and wake up at 3 a.m. and wondering what you need to do, and what's good question. I'll go and do a fact check. So moving on. So as the slide, the big font says I am at each work for the Western Digital, and I'm here to talk about the supervisor binary interface that's known as SPI in desk 51, what the future looks like for it. It's a brief agenda of today's talk. I'll briefly introduce what's just a to give you an overview of what's SPI, what's the current status of it, what are the limitations, and then how we are thinking to extend it so that it can be a clean, better interface, and then I'll talk about the open SPI project. We just made it publicly a couple of days ago, and we'll have couple of cool demos for you to see. So to start with what exactly is SPI? So just to give you an overview, how many guys have actually walked on this five interface or known about SPI? Three, four, okay, it's good enough audience. So just to give you an overview, so SPI is a supervisor binary interface that gives a clean separation between your supervisor mode and machine mode. So anything that machine mode is not exposed to the S mode, that's basically implemented by an SPI, which is a similar interface you can see between ABI and SPI, and that interface, by that interface supervisor mode talks to your supervisor execution environment, which is basically on bare metals, it's a M mode. So if any of you closely followed what's being discussed in the mailing list recently a couple of months ago, there's a huge difference of opinion saying, what exactly the SPI's future look like? Should it have all or it should not be exist at all? All kinds of spectrum, I'm pretty sure if I do have vote here, it's probably split by half and half. So to me, it's not surprising because it's kind of a double-edged sword where you start putting a lot of stuff in SPI it become a mini OS and then it becomes a big firmware which becomes big and messy. But as of now where it is, so if we can make it a clean interface and if you can go forward and keep whatever necessary required in it, it can help RISC-5 achieve what it needs. Something like any architecture limitation that's now present, but maybe in two years down the line that architecture limitation will not be there, we can add it in the SPI and then in future, we can adopt the operating supervisor mode OS to implement that instead of SPI. So that's where having good specification and implementation makes sense for SPI. So currently it's implemented by BBL and how it works is basically, it's a supervisor trap and emulate. So you basically trap into a mode using an E-call instruction, you pass your SPI call number in a seven registers, pass your arguments in a zero to a two registers, and then in case of you want to return something, you return using a clobber register a zero. It's the existing implementation is documented in one of the GitHub repository that's mentioned here. Now here is the current interface that exists. So we have a timer call and a why timer, because currently RISC-5 doesn't have a timer register that can be accessed through S-mode, which can be used to program the timer. When do I get the next periodic event? That's where it comes into picture. Then we have console and IPI. So whenever we send an inter-processor interrupts to other CPU, we need to go trap into the M-mode and then send it because the client access everything is M-mode only. Similarly, TLB flushing, we have all the memory model interfaces for TLB flushing, we need to call an SPI and shut down API. So what's the problem with it? Why it is limited or why do we need to change it? First, it's fixed. So there are eight APIs that are fixed. There is no present way to extend it. If even if we add new functionality, we are probably going to break the backward compatibility. That's where we need to have a specification that allows modifying it, adding it or removing functions from it without breaking backward compatibility. What kind of features we need to add? Something like power management or let's say CPU heart or CPU hot plug, which is basically necessary and required for any kind of systems that you build today. Coming back to the specification that we talked about. Now, I think Alex is in the room. So there is a lot of discussion about how we define the scope, like where do we stop it? Defining the SPI scope. So that is my view saying it shouldn't be, as I said, it shouldn't be treated as a kitchen sink. You cannot dump any feature you want or vendors cannot should not dump any features they want. Whatever functionality they suggest, if it is absolutely necessary, then only it should be implemented SPI without breaking the backward compatibility. So backward compatibility is absolutely necessary. We do not want to go ahead and have something that's not going to let's say work in the previous version. We all agree that we see that there is a future where RISC-V can be the ubiquitous ISA among all the devices. So no mandated user should be there of, let's say, this is DT-specific implementation or ACPA-specific implementation. It's open to adopt anything, and we probably want to keep it in that way. Any functionality that currently SPI has, we should allow it to be replaced by your S-MODE software and feature. So something like a timer. So there are discussions about having a S-MODE timer registers that will allow to remove that S-MODE, sorry, a mode SPI call. These are only some of the few points that defines the scope. There are a lot of other discussions happening. So anything else as this is a evolving discussion, we can keep on adding as long as it makes sense, and we define the SPI within that scope. Now, how the specification working will progress. So as of now, it's been decided that the specification will be part of the RISC-V Unix Class Platform specification. It need to be approved by the working group and you need to have an implementation before the freeze. Now, why the working group? Again, there are some discussion about why we are going to a closing discussion, why it's not happening in the mailing list. Actually, it is an open discussion. It's not having forming a working group doesn't mean that it's a closed discussion. In fact, the proof that I'm talking about it without having the first meeting of the working group is a proof that it's being discussed in the public forum with everybody and then we are taking inputs from everybody. But the objective of the working group to make progress on the specification in continuously and finalize it within finite amount of time. We cannot have years and years just talking about it, but not actually finalizing spec and not implementing it. Also, working group make sure that there is one reference implementation available for every SPI specification that we make or every SPI modification that we make. So that's decided that to keep the discussion focused, we'll have a minimum base mandatory spec, which will define just the layout saying how the worsening should be management and how the functionality should be managed. That's it. That will be mandatory for every future SPI worsens. Then there will be any other, something like power management, either CPU or system, all those will be an extension to it. So that can be worked by different people in the same working group and then that those can run in parallel while based on the layouts defined by the base specifications. So let's take a look what all is being proposed as a base specification. So calling convention, whatever the calling convention exists today, it also kind of works. The only thing I think that's suggested by Ron a couple of months ago, so we can have a return value with a structure which gives you a flexibility to distinguish the difference between your whatever the SPI function returns and what the SPI library wants to return. So those are two different things and this is the way to distinguish it. That's where I say came in as a help because it defines that the API defines that we can have two registers as a return value. Other than that, the existing calling convention which is documented in the GitHub stands correct for the even updated proposal. So the new thing that we are going to add is a versioning scheme, which is basically a major and minor, which is standard versioning scheme that everybody follows. 16 bits, minor 16 on the last 16 bits, upper 16 bits are basically defined the major version. The existing current legacy version will be 0.1. So that's called legacy. We hope that we'll get rid of it one day. The base version that we're talking about here, which will be mandatory, we'll start with the 0.2 and going forward depending on what kind of feature we're adding, we'll keep on adding the version numbers. Now there's a function ID that we need to define. So it's again unsigned 32-bit integer. So the function ID is basically a combination of function set and a function type. Function set is similar kind of functionality that can be grouped is a function set. And the function type is basically individual functions feature that's being added. So something like let's say legacy. Legacy is a function set. All this base specification we are discussing, it's a function set, which is basically statically defined IDs that are assigned. Then we have let's say CPU power management or system power management. All those IDs are predefined assigned. And we also have something like reserved reason, which allows anybody to, let's say somebody is experimenting with a SBI call. And we are not sure whether that fits into any of the function ID or function set, or you need to have your own function set. So that's why reserved comes into picture. You can pick any number from the reserved and in future, if you want to keep it that way, you can keep or you can move it to any of the function set. The last, which is I guess most controversial thing is the vendor extension. So whether we need, I hope we don't have to, but since ISA allows you to have vendor specific ISAs, there may be a future where, we don't know there may be a future where vendor might absolutely need it. If we don't provide it now and they need it in future, it might breaking the compatibility. So let's see if it makes sense to keep it. Again, it's just a proposal. It's still being discussed. So it's not like finalized under certain stone. So there's a scope for revision for everything. Now this is the base version functions. These are the only functions that will be mandatory to implement and basically will be part of the SBA version. So something like it's a no-brainer. We need to have a version. So SBA get version which returns the specification version. Then there is SBA implementation version, which is basically provided by the software that's implementing the SBI. So something like let's say open SBI provides this one and open SBI gets an ID, same something like let's say one, one, two. And then there is another software, let's say core boot implements SBI. So core boot gets like one, three. So that helps to identify the difference. So to know that supervisor mode that which software actually implementing the SBI. Similarly, we have a function set and function type. It's just a probing of whether a particular function set exists and within that function set whether a particular function type exists. Then we have get vendor ID and machine implementation ID, which basically returns you the value that's stored in M vendor ID register and MIMP CSR. And this vendor ID and MIMP helps you to identify which particular vendor specific functions if they, in the future, if they have or if we have a vendor specific APIs or SBI, that helps to identify which vendor belongs which function belongs to which vendor and all. Lastly, we have an implementation ID, which basically, oh sorry, I switched the earlier one. So earlier I was talking about the implementation ID, which is basically a specific ID for SBI implementation. And the second one was SBI implementation version, which is, so something like open SBI or BBL or core boot, they get an implemented implementation ID which is fixed, let's say 11, 12 and 13. And then there is implementation version where open SBI will be have 0.1, 0.2 or 0.3. Similarly, core boot might have a different version. So that's where they communicate between what features, what specification they implement, what feature they support and what software they are talking about. So this is all about the specification, how SBI specification will be, what will all be implemented in the specification. But what about the implementation? We need a solid standard implementation that provides the SBI that not only provides the implementation after the spec is frozen, it should also, we should also provide it while the spec is, the discussion is going on so that we know whether that's whatever we are proposing or somebody else is proposing or what's being discussed makes sense. So currently we have two options, BBL and core boot provides a separate SBI implementation. In future, there may be more fragmentation, there will be more different SBI implementation because everybody goes and tries to implement their own because everybody's core structure, everybody's open source model is different. And so that becomes a pain too difficult to track and maintain those SBI changes. Everybody, now we don't know which version, which, who implements which version and then how they are backward compatible. Then with the, BBL has been really useful and helpful until now in bringing up all the RISC-5 systems. But this is a fundamental problem in BBL is that it doesn't, it has a tightly coupled platform code and SBI code. So if you want to swap out or modify SBI code without changing in the platform code, that becomes messy. Or if you want to add new platform support, that becomes difficult. So keeping in all this mind, that's where the open SBI comes into picture. That's why open SBI is being developed. So let's take a look what exactly open SBI is. So it's an open source SBI implementation project. So all we need is a standard implementation that everybody can use, which adheres to all the specs that we propose. It's driven by a community, the open source community. And it has the most permissible license. So it's, you are open to take it, implement it, modify it, whatever you want. And we would like to contribute back so that it grows and becomes the standard project. It's fine to have another SBI implementation as well. It's not mandated. It's not saying, nobody's saying that this is the only SBI implementation that should exist in future. But this is a reference implementation. At least we'll make sure that every specification is implemented. If there are a couple of other, that's still good. But at least I hope that this will prevent 10 other to fork it. Couple of other is okay. So how, what does it actually do? So it builds a static library that any of the, that's just a SBI implementation, any of the emote bootloader can link. It also provides you on reference implementation for your platform code and your firmware code. And it also uses PMP to protect your firmware. So it's well documented. Go and take a look at GitHub repository. And it's all standard GitHub process is followed. So if you have an issue, raise it, or if you have a doubt, just ask the question in the GitHub. There are a couple of pull requests on issues already pending in the GitHub. So I said a lot of things about, this is what OpenSBI does. So let's see how it does, what exactly it builds. And what I said is how the objective is achieved using OpenSBI. So first, it builds on libSBI.a, which is just an SBI implement. It's a static library, and it just implements the SBI. That's it. Doesn't have any other feature. So any emote bootloader basically can link this SBI implementation for their SBI feature. And they don't have, so this prevents forking up SBI implementation, varying degree of, for using different SBI implementation and everybody coming up with their own. So, and as I said, we make sure that, we'll make sure that every feature proposed SBI specification or extension will be implemented in libSBI.a. And it also builds on libplatSBI.a. So libplatSBI.a is like a container that has the libSBI.a. It uses the libSBI.a to use the static, to use the get the SBI feature. So again, what's the difference between libSBI.a, platSBI.a as the name suggests, it also has the platform support. So all the platform drivers, whatever the minimal platform driver required, that's what the platSBI.a uses. So any of the vendors or a SOC platform support require, they, let's say they already have, they already IP block that are already implemented in OpenSBI. They'll just take this one and build their own firmware. So what all platform we have supported, we already have support for QMU Word, QMU Sci-Fi View, obviously Sci-Fi on list. So we have complete support for on list and we also can write support, which is like $20 amazing, this type board which can run free at us, do face recognition and whatnot. So, so almost I can say that any SOC that's available, that's supported by OpenSBI currently. If not, if anybody has an SOC on that, we are not aware of, please talk to us. We'll try to make sure that it's also supported using OpenSBI. So the last piece that OpenSBI builds is an firmware binary. So all the firmware binary, it's just a reference implementation to showcase how Plat-SBI or Lib-SBI is used, but it also complete a platform specific bootable binary. So you can just take it and use it for your own project. You just, if it is a different platform, you just add your platform support and then you get your firmware binary completely and you just go ahead and use it. If you're existing, if you're trying to use the existing platform, that platform, let's say Unleashed platform you need, just build it and then you will get the binary. You will have obviously binary releases as well, which will directly work on the Unleashed platform or any other future platforms that come up and we have access to. So there's two way of building the firmware. One is basically with a payload, which is a standard mechanism of giving you, you give the next, so next is bootloader or next is image as a payload to OpenSBI, OpenSBI combines it and boots it and make sure that it from OpenSBI, it boots the next image. There is a feature that we can add a device tree as a separate file. So any of the device tree modification that you want, you can go ahead and do with it. So the next type of the firmware that uses is, it builds is using a jump address. So that's, let's say the previous test to the OpenSBI knows how to load the next test to the OpenSBI. So in that case, you don't really don't care about the payload. The payload can come from anywhere. So you just provide the jump address and then it makes sure that it will jump to the next address, which is being loaded by the previous stage. Now, as I said, vendors can choose either way to, depending on their flexibility, either way to build the firmware or just use as it is. So all this talk is required to standardize the boot flow. So that's the big mess. I think Kastan also mentioned something. We need to standardize the boot flow. We need to follow what every other let's say R64 or X86 or every other boot flow that's being used. We need to follow that model. And that's where all the CI, everything comes into picture because nobody wants to change only for RISC-5. So we need to support whatever the upstream, all the boot loader support. So this is the current boot flow. So we have JSPL, then FSBL, which is like M-mode, ROM-based binaries, and then it loads BBL. BBL basically combines the Linux image into it, embeds into it, and then there is no way to separate the DT from the kernel image. There is no way to do the network booting. That's where OpenSBI has been implemented to address all these issues. So how does the OpenSBI feature as the standard boot flow is the same model, just the OpenSBI replaces the BBL, but here you have the ability to create separate data files, DT files, and you can boot complete Linux, full SMP support is there, and you can basically give a Linux payload to OpenSBI, and then it just boots Linux. But the upstream model that I was talking about is this one, which I'm really excited about saying, it's the same thing, if JSPL and FSBL, then we have OpenSBI, which is M-mode, which boots into your U-boot S-mode, and then you just provide the Linux image into the U-boot as every other implementation or every other architecture does it. So you have a kernel image, you just load it via network, that's where it's also supported. So this is the standard flow. So U-boot becomes the last-stage boot loader, not a BBL or not OpenSBI, and you load the image via TFTP boot. And as of now, it can only boot one core out of the, it builds SMP and boot SMP, but we can bring up only one core in Unlist because there is no support in U-boot SMP support. So as long as we, as soon as we have a hard power management, we can bring up all the CPUs. It's just put in the WFI loop in OpenSBI. So this is just a quick instruction, quick instruction overview. The detail instructions, everything is available in docs and for each platform. So this is just a quick way to show you that, how you do, how do you build and generate the binaries. So there's basically two arguments. One is platform. So you say, whether it's a QMU or sci-fi platform, and the next one, whether you want to give a payload path or you want to give a jump address. So this is how you provide the Linux image as a direct payload. So you just assign thing, make platform QMU vort, and then this is my Linux image path. And then this is a standard way to run QMU REST pipe. And you give the root FS file as the QMU drive file. If you are using U-boot to load it, just say same thing, make platform QMU vort, then you give a payload path as a U-boot.bin, your U-boot binary. And then for running it, you just run QMU with, here notice that there is no root FS required because we are using U-boot. So it will boot into U-boot, and then you follow standard U-boot model to load your kernel image. Similar process in the high five on list as well, where you just give your platform as the sci-fi, if you five four zero, and your payload path as a kernel image, and for U-boot, same thing. And this is a screenshot open SPI booting, renecs directly. I don't think it's visible, but anyways I have a demo, so don't worry. This is another screenshot which was basically open SPI booting renecs using U-boot. So I have a couple of demos that I wanted to show. Let me see if demo gods are happy with me. And if it works, otherwise, I just a backup video also. You didn't know how do I slide the windows, okay. So here is my TF2 boot server, and then here is the other window, okay. So here I am as the boot prompt, okay. So let me reboot and just show you. This is the U-boot prompt. So in a minute, you will see open SPI booting U-boot, and I have a preloaded image binary that basically has U-boot as the payload, and it boots using this is the on list board, that's a sci-fi on list board we have, and you see open SPI and booting here U-boot, and you see open SPI, hold on, okay. So now you see open SPI has been booting on list board using U-boot, and the rest of the things, we just need to use a TF2 boot to load the image. Let's see if I can do that. Yes, so currently that's not yet done because there is no SPI driver in U-boot. As soon as somebody puts the SPI driver in U-boot, that will be possible. Yes, I need to, okay. So all the network is set up. Oh, it's too below. Now if you can see that screen, can you see? I don't know, I'm just typing TF2 boot U-mage. Hopefully it will work, we'll see. Oh, I did not set the server IP. Is there a random character? Okay, I will just type it. Oh, it's working. So it boots. So demo gods are not that angry with me. So it load the address with a six zero. So we just go with that and put here. And let's see if it puts kernel. So ideally it should boot Fedora 29. Oh, it puts now. So this is basically the demo that wanted to show. So it, we have open SPI U-boot and you load your Linux image and here is your Fedora without changing anything without recompiling the Linux every time. And you just load your image from wherever you want. So it'll take a couple of minutes to get into the prompt. Just wanted to show you, I'm not faking those ones. So any questions in the meantime? I can take a couple of questions until this boots. So takes a bit time, not yet. So this is all standard, whatever the existing SPI. So we have not changed anything to the SPI. Once the spec is frozen, we'll have all those implementations. And vendor I, we don't have to assign. We just pick, get from the vendor ID CSR, which already given by the specific, I think, privileged spec. So the basically privileged spec or the manufacturer will not have ZX spec ID, is that possible? I thought it's mandatory to have the vendor ID, no? Any other question? It's still booting. In the supervisor binary interface for those of us that are new, but familiar with Uboot, how is this applied to the Unleashed board? Because I'm confused where it comes into play. I mean, we have a GPL, you know, Uboot. What is the, what's the part that's here? So supervisor we implemented is, SPI is implemented by the open SPI. So Uboot doesn't have to deal with that. So Uboot acts as the bootloader. So it's, think it like it provides a runtime services. So runtime, you need to send an IPI, runtime, you need to perform the count, program the counter. So Uboot doesn't have to deal with any SPI implementation. It's Linux, the supervisor OS, that actually needs to make those SPI calls. As of now, Uboot don't need that. So what all we need to, Uboot is the fix the network driver, support the UR driver so that we get the Uboot prompt, and then just add the Unleashed Board Support in Uboot. The patches are being upstream, so it should be available in mainline. Maybe you're sure they're going to hear from me. Okay. Yeah, sure. No, sure. So I thought. How security bugs come into play, because you have the like standard reference version that's well tested, everybody has to open it in GPL, and because the vendors don't want to, they want to have their own secret source there, and they cannot use the GPL version, they write them in constructs to do that, so they can't do all of that. And that will happen, right? If they don't, if they can't use it, excuse me, they will just write it. Well, they can just go use ARM. They don't need to use REST 5. So, use this architecture. They can go make their own, and do a tool chain, and 4T libc, and whatever it is they're going to do. Yeah, we do. I'd like to point out an error that I see just about everyone making. People talk about, because of the current boot process, because of how simple it is, because it starts out in M mode, and then does almost nothing before running a kernel in S mode, people think that the privilege level is decreasing during a boot, but no, the boot process and the privilege level are perpendicular. If you have like a net boot system which requires a rich environment, build a full network stack, in order to load the kernel, that means that your privilege stack and your boot order are simultaneously existing. You can have a machine mode, a supervisor mode, in a user mode, while you're fetching net boot resources, you can have a machine mode, a supervisor mode, a user mode. After the boot process is completed, we can and should have a chain loading mechanism that replaces all three privilege modes. We also need more restricted chain loading mechanisms, because a virtual machine is not going to have an M mode. But, the solution to what we want to be done to be able to give hardware manufacturers the option of the ability to opt out of an unmodifiable M mode, is not to sabotage the SBI, it's to have a defined procedure for handing over the keys. Giving hardware manufacturers options from a free software point of view, I think that we control much more the power than we used to, and capitulating to the requests on designs of chips that they can modify this in ways that is uninteresting, I think, to us. I don't know why we would bother even trying to help. But, otherwise it will, how the RISC-5 mass adoption will happen. So, the way- Because it's gonna be better than anything else. We hold all the power here. Here also, let's say- They can go license on them all day long and do every stupid proprietary Microsoft garbage that they do there. I think we should not hold them at all. Right now, we have enormous power as software engineers. It's almost a coup against the hardware manufacturers. We're gonna define how this works. But what if they, let's say it's a GPL, they take it and make it there, as I said, as he said, as I said. Well, you're also making the implicit assumption that the GPL- It is. Yeah, okay. We have good lawyers. I didn't understand the argument that if it's GPL, they're gonna do what? They're gonna change this. No, they're gonna write it themselves, right? I mean, is it even worth it? They're gonna write it themselves. Fine, they can do that. The thing is, if you don't expect, if you think vendors aren't gonna fork this stuff, you're not living in the world I live in, where they fork it for every damn board they build. So, one option is you could do a license it for people who want to do a license. That solved the problem in a lot of areas. What, going on for the licensing, because I don't ever, I just have one quick question. Because a bunch of others talking, we've never understood, following this discussion, why you didn't put the bindings in the FDT? Because you've defined this space with 11 bits of vendor and 16 bits, and then your idea is you're gonna probe that space, which, if I did my math right, is two to the 27th times I'm gonna call and say, do you do this? I don't understand why you wouldn't just put the bindings, in fact, in some sense, by not putting the bindings in the FDT, this ends up even looking worse than ACPI, and there's nothing worse than ACPI. You know, I just don't understand why you're not collaborating in tables, instead of asking me to call a function over and over. I know we had that discussion, but then there are other side of the people which basically wants ACPI or something, somebody mentioning we want Windows to run on risk five. So, we don't want to cut themselves out, cut them out like, so whoever doesn't use a device tree. So, I just don't get the problem here, right? I can't understand the idea that probing by doing repeated calls is better, and following on that, have you outlined what the call in the SBI are, because you're asking people to call in the SBI to do a fence, which is- That, no, that's- I recall that the SBI did do a remote fence. Okay. Yeah. Interrupting another heart to do a fence. Okay, you're right. But still, you know, we had this discussion, I was at a low risk, the last two days, when you drop into the SBI, you're gonna probably, in most cases, have to blow all the pipelines out. So, what are you looking at in terms of a cost to SBI? Have you listed that or enumerated it or? Not yet, but that's what basically, that's why we had that thing, I think you mentioned something, we should be able to replace any of the S-mode by S-mode. So, let's say tomorrow there is- The timer one, there is a architecture register, we go and replace it. So, let's say there is a better way to do the IPI or TLB flushing, we go and replace it. That's why those are, as of now, is not mandatory. Those fall under legacy. But to answer your question regarding the initial part, initial probing, the assumption is here is it's, it will all happen in early boat. So, you just query in the beginning and whatever feature you require and just store it in a bit mask or some feature of- Still think it will be- There's least one company I know that's not gonna have it. The counterpoint of what I just said is that runtime services should require to be smallest possible amount of privilege. And stuff like remote fences can and should be done entirely in S-mode. But that requires some more interfaces which are separate from the SPI. And another thing I don't see going on at all in any of this is any kind of verified boot. Any spots around verified boot and it just seems like there's no consideration of any of those issues in here at all. So, that's what I'm saying. So, all those things will at least fall into place. So, that's why we wanted to focus in the first get the best SPI so that at least we get it done and then any let's say verified boot, power management, we keep on adding it. But if we keep, like from the beginning of the discussion we keep diverging to verify boot and let's say power management, things doesn't get done. And I'm sorry, the final R use of this would be to compile. We would not use it as a .a because you gotta, I've looked at your code and you've got a lot of things that will clash with names and corgut like for example, printf. And so, it just a take home way for you. It'd be needed, and we can work with you on this. It'd be needed if you could think of ways that something like corgut would say, gosh, they've done a nice job on a lot of this actual implementation but they wanna compile it in, right? We're not gonna use it as a .a. So, that's fine. I think that's fine. That should be fine. Yeah, that's. Yeah, yeah. There are ways you could have structured things that make it hard. It doesn't look like it'll be hard for us to do it. Yes. I just wanted to get it out there. So, I think that was the initial motivation to have most permissive license that anybody can use it. But I understand the argument, but eventually you think like if we restrict it, then people will just write their own then we will not able to enforce anything with that. But at least if keep using, let's say vendors keep using OpenSBI, then at least we have a way to enforce everything. What we accept in kernel, what we accept in OpenSBI is up to the group. So. I mean, there's, we're talking about some intellectual property that some investment bank in a trivial boot loader at the beginning of code where it's all free on every single direction, there's no corporate argument here. Like whoever, I mean, we'll force that down and throw it to them. It's not that it's some vendors might have there's some secret social example for power management that they don't want to disclose but they don't want to reflect you in the background. So we're out of time. Yeah. Yeah. Okay, yeah, we can talk about it. And as he said, like, say it's risk five. So we have complete booting flow.