The future of Supervisor Binary Interface(SBI)
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 561 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/44590 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Binary codeDigital signalPay televisionReduced instruction set computingField extensionBootingDataflowDemo (music)Asynchronous Transfer ModeVirtual machineThermodynamisches SystemFlow separationVideo game consoleSemiconductor memoryModel theoryFunction (mathematics)System callLatent heatComputing platformLocal GroupStreamlines, streaklines, and pathlinesImplementationParallel portExtension (kinesiology)Slide ruleLatent heatoutputGroup actionComputer programmingSystem callNumberAsynchronous Transfer ModeImplementationArithmetic progressionObject (grammar)Thermodynamisches SystemEvent horizonDirected graphInfinityFrequencyMultiplication signCASE <Informatik>SoftwareParameter (computer programming)Functional programmingProof theoryDemo (music)Limit (category theory)EmailClosed setRepository (publishing)Computing platformInternet forumDataflowLattice (order)Operator (mathematics)Model theoryWater vaporSpectrum (functional analysis)Revision controlVideo game consoleData managementView (database)Interrupt <Informatik>VotingFreezingProcess (computing)Perturbation theoryBlogVirtual machineComputerComputer fontGoodness of fitPower (physics)Electronic mailing listPoint (geometry)Open setBinary codeProjective planeMixed realityLine (geometry)Social classEnterprise architectureFunctional (mathematics)Different (Kate Ryan album)MereologyBefehlsprozessorFirmwareSemiconductor memoryFlow separationOcean currentEmulatorMathematicsClient (computing)Computer animation
08:29
Reduced instruction set computingComputing platformLocal GroupStreamlines, streaklines, and pathlinesImplementationParallel portExtension (kinesiology)IntegerData structureError messageLibrary (computing)Function (mathematics)Numbering schemeRevision controlMetreNumberLatent heatFunctional programmingData managementOvalVirtual machineTrailModel theoryOpen sourceBootingLink (knot theory)Fluid staticsAsynchronous Transfer ModeCodeFirmwareSource codeThermodynamisches SystemNumberImplementationOcean currentBitIntegerCodeFunctional programmingOpen sourceRevision controlNumbering schemeSet (mathematics)Type theoryProjective planeFunctional (mathematics)Combinational logicPower (physics)Open setComputing platformLatent heatGroup actionDifferent (Kate Ryan album)InformationExtension (kinesiology)Parallel portLibrary (computing)Online helpComputer configurationBefehlsprozessorFlow separationData managementPoint (geometry)Data structureSoftwareResultantSystem callBootingFundamental theorem of algebraCore dumpIntrusion detection systemMaxima and minimaMathematicsExistenceMereologySimilarity (geometry)Virtual machineComputer animation
16:52
Open sourceImplementationBootingFluid staticsAsynchronous Transfer ModeLibrary (computing)Link (knot theory)CodeComputing platformFirmwareSource codeLatent heatImplementationBootingLibrary (computing)Projective planeAsynchronous Transfer ModeComputer animation
17:45
Open sourceImplementationBootingLibrary (computing)Link (knot theory)Asynchronous Transfer ModeFluid staticsCodeComputing platformFirmwareSource codeEmulationComputer wormRule of inferenceBinary codeLatent heatAddress spaceHydraulic jumpLevel (video gaming)Directed setNetwork topologyModule (mathematics)Execution unitLemma (mathematics)Computer networkKernel (computing)Computer-generated imageryReduced instruction set computingModel theoryExtension (kinesiology)Standard deviationData managementUsabilityDynamic random-access memoryMathematicsBuildingCurve fittingWechselseitige InformationMoving averageComputing platformCodeFirmwareRepository (publishing)Standard deviationProcess (computing)Library (computing)Device driverKernel (computing)Address spaceBootingLipschitz-StetigkeitBinary codeOpen setObject (grammar)Different (Kate Ryan album)Hydraulic jumpComputer fileLatent heatPersonal identification numberBlock (periodic table)DataflowRoutingLevel (video gaming)Model theoryParameter (computer programming)System on a chipComputer wormOcean currentPhase transitionPeer-to-peerAsynchronous Transfer ModeMedical imagingMechanism designType theoryBefehlsprozessorSoftwarePerturbation theoryImplementationElectronic visual displayData managementGodFlow separationExtension (kinesiology)Associative propertyPower (physics)Enterprise architectureLoop (music)CurvatureDemo (music)Embedded systemFeasibility studyComplete metric spaceLattice (group)Network topologyProjective planeSimilarity (geometry)Maxima and minimaView (database)SpacetimeElectronic mailing listPattern recognitionCASE <Informatik>Sign (mathematics)WhiteboardCore dumpVideoconferencingRootStructural loadMiniDiscRobotDirection (geometry)NP-hardComputer animation
26:48
Link (knot theory)Loop (music)Charge carrierRandom numberAddress spacePhysicsDuplex (telecommunications)Boom (sailing)BootingSerial portComputing platformModel theoryUsabilityRevision controlBackupVideoconferencingBootingWhiteboardOpen setComputer wormBinary codeMedical imagingWindowServer (computing)Computer animationSource code
28:53
Maxima and minimaPhysicsComputing platformRevision controlRandom numberAddress spaceLink (knot theory)Duplex (telecommunications)Dynamic random-access memoryBootingTemplate (C++)Online helpError messageDevice driverWhiteboardRenewal theoryGodServer (computing)TouchscreenSoftwareType theoryBootingRandomizationLecture/ConferenceSource codeJSON
30:49
DampingCloud computingStructural loadComputer-generated imageryKernel (computing)Server (computing)BootingExecution unitError messagePhysicsProgrammable read-only memoryRootVideo game consoleCore dumpDevice driverLoop (music)Ultraviolet photoelectron spectroscopyComputer hardwareCommunications protocolPlastikkarteRead-only memorySpeicherschutzFluxData recoveryExt functorAsynchronous Transfer ModeSynchronizationGame controllerProcess (computing)Hybrid computerHierarchyDefault (computer science)MathematicsEnterprise architectureComputing platformInformationLocal ringVariable (mathematics)Random numberMountain passNetwork socketControl flowThermodynamisches SystemComputer multitaskingHardware-in-the-loop simulationComputer wormTable (information)Hydraulic jumpConfiguration spaceVertex (graph theory)Virtual realityService (economics)Computer fileDirectory serviceHookingData storage deviceOnline helpSystem programmingIntrusion detection systemFluid staticsStirling numberInstallable File SystemKernel (computing)Structural loadGodAddress spaceBootingMedical imagingMultiplication signTheoryDemo (music)Source code
31:40
Execution unitInsertion lossLine (geometry)Demo (music)Coma BerenicesConvex hullWhiteboardBootingPoint (geometry)Ocean currentAsynchronous Transfer ModeKernel (computing)Mechanism designImplementationOrder (biology)Virtual machineDevice driverBinary codePatch (Unix)Thermodynamisches SystemIdeal (ethics)Multiplication signSoftwareProcedural programmingComputer configurationLevel (video gaming)CountingArmLatent heatService (economics)Key (cryptography)Run time (program lifecycle phase)Computer hardwareError messageStack (abstract data type)Computer programmingLink (knot theory)Enterprise architectureWeightMereologyFreewarePower (physics)Algebraic closureChainSystem callLine (geometry)Game controllerSource codeComputer animation
38:22
Convex hullExecution unitMassPower (physics)WeightQuicksortArmSoftware engineeringComputer hardwareParameter (computer programming)Computer animationSource code
39:01
BitRun time (program lifecycle phase)Auditory maskingMultiplication signBootingForcing (mathematics)Data managementPower (physics)SpacetimeParameter (computer programming)CodeKeyboard shortcutService (economics)Core dumpProcess (computing)MathematicsSystem callWindowAsynchronous Transfer ModeWhiteboardNP-hardTable (information)Network topologyQuery languageImplementationRight angleCategory of beingRemote procedure callTerm (mathematics)DataflowDirection (geometry)Computer configurationAreaMereologyMusical ensembleComplete metric spaceEnterprise architectureGroup actionOpen setLecture/Conference
45:13
Point cloudComputer animation
Transcript: English(auto-generated)
00:05
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?
00:21
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 Ateesh, work for the Western Digital, and I'm here to talk about the
00:45
Supervisor Binary Interface that's known as SPI and describe what the future looks like for it. This is a brief agenda of today's talk. I'll briefly introduce what, just to give you an overview of what's SPI, what's the current status of it,
01:01
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 OpenSPI project. We just made it public like a couple of days ago, and we'll have a couple of cool demos for you to see.
01:21
So to start with, what exactly is SPI? So just to give you an overview, how many guys have actually walked on this kind of interface or known about SPI? Three, four, okay, that's a 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.
01:45
So anything that Machine Mode is not exposed to the S Mode, that's basically implemented via 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.
02:05
It's an M Mode. So what's the, if you have 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 SPS feature looked like. Should it have all or
02:23
it should not be exist at all. There's all kinds of spectrum. I'm pretty sure if I do a 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 SBI, it become a mini OS and then it becomes a big firmware
02:43
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-V achieve what it needs and something like any
03:02
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 SBI and then in future we can adopt the Operating Supervisor Mode OS to implement that instead of SBI. So that's where having a good specification and implementation makes sense for SBI.
03:25
So currently it's implemented by BBL and this how it works is basically it's a supervisor trap and emulate. So you basically trap into M-Mode using an E-call instruction. You pass your SBI call number in A7 registers, pass your arguments in A0 to A2
03:45
registers, and then in case of you want to return something, you return using a clobber register A0. The existing implementation is documented in one of the GitHub repository that's mentioned here.
04:01
Now here is the current interface that exists. So we have a timer call and a Y timer because currently RISC-V doesn't have a timer register that can be accessed through S-Mode which can be used to program the timer. So when you get the next, when do I get the next periodic event? That's where it comes into picture.
04:22
Then we have console and IPI. So whenever we send an interprocessor 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 like all the memory model interfaces for TLB flushing
04:40
we need to call an SBI and a 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, those are fixed. There is no present way to extend it and if even if we add it, add new functionality, we are probably going to break the backward compatibility.
05:05
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 HART or CPU HART plug
05:22
which is basically necessary and required for any kind of systems that you build today. So 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?
05:43
Defining the SBI 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 should not dump any features they want. Whatever functionality they suggest, if it is absolutely necessary, then only it should be implemented SBI without breaking
06:05
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. And we all agree that we see that there is a future where RISC-V can be the ubiquitous
06:20
ISA among all the devices. So no mandated usage should be there of let's say DT, 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. And any functionality that currently SBI has, probably we should allow it to be replaced
06:41
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 SBI call. And these are only some of the few points that define the scope. There are a lot of other discussions happening. So anything else, as this is an evolving discussion, we can keep on adding as long as it makes sense.
07:08
And we define the SBI within that scope. Now, how the specification working will progress. So as of now, it's been decided
07:21
that the specification will be part of the RISC-V UNIX class platform specification. It needs to be approved by the working group and you need to have an implementation before the freeze. Now, why the working group? Again, there is some discussion about why we are going
07:41
to a closing discussion, why it's not happening in the mailing list. Actually, it is an open discussion. 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.
08:03
But the objective of the working group to make progress on the specification continuously and finalize it within a finite amount of time. We cannot have years and years just talking about it, but not actually finalizing spec and not implementing it.
08:21
And also working group make sure that there is one reference implementation available for every SBI specification that we make or every SBI 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 managed and how the functionality should be managed.
08:43
That's it. That will be mandatory for every future SBI versions. 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 as a, again, by different people in the same working group
09:04
and then those can run in parallel based on the layouts defined by the base specifications. So let's take a look at what all is being proposed as a base specification. So calling convention, whatever the calling convention exists today,
09:23
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 whatever the SBI function returns and what the SBI library wants to return.
09:47
So those are two different things and this is the way to distinguish it and that's where RISC-V ISA came in as a help because it defines that ABI, defines that we can have two registers as a return value. Other than that, the existing calling convention which is documented in the GitHub
10:04
stands correct for the even updated proposal. So the new thing that we are going to add is worsening scheme, which is basically a major and minor, which is standard worsening scheme that everybody follows. 16 bits, minor on the last 16 bits, upper 16 bits are basically defined the major version.
10:24
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 will start with 0.2 and going forward depending on what kind of feature we're adding,
10:40
we'll keep on adding the version numbers. Now, there's a function ID that we need to define. So it's again an 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
11:03
feature that's being added. So something like, let's say legacy. Legacy is a function set. All these 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.
11:23
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
11:42
or you need to have your own function set. So that's where reserved comes into picture. You can pick any number from the reserve 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,
12:03
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, we might breaking the compatibility. So let's see if it makes sense to keep it.
12:23
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 to scope in 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 SBI version.
12:44
So something like, it's a no-brainer. We need to have a version. So SBI GET version, which returns the specification version. Then there is SBI implementation version, which is basically provided by the software that's implementing the SBI.
13:00
So something like, let's say, Open SBI provides this one. And Open SBI gets an ID, something like, let's say, 1, 2. And then there is another software, let's say, Coreboot implements SBI. So Coreboot gets 1, 3. So that helps to identify the difference, so to know that supervisor mode, which software actually
13:21
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
13:42
in a vendor ID register and MIMP CSR. And this vendor ID and MIMP helps you to identify which particular vendor-specific functions, in the future, if they have or if we have a vendor-specific API or SBI. That helps to identify which function belongs
14:02
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,
14:21
which is something like Open SBI or BBL or Coreboot. They get an implementation ID, which is fixed, let's say, 1.1, 1.2, and 1.3. And then there is implementation version, where Open SBI will have 0.1, 0.2, or 0.3, 0.3. Similarly, Coreboot might have a different version. So that's where they communicate
14:41
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.
15:02
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, we should also provide it while the discussion is going on, so that we know whether whatever we are proposing
15:21
or somebody else is proposing, what's being discussed makes sense. So currently, we have two options. BBL and Coreboot 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.
15:43
And so that becomes a pain, too, difficult to track and maintain those SBI changes. Now, we don't know who implements which version, and then how they are backward compatible. Then, BBL has been really useful and helpful until now
16:04
in bringing up all the RISC-V systems. But this is a fundamental problem in BBL, is that 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,
16:22
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
16:42
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 permission license. So you are open to take it, implement it, modify it,
17:00
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 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.
17:22
If there are a couple of others, that's still good. But at least I hope that this will prevent 10 others to fork it. A couple of others is okay. So what does it actually do? So it builds a static library that any of the SBI implementation
17:41
and any of the remote 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 its all standard GitHub process is followed.
18:00
So if you have an issue, raise it. If you have a doubt, just ask the question in the GitHub. There are a couple of pull requests and 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 object will be achieved using OpenSBI.
18:25
So first, it builds on libsbi.a, which is just an SBI implementer. It's a static library. And it just implements the SBI. That's it. Doesn't have any other feature. So any remote bootloader basically can link this SBI implementation for their SBI feature.
18:45
So this prevents forking of SBI implementation, using different SBI implementation and everybody coming up with their own. And as I said, we'll make sure that every future proposed SBI specification or extension
19:01
will be implemented in libsbi.a. And it also builds on libplat SBI.a. So libplat SBI.a is like a container that has the libsbi.a. It uses the libsbi.a to get the SBI feature.
19:21
So again, what's the difference between libsbi.a and plat SBI.a? As the name suggests, it also has the platform support. So all the platform drivers, whatever the minimal platform driver requires, that's what the plat SBI.a uses. So any of the vendors or an SOC platform support require,
19:42
let's say they already have IP blocks that are already implemented in open SBI. They'll just take this one and build their own firmware. So what all platform we have supported? We already have support for QEMU what? QEMU sci-fi view. Obviously sci-fi on list. So we have complete support for on list. And we also have can write support, which is like $20 amazing describe board,
20:05
which can run free at us, do face recognition and whatnot. So almost I can say that any SOC that's available, that's supported by open SBI currently. If not, if anybody has an SOC that we are not aware of,
20:20
please talk to us. We'll try to make sure that it's also supported using open SBI. So the last piece that open SBI builds is a firmware binary. So all this firmware binary, it's just a reference implementation to showcase how plat SBI or libSBI is used. But it also complete a platform specific bootable binary.
20:42
So you can just take it and use it for your own project. If it is a different platform, you just add your platform support and then you get your platform firmware binary completely and you just go ahead and use it. If you're existing, if you're trying to use the existing platform,
21:00
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.
21:21
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 open SBI, open SBI combines it and boots it and make sure that from open SBI it boots the next image.
21:41
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 stage to the open SBI knows how to load the next stage to the open SBI.
22:03
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,
22:23
depending on their flexibility, either way to build their 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 Karsten also mentioned saying, we need to standardize the boot flow. We need to follow what every other,
22:42
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-V. So we need to support whatever the upstream, all the boot load or support.
23:02
So this is the current boot flow. So we have ZSPL, then FSPL, 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 DTs, there is no way to separate the DT from the kernel image.
23:22
There is no way to do the network booting. That's where OpenHPI has been implemented to address all these issues. So how does the OpenHPI feature as the standard boot flow? It's the same model, just the OpenHPI replaces the BBL. But here you have the ability to create separate DT files.
23:45
And you can boot complete Linux. Full SMP support is there. And you can boot, basically you give a Linux payload to OpenHPI, and then it just boots Linux. But the upstream model that I was talking about is this one,
24:02
which I'm really excited about. Saying it's the same thing, ZSPL and FSPL. Then we have OpenHPI, 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 by a network.
24:23
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 OpenHPI. And you load the image via TFTP boot. And as of now, it can only boot one core out of the...
24:41
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 soon as we have a hard power management, we can bring up all the CPUs. It's just put in the WFI loop in OpenHPI.
25:00
So this is just a quick instruction overview. The detailed instructions, everything is available in docs and for each platform. So this is just a quick way to show you how do you build and generate the binaries. So there's basically two arguments. One is platform.
25:20
So you say whether it's a QEMU 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, QEMU bot, and then this is my Linux image path. And then this is a standard way to run QEMU disk type.
25:43
And you give the root FS file as the QEMU drive file. If you are using U-boot to load it, just say the same thing, make platform, QEMU bot. Then you give a payload path as a U-boot.bin, your U-boot binary. And then for running it, you just run QEMU with here.
26:04
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 fu540.
26:22
And your payload path as the kernel image. And for U-boot, same thing. And this is a screenshot of OpenSPI booting Linux 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 OpenSPI booting Linux using U-boot. So I have a couple of demos that I wanted to show.
26:44
Let me see if demo gods are happy with me. And if it works, otherwise, it's just a backup video. I'll show you.
27:26
You already know how do I slide the windows?
27:46
OK, I have it. So here is my TFTP boot server. And then here is the other window. OK, so here I am as the boot prompt.
28:06
So let me reboot and just show you. This is the U-boot prompt. So in a minute, you will see OpenSPI booting U-boot. And I have a preloaded image binary that basically has U-boot as the payload.
28:24
And it boots using this is the unleashed board. There's a sci-fi unleashed board we have. And you see OpenSPI and booting here U-boot. And you see OpenSPI. Hold on. OK. So now you see OpenSPI has been booting unleashed board using U-boot.
28:45
And the rest of the things, we just need to use a TFTP boot to load the image. Let's see if I can do that.
29:01
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.
29:27
OK, so all the network is set up. Oh, it's two below. Now, if you can see that screen, can you see? I don't know. I'm just typing TFTP boot U-image.
29:43
Hopefully, it will work. We'll see. Oh, I did not set the server IP. Is there a random character?
30:20
OK, I'll just type it.
30:49
Oh, it's working. So it boots. So demo gods are not that angry with me. So it loads the address with the 6-0.
31:04
So we just copy that and boot here. And let's see if it boots kernel. So ideally, it should boot Fedora 29. Oh, it boots now. So this is basically the demo that wanted to show.
31:24
So we have OpenSPI. You 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 in the prompt.
31:42
Just wanted to show you it. I'm not faking those ones. So any questions in the meantime? I can take a couple of questions until this boots. So it takes a bit of time. Not yet. So this is all standard, whatever the existing SBI. So we have not changed anything to the SBI.
32:01
Once the spec is frozen, we'll have all those implementations. And vendor ID, we don't have to assign. We just get from the mvendor ID CSR, which is already given by the specific, I think, privilege spec.
32:23
So the basically privilege spec, the manufacturer will not have ZX spec ID. Is that possible? I thought it's mandatory to have the vendor ID, no?
32:59
Any other question?
33:00
It's still booting. In the supervisor binary interface, for those of us that are new, but familiar with U-Boot, how is this applied to the unleashed board? Because I'm confused where it comes into play. I mean, we have a GPL U-Boot. Where's the S?
33:21
What's the part that's here? So SBI is implemented by the open SBI. So U-Boot doesn't have to deal with that. So U-Boot acts as a bootloader. So I think it provides runtime services. So runtime, you need to send an IPI. Runtime, you need to program the counter.
33:40
So U-Boot doesn't have to deal with any SBI implementation. It's Linux, the supervisor OS that actually needs to make those SBI calls. As of now, U-Boot don't need that. So what all we need to U-Boot is fix the network driver, support the UART driver so that we get the U-Boot prompt, and then just add the unleashed board support in U-Boot.
34:02
The patches are being upstream. So it should be available in main line. Maybe some of the control out of us.
34:48
Just a closure is, I think, you're certainly going to hear from me. Okay, yeah, sure. No, sure. So I thought...
35:53
Well, they can just go use ARM. They don't need to use RISC-V.
36:00
So use this architecture. They can go make their own and do a toolchain and port tlibc and whatever they want. Yeah, we do. I'd like to point out an error that I see just about everyone making.
36:21
People talk about, because 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 of the privilege level as decreasing during a boot. But no, the boot process and the privilege level are perpendicular.
36:44
If you have a net boot system, which requires a rich environment to build a full network stack in order to load the kernel, that means that your privilege stack and your boot order
37:00
are simultaneously existing. You can have a machine mode, a supervisor mode, and 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,
37:23
because a virtual machine is not going to have an M mode. The solution we want to be able to give hardware manufacturers the ability to opt out of an unmodifiable M mode
37:43
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,
38:01
I think that we control much more of 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.
38:21
But otherwise it will, how the RISC-V mass adoption will happen. So the way- Because it's going to be better than anything else. We hold all the power here. Here also, let's say- They can go license arm all day long and do every stupid proprietary Microsoft garbage that they do there. I think we should not hold it off. Like right now, we have enormous power
38:42
as software engineers. It's almost a coup against the hardware manufacturers. We're going to define how this works. But what if they, let's say it's a GPL, they take it and make it their property, as he said. I don't understand that argument. Well, you're also making the implicit assumption that the GPL is still enforceable in 2019. It is. Yeah, okay, but-
39:00
We have good lawyers. I didn't understand the argument that if it's GPL, they're going to do what? They're going to change it? They're going to write it themselves, right? I mean- They're going to write it themselves. I mean, they can do that. The thing is, if you don't expect, if you think vendors aren't going to fork this stuff, you're not living in the world I live in, where they fork it for every damn board they build.
39:21
So one option is you could dual license it for people who want to do a license. That solved the problem in a lot of areas. Going on for the licensing, because that'll never end. I just have one quick question. There's 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
39:41
and 16 bits. And then your idea is you're going to probe that space, which if I did my math right, is two to the 27th times I'm going to 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.
40:02
I just don't understand why you're not enumerating 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 RISC-V. So we don't want to cut them out.
40:23
Like, so whoever doesn't use a device tree. So it's just both places. I just don't get the problem here, right? I can't understand the idea that probing by doing repeated calls is better.
40:43
And following on that, if you outline what the costs of a call in the SBI are, because you're asking people to call in the SBI to do a fence, which is- No, we're calling the SBI to do a remote fence. Okay. That's interrupting another heart to do it to do a fence. Okay, you're right. But still, we had this discussion.
41:03
I was out at low risk the last two days. When you drop it in the SBI, you're going to 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? 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.
41:23
So let's say tomorrow there is the timer one. There is an 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, not mandatory. Those fall under legacy. But to answer your question regarding the initial probing,
41:43
the assumption is here is it will all happen in early boot. So you just query in the beginning and whatever feature you require, and just store it in a bit mask. Or some feature will still think it will be.
42:08
There's at least one company I know that's not going to have any. The counterpoint of what I just said is that runtime services should require the smallest possible amount of privilege.
42:20
Stuff like remote fences can and should be done entirely in S mode. That requires some more interfaces which are separate from the SBI. And another thing I don't see going on at all in any of this is any kind of verified boot. Any thoughts around verified boot. And it just seems like there's no consideration
42:41
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 and first get the base SBI 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 verified boot and let's say power management things doesn't get done.
43:02
And I'm sorry, our use of this would be to compile. We would not use it as a .a because I've looked at your code and you've got a lot of things that will clash with things in core boot like for example printf. And so it's just a take home way for you.
43:21
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 core boot would say gosh they've done a nice job on a lot of this actual implementation but they want to compile it in, right? We're not going to use it as a .a. So I think that's fine. That should be fine. Yeah, yeah, yeah. There are ways you could have structured things
43:42
that make it hard. It doesn't look like it'll be hard for us to do it. I just wanted to get it out there. So I think that was the initial motivation to have most permissible 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
44:01
then we are not able to enforce anything with that. But at least if keep using up let's say vendors keep using OpenHPI then at least we have a way to enforce everything. What we accept, what we accept in kernel, what we accept in OpenHPI is up to the group. So I mean there's, we're talking about some intellectual property
44:25
that some investment bank in 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
44:43
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 and they don't want to, like you read the data So we're out of time. Okay yeah we can talk about it
45:01
and as I said like say it's risk five so we have complete booting flow.