ACPI and Suspend/Resume under coreboot
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 | 97 | |
| 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/45678 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201097 / 97
1
2
4
5
6
8
14
15
16
17
23
29
38
41
42
44
46
47
48
50
53
54
62
63
64
65
66
71
74
75
77
78
79
80
82
84
85
94
00:00
QuicksortMultiplication signVideoconferencingOperating systemTable (information)DialectLine (geometry)Flow separationCoroutineDecision theoryRight angleBit rateFormal languageGame controllerPhysical systemComputer programmingInformationElectronic program guideTotal S.A.Mixed realityVisualization (computer graphics)Keyboard shortcutException handlingStability theoryTerm (mathematics)VotingSelf-organizationCodeProcess capability indexInterrupt <Informatik>Address spaceComputer hardwarePower (physics)Kernel (computing)Complex (psychology)Software bugElectronic mailing listRootInstallable File SystemNeuroinformatikIntrusion detection systemEmailMotherboardExpressionBytecodeBridging (networking)Slide ruleBefehlsprozessor
05:37
Event horizonControl flowCoprocessorConvex hullCASE <Informatik>InformationArithmetic meanFrequencyNeuroinformatikTable (information)Game theorySpacetimeProcess (computing)Line (geometry)State of matterBitWritingLink (knot theory)Game controllerImpulse responseVideoconferencingVirtual machineElectronic visual displayPhysical systemMultiplication signStability theoryBridging (networking)DivergenceReading (process)Functional (mathematics)Utility softwareComputer programmingSimilarity (geometry)Level (video gaming)Address spaceSlide ruleWordComputer hardwarePower (physics)Doubling the cubeComputing platformCore dumpEvent horizonBlock (periodic table)BefehlsprozessorLaptopAreaPersonal identification numberThread (computing)Device driverLatent heatType theoryMiniDiscBytecodeInformation privacyDifferent (Kate Ryan album)CoprocessorImage registrationTable
11:47
CompilerDaylight saving timeComputer animation
12:12
Daylight saving timeCompilerOperating systemTable (information)Copyright infringementSemiconductor memoryGame theoryComputer hardwareBytecodeUtility softwareComputer fileApplication service providerInformationBinary fileForm (programming)Core dumpComputer animation
14:24
BitInformationCore dumpBootingComputer animation
14:40
Physical systemInformationMultiplication signTable (information)BitRoutingLatent heatComputer animation
15:20
Electric currentDaylight saving timeCodeBitCore dumpBootingMotherboardComputer animationSource code
15:51
Address spaceMereologyTable (information)Semiconductor memoryGoodness of fitGame controllerComputer animation
16:39
MotherboardComputer animationSource code
17:04
Library (computing)State of matterProcess capability indexAreaPixelBootingCore dumpComputer hardwareWhiteboardKeyboard shortcutDescriptive statisticsLine (geometry)Operating systemWindowPhysical systemData storage deviceWeb pageEndliche ModelltheorieSource codeXML
18:31
BytecodeCore dumpInformationMathematicsBitBefehlsprozessorBootingData storage deviceObject (grammar)Line (geometry)Binary codeDifferent (Kate Ryan album)Set (mathematics)WhiteboardWeb pageDigital photographyVideo gameComputer animation
19:15
CodeRun time (program lifecycle phase)Computer programming
19:49
BitComputer fileView (database)Portable communications deviceRight angleMetropolitan area networkPoint (geometry)SpeciesData managementNeuroinformatikGradientRule of inferenceAsynchronous Transfer ModeCore dumpCache (computing)System administratorDevice driverBootingOperating systemComputer animation
21:14
BefehlsprozessorRead-only memoryOperating systemFrequencyBitType theoryComputer hardwareMessage passingComputer animation
Transcript: English(auto-generated)
00:00
regions and this resource handling is mostly done there. And of course, if you remember the slide from Peter about the interrupt routing, all this information is stored in this DSDT table. And especially this IRQ routing is stored in the PRT methods I will show in next lecture
00:26
more when I will be speaking about porting this porting cargo to a new motherboard. So I will talk more about it then. Because the ACPI is somehow trying
00:43
to be generate for the operating system. So for example, there are stored values which operating system has to write to some certain registers inside. So we will see. If you take this table and disassemble it back
01:03
to human readable form, it's around 10,000 lines. So it's quite huge. Here are some examples. So on the left, I have just taken very easy and very generic stuff like this real-time
01:23
clock. I think you were also mentioning it. So this real-time clock are on port 71. So these are defined resources. So if operating system ask device RTC0, what are your system resources?
01:40
So this method CRS gets executed, and this returns to operating system. So it starts at address 70, and it's two ports in total. And IRQ8 is used. So similar is on the other side.
02:02
It's for the TS2 keyboard. I think there is some method which is called STI, and it's just status if the keyboard is there or not. And you can see it's, let's say, touring complete language. So you have the ifs in the new specification,
02:24
or the new revision, you can add whiles, and you can program whatever you want there. So here is a big example. So you can shift left and do the conditions and return values. It's just like programming in C,
02:41
but it's by code which is stored inside your computer. So I did a little of just a listing of devices which are there. Most of the stuff is the legacy stuff.
03:00
Then what is important, there must be the PCI root bridge described, plus its resources which are decoded, other PCI bridges, or the PCI devices, PCI express devices, status, and everything. So these are just headers for the devices,
03:21
and each device has a long staff, a lot of routines around which can set up the device, put it to some certain power state, and so on. This all is because it's all necessary to hide this complexity away from the operating system to make it so generic.
03:46
Well, there is another table which is not DDSDT table, but it's also important. This table describes where are the APICs, what
04:02
addresses are for the APICs, what are the IDs of the interrupt controllers inside CPUs. And maybe you remember the picture of the legacy stuff from IRQ 0 to 16. There are some exceptions which must be handled.
04:22
I'm not sure why this information is not in the bytecode. Why is it separate table? It's like the design decisions sometimes were quite strange. So this table mostly describes what are the hardware addresses of these devices in the systems,
04:42
and how this routing here declines, how it looks like. So maybe you can see that the legacy interrupt controller is connected to pin 0, and that the timer is connected
05:05
to pin 2, and is connected to pin 0. So you need to handle this situation that this place looks strange. Maybe you have seen that the Linux kernel wrote you
05:22
MP BIOS bug IRQ 0 is not something. So this is the reason, because this table didn't describe this situation, how is it wired correctly. So in this table, it should be expressed
05:42
how the particular platform handled this situation. So because this was enough with the software, maybe a little more words about the hardware. So the ACPI defines some fixed function registers,
06:03
which has fixed layout. Usually, it's kind of double register. It's with the enable bits, and another register is with the status bits. And of course, there must be a register which
06:23
handles the sleep states of the computer. If the computer goes to suspend to RAM or to S5, so it shutdowns completely. All this stuff is defined in the specification. So there is some other hardware register,
06:42
which is located in Southbridge, which handles the C states of the CPUs. It's called PCNT. And this is used to put the CPU to the C2 and C3 states. And the last block, very general,
07:02
is the general purpose event block. It's for the waking up event. So for example, if you are the hardware designer, there must be some switch for the lid of the notebook. And this lid is connected to some line. And the pin inside the Southbridge is then routed.
07:21
And you can be seen what is the status of this line in this registrant. You can use this information to wake up the computer from sleep, for example. So if you want to know more about the hardware stuff, you can open any public data sheet.
07:44
You can use even in full documentation, AMD, so whatever. Usually, this all registers, even if the FADT table requires them on, let's say, different places.
08:00
Usually, they are stored in one block. So for example, in FADT table, here you have the status registers and the timer. The base address was 800. So this is 804 was something. Maybe you remember it from the previous slide. So here is the C state control.
08:24
So C2, C3 state is the level 2 and level 3. What is quite interesting is that the CPU then puts to sleep. And you don't write to these registers. You will read them.
08:41
So you must be very careful if you are doing some register dump of this memory area. Because if you do that, you will do the read. And if you do the read, these registers will be read, in fact. And the CPU will be put to unexpected sleep, for example. Or the machine can freeze while reading some region.
09:01
So be careful when doing some experiments like this. Because I don't know why they design it this way, that reading will cause something and not writing. So I have chosen some control register.
09:23
Here is what's important. If you, for example, write your own program to switch off the computer, all you need is to write to the sleep type register.
09:43
I think if you want to suspend it to disk or even lower state, you just need to write this magic value there. This is in Linux. It is done that these bits, or the meaning of the bits, is stored in the DSDT table.
10:02
Then the operating system, when it's running off the computer, will just take the IO port from another folder, this information from the DSDT table, and then do the power off for the system. Again, this is not done in the bytecode for some reason.
10:21
It's quite tangled together. The design is really unclear why is it this way. Here is more information about the CPU power states. I wasn't just sure if the people has the knowledge.
10:40
So just very shortly, this is the P states stuff. So the CPU thread driver is some information from a CPI to put the processor to different voltage and different frequency. It's similar for AMD and Pinterest. And as I already told, this is stored in the DSDT table.
11:08
It's some methods, as you have seen, it was there for the example of the RTC clocks.
11:21
So if you want to learn more about this kind of stuff, we can now use some utilities and to actually look to these tables now. But unfortunately, I don't have any clock device. So what's the time, please?
11:41
That's 20 minutes. Left. Yeah, OK. So it can be easily maybe a white what?
12:21
White, sorry, black on white, of course. So black, the other way around. OK. Yes.
12:41
So if you install some utilities, I think it's in ASP.util package, so you will get the ASP.dump. So let's run it. So it will generate just the memory dump of the table.
13:05
So it will go through the tables as we did in the beginning of the lecture. We have all tables and all information. And because we are humans, we want some more human readable form. There is another utility which will put it to separate files.
13:31
Now we have produced some date files, which are just the binary files. And because we want to read it, we can use the IACL from Intel to disassemble back.
13:47
So for example, the DSDP. So now we have produced the DSDP file of the DSL. And here is the DSDP table, the bytecode, which is put back.
14:03
There are some funny paths, like maybe it's there. I'm not sure if, yeah. So depending on operating system, the API bytecode is doing different things
14:22
to the hardware. So it happens. So with this utility, which is described on the slides, you can have a look on all the tables, then take the specification and have a look.
14:40
So now a bit more information about the core boot and the API. So the specification is wanting some tables that must be present in the system. So we need also to provide such tables.
15:01
What we have done is that we have taken some minimalistic DSDP table, which is mostly empty, just with the interrupt routing. So we have to provide all these tables, which are there.
15:20
Maybe at the end, if there will be more time, we can go through it a bit. So just to show you, so each motherboard in core boot has to have the API.
15:55
So yeah, just. Very good.
16:01
Yeah, so I'm not sure if you can see it. I will fix it in my next lesson. So we just construct the tables. We have some callbacks for it. So this is the main routine, which is constructing all the crowd of the tables, putting them into memory.
16:23
In this part of the code, we are filling up the addresses of the APEX and interrupt the addresses of the interrupt controllers and so on. So everything has to be filled in.
16:40
The DSDP for the main board is quite easy, I think.
17:09
Because I cannot see the last few pixels here. So it's kind of difficult. So this is what was done in the core boot.
17:22
It's not so complicated. Just to show you, here are the interrupt routing description for the operating system. And I think Windows needs to have mouse describe
17:41
and PS keyboard. So we have to add this and mouse and copy it, I think. And that's it. So we try to keep it as simple as possible. I think only place which is really for this board
18:02
is to blink with the light if the system goes through the suspend to RAM. So we go right to some register inside Southbridge to blink the light. It's done with the store line. And in wake up, we stop the blinking. So here you can see how the hardware is programmed.
18:27
So that's it. 15 minutes until end? Yeah, OK. So on this slide, here's a bit of information
18:43
about the generator for the bytecode. For the CPU P state, you need to generate this for different CPUs. So you cannot store it in your flash, because if someone
19:01
changes the CPU, you would need to recompile the core boot with some different settings, which is quite unpractical. So we are filling those PSS objects on the fly. So previously, it was done like that. Somebody binary patched the bytecode,
19:21
just changing the values. So we removed that. And we programmed a little framework, which is used for generating the ACPI packages and methods and so on. So now the code is much, much, much cleaner. So it's more easy to read it, write it, and develop
19:44
the runtime code which is needed. So now a bit about suspend and assume. So what's actually a computer doing if it goes to suspend?
20:02
So if you choose the suspend or just write a man to this special file, so Linux will execute in all drivers the suspend method. The ACPI for drivers will then run standard defined methods
20:22
from the DSDT. Then the caches get splashed, these caches. And then some value, which is in underscore S3, is written to PM1 register. And the computer will introduce me.
20:42
So from the BIOS or core boot point of view, nothing more has to be done. You can use system management mode to track this event. So you can do something else just before the computer goes to sleep.
21:01
So note the operating system is the last, which can do the write because the system management mode can catch the writes to the register and do whatever it wants. So from the hardware side, it's a bit more complicated.
21:20
So the operating system writes to the sleep type register. Then some message is generated to CPU. It's a bit similar when the frequency and voltage is changed.