 This resource handling is mostly done there and of course if you remember the slide from FITRA 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 more when I will be speaking about porting this, porting CORBU to new motherboard so I will talk more about it then. Because the ACPI is somehow trying to be generic for the operating system, so for example there are stored values which is operate, which operating system has to write to some certain registers inside. So we will see. If you take this table and disassemble it back 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 clock I think you were also mentioning it. So this real time clock are on ports 70 and 71 so these are defined resources so if operating system asks device RTC0 what are your system resources? So this method CRS gets executed and this is returned to operating system. So it starts at address 70 and it's two ports in total and IRQ 8 is used. So similar is on the other side it's for the PH2 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 two in complete language so you have the ifs in the new specification or the new revision you can add while and you can program whatever you want there. So here is a little example so you can shift left and do the conditions and return values. It's just like programming and C but it's this byte 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 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, SATA's and everything so these are the headers for the devices and each device has a long stuff a lot of routines around which can set up the device to some certain power states and so on. This all is because it's unnecessary to hide this complexity away from the operating system to make it so generic. Well, there is another table which is not need the SDT table but it's also important this table describes where are the APICS, what addresses are for the APICS, what are the IDs of the interrupt controllers inside CPUs and maybe you remember the picture the legacy stuff is from IRQ 0 to 16 there are some exceptions which must be and 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 and how this routing here that lines 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 to pin 2 and here is connected to pin 0 so you need to handle the situation that this place looks strange maybe you have seen that the line of Skarnov wrote to you MP bios bug IRQ 0 is not something so this is the reason because this table didn't describe the situation how is it wired correctly so in this table it should be expressed how the particle platform handle the 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 which has fixed layout usually it's kind of double register one it's with the enable bits and another register is with the status bits so and of course there must be a register which handles the sleep state of the computer if the computer goes to suspend to rhyme or to S5 so it's shut down completely all this stuff is defined in the specification so there is some other hardware register which is located in Southbridge which handles the C states of the CPUs it's called CNT and this is used to put the CPU to the C2 and C3 states and the last block very general is the general purpose even 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 to inside the Southbridge is then routed 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 it's you can open any public data sheet you can use even in full documentation AMD so whatever usually it is all registers even if the FADT table requires them on let's say different places usually they are stored in one block so for example in FADT table here you have the status registers then 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 so C2, C3 state is the level 2 and level 3 what is quite interesting is that the CPU is then puts to sleep and you don't write to this register you will read that so it's quite 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 reads this 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 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 here is what is 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 I think if you want to suspend it to this or to even lower state you just need to write this magic value there this is in Linux it is done that this bits or the meaning of the bit is stored in the DSDT table then the operating system and when it's running off the computer it will just take the IO port from another information from the DSDT table and then do the do the power off for the system again this is not done in the bytecode for some reason 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 so just very shortly this is the P state stuff so the CPU drive driver is some information from ACPI to put the processor to different voltage and different frequency it's similar for AMD and Intel and as I already told this is stored in the DSDT table it's some methods as you have seen for it was there for the example of the RTC plugs so yeah 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 that's 20 minutes left yeah okay so it can be easily maybe white what white sorry black on white okay so so if you install some utilities I think it's in ACPI utility aspect so you will get the ACPI dump so let's run it so it will generate just a memory dump of the table so it will go through the tables as we did in the beginning of the lecture here are 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 now we have produced some data files which are just the binary files and because we want to read it we can use the IACL from Intel to disassemble back so for example the DSDT so now we have produced the DSDT file the DSL and here is the DSDT table the bytecode which is put back there are some funny parts like maybe there I'm not sure so depending on operating system the ACPI bytecode is doing different things to the hardware so it happens yeah 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 now a bit more information about the core boot and ACPI so as the specification is wanting some tables that must be present in the system so we need also to provide such tables what we have done is that we have taken some minimalistic DSDT table which is mostly empty just with the just with the interrupt routing so we have to provide all these tables which are there maybe at the end if there will be more time you can go through it a bit yeah so just to show you so each motherboard in core boot has to have the ACPI 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 holdbacks for it so this is the this is the main routine which is constructing all the crowd of the tables putting them into memory the in this part of the code we are filling up the addresses of the APPs and interrupt the addresses of the interrupt controllers and so on so everything has to be filled in the DSDT for the main board is quite easy I think 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 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 and PST board so we have to add this and mouse and flop it I think and that's it so we try to keep it as simple as possible I think only place which is really which is really for this board is to blink with the light if the system goes to the suspend to RAM so we will write to some register inside Southbridge to blink to blink the light it's done with the store line and in wake up we stop the blinking so here you can a bit see how the how the hardware is programmed so that's it 15 minutes until end okay so on this slide is a bit of information about the generator for the bytecode for the CPU estates you need to generate this for different CPUs so you cannot store it in your flash because if someone changes the CPU you would need to compile 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 some somebody binary patched the bytecode just change changing the values so we removed that and we programmed some little framework which is used for generating the SPI 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 the runtime code which is needed so now a bit about suspend and resume so what's actually computer doing if it goes to suspend so if you show 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 from the DSDP then the caches gets flushed the caches and then some value which is in under store S3 is written to PM1 register and the computer will enter the sweep so from the bios or core boot point of view nothing more has to be done you can use system management mode to trap this event so you can you can do something else just before the computer goes to sleep so not the operating system is the last which can do the right because the system management mode can catch the right to the register and do whatever whatever it wants so from the hardware side it's both a bit more complicated 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 you