 Selamat pagi, selamat datang kembali. Nama saya GameGaum. Saya adalah pembangunan pembangunan untuk kerunom dan pembangunan platform. Seperti biasa, saya mulai mengambil sponsor Microsoft Open Sousa. Gary bekerja untuk Sousa. Oracle, MySQL, Devleta dan beberapa nama lain saya tidak pasti apa-apa. Okey. Okey, so the talk by Gary Lee, who works for Sousa, is a developed UEFI with Open Sousa. In the bio-style firmware was usually obscure and always developers had to deal with it by experience. Nowadays, most of the firmware hardware vendors share the code from Open Source Project, EDK II, in their own UEFI implementations. So it's easier to understand how the firmware works, especially the hardware-independent software stack. And the EDK II contains software jack, OBMF, to provide firmware for Qmoo, the virtual machine. So we don't need band metal to implement features of the hardware-independent issues anymore. Okey, no need to flash program, just copy the file to update the firmware immediately. The talk will present how to develop and debug OBMF with Open Sousa and introduce new UEFI features in Open Sousa lead 42.2. So Gary Lee is a Sousa engineer based in Taiwan, long-time leading user, participates in Open Sousa gunung development or participator. Participator or participates? Participate. Okey, and mainly focuses on UEFI related issues now. Okey. Hello everyone and I'm Gary Lee and I work for Sousa. And I'm from the Sousa Taipei. And so I've been able, as I said, my mother will say that I've been able to work on the UEFI stack. So today I want to share with you my experience of developing what UEFI is Open Sousa as best in my daily life. So our topic today is UEFI. So what is UEFI? And it's an acronym of the unified Firmware Interface. So since that is the Firmware Interface between Firmware and our existence. And there is an organization called UEFI Forum and they were made the UEFI spec for the Firmware vendor so they can follow us back to implement Firmware. And as a Firmware vendor and we can we can just use the protocol defined by Firmware to access the hardware resource. So it's more like a easier to a unified way to access the hardware resource among the different firmware. So for the for all its vendors to look like so in the beginning we will load the UEFI from its fresh rom and UEFI will start to load the bloater and UEFI load the bloater and the bloater will load the Nines kernel and Nines kernel will start to start any other service so you can test out the server or whatever. So it looks like BIOS and starts like BIOS and smells like BIOS but it's kind of different. So what very different things from the differences from the UEFI from the BIOS is that there's an open source project called EDK2 and it's actually hosted by Intel and EDK2 is actually a basically licensed reference implementation so every time there's a new UEFI spec then they will add the new features into the IDK2 and nowadays the Firmware vendor just merge the code from EDK2 into their own firmware so maybe the UI will simply render but actually some features they actually use the same code and this is very good for us but we can just check the code in EDK2 and to know what really happened like there are some drivers it doesn't include driver maybe for hybrid driver but basically most of the things are in EDK2 but not for the driver so like your GPU driver or the Neocard driver you will not have it and some maybe the BSP for the bold so you need driver in the firmware? BSP more like the first program for the firmware for the motherboard you will need lab to put into your own EDK2 you need driver to read the hard drive and also to do a network booter? hard drive will maybe not mostly for the network driver and GPU driver so for EDK2 and it's open source project so it's very good for us we can just look into the code and know what happened not like the old BIOS days i heard old firmware assembly code so maybe even open source to you and you will not really understand so and it also it also uses a modularized design so you don't have to build everything into your firmware so you can design which part of the feature you need and just enable it and you also support the multi-core architecture so it's quite good and basically on average there will be one release every year but as i said it's an open source project so actually every day there will be a lot of patches committed into the GPU so for me i am testing the UEFI stuff and i would like to test a new feature as soon as possible so i cannot wait the firmware vendor to provide their own firmware to me too slow because they will have a long QA process and maybe after the UEFI spec maybe after a year they just provide a feature so they will be too late for us so i would need a kind of development board and the development board is a special board you can just flash the firmware and update very frequently and any version you need so they are 2 kind of solution so first is bare mental just physical machine you can buy from intel or indeed they have this kind of thing and the advantage is it's very very close to the production machine and you can add the real name of car new GPU to the machine so you can test it if you want cost of money and also you need a space for the board especially if you buy from intel it's actually an old station so you need a space for that and you cannot buy every generation so it's quite expensive and not very expensive but it's still money maybe $1,300 so you may ask for your and it also can be very slow to flash to program the flash wrong and for example like the Minopo and the SPI if you use this kind of solution you took a wrong 5 minutes you make a vice vice and very slow if you just want to add a debug message and you have to wait 5 minutes and it's not very efficient so this is the solution I choose zero cost I don't ask for my to buy anything for me so it's much easier and it's very very fast to update firmware because you just copy the file so it's very easy and you also can share your settings with your colleagues and especially it's very useful for QA because if you want to verify issue or fix verify bug and QA must know how to set the firmware and with virtual machine you can just tell him how to use virtual machine and what purchasing you are using and that's it but that's the downside if you need something very special like a special CPU or like a TPN it's not very good now and you may have some problem with the virtual machine but for me most of you are working on the software app kind of independent from the hardware so this is not a big issue for me so most of you are using virtual machine so virtual machine so what is my virtual machine solution it's a QMU plus a copy F very standard standard virtual machine nowadays everything is default and OVF is what is OVF OVF is open virtual machine firmware as an example you can see it's a firmware for the virtual machine best is it's an EDK sub-project so actually it shares the codes in the EDK 2 so it also shares the code among all those firmware so this is very good for me I can just test software stack box or software stack features with EDK 2 and with OVF and I can make sure it all works on all those firmware and this is very good now we know OVF and how can we use it so first you have to do the firmware so it's very easy just a few steps so first you chrome the source code from the Github so you can just google the EDK 2 Github and you'll find it and the next step just from the field script in OVF you can add dash D and some new options new options you have to check with me and the field script and so today because I don't have much time for this so if you are really interesting you can check it with me and so if everything goes well field script just force for me force for you and you will get two firmware files first there is an OVF code the other is an OVF bus OVF code is a compiled machine code and the bus is a very kind of special section for the UEFI UEFI you need the tool you need to store the non-monetized data in the fresh run so you need a section in the fresh run message so so the bus is how to immobilize the writeable fresh run so if you are using OpenSloser then you don't have to view it by yourself if you just want to try that you just need to install OVF that dash x8664 and I already package for you so if you want to try that and you can just download and install it it's very easy just one comment and then you will see those files in your systems so I separated the code part and the bus part as I say the bus is kind of special section UEFI has to be writeable and you will see there are some the first NS and it's for the secure boot because the secure boot you have to enroll some key into the firmware and NS is the firmware in order Microsoft key and the other OpenSloser key so I can just put the firmware and test it secure boot was for me after you install that you can try to start your own virtual machine so first you create the firmware the variable store has to be writeable originally it's in the system directory so you have to copy to somewhere you can write so you start virtual machine and you can write it to the bus store and the next you can just create a virtual UEFI system partition this status is not really necessary but I always use it because it's very convenient for testing the UEFI application you can just copy the UEFI application into the virtual UEFI system partition and the firmware can recognize it's writeable so you don't have to create it's convenient for the virtual machine to start your test and the next is to start QEMU so this command looks quite complicated but actually just to those two lines are really matters so first you have to specify the P-flash device for your code code firmware so OVM code part and the other one so you can see the code part has to be read only because it's just code so it's not supposed to be write but in 20 days or you will work and it will firmware so the other one is to specify your bus store and you can see here no read only parameter so it's writeable and readable and this one that's the line is how I create the virtual UEFI system partition so I just specify the directory as a as a fat partition so the firmware can just read the content so if you do it right then you will see screen and Tiana told logo show so you can start your work and to load your UEFI application ok so now we have virtual machine solution and the next question is how can I debug it is a very important question for me so first as C programmer you will very familiar just print the message maybe you do your like you do your C programming and add some printf or printf to print the error message and to try to identify which part is wrong and it's very the same as maybe they do it and add debug message so it's very easy to add debug message there's a markable define in EDK 2 it's called debug, very straightforward and so if you are trying to use debug and you have to specify debug label and then the format is much the same as the printf so if you are C programmer so then what is debug label it's more like it's actually a big mask for the debug message so it's defined in OVF PKG S64 this file it's actually hard hold in the firmware so you cannot change it after you build the firmware so you have to specify value in the very beginning and by default it's 0x8 0,0,0,0 4F then what it means and so like this here so it's more like you just hold all the debug labels so it means you turn on the initialization error or initialize an add message and the warning message you debug it by default you use debug info here usually I use this and actually you can turn on all the debug messages you like but I would not recommend that you can turn on by aside from the OVF to this value but I usually I would not recommend to turn everything on because it will cause your system very very very slow because it's always printing something and it's not very useful unless you are trying to debug some very difficult issues and you really need that then after you have the after you add a debug message then you can you can capture the debug message with a special command from the you can add a debug console so by default you can use you can add this command to the QEM QEM settings and usually I would redirect the error like a debug.loop this kind of file you can also redirect into like a socket or some SEDI or whatever but redirect to the file is the most convenient way for me because I can check the error message later and to make sure what happens so then after you start your after you start your virtual machine and with a debug console and you can check the debug message with another console with a tl-f debug double so I can capture the error message right away so usually you can debug this kind of debug message but sometimes you may have a crash or a serious problem and so you will need another way to catch a crash because sometimes it's crash and it's too fast so the debug message cannot be printed and so it's happened before but sometimes it's very difficult so you will need another another way to debug it and another debug is source-label debugging so actually like you debug OVNF with 3DB so if you don't 3DB and you can debug with that but it's not very easy to setup this because source-label debugging actually but it never works for me and I don't know I never heard anyone really successfully use it so basically I would suggest to download external debug from another and build it by yourself so it's quite a complicated thing and at least if you have I think this slide will be available so if you are really interesting in this thing and it helps in whichever the link later so but if you are using the OVNF and I already take you the debug package for you so you don't have to build all the things by yourself it's very easy just install the debug package and that's it so after you have a debug package and the next thing it's kind of complicated more complicated from another because you have a few steps to setup you need a few steps to setup the debug so first you have to start Qmea with the Dash S or you can use the Dash GDB and specify the TCP code 1234 those two command are actually equal so by default you can just specify Dash S then it means you open the 1234 code for debug and then you have to specify your architecture I usually use S64 so I usually specify so and then use target target remote is a GDB command to connect to a debug in the market but like a GDB server and so in this case it's more like QEMU open a GDB server for software inside the virtual machine so you have to target remote the localhost because I do it in localhost then after this command you will connect to the GDB server and you will see your virtual machine start here because it connect to the GDB server and you will start the virtual machine so after you you type continue and you start to do anything next so after you connect to the virtual machine and you have to include a special a special GDB script is a Python script and GDB can read it and next is to use the command reload the dash and this is the debug signal so it actually is not a real GDB signal start for a GDB signal so after you load the single signal start to pass all the signals in the firmware so you can connect to all the sources for the firmware and after this complicated steps you can debug your just with GDB so it's very useful you can attach GDB and produce your crash and when the crash happen you will just go to GDB and you can use GDB to see the backtrack and do whatever you want variables very useful summary for me i will recommend if you want to try the debug in the UBFI stuff and i will recommend to use virtual machine as you will zero cost development because it's free and you can modify firmware by yourself it's very useful and i will recommend to use GDB development because you can just check a local file and you will know how the firmware works and if you have a crash happen and try to attach GDB basically my suggestion so crash test