These tasks have been identified by our community. Many of these tasks would make good GSoC projects. They are currently open for development by community members, and would be a great way to get involved and start contributing. Please let us know on https://edk2.groups.io/g/devel if you plan to work on one of these tasks (to prevent duplicated effort). Also, please provide status updates on https://edk2.groups.io/g/devel so the community will know the project is still being actively developed.
Medium versus Large Projects
Skills Required
A good knowledge of the programming languages listed for each project will be required to be successful. We do not expect prior knowledge of firmware or UEFI, our mentors will help you learn those details. Having some experience finding your way around a large codebase is helpful but not required.
Current EDK II doesn’t support the dynamic linking (https://en.wikipedia.org/wiki/Dynamic_linker), which limits UEFI firmware to be split into modular components that can be distributed separately in binary and loaded only when necessary. This project is to add native dynamic library build support (PE/COFF first) and introduce a dynamic linker in edk2 core.
Add support for the Rust programming language to EDK II
More information: Tasks-Add-Rust-Support-to-EDK-II
Add support for the Go programming language to EDK II. Requires implementing a new “GOOS” target OS in the Go compiler. Bonus points if you can get this new GOOS upstreamed.
More information: TODO
Add AddressSanitizer, UBSan, and possibly MSAN support to EDK2
Build a MinPlatform Board Port for Qemu.
More information: Tasks-MinPlatform-QemuOpenBoardPkg
Build a MinPlatform board port for a new motherboard of your choice.
More information: Tasks-MinPlatform-Board-Port
Build a MinPlatform board port for the Raspberry Pi.
More information: Tasks-MinPlatform-Port-to-Raspberry-Pi
Update EDK II CI to support testing of platforms in the https://github.com/tianocore/edk2-platforms repository. The CI tests can be run in simulators or on physical HW. This task involves defining a standard interface between EDK II CI agents and remote CI agents that take as input a FW image built by an EDK II CI agent and provides pass/fail results back to the EDK II CI agent.
Currently MinPlatform does not support S3 resume, so let’s implement it! This will require implementing support for the SMM lock box, parsing of the DRAM scatter-gather list, and restore of system state. Demonstrate working S3 resume on at least one real board.
EDK II needs more unit tests… help us write them!
Add support for the https://google.github.io/googletest/ mocking framework to the EDK II https://github.com/tianocore/edk2/tree/master/UnitTestFrameworkPkg to support implementing host based tests. Also port the cmocka based unit tests to GoogleTest to test the mocking framework and provide GoogleTest examples to the rest of the EDK II Community.
Improvements to the test harness in the edk2-test staging branch. https://github.com/tianocore/edk2-staging/tree/edk2-test
Mentor: https://github.com/mdkinney, Supreeth Venkatesh
Azure pipelines CI is currently only enabled for core EDK II. Extend this by implementing Azure pipelines to test patches submitted for open source platforms hosted in edk2-platforms.
EDK II CI currently supports GCC and VS2019. Add EDK II CI tests to build using CLANG compilers for Windows and Linux.
Address all blocking issues that prevent EDK II CI agents from using Ubuntu 20.
The DXE core’s DataHub and GCD (Global Coherency Domain) layers don’t scale well as the number of data items gets large, since they are based on simple linked lists. Find better data structures.
Implement intrinsic libraries for the supported compilers for memcpy(), memset(), and 64-bit integer math operations. This improves compatibility of EDK II with standard C sources.
The first step towards an audio interface is enabling standardized support for audio output. This task means prototyping an AUDIO_OUTPUT_PROTOCOL, and implementing at least one device driver producing this protocol. The initial drivers envisioned are `virtio-sound` (for use with QEMU), `USB Audio Class`, and `HDA`. The HDA driver would additionally need to prototype an HDA_CODEC_PROTOCOL and implement it in a driver targeting a specific hardware codec.
Follow-on tasks
Implement a fully functional gdb stub for x86/x64, attaching to SourceLevelDebugPkg’s remote protocol. Expected outcome is the ability to debug GCC binaries via the software debugger attached to Qemu via an emulated serial port.
Make use of __builtin_return_address(n) & _ReturnAddress to add debug & data gathering capabilities. Some ideas:
Summary:
Create a thread safe version of the DEBUG and ASSERT trace functions. This will allow APs (CPUs other than the Boot Strap Processor (BSP)) to safely print and use DEBUG trace messages.
Create a ARM based host environment for EmulatorPkg. Expected outcome is being able to run ARM UEFI binaries on top of Linux running on an ARM system.
Port EmulatorPkg/EmuSnpDxe to support Linux. Expected outcome is being able to open TCP/IP connections from UEFI shell applications running in EmulatorPkg on top of Linux.
Note: There are many ideas here. Please feel free to gather any reasonable subset for a project proposal.
Summary:
Enable accessing content on an SMB network share. Expected outcome is being able to read data from an SMB network share via the UEFI shell. Bonus points if you implement EFI_SIMPLE_FILESYSTEM_PROTOCOL, which allows the network share to be mounted as a disk.
More information: Tasks-Network Block Device
Implement DNS proxy on EDK II. Expected outcome is being able to resolve hostnames via a tunneled DNS connection. TCP/IP utilities like ping can be used to test and demonstrate this.
A command-line based HII browser, suitable for automation. Either a shell command or set of commands for locating, dumping, and modifying configuration values, or commands for dumping and loading HII data to/from a file in an easily-edited format.
Python3 in the edk2-libc https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications/Python/Python-3.6.8 can be used to implement UEFI firmware tests. In order to increase the scope of possible tests, it would be valuable to have python modules that wrap the UEFI Boot Services, UEFI Runtime Services, and the commonly used UEFI Protocols.
Port portions of ACPI-CA to a shell application to enable dumping and disassembly of ACPI tables.
Port OpenSSH to the UEFI shell. Use the UEFI networking stack to establish TCP/IP connections to remote systems. Should be able to demonstrate working remote shell session from the UEFI shell.
Python3 in the edk2-libc https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications/Python/Python-3.6.8 supports Visual Studio builds. Update the sources and the build files to support the GCC and CLANG compilers.
Python3 in the edk2-libc https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications/Python/Python-3.6.8 supports IA32/X64. Update the sources and the build files to support AARCH64.
Port tools currently implemented in C to Python. This removes the need to run a C compiler to build the tools required to build EDK II firmware.
Implement a resource compiler in Python that can add resource sections defined by the UEFI Specification to a PE/COFF image.
Improvements to existing UEFI Driver Wizard
Simplify EDK II development:
None at the moment.