Hi Ayush,

Great to hear you are making progress on your application. Yeah getting OVMF running is mostly straightforward, the thing I usually forget is to pass the -debugcon parameter to Qemu in order to capture the debug messages. Happy to hear you are learning something new, in my opinion learning new things is the most important outcome of GSoC. I'd even rate it as slightly more important than the actual code produced by GSoC... though don't get me wrong the code is also important and helpful 😊.

Thanks,
Nate

Absolutely!

Can I use an Ubuntu VM?

Hi Nate,
I am working on my GSoC proposal(I am running out of time). I am also learning to debug OVMF image running on QEMU using gdb. Since the target is set to debug by default in Conf/target.txt I guess I don't need to change anything. I am referring to the OVMF documentation. Beyond BIOS is an amazing book thanks for the awesome recommendation. I will be using it to get my concepts clear. I guess in the process of learning to debug the images I will learn a lot.

Thanks,
Ayush

Hi Ayush,

I suspect the comment about Arch Linux was more to the effect that no one in the TianoCore project has really been using Arch and as you noticed getting the needed dependencies installed is somewhat painful. If you would like to use Arch we are all absolutely fine with it, but just keep in mind that you are straying from the most commonly travelled path and you might run into issues that the rest of us do not.

Thanks,
Nate

On 3/23/21, 12:04 AM, "discuss@edk2.groups.io on behalf of Ayush Dwivedi" <discuss@edk2.groups.io on behalf of 21cencturyayush@...> wrote:

I have one more question. Actually I am using Arch Linux 64 bit so finding dependencies took some time and in the documentation it says "Arch Linux is not officially supported or tested by the edk2 project at this time". Is it going to be a problem because of that?

Hi Ayush,

Great to hear you got it working! So, the next logical step would be to use a SF-600 (https://www.dediprog.com/product/SF600) to program that image you just compiled on to an Intel Tiger Lake RVP (Reference and Validation Platform) and try booting it. Unfortunately, very few Tiger Lake reference boards are in existence and they are very expensive, so we won't be able to go that far.

To address this situation, we have been adding support for other x86 boards that are easy to find and buy as we come across good ones. For example, we have support for the Up Xtreme board (https://up-shop.org/up-xtreme-series.html) in WhiskeyLakeOpenBoardPkg. There is a new version of that board coming out soon called the Up Xtreme i11 (https://up-shop.org/up-xtreme-i11-boards-series.html) that upgrades from Whiskey Lake to Tiger Lake. The problem is the starting price for that board is $400 USD. Add in the $285 for the DediProg and I don't think it would be reasonable to expect a student to spend that much money on hardware for a GSoC project. That is the nice thing about the Qemu OpenBoard project is since it is all emulation there is no expensive and special hardware needed.

So, what to do next? First of all, I recommend that you work on your GSoC application(s) of course ☺. I also recommend building OVMF, since that works in the Qemu emulator you can actually run the image you compile, read the debug messages as the firmware is booting and start to get a feel for how the boot process works. You mentioned that you were interested in learning more about how UEFI is different from BIOS. For a very detailed answer to that question, I recommend that you read "Beyond BIOS". Beyond BIOS also does a really good job of describing the boot process and the driver model and gives a good baseline knowledge for how UEFI firmware works. Hope that helps!

Thanks,
Nate

On 3/22/21, 10:04 PM, "discuss@edk2.groups.io on behalf of Ayush Dwivedi" <discuss@edk2.groups.io on behalf of 21cencturyayush@...> wrote:

Thank you Nate.
I installed edkrepo using the instructions you gave. I ran edkrepo clone min Intel-MinPlatform and it setup my workspace. Since I had already setup the EDK2 build environment and installed the dependencies(such as gcc-5) I jumped to Board Builds section and finally used python build_bios.py -p TigerlakeURvp. I chose the intel board TigerlakeURvp which was given in the list of MinPlatform supported boards. When the build was completed it yielded TIGERLAKEURVP.fd in the Build directory. I have attached one screenshot as well. What should I do next?

I have one more question. Actually I am using Arch Linux 64 bit so finding dependencies took some time and in the documentation it says "Arch Linux is not officially supported or tested by the edk2 project at this time". Is it going to be a problem because of that?

Thank you Nate.
I installed edkrepo using the instructions you gave. I ran edkrepo clone min Intel-MinPlatform and it setup my workspace. Since I had already setup the EDK2 build environment and installed the dependencies(such as gcc-5) I jumped to Board Builds section and finally used python build_bios.py -p TigerlakeURvp. I chose the intel board TigerlakeURvp which was given in the list of MinPlatform supported boards. When the build was completed it yielded TIGERLAKEURVP.fd in the Build directory. I have attached one screenshot as well. What should I do next?

Hi Ayush,



Great to meet you and welcome to the TianoCore project! Glad you hear you are interested! Sorry it has taken me a while to get back to you. I completely agree that the codebase is rather large and navigating it can be a challenge if you don’t know where to start. Let’s take a couple of steps back and talk about the architecture of UEFI system firmware in general. At a high level, there are three pieces of code needed to create a complete UEFI firmware solution: Core, Silicon, and Platform.



[UEFI Firmware Building Blocks]



While the core code (aka EDK II) has been open source for many years, historically the platform and silicon code have not been. EDK II leaves a lot of functionality to platform code and the implementation of that is largely left as an exercise for the user. Historically only a Qemu example was given in the form of OvmfPkg. The lack of open source platform code in particular has led to large amount of inconsistency between implementations and has been a hinderance to the development of open source UEFI firmware in general.



MinPlatform intends to bring more consistency to the platform code by decomposing it into smaller more reusable pieces. Under the MinPlatform Architecture, platform code is further sub-divided into MinPlatform, Advanced Features, and Board. Under the new design, both Advanced Features and MinPlatform are reusable. Only the board code remains specific to the motherboard being used. The board code provides the glue that connects the generic advanced features with the chipset being used and any motherboard specific details required.



[cid:image002.png@...]



How the silicon code is provided varies depending on the silicon vendor. Typically, silicon code is a mix of open source and closed source. We have open source silicon code from several vendors in https://github.com/tianocore/edk2-platforms/tree/master/Silicon. The closed source silicon code is provided using differing mechanisms that vary by vendor. For example, Intel provides the silicon code using FSP binaries (Firmware Support Package). AMD provides the equivalent using AGESA. ARM SoCs typically use ARM Trusted Firmware (TF-A) to provide silicon code.



To help you get an environment set up, you can try using the EdkRepo tool. I have pre-built binaries available here: https://github.com/nate-desimone/edk2-staging/releases/tag/EdkRepo-preview-2020-10-09



Installation instructions are available here: https://github.com/tianocore/edk2-edkrepo



After you have edkrepo installed, you can set up a MinPlatform development environment by running: edkrepo clone min Intel-MinPlatform



From there, you can try building one of the existing MinPlatform boards using https://github.com/tianocore/edk2-platforms/blob/master/Platform/Intel/build_bios.py Detailed build instructions are available here: https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel#windows-build-instructions



In general, the build system starts with a single DSC file which can (and often does) include several other DSC, INF, FDF files. This provides a full description of all the UEFI modules to build and any firmware volumes that need to be constructed. Every OpenBoardPkg has a *OpenBoardPkg.dsc file that provides this initial starting point for the build.



As far as skills needed, the most important one is a strong understanding and comfort with the C programming language.



Finally, given that there seems to be a large amount of interest in the QemuOpenBoardPkg task, I would recommend that anyone interested in that task write up another proposal for an alternate task that is also interesting. It seems likely that we will get more than one application for the QemuOpenBoardPkg task and we can only pick one.



Hope this helps and welcome to the project!



With Best Regards,

Nate

CC Nate

Hello everyone,
My name is Ayush Dwivedi. I am currently studying Computer Science and
Engineering and am in my 3rd year of B.Tech program. I am interested in
operating systems, firmwares and game programming. I have written some
personal projects in C and C++ programming languages and have experimented
with x86_64 assembly. Recently I have been using QEMU with the OVMF UEFI
firmware which I had built from source using edk2. I have tried to write my
own EFI applications(it was an attempt to understand how UEFI differs from
BIOS). I wish to be a part of the TianoCore community and want to
contribute. I would like to know what skills and knowledge is needed for
the task "MinPlatform Qemu Support". It is explained that we are needed to
port MinPlatform to QEMU so as of now I have started looking into the
OvmfPkg(since it already runs on QEMU) and Platform/Intel/MinPlatformPkg
but the source tree for edk2 and edk2-platform is huge so I am confused on
how and where I should start. I am looking forward to guidance from the
community.

Thank you for your precious time.

Regards,
Ayush Dwivedi